平时在折腾 AI Agent 的时候大家应该都遇到过类似的困惑明明同一个模型换一种方式组织提示词输出质量能差出一条街但按一套固定的提示词去跑又总觉得模型只是在“泛泛而谈”不够聚焦。最近我在做一个偏安全场景的项目时接触到了security-audit-skill这个概念研究了一圈之后发现它其实不属于某个具体的软件或平台而是一套把“安全审计”这件事沉淀成 AI Agent 可复用技能的完整思路。今天就把我从设计、写死到跑通的完整过程拆开聊一聊。如果你正在用 Codex、OpenCode 这类编码代理或者对“怎么把专家经验固化给 Agent 用”这件事感兴趣这篇文章应该能给你省下不少试错的成本。我会把 skill 和 agent 到底什么关系、和普通提示词有什么区别、怎么写一个能落地的安全审计 skill、以及部署和排坑这些环节都过一遍全程用我实际跑过的例子来说明。1. 先搞明白skill 到底是什么和 agent 别搞混了先说一个我从热词里反复看到的问题很多人把 skill 和 agent 当成同一个东西或者觉得 skill 就是“高级一点的提示词”。这两种理解都不太准确尤其是当你想认真做一个安全审计方向的 skill 时这个概念的偏差会直接导致设计上的跑偏。1.1 skill 的本质把“行为方式”打包进上下文简单来说skill 是一套结构化的指令、规则、脚本和参考资料的组合体它描述的是一种“应对某类任务的完整方法论”而不是一个独立运行的智能体。你看它的载体通常非常朴素一个 Markdown 文件比如SKILL.md加一堆辅助脚本或参考文档。当 agent 需要处理某项任务时会把这份 skill 的关键内容加载进自己的上下文里然后按这套方法论去执行。打个比方agent 像是一个经验丰富的“临时工”你告诉它做什么它就做什么但前提是它得知道自己该按什么流程来。skill 就像是给这个临时工的一本“作业指导书”里面有操作规范、有检查清单、有质量标准。临时工本身还是那个模型但拿到了指导书之后工作方式就从“自由发挥”变成了“按指令办事”。1.2 agent 和 skill 的分工差异一个管行动一个管方法很多资料会把 agent 描述成“能自主规划、调用工具、完成任务”的程序这没错。但如果你细看主流 agent 框架比如 Claude Code、Codex、OpenCode 等的实现方式会发现 agent 更像是一个“调度器”和一个“执行器”的结合体agent 负责理解用户目标拆解任务决定调用哪些能力skill 负责在某个特定场景下为 agent 提供“该怎么做”的细节举个例子同样是让模型去检查一个 Web 项目的安全性如果没有 skill模型可能会凭训练时的记忆泛泛地列出“SQL 注入、XSS、CSRF”这老三样。但如果挂载了一个写好的security-audit-skill它就会按照你规定的审计流程去走先看依赖清单再逐项检查认证逻辑接着核查配置项最后输出一份固定格式的报告。也就是说skill 把“做安全审计”这件事的方法论给固化了agent 要做的是加载并执行这套方法论。1.3 为什么叫 skill 而不是插件或剧本我在热词里看到有“skill插件”这种说法也有人在问“skill和agent的区别”。这类概念辨析其实挺重要因为它决定了你怎么使用它。如果把它理解成插件你可能会以为它是个独立运行的软件需要单独启动如果把它理解成剧本你可能又会觉得它只是写死的一段对话流程。实际用过之后我的感受是skill 更像是一个“微方法包”粒度比插件更小但比纯提示词更有操作性。它不负责跑服务不负责管理生命周期它只干一件事在 agent 需要的时候把最好的做法塞进模型的“脑子里”。所以你完全可以把 skill 当成活跃在 agent 生态里的一套“能力胶囊”这也是为什么现在很多 agent 框架都会原生支持 skill 机制。2. security-audit-skill 的核心思路与方案选型有了基本概念打底接下来聊聊我设计security-audit-skill时的整体思路。这套技能的目标很明确让一个通用的大模型 Agent在不需要额外微调的情况下能按专业安全审计人员的思维方式去检查代码和配置。2.1 为什么安全审计特别适合做成 skill当时我为什么要专门做这么个东西原因是安全审计这个场景对专业性和流程性的要求非常高专业性你得知道检查哪些点、用什么方式查、各种漏洞的特点和利用条件流程性审计不是东一榔头西一棒子需要按一定逻辑系统地排查可复制性同样的检查方法应该能在不同项目上重复使用这三个特点恰好是 skill 最擅长解决的问题。普通提示词无法承载复杂的判断逻辑而如果写一个全功能的 agent投入产出比又太低。用 skill 的方式来干这件事既可以把“审计方法论”独立维护又能随时适配不同的 agent 框架和模型灵活性最高。我把这个名为security-audit-skill的技能定位成一条“审计流水线”当模型面对一个待检查的项目时它不再自由发挥而是按我预设的流程一步步检查最终产出一份结构化报告。通过这种方式模型输出的专业度和一致性都有了保障。2.2 技术选型为什么用 Markdown 加脚本的轻量结构在做具体方案时我对比过三种实现思路方案优点缺点我的结论纯提示词模板简单、兼容性好信息密度低、流程容易跑偏不够用独立安全审计程序结果精确无法让模型参与分析、维护成本高过度设计skill 结构Markdown 辅助脚本兼顾方法引导和模型智能需要一定的结构设计经验选这个最后选 Markdown 加辅助脚本的方案主要是因为这类 skill 的消费方是模型而不是程序。Markdown 对模型的解析非常友好同时又具备轻量、跨平台、易维护的特点。配合少量脚本用于自动收集依赖、扫描文件就可以在保留模型分析能力的同时把一些机械性工作交给代码去完成。另外这种结构对多 agent 框架的兼容性也很好。我现在在 Codex 和 OpenCode 里都挂过同一个 skill只需要把文件夹放到对应的 skills 目录下就行不改一行代码。如果选用了自研程序迁移成本会高很多。2.3 结构设计一个可扩展的安全审计工具箱我最终把security-audit-skill的目录结构设计成这样security-audit-skill/ ├── SKILL.md ├── scripts/ │ ├── collect_deps.py │ ├── scan_configs.py │ └── summarize_report.py ├── references/ │ ├── owasp_top10_notes.md │ ├── auth_checklist.md │ └── config_review_cases.md └── examples/ └── sample_report.md核心是SKILL.md它负责告诉模型“你是一名安全审计员你要按以下方法论工作”scripts/目录里放的是辅助脚本比如自动收集依赖清单、查找敏感配置项references/放的是模型可以参考的专业笔记examples/则给它提供输出格式的样例。这个结构的好处是你把“方法论”和“工具”分离了。方法论更新时只需要改SKILL.md工具需要更新时只动scripts/两者互不干扰。我后来在维护其他方向的 skill 时也复用了这套结构实操下来非常省心。3. SKILL.md 的编写要点把专业方法论写成模型能执行的语言SKILL.md 是整个 skill 的灵魂它的质量直接决定了最终效果。很多新手在写 skill 时会陷入两个极端要么写成一本厚厚的教科书要么写得太简单跟普通提示词没有区别。这两种方式我都在security-audit-skill的开发过程中踩过坑下面拆开讲一讲。3.1 描述区让 agent 能准确识别“什么时候该用我”Skill 文件的开头通常是一个 YAML 格式的描述区它的作用是让 agent 在“技能匹配”阶段快速判断这个 skill 是否适用于当前任务。这部分虽然只占了文件很小的一块但它决定了技能能不能被正确触发。我一开始写描述时犯过一个大错只写了“用于安全审计”这几个字。结果在真实项目中当 agent 遇到“检查项目安全性”这类需求时经常不会自动调起这个 skill。后来我把描述改成了带场景和关键词的形式效果立刻就不一样了--- name: security-audit description: - Use this skill when the task involves checking code, dependencies, authentication logic, or configuration files for security issues. This includes requests like audit this project, check for vulnerabilities, is this code safe?, and any security review scenario. ---这段描述的作用是教会 agent 做“意图匹配”。它不是简单写“安全审计”而是列出了所有可能触发的用户表达让模型能更准确地判断。通俗理解这就像是在一本书的封面上写清楚“这本书适合谁读、讲了什么主题”一样agent 拿到手才能判断要不要翻开看内容。3.2 指令区把审计流程拆成可执行步骤指令区是整个 skill 的核心它会影响模型执行的逻辑。我参照专业安全审计的执行顺序将其分为“信息收集→静态分析→动态核查→总结报告”四个阶段。具体来看我在SKILL.md的指令区里按这个顺序列了清单## What to Do You are a professional application security auditor. Your job is to systematically review the provided codebase or configuration through the following process: ### Step 1: Inventory - Identify the language(s), framework(s), and package management files involved. - Run the dependency collection script to get a list of direct dependencies and, if possible, their versions. ### Step 2: Static Checks - Review authentication and authorization flows. - Look for hard-coded secrets, weak hashing algorithms, or unsafe deserialization. - Inspect database queries for injection patterns. - Check file upload and path handling logic. ### Step 3: Config Review - Inspect default/live configuration files for insecure settings (e.g., debug mode enabled, permissive CORS, missing security headers). ### Step 4: Report - Summarize findings into a structured report. - Classify each issue by severity (Critical / High / Medium / Low / Info). - For each finding, include: affected file, line or config key, why it is a problem, and a concrete remediation suggestion.为什么要把步骤写得这么细因为模型在自由状态下容易遗漏检查项。人在审计时可能会因为经验丰富而自动想到某些点但模型如果没有引导很可能只挑自己训练数据里出现最多的漏洞类型来输出。把步骤写细本质上是给模型划了一条执行路径让它每一步都走完再往下。实测下来这样写出的报告覆盖度比自由发挥要高得多。3.3 落款区明确约束与边界我发现很多人写 skill 时会忽略“落款区”但这对安全审计类 skill 尤其重要。安全审计如果让模型随意发挥它可能会给出不切实际的建议或者在你没有完整代码上下文时强行编造结论。我在SKILL.md的结尾部分加了一段“声明与边界”内容大约是## Boundaries - If you do not have access to the source files, do not guess. State clearly which parts could not be reviewed. - Report only issues you can verify or reason about from the visible evidence. - Do not attempt to exploit or verify a vulnerability by executing attack code. - All remediation suggestions must respect the projects architecture and language ecosystem.这段约束的作用是防止模型“一本正经地胡说八道”。没有这段约束时我遇到过模型毫无根据地声称某处存在 SQL 注入的情况——它只是想迎合用户的排查需求。加了边界约束之后输出的报告更接近一个真正的安全审计专家会给出的判断。4. 辅助脚本与参考资料让模型从“凭记忆”变成“有依据”SKILL.md只是“方法论”而一个好的安全审计 skill 还必须配备辅助脚本和参考资料。这部分对应到热词里“skill脚本”和“检索文献skill”的方向也是让技能具备实操性的关键。4.1 辅助脚本自动收集信息减少幻觉安全审计最怕模型凭空猜测依赖版本、配置内容、代码结构。为了减少这类问题我给 skill 配了collect_deps.py和scan_configs.py两个脚本。collect_deps.py的核心逻辑是自动识别项目的包管理文件并提取依赖列表再输出成模型容易解析的文本格式。比如检测到package.json就读取 dependencies 和 devDependencies 字段检测到requirements.txt就逐行解析包名和版本。脚本并不做漏洞库匹配它的职责仅仅是“如实告诉模型项目里装了什么”这样模型在后面的分析中就有了事实基础。#!/usr/bin/env python3 Collect dependency information for a project in a model-friendly format. import json import os import sys from pathlib import Path def collect_from_package_json(path): with open(path, r, encodingutf-8) as f: data json.load(f) deps data.get(dependencies, {}) dev_deps data.get(devDependencies, {}) return deps, dev_deps def collect_from_requirements_txt(path): deps {} with open(path, r, encodingutf-8) as f: for line in f: line line.strip() if not line or line.startswith(#) or :// in line: continue if in line: name, version line.split(, 1) deps[name.strip()] version.strip() else: deps[line] any return deps, {} def main(): root Path(sys.argv[1] if len(sys.argv) 1 else .) print( Dependency Inventory ) for path in sorted(root.rglob(package.json)): if node_modules in path.parts: continue deps, dev_deps collect_from_package_json(path) print(f\n[package.json] {path}) print(direct deps:) for name, version in deps.items(): print(f {name}: {version}) print(dev deps:) for name, version in dev_deps.items(): print(f {name}: {version}) for path in sorted(root.rglob(requirements.txt)): deps, _ collect_from_requirements_txt(path) print(f\n[requirements.txt] {path}) for name, version in deps.items(): print(f {name}: {version}) if __name__ __main__: main()这个脚本写的很简单但它对模型的作用非常大。没有这份清单时模型只能凭文件名或 import 语句去猜有了它之后整个审计过程的所有分析都有了稳定的起点。热词里有人在问“codex用的检索文献skill”这类需求其实是一样的思路给模型提供额外的检索依据让它在更充分的信息基础上做判断。4.2 参考资料把专家笔记压缩进技能包除了脚本我还准备了几个 Markdown 格式的参考资料文件。这些资料不需要面面俱到它们的作用是在模型需要的时候提供关键提示。以auth_checklist.md为例我整理了认证逻辑中常见的检查点# Auth Checklist - Password storage: Is bcrypt/scrypt/argon2 used? Plaintext or MD5/SHA1 is a finding. - Session management: Are session tokens generated with enough entropy? Are session cookies marked HttpOnly and Secure? - Password reset: Is the reset token single-use? Does it expire? - MFA: Is multi-factor authentication supported for sensitive operations? - Access control: Are object-level access checks enforced on every request? Is there a server-side authorization check beyond UI hiding?这类资料写的比较精炼每一条都是“检查点”而不是长篇大论。模型在审计时读到这些列表会像一位资深安全工程师在旁提点一样知道自己该去验证哪些项。如果你想让 skill 适配更具体的团队规范可以在 references 里增加内部安全规范文档这样模型输出的建议就会向团队标尺对齐。4.3 脚本与模型的协作边界写到这里我想特别说明一点这些脚本一定要设计成“被动调用”的模式。很多人在做辅助工具时会想着把功能做得越大越好比如直接做一个扫描器返回“有漏洞”的结论。但对 AI skill 来说这是反效果的。如果你的脚本已经能精确判断漏洞你还用模型做什么正确的关系是脚本负责提供客观事实依赖清单、配置项、可疑文件的列表模型负责专业判断某个配置是否危险、某种写法是否易受攻击、如何修复维持这个边界很重要它让模型始终处于“分析和决策”的位置而不是变成一个只会复读脚本输出的“传声筒”。我在设计scan_configs.py时也只做“发现并展示配置项”这一步绝不在脚本里写任何漏洞判断逻辑判断的事全部交给 SKILL.md 引导模型去完成。5. 部署、使用与工具链整合从“写好的 skill”到“能用的 skill”写好了 skill下一步就是把它挂到 agent 环境里跑起来。这一步看似简单但如果没有理顺部署路径和调用方式后面你会遇到不少莫名其妙的报错。5.1 安装路径不同框架都有对应的 skills 目录目前主流支持 skill 机制的 agent 框架大多采用“目录放取”的方式。以我实际用过的两个环境为例。Codex 环境它支持通过codex install skill之类的命令来安装也可以直接把 skill 文件夹放到配置文件中指定的 skills 目录下。你可以在项目根目录集中维护一个skills/目录也可以把不同项目各自的 skill 放在项目内部。我推荐把通用型 skill比如这个安全审计的放到全局目录这样跨项目都能用。# 把安全审计 skill 安装到全局 skills 目录 cd security-audit-skill codex install skill .OpenCode 环境它的 skill 目录通常位于~/.config/opencode/skills/或项目级.opencode/skills/下。安装时直接把整个security-audit-skill/文件夹复制过去即可。mkdir -p ~/.config/opencode/skills cp -r security-audit-skill ~/.config/opencode/skills/注意这里有几个容易踩的坑我逐个讲一下。坑一文件夹名必须与 SKILL.md 中的 name 一致或符合框架约定。比如我给 Codex 用的时候skill 目录名一般得对应到一个合法的标识符不能带空格和特殊字符。如果你命名不一致agent 可能加载了内容却无法正确索引到技能名称。坑二SKILL.md 必须放在 skill 文件夹根目录。有的框架要求 skill 的描述信息必须在首屏可见位置如果嵌套太深框架可能完全识别不到这个 skill。我有一次把SKILL.md放到了docs/子目录里结果整个技能在 agent 侧完全不可见排查了半天才意识到是路径问题。坑三开发完 skill 之后一定要重启 agent 进程。我用 Codex 时第一次测试写完 skill 没有重启结果在会话里怎么调用都提示找不到。这和服务器热部署完全是两码事agent 框架读取技能列表通常是在启动时做的。5.2 实际调用让 agent 正确识别并执行审计流程部署完之后的调用方式主要取决于 agent 框架的交互设计。在支持多 agent 协作的工具里你通常可以在代码提交前、构建流程或发布的环节中挂载这个安全审计任务在普通命令行场景里你只需要在会话里明确要求做一次安全审查即可。以下是使用 OpenCode 时的会话示例用户请对这个项目做一次全面的安全审计。 Agent: 我将使用 security-audit-skill 技能开展审计。 首先收集项目依赖信息然后检查核心代码和配置文件……在 Codex 里你还可以通过 AGENTS.md 文件配置自动规则比如“所有涉及数据库操作代码的变更都要先运行安全审计 skill 再提交”。这样就可以把安全审计固化到开发工作流中而不依赖人工每次手动触发。我实测下来比较推荐的一种方式是在 CI/CD 流程中加入一个“预提交安全审计”环节让 agent 在代码合并前自动调用这个 skill。这样既能利用模型的智能发现潜在风险又不增加太多人工干预成本。5.3 skill 与整体工具链的协同部署并不是终点。想让security-audit-skill真正发挥价值你还需要让它和日常使用的其他工具链配合起来。比如与代码托管平台的 PR 检查集成每次提交自动触发审计与通知系统联动发现高危问题时及时提醒与其他辅助 skill 串联先做代码分析再做安全审计热词里有人提到“springai skill agent”、“skill和agent的区别”这类问题在实际协作中体现得更明显。在一个成熟的 agent 编排系统里会有多个 skill 共同工作一个负责需求分析、一个负责编码、一个负责测试、一个负责安全审计。每个 skill 之间可以互相引用对方的输出从而形成完整的工作流。安全审计 skill 在里面扮演的是“把关人”的角色它不生产代码但它负责判断这些代码能不能安全地进入生产环境。6. 使用实战一次完整的 security-audit-skill 审计记录讲原理和部署讲了半天不如直接看一次真实的执行记录。下面是我在一个 Node.js 示例项目上跑security-audit-skill的过程项目里故意埋了几个典型问题。6.1 审计准备与信息收集我先把 skill 安装好然后在项目根目录执行会话指令。agent 第一步会加载 SKILL.md并按照定义先运行collect_deps.py。下面是我在项目里的执行记录$ python scripts/collect_deps.py . Dependency Inventory [package.json] ./package.json direct deps: express: ^4.17.1 mysql2: ^2.3.3 jsonwebtoken: ^8.5.1 dev deps: nodemon: ^2.0.15这个步骤的价值在于模型接下来会基于这份依赖清单去思考“这些组件的已知风险点有哪些”。比如express4.x 版本较老mysql22.3.3 也存在版本偏旧的问题模型就会在后面的审计中重点核查这些依赖是否引用了不安全的写法。6.2 静态审计发现与推理拿到依赖清单后agent 调起scan_configs.py扫描配置文件同时开始审查关键代码文件。我准备了一个带有典型问题的代码片段agent 的审计路径大致是这样推进的发现config.js中设置了debug: true结合依赖版本分析判定这是生产环境遗留的调试配置在routes/login.js中看到密码校验用的是crypto.createHash(md5)得出弱哈希算法的结论在db.js中发现 SQL 语句使用字符串拼接而不是参数化查询判定存在注入风险这些判断不是模型凭空想出来的它是在SKILL.md的 Step 1-3 引导下逐个检查点排查后得到的结果。相比之下我之前用普通提示词让模型做同样的检查时它只输出了“存在 SQL 注入和弱加密”没有指出debug: true这种配置问题。6.3 报告生成与输出Agent 按照 SKILL.md 中定义的格式输出了结构化报告。报告中包含严重程度分级、受影响文件、具体问题描述和修复建议。我截取报告的主要结构方便你参考# Security Audit Report Date: 2025-xx-xx Scope: node-sample-project ## Findings ### [High] SQL Injection in db.js - File: db.js, line 22 - Detail: User input is concatenated into a SQL query string. This allows an attacker to manipulate the query logic. - Remediation: Use parameterized queries (e.g., connection.execute() with ? placeholders) instead of string concatenation. ### [Medium] Weak Password Hashing in routes/login.js - File: routes/login.js, line 45 - Detail: MD5 is used for password hashing, which is considered cryptographically broken. - Remediation: Migrate to bcrypt or argon2 with a per-user salt. ### [Low] Debug Mode Enabled in config.js - File: config.js, line 5 - Detail: debug: true exposes stack traces and internal error details in production responses. - Remediation: Set debug: false in production, or better, load this value from an environment variable.看到这个过程你应该能理解为什么我要强调“流程化”了。安全审计是一个系统性的排查过程靠模型自由发挥很容易漏项而一旦把专业方法论固化到 skill 里模型就能像一个有经验的安全工程师一样按步骤检查、推理、输出。整个过程既保存了模型的灵活性又提升了输出的规范和完整性。7. 常见问题与排查技巧实录最后这部分我整理了在实际使用security-audit-skill和编写各种 skill 过程中遇到的高频问题。很多问题光看文档是发现不了的都是在实际跑的时候才会冒出来。7.1 skill 没有被加载或识别这是我遇到最多的问题查了半天发现自己犯了一个低级的错误——SKILL.md里的name字段用了驼峰命名而目录名用了小写加连字符导致框架在初始化时匹配不上。排查清单可能原因检查方法解决办法SKILL.md 不在根目录查看 skill 文件夹结构把文件移到根目录name 和目录名不一致检查 YAML 中的 name 字段统一命名风格小写加连字符框架缓存未刷新重启 agent 进程强制重启后再试路径配置错误查看 agent 配置文件中的 skills 路径修正为实际路径7.2 模型忽略 skill 中的步骤仍然自由发挥这个问题相对隐蔽。有时明明已经把 SKILL.md 写好、部署也正确但模型还是会跳过步骤直接给结论。通过几次试验我总结出了一套行之有效的优化方法。原因一SKILL.md 的指令太笼统。比如只写“check for common vulnerabilities”模型无法从中获得行为约束。后来我改成“Step 1: 收集信息Step 2: 执行静态检查Step 3: 输出报告”每一步还附上具体要检查什么模型的遵从度立刻提升。原因二模型上下文不够长或任务过长。当审计任务涉及多个文件时模型可能会为了节省 token 而跳过一些步骤。我的解决办法是在 SKILL.md 中明确要求“Do not skip any step”并且在最终报告中必须包含所有步骤的对应输出字段。如果模型觉得信息不足它至少会显式声明“未能核实某项”而不是假装查过。7.3 模型输出的修复建议与项目实际环境不匹配安全审计技能生成报告之后你有时会发现建议方案并不适配当前项目的实际生态。比如它建议一个 Python 项目使用某个 Java 生态的安全库。究其原因是模型把训练数据中的通用经验直接套用过来了没有结合项目技术和语言上下文。我的解决方式是在 SKILL.md 的“Boundaries”部分明确要求“All remediation suggestions must respect the projects architecture and language ecosystem”同时在第一步的信息收集中就让模型获取语言和框架信息。这两点合在一起可以让模型的建议更具针对性。7.4 Skill 文件过大导致 agent 上下文溢出Skill 写得过于详细虽然能保证专业性但也可能导致SKILL.md太大。当 agent 为节省上下文而截断内容时模型执行效果反而下降。我的实践经验是把核心的方法论写在SKILL.md里保证它短小精悍把大段的代码示例、内部规范、详细案例放到references/目录让模型按需查阅。这样可以让核心驱动保持轻量同时保留足够的参考信息。这一思路在“ppt skill”“会议纪要 skill”“科研论文 skill”等非技术场景同样适用——核心指令要精简深层资料要沉淀。8. 写在最后把重复性专业工作交给 skill最近身边越来越多人在聊“codex skill”“opencode skill”“agent skill”我能感觉到 AI Agent 的应用方式正在发生一次范式转移。以前我们习惯于写提示词后来学着搭 agent 流程现在大家开始意识到真正专业的东西是需要以“技能包”的形式沉淀下来的。security-audit-skill只是我在安全领域的一次尝试但它反映的方法论适用于任何领域——把你最拿手的专业经验梳理成一套模型能理解的流程然后让它在你不在场的时候也能按标准执行。我个人在实际操作中最大的体会是skill 设计最关键的并不是写多复杂的代码而是想清楚你要模型遇到什么样的任务、按什么思路去思考、参考哪些信息、输出什么结果。只要这四个问题理清楚了skill 的结构和内容自然就能定下来。后面如果你也想为自己手头的工作流做一个专属 skill建议先从最常见的场景入手把你平时反复给人解释的那套经验先文字化再结构化成SKILL.md文件。等你试用顺手之后可能会发现原来 AI 能干好的事情比我们想象的要多得多。