最近这个词在圈子里出现的频率越来越高尤其是做 AI 开发、AI 工作流的人几乎都在聊同一个东西怎么让 AI 助手不再每次对话都“从零开始”而是像老员工一样一上来就知道该用哪套流程、哪些模板、哪些工具。说白了就是要给 AI 配一套可复用的“技能包”。我结合自己折腾了几个月的编程、写作、数据整理场景把 Skills 的核心逻辑、目录设计、编写方法和踩坑记录系统梳理了一遍。这篇文章适合三类人一是用 AI 辅助编程和写文档的开发者二是想搭建个人知识工作流的效率型玩家三是团队里负责沉淀 AI 使用规范的人。看完你就能照着搭出第一个能真正干活儿的技能包而不是又一个躺在 GitHub 里的空目录。1. 为什么 Skills 正在变成 AI 工作流里最重要的一层1.1 从 Prompt 到持久化技能先说一个最直观的变化。以前我们跟 AI 协作靠的是 Prompt也就是每次对话时把需求、背景、约束全部重新交代一遍。但问题很明显同一类任务下次还得重新写一遍不同的人写出来的 Prompt 质量参差不齐团队里积累的 Prompt 散落在各个聊天记录里没有人愿意维护。Skills 解决的就是“知识能不能沉淀下来、流程能不能复用”这个问题。它本质上是一组结构化的文件包含说明、步骤、模板、示例和脚本放在项目的固定目录里AI 在需要的时候自动加载并按照这套文件去执行。你可以把它理解成“岗位说明书 标准作业程序 工具箱”三合一的东西。这个思路之所以重要是因为大模型本身的能力已经足够强真正的瓶颈变成了“怎么让模型稳定地按正确方式做事”。Prompt 是一次性的口头交代Skills 是写成文档的工作流程。前者靠临场发挥后者靠体系支撑。打个比方Prompt 像你临时叫外卖每次都得重新告诉店家口味偏好Skills 像你提前在 App 里存好了常用订单点一下就是你要的那份。另外Skills 还有一个容易被忽视的价值——它让“经验”变成了可审查、可测试、可版本管理的对象。以前团队里某个同事特别会用 AI他的技巧只存在于他的脑袋里现在这些技巧被写成技能文件之后任何人打开仓库都能看到 AI 是怎么被引导的甚至能指出里面哪一步有问题。这才是它真正值钱的地方。1.2 一个典型的 Skills 目录长什么样按目前比较通行的做法一个项目的 skills 目录大概长这样skills/ ├── code-review/ │ ├── SKILL.md # 技能主文件目标、流程、规则 │ ├── checklist.md # 审查清单 │ ├── examples/ │ │ ├── good-review.md # 一份高质量的审查示例 │ │ └── bad-review.md # 一份有问题的审查示例避免踩坑 │ └── scripts/ │ └── extract_diff.py # 辅助提取代码变更的小工具 ├── meeting-notes/ │ ├── SKILL.md # 会议纪要技能 │ └── templates/ │ └── weekly-report.md # 周报模板 └── README.md # 技能索引告诉 AI 有哪些技能、何时用SKILL.md 是核心其他文件都是配套资源。这个目录结构本身就在传达一个信息技能不只是“一段提示词”而是一套包含参考材料和执行工具的完整资产。我见过不少人的技能包目录乱成一锅粥所有文件平铺在根目录下AI 加载的时候根本分不清哪个是主文件、哪个是参考材料。所以从一开始就建议确立一条硬规则每个技能一个独立文件夹主文件统一叫 SKILL.md配套资源按用途分 subdirectory。这样 AI 扫描目录的时候能快速定位人维护的时候也一目了然。2. 一套可落地的 Skills 设计方法2.1 命名与目录结构命名是第一关。一个好的技能名要满足三个条件一看就懂、对应明确的触发场景、不容易和别的技能混淆。比如code-review比review好weekly-report-generator比report好。命名时不建议用过于诗意的词汇AI 的语义理解虽然不差但在技能名这种短文本上还是直白词更可靠。目录结构建议遵循“一技能一目录”的原则每个技能目录下至少要有SKILL.md技能定义描述用途、适用场景、执行步骤、质量要求可选资源文件模板、示例、脚本、数据字典一个简短的 example 或 test 文件写给 AI 看的“演示样本”这里特别说一下示例文件的价值。我在刚接触 Skills 时总觉得“只要 SKILL.md 写得够详细就够了”后来实测发现完全不是这么回事。大模型是概率模型它对“抽象描述”的遵循程度远低于对“具体范例”的模仿程度。你给它一套精心设计的流程步骤它可能执行得七零八落你给它一份完整的输入输出对它反而能举一反三。这也是为什么我后面会反复强调示例的重要性。2.2 SKILL.md 怎么组织SKILL.md 的核心目标是在保证内容精炼的同时把 AI 需要的上下文说清楚。根据我试过多个方案后的经验推荐按下面几个小节来组织# 技能名称 ## description 这个技能在什么时候使用什么时候不要使用。用 1-3 句话说清楚。 ## steps 执行步骤尽量细化到可操作的程度。每一步用祈使句。 ## rules 约束和边界。例如不要修改测试文件不要在回答中放无关代码必须引用原始来源。 ## inputs 需要哪些输入格式是什么。 ## outputs 输出应该长什么样最好附一个典型输出结构。这里有个特别重要的原则也是我反复跟朋友强调的SKILL.md 是写给 AI 看的但更要让人能读懂。因为技能文件会被反复维护如果只有机器能看懂过两周你自己回来改的时候就会非常痛苦。我在后面会写一个反面教材说的就是这个问题。2.3 参考材料和模板怎么放很多人一开始只写 SKILL.md完全不考虑配套文件。但实际用下来配套文件的价值往往比主文件更高。原因很简单光靠文字描述模型很容易发挥不稳定一旦给它一个“标准答案”作为参考输出质量立刻上一个台阶。我的做法是每个技能都放 1 到 2 个高质量示例示例要覆盖“典型场景”和“边界场景”两种情况。拿周报技能来举例示例里既要有一份正常节奏的周报也要有一份“这周进度缓慢但必须写得体面”的周报。前者教模型套路后者教模型分寸。这种细节往往才是决定输出质量差距的关键。模板文件同样重要。模板不是摆设它会直接影响 AI 的输出结构。模板本身要写得“足够空”空到只保留结构框架又要“足够满”满到包含注释说明每个字段该怎么填。举例# 周报模板 ## 本周进展 !-- 列出 3-5 条具体成果每条包含做了什么、结果如何 -- - 事项一... - 事项二... ## 风险与阻塞 !-- 如果没有风险写“无”不要留空 -- - 风险一... ## 下周计划 !-- 按优先级排序最多 5 条 -- 1. ...模板里的注释非常重要因为 AI 会把它当作填写指引。你也可以在模板头部直接写一行“请严格按照此模板填写不要增减章节”实测下来约束力比在 SKILL.md 里写十条规则都强。2.4 一个反面教材过度抽象的 SKILL.md我之前给一个文档整理技能写过一版 SKILL.md通篇用词高大上。比如“深入理解用户意图”“采用系统化思维”“综合考量多方因素”结果实际跑下来输出极其空泛每句话都对但没有一句有信息量。后来我把这些抽象表述全部替换成具体规则比如“理解用户意图”改成“输出前先用自己的话复述一遍需求确认无误再动手”“系统化思维”改成“按时间线、按责任人、按状态三列输出”。这个改动带来的效果是立竿见影的。原因在于大模型对“动词 方向”的理解力远不如对“名词 结构”的理解力。你给它一堆形容词它只能回你更华丽的形容词你给它具体的名词和结构它才能给你具体的产出。3. 从零搭建一个自己的技能包以代码审查为例讲了这么多理论不如直接走一遍实操。我拿代码审查code review这个技能来说这是我认为最适合入门 Skills 的场景因为它的边界清晰、产出明确、容易验证。3.1 需求拆解动手之前先想清楚这个技能要解决什么问题。我的需求很具体每次提交代码合并请求之前让 AI 帮我检查是否存在明显的逻辑错误、安全漏洞和代码风格问题并且输出一份可以留给开发者的评审意见。拆解之后这个技能需要四样东西明确的输入代码 diff 或者文件路径明确的执行步骤先读 diff再定位上下文再逐项检查明确的质量标准哪些问题必须报哪些问题是可选的优化建议明确的输出格式问题清单 严重程度 修改建议这四个要素在 SKILL.md 里必须全部体现缺一个都会导致输出不可用。比如没有质量标准AI 会把“变量名不够优雅”和“存在 SQL 注入风险”并列报出来——不是不行但轻重缓急完全没体现。3.2 编写 SKILL.md我最终落定的 SKILL.md 大概是这样的# Code Review Skill ## description 对指定的代码变更进行审查。适用于合并请求提交前或提交后的代码检查。 不要用于需要大范围架构重设计的场景、纯 UI 调整场景。 ## steps 1. 读取用户提供的 diff 内容或根据文件路径定位变更。 2. 提取变更涉及的核心逻辑先用 2-3 句话概括这段代码在做什么。 3. 按优先级逐项检查 - 潜在 bug空指针、边界条件、并发问题、资源未释放。 - 安全问题输入校验、SQL 拼接、敏感信息硬编码。 - 可维护性重复代码、过长函数、命名是否表意。 4. 输出审查结果。 ## rules - 每个问题必须标注所在文件和大致行号。 - 严重程度分级critical / warning / suggestion分级要有依据不得滥用 critical。 - 给修改建议时要给出具体代码示例禁止只说“建议优化”。 - 如果 diff 中不存在安全问题明确写“未发现明显安全问题”不得编造问题。 ## inputs - 代码 diff 文本或 Git 仓库路径 提交范围。 ## outputs - 一段代码变更概述。 - 问题清单按严重程度排序。 - 修改建议附带示例代码。写完 SKILL.md 之后我顺手在 examples 目录里放了一份“标准输出示例”让模型模仿那种结构。这一步非常重要——模型在执行时的输出结构往往会往示例上靠有示例和没示例的稳定性差距非常明显。3.3 配套脚本与校验代码审查技能还有一个常见痛点AI 经常拿不到完整的上下文。直接贴 diff 的情况还好但如果要审查整个 PRdiff 可能几百个文件模型根本处理不过来。我的解法是写一个简单脚本extract_diff.py用 GitPython 把指定提交范围内的 diff 提取出来按文件类型过滤只保留src和tests目录下的 Python 文件并且输出成纯文本。这样喂给模型的数据量可控审查效率也更高。import subprocess import sys def extract_diff(base, head): cmd [git, diff, base, head, --, src/, tests/] result subprocess.run(cmd, capture_outputTrue, textTrue) if result.returncode ! 0: print(git diff failed:, result.stderr, filesys.stderr) sys.exit(1) return result.stdout if __name__ __main__: if len(sys.argv) ! 3: print(usage: extract_diff.py base-branch head-branch) sys.exit(1) diff extract_diff(sys.argv[1], sys.argv[2]) print(ftotal diff chars: {len(diff)}) print(diff[:20000])脚本本身不复杂但它解决了一个实际问题不看完整上下文就审查AI 很容易“神评论”。我试过直接把一个 300 行的 diff 硬塞给模型它确实能看但大部分注意力都花在无关的格式变动上真正关键的逻辑漏洞反而漏掉了。用脚本做过滤之后审查质量明显提升。3.4 实测效果记录我连续用这个技能审查了 10 个合并请求记录了每次的表现编号发现真实问题数误报数漏报情况输出可用性121未发现关键漏报直接可用212无明显漏报需要裁剪330无明显漏报直接可用403有但属轻微问题参考价值低521无明显漏报直接可用614无明显漏报过滤后可用720无明显漏报直接可用832无明显漏报需要裁剪911无明显漏报直接可用1020无明显漏报直接可用整体来看10 次里有 5 次输出可以直接用3 次需要稍微裁剪1 次误报偏多1 次基本没有参考价值。对于一个完全由文本文件定义的“数字员工”来说这个稳定性已经很能打了。如果你觉得还不够可以从两个方向改进一是继续增加不同场景的示例二是把容易误报的检查项移出必查清单改成只在特定条件下触发。4. 常见问题与排查技巧实录4.1 技能根本不被触发这是最常见的坑。你明明把技能文件写好了但 AI 就是不按照里面的内容执行。我排查下来原因大概率出在 description 写得不够明确。比如你写“这个技能用于代码审查”AI 会在对话中反复判断“当前任务算不算代码审查”稍有歧义就跳过。更好的做法是把触发条件写得非常具体甚至可以用“当用户提到合并请求、pull request、code review、diff 等关键词时优先调用本技能”这种写法。另外有些 AI 工具要求技能文件里的元信息格式完全正确比如name字段必须和目录名一致存在不一致时技能会被静默忽略。遇到技能没生效第一步就去核对描述格式和命名。4.2 技能之间互相冲突当技能数量超过 5 个之后冲突问题就开始出现了。最典型的是“周报生成”和“会议纪要整理”两个技能它们都需要处理开会信息都要求输出结构化文本AI 偶尔会把两者的格式混在一起。解决思路有两个。第一个是给每个技能加上明确的“不适用场景”例如在周报技能的 description 里写清楚“此技能不用于整理会议纪要本身的逐字摘要”。第二个是设计一个简单的优先级机制在 README.md 索引文件里注明“如果多个技能同时匹配优先使用 XXX”。我实测下来这两个手段叠加之后冲突率能从三成降到一成以下。核心是让 AI 有足够的判断依据而不是靠它随机发挥。4.3 技能文件越改越臃肿技能用久了很容易被人往里不断加规则。今天加一条“不要写 too long”明天加一条“记得检查拼写”最后 SKILL.md 变成了上千行的“弹药库”。但实际效果是规则越多模型越无所适从重要规则反而被稀释了。我的经验是一份 SKILL.md 的核心规则控制在 10 条以内超过这个数就开始做减法。而且每加一条规则都要在示例文件里同步加一个对应的演示否则这条规则大概率不会被遵守。规则和示例是一一对应的关系这条经验我从一开始就记在备忘录里也确实帮我避免了很多兼容性灾难。4.4 输出风格不稳定同一个技能每次跑出来的风格都不一样时好时坏。这个问题通常可以通过固定输出模板解决。我在 SKILL.md 里直接放一个空模板要求 AI 按模板的字段顺序输出效果非常明显。模板里甚至可以连标点符号使用方式都规定好比如“所有列表中不得使用分号”“每个条目必须用句号结尾”。这些看起来细枝末节但对输出的专业观感影响很大。5. 几类高性价比的 Skills 搭建场景5.1 写作与总结类这是最容易上手的场景也最适合个人使用。拿周报来说我曾经花了一下午搭建了一个“周报生成”技能定义了输入格式这周做了什么事、卡在哪里、模板和风格约束。之后每次写周报只需要把自己零散的笔记喂进去AI 按模板展开我再润色一遍就能提交。这类技能还有个好处它是“内容安全”的因为输出只依赖你提供的原料不会突然冒出脱离上下文的内容。而且写作类技能的迭代周期特别短看到哪里不满意改一行模板就能立即验证效果。5.2 代码工程类代码审查是我最推荐入门的场景因为结果容易验证——AI 报出的问题到底是真是假翻开代码看几眼就知道。其他值得做的包括自动生成提交信息、自动补全测试用例、按项目规范检查代码格式等。代码类技能要注意一点工具脚本的调用要慎重。如果技能里包含脚本执行必须明确脚本的运行环境和失败处理否则脚本一旦报错整个技能就卡死了。我在 3.3 的脚本里就加了明确的错误退出逻辑这是过程中必须养成的习惯。5.3 数据整理与报告类这类技能适合有一定模板需求但重复性强的场景比如从导出的 CSV 里分析用户反馈、把零散的项目进展整理成幻灯片大纲、把会议录音转写稿压缩成行动清单。搭建这类技能时最重要的工作是定义好“输入格式的容错范围”。因为数据文件往往脏得很模型需要知道字段缺失时该怎么处理。我的做法是在 SKILL.md 里加一条规则“遇到缺失字段时在输出中明确标注’数据缺失’不要自行推断填写。”这句话能避免一大堆假数据污染决策。5.4 个人知识管理工作流最后说一下把 Skills 和个人知识库结合的方式。我现在有一个skills/knowledge-base/技能包职责是把我丢进某个目录的零散笔记整理成带标签、带互链的知识条目。运行起来之后它相当于一个自动化的“信息管理员”帮我把输入材料按统一标准归档。这个场景的另一个好处是它让“技能包”本身变成了知识沉淀的一部分。你不需要额外维护一套“怎么用 AI”的文档——技能文件就是文档代码就是模板示例就是最佳实践。对整个知识管理流程来说这是一种相当自然的闭环。6. 维护技能包的一些长期心得技能包不是建完就完事的它和代码仓库一样需要持续维护和迭代。我现在每个季度会做一次全面的技能复查重点看三件事哪些技能已经没用了、哪些技能可以用但输出质量下滑了、哪些技能之间的边界需要重新划分。我个人的体会是Skills 最迷人之处不在于“写一个超强提示词让 AI 惊艳一次”而在于把 AI 的使用经验变成一个可以用版本控制、可以做代码评审、可以被多人共同改进的工程系统。以前我们积累的是 Prompt 碎片现在积累的是结构化的、可复用的“组织记忆”。最后再分享一个小技巧每当你在对话里发现某段 Prompt 特别好用、特别稳定不要只把它留在聊天记录里趁热打铁把它落成一个技能文件的雏形。哪怕一开始只有 description 和两行步骤也足够了——后续用的时候再慢慢补全。真正的技能高手不是写出来的而是在一次次的实战迭代中磨出来的。
AI Skills实战：从Prompt到可复用技能包，打造高效AI工作流
最近这个词在圈子里出现的频率越来越高尤其是做 AI 开发、AI 工作流的人几乎都在聊同一个东西怎么让 AI 助手不再每次对话都“从零开始”而是像老员工一样一上来就知道该用哪套流程、哪些模板、哪些工具。说白了就是要给 AI 配一套可复用的“技能包”。我结合自己折腾了几个月的编程、写作、数据整理场景把 Skills 的核心逻辑、目录设计、编写方法和踩坑记录系统梳理了一遍。这篇文章适合三类人一是用 AI 辅助编程和写文档的开发者二是想搭建个人知识工作流的效率型玩家三是团队里负责沉淀 AI 使用规范的人。看完你就能照着搭出第一个能真正干活儿的技能包而不是又一个躺在 GitHub 里的空目录。1. 为什么 Skills 正在变成 AI 工作流里最重要的一层1.1 从 Prompt 到持久化技能先说一个最直观的变化。以前我们跟 AI 协作靠的是 Prompt也就是每次对话时把需求、背景、约束全部重新交代一遍。但问题很明显同一类任务下次还得重新写一遍不同的人写出来的 Prompt 质量参差不齐团队里积累的 Prompt 散落在各个聊天记录里没有人愿意维护。Skills 解决的就是“知识能不能沉淀下来、流程能不能复用”这个问题。它本质上是一组结构化的文件包含说明、步骤、模板、示例和脚本放在项目的固定目录里AI 在需要的时候自动加载并按照这套文件去执行。你可以把它理解成“岗位说明书 标准作业程序 工具箱”三合一的东西。这个思路之所以重要是因为大模型本身的能力已经足够强真正的瓶颈变成了“怎么让模型稳定地按正确方式做事”。Prompt 是一次性的口头交代Skills 是写成文档的工作流程。前者靠临场发挥后者靠体系支撑。打个比方Prompt 像你临时叫外卖每次都得重新告诉店家口味偏好Skills 像你提前在 App 里存好了常用订单点一下就是你要的那份。另外Skills 还有一个容易被忽视的价值——它让“经验”变成了可审查、可测试、可版本管理的对象。以前团队里某个同事特别会用 AI他的技巧只存在于他的脑袋里现在这些技巧被写成技能文件之后任何人打开仓库都能看到 AI 是怎么被引导的甚至能指出里面哪一步有问题。这才是它真正值钱的地方。1.2 一个典型的 Skills 目录长什么样按目前比较通行的做法一个项目的 skills 目录大概长这样skills/ ├── code-review/ │ ├── SKILL.md # 技能主文件目标、流程、规则 │ ├── checklist.md # 审查清单 │ ├── examples/ │ │ ├── good-review.md # 一份高质量的审查示例 │ │ └── bad-review.md # 一份有问题的审查示例避免踩坑 │ └── scripts/ │ └── extract_diff.py # 辅助提取代码变更的小工具 ├── meeting-notes/ │ ├── SKILL.md # 会议纪要技能 │ └── templates/ │ └── weekly-report.md # 周报模板 └── README.md # 技能索引告诉 AI 有哪些技能、何时用SKILL.md 是核心其他文件都是配套资源。这个目录结构本身就在传达一个信息技能不只是“一段提示词”而是一套包含参考材料和执行工具的完整资产。我见过不少人的技能包目录乱成一锅粥所有文件平铺在根目录下AI 加载的时候根本分不清哪个是主文件、哪个是参考材料。所以从一开始就建议确立一条硬规则每个技能一个独立文件夹主文件统一叫 SKILL.md配套资源按用途分 subdirectory。这样 AI 扫描目录的时候能快速定位人维护的时候也一目了然。2. 一套可落地的 Skills 设计方法2.1 命名与目录结构命名是第一关。一个好的技能名要满足三个条件一看就懂、对应明确的触发场景、不容易和别的技能混淆。比如code-review比review好weekly-report-generator比report好。命名时不建议用过于诗意的词汇AI 的语义理解虽然不差但在技能名这种短文本上还是直白词更可靠。目录结构建议遵循“一技能一目录”的原则每个技能目录下至少要有SKILL.md技能定义描述用途、适用场景、执行步骤、质量要求可选资源文件模板、示例、脚本、数据字典一个简短的 example 或 test 文件写给 AI 看的“演示样本”这里特别说一下示例文件的价值。我在刚接触 Skills 时总觉得“只要 SKILL.md 写得够详细就够了”后来实测发现完全不是这么回事。大模型是概率模型它对“抽象描述”的遵循程度远低于对“具体范例”的模仿程度。你给它一套精心设计的流程步骤它可能执行得七零八落你给它一份完整的输入输出对它反而能举一反三。这也是为什么我后面会反复强调示例的重要性。2.2 SKILL.md 怎么组织SKILL.md 的核心目标是在保证内容精炼的同时把 AI 需要的上下文说清楚。根据我试过多个方案后的经验推荐按下面几个小节来组织# 技能名称 ## description 这个技能在什么时候使用什么时候不要使用。用 1-3 句话说清楚。 ## steps 执行步骤尽量细化到可操作的程度。每一步用祈使句。 ## rules 约束和边界。例如不要修改测试文件不要在回答中放无关代码必须引用原始来源。 ## inputs 需要哪些输入格式是什么。 ## outputs 输出应该长什么样最好附一个典型输出结构。这里有个特别重要的原则也是我反复跟朋友强调的SKILL.md 是写给 AI 看的但更要让人能读懂。因为技能文件会被反复维护如果只有机器能看懂过两周你自己回来改的时候就会非常痛苦。我在后面会写一个反面教材说的就是这个问题。2.3 参考材料和模板怎么放很多人一开始只写 SKILL.md完全不考虑配套文件。但实际用下来配套文件的价值往往比主文件更高。原因很简单光靠文字描述模型很容易发挥不稳定一旦给它一个“标准答案”作为参考输出质量立刻上一个台阶。我的做法是每个技能都放 1 到 2 个高质量示例示例要覆盖“典型场景”和“边界场景”两种情况。拿周报技能来举例示例里既要有一份正常节奏的周报也要有一份“这周进度缓慢但必须写得体面”的周报。前者教模型套路后者教模型分寸。这种细节往往才是决定输出质量差距的关键。模板文件同样重要。模板不是摆设它会直接影响 AI 的输出结构。模板本身要写得“足够空”空到只保留结构框架又要“足够满”满到包含注释说明每个字段该怎么填。举例# 周报模板 ## 本周进展 !-- 列出 3-5 条具体成果每条包含做了什么、结果如何 -- - 事项一... - 事项二... ## 风险与阻塞 !-- 如果没有风险写“无”不要留空 -- - 风险一... ## 下周计划 !-- 按优先级排序最多 5 条 -- 1. ...模板里的注释非常重要因为 AI 会把它当作填写指引。你也可以在模板头部直接写一行“请严格按照此模板填写不要增减章节”实测下来约束力比在 SKILL.md 里写十条规则都强。2.4 一个反面教材过度抽象的 SKILL.md我之前给一个文档整理技能写过一版 SKILL.md通篇用词高大上。比如“深入理解用户意图”“采用系统化思维”“综合考量多方因素”结果实际跑下来输出极其空泛每句话都对但没有一句有信息量。后来我把这些抽象表述全部替换成具体规则比如“理解用户意图”改成“输出前先用自己的话复述一遍需求确认无误再动手”“系统化思维”改成“按时间线、按责任人、按状态三列输出”。这个改动带来的效果是立竿见影的。原因在于大模型对“动词 方向”的理解力远不如对“名词 结构”的理解力。你给它一堆形容词它只能回你更华丽的形容词你给它具体的名词和结构它才能给你具体的产出。3. 从零搭建一个自己的技能包以代码审查为例讲了这么多理论不如直接走一遍实操。我拿代码审查code review这个技能来说这是我认为最适合入门 Skills 的场景因为它的边界清晰、产出明确、容易验证。3.1 需求拆解动手之前先想清楚这个技能要解决什么问题。我的需求很具体每次提交代码合并请求之前让 AI 帮我检查是否存在明显的逻辑错误、安全漏洞和代码风格问题并且输出一份可以留给开发者的评审意见。拆解之后这个技能需要四样东西明确的输入代码 diff 或者文件路径明确的执行步骤先读 diff再定位上下文再逐项检查明确的质量标准哪些问题必须报哪些问题是可选的优化建议明确的输出格式问题清单 严重程度 修改建议这四个要素在 SKILL.md 里必须全部体现缺一个都会导致输出不可用。比如没有质量标准AI 会把“变量名不够优雅”和“存在 SQL 注入风险”并列报出来——不是不行但轻重缓急完全没体现。3.2 编写 SKILL.md我最终落定的 SKILL.md 大概是这样的# Code Review Skill ## description 对指定的代码变更进行审查。适用于合并请求提交前或提交后的代码检查。 不要用于需要大范围架构重设计的场景、纯 UI 调整场景。 ## steps 1. 读取用户提供的 diff 内容或根据文件路径定位变更。 2. 提取变更涉及的核心逻辑先用 2-3 句话概括这段代码在做什么。 3. 按优先级逐项检查 - 潜在 bug空指针、边界条件、并发问题、资源未释放。 - 安全问题输入校验、SQL 拼接、敏感信息硬编码。 - 可维护性重复代码、过长函数、命名是否表意。 4. 输出审查结果。 ## rules - 每个问题必须标注所在文件和大致行号。 - 严重程度分级critical / warning / suggestion分级要有依据不得滥用 critical。 - 给修改建议时要给出具体代码示例禁止只说“建议优化”。 - 如果 diff 中不存在安全问题明确写“未发现明显安全问题”不得编造问题。 ## inputs - 代码 diff 文本或 Git 仓库路径 提交范围。 ## outputs - 一段代码变更概述。 - 问题清单按严重程度排序。 - 修改建议附带示例代码。写完 SKILL.md 之后我顺手在 examples 目录里放了一份“标准输出示例”让模型模仿那种结构。这一步非常重要——模型在执行时的输出结构往往会往示例上靠有示例和没示例的稳定性差距非常明显。3.3 配套脚本与校验代码审查技能还有一个常见痛点AI 经常拿不到完整的上下文。直接贴 diff 的情况还好但如果要审查整个 PRdiff 可能几百个文件模型根本处理不过来。我的解法是写一个简单脚本extract_diff.py用 GitPython 把指定提交范围内的 diff 提取出来按文件类型过滤只保留src和tests目录下的 Python 文件并且输出成纯文本。这样喂给模型的数据量可控审查效率也更高。import subprocess import sys def extract_diff(base, head): cmd [git, diff, base, head, --, src/, tests/] result subprocess.run(cmd, capture_outputTrue, textTrue) if result.returncode ! 0: print(git diff failed:, result.stderr, filesys.stderr) sys.exit(1) return result.stdout if __name__ __main__: if len(sys.argv) ! 3: print(usage: extract_diff.py base-branch head-branch) sys.exit(1) diff extract_diff(sys.argv[1], sys.argv[2]) print(ftotal diff chars: {len(diff)}) print(diff[:20000])脚本本身不复杂但它解决了一个实际问题不看完整上下文就审查AI 很容易“神评论”。我试过直接把一个 300 行的 diff 硬塞给模型它确实能看但大部分注意力都花在无关的格式变动上真正关键的逻辑漏洞反而漏掉了。用脚本做过滤之后审查质量明显提升。3.4 实测效果记录我连续用这个技能审查了 10 个合并请求记录了每次的表现编号发现真实问题数误报数漏报情况输出可用性121未发现关键漏报直接可用212无明显漏报需要裁剪330无明显漏报直接可用403有但属轻微问题参考价值低521无明显漏报直接可用614无明显漏报过滤后可用720无明显漏报直接可用832无明显漏报需要裁剪911无明显漏报直接可用1020无明显漏报直接可用整体来看10 次里有 5 次输出可以直接用3 次需要稍微裁剪1 次误报偏多1 次基本没有参考价值。对于一个完全由文本文件定义的“数字员工”来说这个稳定性已经很能打了。如果你觉得还不够可以从两个方向改进一是继续增加不同场景的示例二是把容易误报的检查项移出必查清单改成只在特定条件下触发。4. 常见问题与排查技巧实录4.1 技能根本不被触发这是最常见的坑。你明明把技能文件写好了但 AI 就是不按照里面的内容执行。我排查下来原因大概率出在 description 写得不够明确。比如你写“这个技能用于代码审查”AI 会在对话中反复判断“当前任务算不算代码审查”稍有歧义就跳过。更好的做法是把触发条件写得非常具体甚至可以用“当用户提到合并请求、pull request、code review、diff 等关键词时优先调用本技能”这种写法。另外有些 AI 工具要求技能文件里的元信息格式完全正确比如name字段必须和目录名一致存在不一致时技能会被静默忽略。遇到技能没生效第一步就去核对描述格式和命名。4.2 技能之间互相冲突当技能数量超过 5 个之后冲突问题就开始出现了。最典型的是“周报生成”和“会议纪要整理”两个技能它们都需要处理开会信息都要求输出结构化文本AI 偶尔会把两者的格式混在一起。解决思路有两个。第一个是给每个技能加上明确的“不适用场景”例如在周报技能的 description 里写清楚“此技能不用于整理会议纪要本身的逐字摘要”。第二个是设计一个简单的优先级机制在 README.md 索引文件里注明“如果多个技能同时匹配优先使用 XXX”。我实测下来这两个手段叠加之后冲突率能从三成降到一成以下。核心是让 AI 有足够的判断依据而不是靠它随机发挥。4.3 技能文件越改越臃肿技能用久了很容易被人往里不断加规则。今天加一条“不要写 too long”明天加一条“记得检查拼写”最后 SKILL.md 变成了上千行的“弹药库”。但实际效果是规则越多模型越无所适从重要规则反而被稀释了。我的经验是一份 SKILL.md 的核心规则控制在 10 条以内超过这个数就开始做减法。而且每加一条规则都要在示例文件里同步加一个对应的演示否则这条规则大概率不会被遵守。规则和示例是一一对应的关系这条经验我从一开始就记在备忘录里也确实帮我避免了很多兼容性灾难。4.4 输出风格不稳定同一个技能每次跑出来的风格都不一样时好时坏。这个问题通常可以通过固定输出模板解决。我在 SKILL.md 里直接放一个空模板要求 AI 按模板的字段顺序输出效果非常明显。模板里甚至可以连标点符号使用方式都规定好比如“所有列表中不得使用分号”“每个条目必须用句号结尾”。这些看起来细枝末节但对输出的专业观感影响很大。5. 几类高性价比的 Skills 搭建场景5.1 写作与总结类这是最容易上手的场景也最适合个人使用。拿周报来说我曾经花了一下午搭建了一个“周报生成”技能定义了输入格式这周做了什么事、卡在哪里、模板和风格约束。之后每次写周报只需要把自己零散的笔记喂进去AI 按模板展开我再润色一遍就能提交。这类技能还有个好处它是“内容安全”的因为输出只依赖你提供的原料不会突然冒出脱离上下文的内容。而且写作类技能的迭代周期特别短看到哪里不满意改一行模板就能立即验证效果。5.2 代码工程类代码审查是我最推荐入门的场景因为结果容易验证——AI 报出的问题到底是真是假翻开代码看几眼就知道。其他值得做的包括自动生成提交信息、自动补全测试用例、按项目规范检查代码格式等。代码类技能要注意一点工具脚本的调用要慎重。如果技能里包含脚本执行必须明确脚本的运行环境和失败处理否则脚本一旦报错整个技能就卡死了。我在 3.3 的脚本里就加了明确的错误退出逻辑这是过程中必须养成的习惯。5.3 数据整理与报告类这类技能适合有一定模板需求但重复性强的场景比如从导出的 CSV 里分析用户反馈、把零散的项目进展整理成幻灯片大纲、把会议录音转写稿压缩成行动清单。搭建这类技能时最重要的工作是定义好“输入格式的容错范围”。因为数据文件往往脏得很模型需要知道字段缺失时该怎么处理。我的做法是在 SKILL.md 里加一条规则“遇到缺失字段时在输出中明确标注’数据缺失’不要自行推断填写。”这句话能避免一大堆假数据污染决策。5.4 个人知识管理工作流最后说一下把 Skills 和个人知识库结合的方式。我现在有一个skills/knowledge-base/技能包职责是把我丢进某个目录的零散笔记整理成带标签、带互链的知识条目。运行起来之后它相当于一个自动化的“信息管理员”帮我把输入材料按统一标准归档。这个场景的另一个好处是它让“技能包”本身变成了知识沉淀的一部分。你不需要额外维护一套“怎么用 AI”的文档——技能文件就是文档代码就是模板示例就是最佳实践。对整个知识管理流程来说这是一种相当自然的闭环。6. 维护技能包的一些长期心得技能包不是建完就完事的它和代码仓库一样需要持续维护和迭代。我现在每个季度会做一次全面的技能复查重点看三件事哪些技能已经没用了、哪些技能可以用但输出质量下滑了、哪些技能之间的边界需要重新划分。我个人的体会是Skills 最迷人之处不在于“写一个超强提示词让 AI 惊艳一次”而在于把 AI 的使用经验变成一个可以用版本控制、可以做代码评审、可以被多人共同改进的工程系统。以前我们积累的是 Prompt 碎片现在积累的是结构化的、可复用的“组织记忆”。最后再分享一个小技巧每当你在对话里发现某段 Prompt 特别好用、特别稳定不要只把它留在聊天记录里趁热打铁把它落成一个技能文件的雏形。哪怕一开始只有 description 和两行步骤也足够了——后续用的时候再慢慢补全。真正的技能高手不是写出来的而是在一次次的实战迭代中磨出来的。
