前段时间好几个朋友问我同一个问题大家都在说“skills”它到底是个什么东西一开始我以为这就是把常用的prompt模板化、封装成可复用的小工具真上手折腾之后发现事情远不止这么简单。Skills背后是一套让AI从“聊天机器”变成“干活专家”的机制它重新组织了模型调用的方式、知识注入的方式、甚至工作流的执行方式。这篇文章我打算把自己从零接触、踩坑、再到搭建出自己一套Skills的完整经验记录下来聊聊它解决什么问题、核心怎么设计、实际怎么落地希望能给正在用AI辅助编程、或者想认真提升AI工作流效率的同行一些参考。1. 先想明白Skills到底解决了什么问题1.1 一个让人崩溃的Prompt现场先说我记忆里非常典型的一次失败经历。当时我想让AI帮我审一份外包开发的采购合同我把合同PDF转成文字丢进对话框然后写了一大段提示词“请帮我审查这份合同重点关注交付标准、付款条件、违约责任要有法律依据输出中文报告。”听起来没什么问题对不对结果AI给我输出的东西怎么看怎么像通用鸡汤。它把“注意验收标准”“付款节点要清晰”“违约条款尽量完整”这些正确但毫无用处的废话翻来覆去地讲真正针对合同条文的具体风险点一个没提更没有告诉我哪一条应该在签约前找对方确认修改。问题出在哪出在它确实拥有“合同审查”这个常识但根本不知道我所在的这类业务里什么样的条款属于高危雷区什么样的付款方式必须坚决拒绝什么叫做一份真的有参考价值的审查报告。它缺的不是能力是专家经验。后来我把公司内部沉淀的几十条审查清单、过去项目踩过的坑、供应商常用的谈判话术都整理成一个文档在每次提问时贴进去再让AI分析效果立竿见影。但新的问题又来了那段资料越来越多从几十行变成几百行每次对话都要重新粘贴而且粘贴的位置、顺序稍不一样AI输出的稳定度就会波动。这就是Skills出现的核心背景把散落在对话里的知识、规则和流程固化成可以被反复调用的独立技能单元。1.2 传统Prompt的两大软肋顺着前面的故事往下看传统Prompt模式有两个很难绕开的软肋。第一个是知识无法持久化。Prompt本质上是一次性的“口述指令”所有背景知识、行业经验、输出要求都必须在对话开始时临时塞进上下文。今天你粘贴进去的资料明天换一个会话就归零了。长此以往每个人都在反复做同一件事——把自己已经整理过的专业内容再粘贴一遍效率极低。第二个软肋是输出的稳定性完全靠运气。同一个任务上午问和下午问措辞稍微改一下AI给出的答案结构可能就差很远更不要说多人协作时每个人写Prompt的口味不一样产出的内容格式五花八门后续修改成本直线上升。Skills在这个背景下出现解决的就是这两件事一是让知识沉淀下来、触手可及二是把“怎么做一件事”的完整套路固定成标准流程让AI每次调用都能稳定输出接近专家水准的结果。用一句简单的话概括Prompt是“这次帮我做这件事”Skills是“以后每次遇到这类事都按这套专业流程来做”。1.3 Skills的实质把专家经验打包成可执行单元那Skills到底长什么样以现在主流AI编程助手和Agent框架的做法来看一个Skills通常是一个独立目录里面包含技能说明文档、参考资料、脚本和模板等文件。这个目录被放在约定好的位置当用户在对话中明确要求“使用某某技能做某件事”时AI会自动读取目录里的技能描述加载对应知识和执行流程然后按照预设步骤完成任务。我把它理解为Skills就是给AI安装了一个“专业岗位说明书”。岗位说明书里写清楚了这个岗位的职责边界、工作步骤、检查标准和验收规范。AI读完说明书后做起事来就不再是自由发挥而是有章法地按规程走。这种从“prompt自由发挥”到“skill规范作业”的转变本质上就是把人的专家经验结构化成机器可执行的程序这是它和普通提示词最根本的区别。2. Skills的核心设计思路与构成要素2.1 一个好技能应该包含哪四层内容搞清楚Skills解决了什么我们再来看它内部是怎么组织的。目前相对成熟的Skills结构基本可以拆成四层触发规则、场景知识、执行流程、输出规范。触发规则解决的是“什么时候该用这个技能”场景知识解决的是“做这件事需要知道哪些专业背景”执行流程解决的是“按什么顺序一步步做”输出规范解决的是“最后交出来的东西长什么样”。这四层缺了任何一层技能都会显得不太对劲。先说触发规则。触发规则是AI判断“该不该调用这个技能”的依据也是很多人容易忽视的一层。在Skill的说明文件里你要明确写清楚这个技能适用于什么场景、不适用于什么场景甚至给出典型输入示例。否则就会出现你希望它用“合同审查”技能的时候它以为你在闲聊或者你只是问一句“今天天气不错”它却莫名其妙把合同审查流程跑了一遍。2.2 触发规则怎么写才不会翻车写触发规则有一个关键经验优先级和边界比触发词本身更重要。我早期犯过的错误是把触发词写得特别宽泛比如“当用户提到合同时使用合同审查技能”。结果用户说“我这周末有个合同要签帮我提醒一下”AI也傻乎乎去调用审查流程了。这就是边界没划清楚的典型问题。后来我改成“当用户提供合同条文、协议正文或需求描述明确要求进行风险审查、条款分析、意见输出时使用本技能如果只是询问合同相关的泛泛问题或没有提供具体文本不要使用本技能”。这样AI遇到模棱两可的输入时至少知道该往哪个方向收敛。特别注意一点触发规则里尽量不要堆砌大量同义词因为大模型对语义的理解已经足够好真正重要的是让它理解“这个场景的核心目标是什么”。2.3 场景知识技能的专业功底所在场景知识是整个Skills的核心价值。这部分通常放在references目录下可以是行业术语表、常见隐患清单、过往项目复盘笔记、成功案例分析、法规摘要。要注意的是这些知识文件不是把网上的资料往下一丢就完事而是需要做“知识蒸馏”的。举个例子如果你要做一个“SQL优化技能”直接丢进100篇数据库文档是没用的。你要做的是把高频出现的性能瓶颈、常用的索引设计经验、以及“先用EXPLAIN看执行计划再动手”这类实操判断方法提炼出来整理成简洁、可检索的条目。我在实践中发现知识文件尽量用表格和短段落来表达少写废话因为AI在读取时对条目化内容的敏感度明显更高。真正的专家经验往往藏在那些“非标准”的内容里比如“当WHERE条件字段存在隐式类型转换时索引会失效”这种大家容易忽略的细节把它写进去技能的价值一下就出来了。2.4 执行流程与输出规范执行流程层就是告诉AI“这件事要分几个步骤每步做到什么程度”。以技术方案评审为例一个完整的评审流程可能包括需求还原、架构合理性检查、性能与安全评估、可维护性审查、风险清单输出。每一步都要写清楚检查重点和需要产出的中间结果避免AI跳步或自己在某一步上过度发挥。输出规范直接决定了最终成品的可用程度。同样一份方案评审没有输出规范的AI可能只给你两百字的“看着还行”而定义了模板之后它会输出一个包含总评分、分维度得分、问题清单、严重级别、修改建议逐条对应的完整评审报告。所以我建议每个技能都要内置输出模板甚至可以提供示例报告作为Few-shot参考让AI照着葫芦画瓢。3. 从零搭建一个“技术方案评审Skills”的完整实操3.1 定义场景边界与输入输出纸上谈兵扯了这么多来一个真实案例。我最近在公司内部搭了一套“技术方案评审”技能这里把它完整拆给大家看。第一步是定义场景边界使用场景是研发同学提交技术方案文档后由AI按照团队标准进行预评审不适用场景是需求讨论、代码审查、项目管理等非技术评审类任务。输入是技术方案文本输出是结构化的评审报告。定好边界以后我会在技能目录下新建一个用来说明技能信息的SKILL.md文件里面写清楚技能名称、适用场景、触发条件以及使用步骤。这一步是AI理解技能的第一入口一定要写得准确、克制。我简单列一下SKILL.md的骨架供参考--- name: tech-design-review description: 对技术方案文档进行结构化预评审输出包含整体评估、架构合理性、性能与安全风险、可维护性建议的评审报告。 triggers: - 用户提供技术方案文档或详细需求描述并要求进行方案评审、技术评审、设计评审时。 - 用户询问方案的可行性、潜在风险、架构改进建议时。 not_trigger: - 用户只是讨论需求功能没有提供具体技术方案文本。 steps: - 1. 提取方案的整体目标、功能范围、技术选型和架构图描述。 - 2. 从功能完整性、扩展性、一致性三个维度评估架构设计。 - 3. 排查性能瓶颈、单点故障、数据安全、权限控制方面的隐患。 - 4. 评估代码结构的可维护性、依赖关系的清晰度、演进成本。 - 5. 汇总风险清单并给出优先级排序。 - 6. 输出最终评审报告。 output_format: | # 技术方案评审报告 ## 整体结论 ## 分维度评分功能/性能/安全/可维护性 ## 风险清单按严重级别排序 ## 改进建议逐条对应 ## 通过条件是否满足这样一个文件AI读到就会明白这个技能是干什么用的、什么情况触发、做事的先后顺序、最终要产出什么。但仅有这个文件还不够还需要把团队内部的检查经验注入进去。3.2 注入团队知识让技能“懂行”我用一到两天的零碎时间把团队过去评审中最常出问题的点整理成了一个references/checklist.md文件。里面全是具体条目比如技术选型是否引入团队无人熟悉的新框架如果引入了是否有备选方案和回退计划数据库表设计是否考虑数据量在千万级时的查询效率索引设计是否覆盖高频查询场景缓存使用是否明确Key的过期策略和缓存击穿、雪崩的应对方式接口设计是否做了幂等处理超时和重试机制是否合理上下游依赖是否有降级预案依赖故障时主链路能否做熔断隔离日志规范是否支持问题追踪关键路径是否有traceId贯穿这些东西在教科书里全有但每一条都是团队踩坑踩出来的。把它们结构化写进技能里AI评审时的“经验水平”就直接从应届生跳到了老工程师。3.3 给技能写脚本自动生成评分矩阵除了知识和流程Skills通常还允许放一些辅助脚本。我写了一个非常简单的Python脚本用来根据风险数量自动生成评分矩阵它的作用是把评审报告中的风险点映射为功能、性能、安全、可维护性四个维度的得分避免AI在打分时凭感觉走。def compute_scores(risks): # risks: [{dimension: performance, level: high}, ...] base {function: 90, performance: 90, security: 90, maintainability: 90} penalty {high: 20, medium: 10, low: 5} for risk in risks: dim risk[dimension] level risk[level] base[dim] max(0, base[dim] - penalty.get(level, 5)) return base risks [ {dimension: performance, level: high}, {dimension: security, level: medium}, ] print(compute_scores(risks))脚本的价值在于把“评分”这件本身容易主观的事情变成了一套可校验的确定性规则。AI在输出风险清单后可以直接调用这个脚本算分而不是自己拍脑袋定个85分。分数背后有明确的扣分依据评审的公正性会好很多。3.4 实际调用效果对比搭完技能之后我做了一次对照测试。用同一份微服务拆分方案分别走“直接让AI评审”和“调用技术方案评审技能”两条路径。直接评审时AI输出的是泛泛而谈的小作文指出了服务拆分要关注数据一致性、调用链变长会增加延迟但完全没有提到团队最关心的权限模型设计。而走技能路径时AI先根据SKILL.md的步骤梳理架构图再对照checklist逐条排查给出的报告里明确标记出“当前方案缺少限流降级策略流量高峰时核心服务存在雪崩风险”、“交易流水表未设计按月分表一年后单表数据量预计达到亿级写入性能将明显恶化”等具体条目。这就是Skills的威力它不改变大模型的基本能力也不给AI加一个“外接大脑”它做的是把组织里的隐性知识变成一套可以被反复调用的标准动作。知道什么场景该查什么查到了该怎么定性最后该输出什么样的结论每一步都有章法。3.5 几个决定成败的操作细节再补充几个实操中容易被忽略的细节。第一SKILL.md文件里的描述一定要亲测迭代不要指望一遍写好。我前后改了七八版才让AI在绝大多数场景下做出正确的触发判断。第二references里的知识文件命名要清晰最好按用途区分比如checklist.md、examples.md、glossary.md这样AI能更快定位。第三技能目录文件名不要用中文和空格尽量用短横线连接的英文命名兼容性更好。第四建议给技能准备至少一个示例输入和示例输出文件作为Few-shot参考AI的表现会更加稳定。4. 常见问题与排障技巧实录4.1 技能不触发问题出在哪这是新手遇到最多的问题我一开始也差点被逼疯。技能文件写得好好的但实际对话时AI完全无视它。逐层排查后发现绝大多数原因出在描述文件里的“触发条件”写得太窄或太含糊。比如只写“当用户要求评审时触发”AI理解的是“必须有‘评审’这个动词出现”但用户实际说得可能是“帮我看下这个方案有没有坑”“这版设计能上线吗”。所以触发描述不能只依赖关键词应该把用户可能的意图描述完整最好给出一到两个典型的触发示例句。还有一种情况是技能文件本身没有被正确加载。不同平台对技能目录的命名和放置位置有严格要求不是放在任意路径都能被识别。我建议搭建初期先用最简单、最标准的目录结构来测试确认技能被正常加载后再逐步增加复杂功能否则很容易出现“文件改了但没生效”的诡异问题。4.2 多个技能互相“打架”当技能多起来以后冲突就出现了。我同时装了技术方案评审、接口设计审查、数据库设计审查三个技能它们的场景高度重叠。经常出现用户只是想评一下数据库表设计AI却把技术方案评审和接口设计审查的流程都串进来跑了一遍输出的报告结构混乱完全没法用。解决这个问题有两种思路。一是给每个技能划分更明确的适用边界在触发规则里写明“本技能覆盖数据库设计相关内容技术方案层面的内容交由tech-design-review技能处理”。二是主动在对话中指定技能名称AI就会以指定的技能为主不再自己风扇式选择。我的经验是两条腿走路边界写清楚调用时也尽量指名道姓。4.3 知识文件“污染”导致输出漂移这个坑比较隐蔽。references目录里放了大量知识文件后AI在读取时会把一些不相关的内容也混进推理过程导致输出“看起来更专业但实际上跑偏了”。比如我在数据库设计审查技能里放了一个很详细的“分库分表最佳实践”文档结果AI在评审一个只有几千数据量的小系统时也强行推荐分库分表方案理由还头头是道。问题出在知识文件没有标明适用范围。后来我在每份知识文档顶部加了一段“适用前提”说明比如“本文档适用于单表数据量千万级或以上场景数据量较小或业务复杂度低时不建议采用”。这一下就解决了很多误用问题。知识不是越多越好关键是每份知识都要有清晰的能力边界和适用条件。4.4 过度封装反倒降低效率最后一个要提醒的是不要陷入“万物皆可Skills”的冲动。早期我什么场景都想做成技能甚至连“周报生成”都单独写了个技能文件结果发现直接用一段prompt效果反而更好。因为技能的价值在于“知识密度高、流程稳定、值得反复调用”如果一个任务足够简单、上下文携带的知识很少强行封装只会增加调用成本和出错概率。我的判断标准是如果一个任务你已经用同样的方式执行过三次以上而且每次都依赖一段固定的领域知识那才值得做成Skills如果是一次性任务或纯自由发挥任务直接对话就好。技能不是越多越体面而是越精准越好用。5. 从个人技能到团队资产Skills的复制与进化5.1 让每个成员的“手艺”变成团队标准个人搭好一套技能后更大的价值在于把它复制到团队里。传统模式下资深工程师的评审经验存在脑子里新同学只能靠“多踩几次坑”来慢慢领悟。有了Skills机制之后这些经验可以直接沉淀为一个技能文件放进项目仓库团队成员无论谁处理同类任务都能调用同一套标准输出风格也保持一致。我们团队现在把评审技能放在一个独立的代码仓库里用Git做版本管理每次经验更新都走CR流程。比如一次线上故障复盘后发现“接口超时时间需要分级配置”这条经验我们就把它补充到checklist.md中合并到主分支后后续所有评审结果都会带上这条检查项。这种模式下技能不只是一个工具它在慢慢变成团队的“数字制度手册”。5.2 技能的回流迭代机制还要说一点技能不是写一次就永久生效的死文档。大模型在不断发展业务场景也在变化技能内容必须持续进化。我们为每个技能配置了“使用记录日志”每次AI调用技能时会生成一条记录包含输入请求、输出结果和用户反馈标记。每隔一两周整理一次这些记录就能发现哪些检查项是高频命中、哪些知识文件基本没用、哪些输出模板让用户反复修改。根据这些数据做一轮针对性调整比闷头看文档去猜效果要靠谱得多。我自己的经验是技能每迭代一轮质量和易用性都会有肉眼可见的提升这也是Skills这种“文件即程序”形态最大的优势——它天生就适合版本化管理和持续改进。6. 写在后面的一点大实话做了一轮Skills的深度实践下来最大的感受是它本质上是把“AI聊天”变成“AI干活”的那层壳。没有Skills时AI是一个什么都知道一点但什么都不精的通才你问它什么都能接几句有了Skills之后AI才能在特定领域带上你的行业积累、你的团队经验、你的输出标准才能把一个任务从头到尾负责起来。这个东西的门槛其实不高难的是你愿不愿意把自己脑子里那些“理所当然”的经验认认真真写成条目、理成流程、装进文件里。我花在整理知识上的时间远比想象中的多但换来的是后续无数次稳定、高效的调用这笔账怎么算都划算。如果你也正准备尝试建议直接挑一个你日常做得最多、最拿手的任务动手第一个技能别追求宏大小而实用才是王道。
从Prompt到Skills：把AI从聊天助手变成领域专家的实战指南
前段时间好几个朋友问我同一个问题大家都在说“skills”它到底是个什么东西一开始我以为这就是把常用的prompt模板化、封装成可复用的小工具真上手折腾之后发现事情远不止这么简单。Skills背后是一套让AI从“聊天机器”变成“干活专家”的机制它重新组织了模型调用的方式、知识注入的方式、甚至工作流的执行方式。这篇文章我打算把自己从零接触、踩坑、再到搭建出自己一套Skills的完整经验记录下来聊聊它解决什么问题、核心怎么设计、实际怎么落地希望能给正在用AI辅助编程、或者想认真提升AI工作流效率的同行一些参考。1. 先想明白Skills到底解决了什么问题1.1 一个让人崩溃的Prompt现场先说我记忆里非常典型的一次失败经历。当时我想让AI帮我审一份外包开发的采购合同我把合同PDF转成文字丢进对话框然后写了一大段提示词“请帮我审查这份合同重点关注交付标准、付款条件、违约责任要有法律依据输出中文报告。”听起来没什么问题对不对结果AI给我输出的东西怎么看怎么像通用鸡汤。它把“注意验收标准”“付款节点要清晰”“违约条款尽量完整”这些正确但毫无用处的废话翻来覆去地讲真正针对合同条文的具体风险点一个没提更没有告诉我哪一条应该在签约前找对方确认修改。问题出在哪出在它确实拥有“合同审查”这个常识但根本不知道我所在的这类业务里什么样的条款属于高危雷区什么样的付款方式必须坚决拒绝什么叫做一份真的有参考价值的审查报告。它缺的不是能力是专家经验。后来我把公司内部沉淀的几十条审查清单、过去项目踩过的坑、供应商常用的谈判话术都整理成一个文档在每次提问时贴进去再让AI分析效果立竿见影。但新的问题又来了那段资料越来越多从几十行变成几百行每次对话都要重新粘贴而且粘贴的位置、顺序稍不一样AI输出的稳定度就会波动。这就是Skills出现的核心背景把散落在对话里的知识、规则和流程固化成可以被反复调用的独立技能单元。1.2 传统Prompt的两大软肋顺着前面的故事往下看传统Prompt模式有两个很难绕开的软肋。第一个是知识无法持久化。Prompt本质上是一次性的“口述指令”所有背景知识、行业经验、输出要求都必须在对话开始时临时塞进上下文。今天你粘贴进去的资料明天换一个会话就归零了。长此以往每个人都在反复做同一件事——把自己已经整理过的专业内容再粘贴一遍效率极低。第二个软肋是输出的稳定性完全靠运气。同一个任务上午问和下午问措辞稍微改一下AI给出的答案结构可能就差很远更不要说多人协作时每个人写Prompt的口味不一样产出的内容格式五花八门后续修改成本直线上升。Skills在这个背景下出现解决的就是这两件事一是让知识沉淀下来、触手可及二是把“怎么做一件事”的完整套路固定成标准流程让AI每次调用都能稳定输出接近专家水准的结果。用一句简单的话概括Prompt是“这次帮我做这件事”Skills是“以后每次遇到这类事都按这套专业流程来做”。1.3 Skills的实质把专家经验打包成可执行单元那Skills到底长什么样以现在主流AI编程助手和Agent框架的做法来看一个Skills通常是一个独立目录里面包含技能说明文档、参考资料、脚本和模板等文件。这个目录被放在约定好的位置当用户在对话中明确要求“使用某某技能做某件事”时AI会自动读取目录里的技能描述加载对应知识和执行流程然后按照预设步骤完成任务。我把它理解为Skills就是给AI安装了一个“专业岗位说明书”。岗位说明书里写清楚了这个岗位的职责边界、工作步骤、检查标准和验收规范。AI读完说明书后做起事来就不再是自由发挥而是有章法地按规程走。这种从“prompt自由发挥”到“skill规范作业”的转变本质上就是把人的专家经验结构化成机器可执行的程序这是它和普通提示词最根本的区别。2. Skills的核心设计思路与构成要素2.1 一个好技能应该包含哪四层内容搞清楚Skills解决了什么我们再来看它内部是怎么组织的。目前相对成熟的Skills结构基本可以拆成四层触发规则、场景知识、执行流程、输出规范。触发规则解决的是“什么时候该用这个技能”场景知识解决的是“做这件事需要知道哪些专业背景”执行流程解决的是“按什么顺序一步步做”输出规范解决的是“最后交出来的东西长什么样”。这四层缺了任何一层技能都会显得不太对劲。先说触发规则。触发规则是AI判断“该不该调用这个技能”的依据也是很多人容易忽视的一层。在Skill的说明文件里你要明确写清楚这个技能适用于什么场景、不适用于什么场景甚至给出典型输入示例。否则就会出现你希望它用“合同审查”技能的时候它以为你在闲聊或者你只是问一句“今天天气不错”它却莫名其妙把合同审查流程跑了一遍。2.2 触发规则怎么写才不会翻车写触发规则有一个关键经验优先级和边界比触发词本身更重要。我早期犯过的错误是把触发词写得特别宽泛比如“当用户提到合同时使用合同审查技能”。结果用户说“我这周末有个合同要签帮我提醒一下”AI也傻乎乎去调用审查流程了。这就是边界没划清楚的典型问题。后来我改成“当用户提供合同条文、协议正文或需求描述明确要求进行风险审查、条款分析、意见输出时使用本技能如果只是询问合同相关的泛泛问题或没有提供具体文本不要使用本技能”。这样AI遇到模棱两可的输入时至少知道该往哪个方向收敛。特别注意一点触发规则里尽量不要堆砌大量同义词因为大模型对语义的理解已经足够好真正重要的是让它理解“这个场景的核心目标是什么”。2.3 场景知识技能的专业功底所在场景知识是整个Skills的核心价值。这部分通常放在references目录下可以是行业术语表、常见隐患清单、过往项目复盘笔记、成功案例分析、法规摘要。要注意的是这些知识文件不是把网上的资料往下一丢就完事而是需要做“知识蒸馏”的。举个例子如果你要做一个“SQL优化技能”直接丢进100篇数据库文档是没用的。你要做的是把高频出现的性能瓶颈、常用的索引设计经验、以及“先用EXPLAIN看执行计划再动手”这类实操判断方法提炼出来整理成简洁、可检索的条目。我在实践中发现知识文件尽量用表格和短段落来表达少写废话因为AI在读取时对条目化内容的敏感度明显更高。真正的专家经验往往藏在那些“非标准”的内容里比如“当WHERE条件字段存在隐式类型转换时索引会失效”这种大家容易忽略的细节把它写进去技能的价值一下就出来了。2.4 执行流程与输出规范执行流程层就是告诉AI“这件事要分几个步骤每步做到什么程度”。以技术方案评审为例一个完整的评审流程可能包括需求还原、架构合理性检查、性能与安全评估、可维护性审查、风险清单输出。每一步都要写清楚检查重点和需要产出的中间结果避免AI跳步或自己在某一步上过度发挥。输出规范直接决定了最终成品的可用程度。同样一份方案评审没有输出规范的AI可能只给你两百字的“看着还行”而定义了模板之后它会输出一个包含总评分、分维度得分、问题清单、严重级别、修改建议逐条对应的完整评审报告。所以我建议每个技能都要内置输出模板甚至可以提供示例报告作为Few-shot参考让AI照着葫芦画瓢。3. 从零搭建一个“技术方案评审Skills”的完整实操3.1 定义场景边界与输入输出纸上谈兵扯了这么多来一个真实案例。我最近在公司内部搭了一套“技术方案评审”技能这里把它完整拆给大家看。第一步是定义场景边界使用场景是研发同学提交技术方案文档后由AI按照团队标准进行预评审不适用场景是需求讨论、代码审查、项目管理等非技术评审类任务。输入是技术方案文本输出是结构化的评审报告。定好边界以后我会在技能目录下新建一个用来说明技能信息的SKILL.md文件里面写清楚技能名称、适用场景、触发条件以及使用步骤。这一步是AI理解技能的第一入口一定要写得准确、克制。我简单列一下SKILL.md的骨架供参考--- name: tech-design-review description: 对技术方案文档进行结构化预评审输出包含整体评估、架构合理性、性能与安全风险、可维护性建议的评审报告。 triggers: - 用户提供技术方案文档或详细需求描述并要求进行方案评审、技术评审、设计评审时。 - 用户询问方案的可行性、潜在风险、架构改进建议时。 not_trigger: - 用户只是讨论需求功能没有提供具体技术方案文本。 steps: - 1. 提取方案的整体目标、功能范围、技术选型和架构图描述。 - 2. 从功能完整性、扩展性、一致性三个维度评估架构设计。 - 3. 排查性能瓶颈、单点故障、数据安全、权限控制方面的隐患。 - 4. 评估代码结构的可维护性、依赖关系的清晰度、演进成本。 - 5. 汇总风险清单并给出优先级排序。 - 6. 输出最终评审报告。 output_format: | # 技术方案评审报告 ## 整体结论 ## 分维度评分功能/性能/安全/可维护性 ## 风险清单按严重级别排序 ## 改进建议逐条对应 ## 通过条件是否满足这样一个文件AI读到就会明白这个技能是干什么用的、什么情况触发、做事的先后顺序、最终要产出什么。但仅有这个文件还不够还需要把团队内部的检查经验注入进去。3.2 注入团队知识让技能“懂行”我用一到两天的零碎时间把团队过去评审中最常出问题的点整理成了一个references/checklist.md文件。里面全是具体条目比如技术选型是否引入团队无人熟悉的新框架如果引入了是否有备选方案和回退计划数据库表设计是否考虑数据量在千万级时的查询效率索引设计是否覆盖高频查询场景缓存使用是否明确Key的过期策略和缓存击穿、雪崩的应对方式接口设计是否做了幂等处理超时和重试机制是否合理上下游依赖是否有降级预案依赖故障时主链路能否做熔断隔离日志规范是否支持问题追踪关键路径是否有traceId贯穿这些东西在教科书里全有但每一条都是团队踩坑踩出来的。把它们结构化写进技能里AI评审时的“经验水平”就直接从应届生跳到了老工程师。3.3 给技能写脚本自动生成评分矩阵除了知识和流程Skills通常还允许放一些辅助脚本。我写了一个非常简单的Python脚本用来根据风险数量自动生成评分矩阵它的作用是把评审报告中的风险点映射为功能、性能、安全、可维护性四个维度的得分避免AI在打分时凭感觉走。def compute_scores(risks): # risks: [{dimension: performance, level: high}, ...] base {function: 90, performance: 90, security: 90, maintainability: 90} penalty {high: 20, medium: 10, low: 5} for risk in risks: dim risk[dimension] level risk[level] base[dim] max(0, base[dim] - penalty.get(level, 5)) return base risks [ {dimension: performance, level: high}, {dimension: security, level: medium}, ] print(compute_scores(risks))脚本的价值在于把“评分”这件本身容易主观的事情变成了一套可校验的确定性规则。AI在输出风险清单后可以直接调用这个脚本算分而不是自己拍脑袋定个85分。分数背后有明确的扣分依据评审的公正性会好很多。3.4 实际调用效果对比搭完技能之后我做了一次对照测试。用同一份微服务拆分方案分别走“直接让AI评审”和“调用技术方案评审技能”两条路径。直接评审时AI输出的是泛泛而谈的小作文指出了服务拆分要关注数据一致性、调用链变长会增加延迟但完全没有提到团队最关心的权限模型设计。而走技能路径时AI先根据SKILL.md的步骤梳理架构图再对照checklist逐条排查给出的报告里明确标记出“当前方案缺少限流降级策略流量高峰时核心服务存在雪崩风险”、“交易流水表未设计按月分表一年后单表数据量预计达到亿级写入性能将明显恶化”等具体条目。这就是Skills的威力它不改变大模型的基本能力也不给AI加一个“外接大脑”它做的是把组织里的隐性知识变成一套可以被反复调用的标准动作。知道什么场景该查什么查到了该怎么定性最后该输出什么样的结论每一步都有章法。3.5 几个决定成败的操作细节再补充几个实操中容易被忽略的细节。第一SKILL.md文件里的描述一定要亲测迭代不要指望一遍写好。我前后改了七八版才让AI在绝大多数场景下做出正确的触发判断。第二references里的知识文件命名要清晰最好按用途区分比如checklist.md、examples.md、glossary.md这样AI能更快定位。第三技能目录文件名不要用中文和空格尽量用短横线连接的英文命名兼容性更好。第四建议给技能准备至少一个示例输入和示例输出文件作为Few-shot参考AI的表现会更加稳定。4. 常见问题与排障技巧实录4.1 技能不触发问题出在哪这是新手遇到最多的问题我一开始也差点被逼疯。技能文件写得好好的但实际对话时AI完全无视它。逐层排查后发现绝大多数原因出在描述文件里的“触发条件”写得太窄或太含糊。比如只写“当用户要求评审时触发”AI理解的是“必须有‘评审’这个动词出现”但用户实际说得可能是“帮我看下这个方案有没有坑”“这版设计能上线吗”。所以触发描述不能只依赖关键词应该把用户可能的意图描述完整最好给出一到两个典型的触发示例句。还有一种情况是技能文件本身没有被正确加载。不同平台对技能目录的命名和放置位置有严格要求不是放在任意路径都能被识别。我建议搭建初期先用最简单、最标准的目录结构来测试确认技能被正常加载后再逐步增加复杂功能否则很容易出现“文件改了但没生效”的诡异问题。4.2 多个技能互相“打架”当技能多起来以后冲突就出现了。我同时装了技术方案评审、接口设计审查、数据库设计审查三个技能它们的场景高度重叠。经常出现用户只是想评一下数据库表设计AI却把技术方案评审和接口设计审查的流程都串进来跑了一遍输出的报告结构混乱完全没法用。解决这个问题有两种思路。一是给每个技能划分更明确的适用边界在触发规则里写明“本技能覆盖数据库设计相关内容技术方案层面的内容交由tech-design-review技能处理”。二是主动在对话中指定技能名称AI就会以指定的技能为主不再自己风扇式选择。我的经验是两条腿走路边界写清楚调用时也尽量指名道姓。4.3 知识文件“污染”导致输出漂移这个坑比较隐蔽。references目录里放了大量知识文件后AI在读取时会把一些不相关的内容也混进推理过程导致输出“看起来更专业但实际上跑偏了”。比如我在数据库设计审查技能里放了一个很详细的“分库分表最佳实践”文档结果AI在评审一个只有几千数据量的小系统时也强行推荐分库分表方案理由还头头是道。问题出在知识文件没有标明适用范围。后来我在每份知识文档顶部加了一段“适用前提”说明比如“本文档适用于单表数据量千万级或以上场景数据量较小或业务复杂度低时不建议采用”。这一下就解决了很多误用问题。知识不是越多越好关键是每份知识都要有清晰的能力边界和适用条件。4.4 过度封装反倒降低效率最后一个要提醒的是不要陷入“万物皆可Skills”的冲动。早期我什么场景都想做成技能甚至连“周报生成”都单独写了个技能文件结果发现直接用一段prompt效果反而更好。因为技能的价值在于“知识密度高、流程稳定、值得反复调用”如果一个任务足够简单、上下文携带的知识很少强行封装只会增加调用成本和出错概率。我的判断标准是如果一个任务你已经用同样的方式执行过三次以上而且每次都依赖一段固定的领域知识那才值得做成Skills如果是一次性任务或纯自由发挥任务直接对话就好。技能不是越多越体面而是越精准越好用。5. 从个人技能到团队资产Skills的复制与进化5.1 让每个成员的“手艺”变成团队标准个人搭好一套技能后更大的价值在于把它复制到团队里。传统模式下资深工程师的评审经验存在脑子里新同学只能靠“多踩几次坑”来慢慢领悟。有了Skills机制之后这些经验可以直接沉淀为一个技能文件放进项目仓库团队成员无论谁处理同类任务都能调用同一套标准输出风格也保持一致。我们团队现在把评审技能放在一个独立的代码仓库里用Git做版本管理每次经验更新都走CR流程。比如一次线上故障复盘后发现“接口超时时间需要分级配置”这条经验我们就把它补充到checklist.md中合并到主分支后后续所有评审结果都会带上这条检查项。这种模式下技能不只是一个工具它在慢慢变成团队的“数字制度手册”。5.2 技能的回流迭代机制还要说一点技能不是写一次就永久生效的死文档。大模型在不断发展业务场景也在变化技能内容必须持续进化。我们为每个技能配置了“使用记录日志”每次AI调用技能时会生成一条记录包含输入请求、输出结果和用户反馈标记。每隔一两周整理一次这些记录就能发现哪些检查项是高频命中、哪些知识文件基本没用、哪些输出模板让用户反复修改。根据这些数据做一轮针对性调整比闷头看文档去猜效果要靠谱得多。我自己的经验是技能每迭代一轮质量和易用性都会有肉眼可见的提升这也是Skills这种“文件即程序”形态最大的优势——它天生就适合版本化管理和持续改进。6. 写在后面的一点大实话做了一轮Skills的深度实践下来最大的感受是它本质上是把“AI聊天”变成“AI干活”的那层壳。没有Skills时AI是一个什么都知道一点但什么都不精的通才你问它什么都能接几句有了Skills之后AI才能在特定领域带上你的行业积累、你的团队经验、你的输出标准才能把一个任务从头到尾负责起来。这个东西的门槛其实不高难的是你愿不愿意把自己脑子里那些“理所当然”的经验认认真真写成条目、理成流程、装进文件里。我花在整理知识上的时间远比想象中的多但换来的是后续无数次稳定、高效的调用这笔账怎么算都划算。如果你也正准备尝试建议直接挑一个你日常做得最多、最拿手的任务动手第一个技能别追求宏大小而实用才是王道。
