从Prompt到可复用Skill：Agent能力构建的完整方法论
最近自己在折腾 Agent 相关的工具链发现一个很有意思的现象很多人手里攒了一大堆 skill但真正能拿出来用的没几个。大多数 skill 要么是把自己写过的 prompt 原封不动存了个档要么是东拼西凑抄了一堆模板进去等真到了要复用的时候效果完全不可控。我自己也经历过这个阶段后来慢慢把创建 skill 这件事本身当成一个项目来对待总结出了一套还算顺手的流程核心就是方法抽象——不急着写指令先想清楚这个 skill 到底在解决哪一类问题哪些东西是无论输入怎么变都不会变的。这篇文章就把这套流程完整拆开讲一遍从抽象思路到实操步骤再到我自己一直在用的 Review 清单希望对正在折腾 skill 的人有点帮助。本文适合用过 Claude Code、Codex 这一类 Agent 工具、但还没系统梳理过自己 skill 流程的人也适合刚接触 skill 概念、想知道它和普通 prompt 有什么区别的新手。1. 先搞清楚 skill 到底是什么别把它做成 prompt 文件夹很多人的第一个 skill 都是从复制粘贴开始的我也不例外。那时候我刚接触 Agent 工具看到一个不错的指令模板就把它存成一个 Markdown 文件放到 skill 目录里然后天真地以为这样就有了一个可复用的能力。结果用了几次才发现这东西离真正的 skill 差得远它顶多算一个不太稳定的 prompt 存档。1.1 skill 的构成从“一次性对话”到“可复用能力”先给一个我自己的定义skill 不是一段指令而是一个“可复用能力单元”。它至少包含五个部分触发条件、执行流程、行为约束、领域知识、输出格式。这里面最容易被人忽略的是触发条件和行为约束因为这两部分决定了 skill 在什么场景下会被正确激活、在什么场景下应该主动退出。我见过太多 skill 文件里只写了“你是 XX 专家请帮我做 XX”然后就没了。这样的 skill 遇到简单任务可能还凑合但一旦输入稍微偏离模板模型就开始自由发挥输出格式、思考路径全部跑偏。一个合格的 skill 必须回答三个问题什么时候用我用到什么程度停遇到搞不定的情况找谁这三个问题都不写清楚就别谈什么可复用。另外skill 和普通 prompt 还有个本质区别普通 prompt 是一次性的对话上下文而 skill 是要被持久化、版本化、甚至分享给其他人使用的。这就意味着它的文本必须有自解释性——过了三个月回头来看哪怕不看文档光读 skill 文件本身你也能知道它当初设计来干什么、边界在哪里、哪些坑已经踩过了。如果一个 skill 文件还需要你额外写一篇几百字的说明才能让别人看懂那说明抽象还不到位。1.2 skill 与 agent、plugin、workflow 的边界很多人把 skill、agent、plugin 这些东西混在一起其实它们解决的是不同层面的问题。用我自己的理解来打个比方plugin 是工具skill 是使用工具的姿势agent 是那个“有目标、会自己决定用什么姿势”的人workflow 则是一套固定的流程编排。举个例子你有一个读取网页内容的插件这是一个工具你写了一个“先抓取页面、再提取正文、最后总结要点”的 skill这是使用这个插件的固定姿势而当你让 Agent 自主决定“先搜索、再读页、再对比、再写报告”时你就已经是在用 agent 的能力了。skill 夹在中间它的价值在于把“某一类任务的最佳做法”固化下来让模型不用每次都在黑暗中摸索。明白这个边界有什么好处好处是你不会试图用 skill 去解决所有问题。比如需要多步决策、需要根据中间结果动态调整方案的任务就不适合硬塞进一个 skill 里硬塞的结果往往是流程僵化模型在分支判断上反复横跳。反过来那些输入输出相对稳定、行为路径比较固定的任务比如日志分析、代码评审、格式化输出就非常适合沉淀成 skill。搞清楚边界再动手能少走很多弯路。还有一个容易被忽略的点不同平台的 skill 底层逻辑是相通的但具体实现有差异。比如在 Claude Code 和 Codex 里skill 的目录结构、文件命名规范、加载机制都不完全一样。我自己维护一套通用的方法论然后针对平台做适配层。核心思路不变换平台只是改改壳。2. 方法抽象核心是“提炼不变的东西”创建 skill 这件事方法论上最关键的词就是“方法抽象”。这个词听着有点玄实际操作起来其实很朴素——把同一类任务反复做几遍然后找出那些“不管输入怎么变处理方式都不变”的东西。抽象的质量直接决定 skill 的复用价值。2.1 抽象路径从个案、场景再到原子能力我自己习惯把抽象分成三个层次个案、场景、原子能力。个案就是一次具体的任务比如“帮我看看这个 Python 脚本有没有 bug”场景是一类相似的任务集合比如“代码评审”这个场景下可能有正确性检查、性能分析、安全审计等多个子场景原子能力则是更底层、不依赖具体业务的东西比如“提取代码中的公共逻辑”“对比两段实现的差异”这种。创建 skill 时正确的抽象方向是从“个案”上升到“场景”再往下提取“原子能力”。大多数人犯的错误是跳过了场景层直接拿一两个个案就去抽象原子能力这样提取出来的东西往往过于理想化换个输入就失效。我的经验是至少要收集 5 到 10 个真实个案找出其中高频出现的共性问题再去定义场景能力。另外一个很实用的方法是“反向抽象”先不看成功案例而是收集失败案例。把你过去在类似任务上让模型翻车的过程记录下来分析失败原因里有哪几条是反复出现的这些反复出现的问题就是抽象时要重点解决的对象。比如你发现每次让模型做代码评审它都会漏掉安全相关的问题那“安全审查”就必须作为一个独立步骤写进 skill 的执行流程里不能指望模型自己临场发挥。2.2 抽象粒度多大算合适抽象粒度是创建 skill 时最纠结的问题。抽象得太粗skill 变成一个大杂烩什么都能干但什么都干不精抽象得太细你会发现需要维护几十个 skill每个都只有一两句话管理成本直接失控。我自己的判断标准是一个 skill 解决一个“类型”的问题而不是一个“具体”的问题。什么叫一个类型比如“日志错误根因分析”是一个类型它可以覆盖 Nginx 日志、应用日志、数据库日志“分析 Nginx 日志”是一个具体问题它不应该单独成为一个 skill。判断粒度是否合适可以跑一个简单测试这个 skill 至少能处理 3 个不同的输入并且这 3 个输入不完全等价。还有一个衡量维度调用频率。如果一个 skill 一个月都用不上一次要么是粒度太细要么是它根本不属于高频场景不值得沉淀。反过来如果同一个 skill 在一天内被反复调用但每次都要临时修改里面的指令那说明抽象层次偏低了应该再往上层提一提把那些需要临时修改的东西设计成可配置的参数。2.3 三个常见的抽象错误第一是过早抽象。很多人在第一次尝试某类任务后就急着把它做成 skill结果还没搞清楚这类任务的完整边界抽象出来的东西必然有漏洞。正确做法是先手动做几次记录过程中遇到的异常情况等积累了足够样本再动手。第二是过度抽象。为了让一个 skill 适配所有场景在指令里堆了一大堆条件分支结果是模型根本记不住那么多约束执行起来反而比不调用 skill 还混乱。skill 的复杂度应该控制在“一个熟练工程师看完后能明确判断适用与否”的程度超过这个门槛就得分拆。第三是伪抽象这个最坑。表面上看你已经把一个任务从具体场景中剥离出来了格式也抽象了但本质上你只是把原来的 prompt 改了个通用点的措辞行为逻辑还是绑定在最初那个特定任务上。识别伪抽象的方法很简单换一个完全不同领域但结构类似的输入看看 skill 还能不能正常工作。比如你写了一个代码评审 skill能不能拿它去评审 SQL 脚本如果立刻失灵说明抽象只停留在表面并没有沉淀出跨场景的处理流程。3. 高效创建 skill 的五步流程前面的抽象原则听起来可能还比较虚这一节我把整个创建流程拆成五步每一步都给具体的操作方法和判断标准。这套流程我自己跑了很多轮从零开始做一个合格的 skill大概需要两三个小时的完整时间如果只是优化现有 skill半小时到一个小时就够。3.1 第一步场景采样从真实任务里收集素材创建一个 skill 的第一步不是写指令而是收集素材。我会先翻出过去一两周里在相关场景下和 Agent 的对话记录挑出 5 到 10 个有代表性的案例。代表什么意思就是这些案例覆盖了输入差异的最大范围——有短的、有长的、有规范的、有语焉不详的、有正向请求、有边界情况。采样时我会特别关注两类对话一类是结果很满意的高光时刻这类对话能告诉你“什么做法是对的”应该被沉淀为 skill 的执行流程另一类是结果翻车、需要反复修正的失败现场这类对话能告诉你“什么约束必须写死”也就是 skill 里的 DONT 清单。采样完成之后先做一次简单的聚类把案例按照处理路径的相似度分组每组就是一个潜在的场景能力。如果发现某个案例的处理路径跟其他所有案例都差别很大果断把它踢出去它不是这个 skill 的对象。这个环节的核心原则是skill 服务的是高频共性需求不是一次性的特例。3.2 第二步定义触发条件与输入输出素材准备好之后下一步是给 skill 定义触发条件和输入输出。触发条件就是要写清楚什么样的情况下模型应该主动想起这个 skill。我会把触发条件写成两层显式触发和隐式触发。显式触发是用户直接说了关键词比如“帮我审一下这段代码”隐式触发是场景特征比如用户丢过来一段带着错误堆栈的日志哪怕没说要分析模型也应该意识到这适合调用日志分析 skill。输入输出定义这一块我会把输入格式化成标准的字段必要输入、可选输入、环境上下文。必要输入是缺了它就无法执行的可选输入是能增强效果但不是必须的环境上下文包括平台信息、语言类型、既有约束条件。输出格式则要定义成模板包括结构、长度、风格、附加产物。这里有个很容易踩的坑输出模板不要写得太死尤其是不要为了美观要求模型按照某种固定的 Markdown 嵌套结构输出因为模型在严格遵守复杂格式时经常会牺牲内容质量。边界条件也是这一步必须定义的这个 skill 在什么情况下应该主动退出或请求补充信息比如输入内容少于多少字、缺失关键字段、或者任务实际涉及的内容超出了 skill 的知识范围这些都是合理的退出条件。写清楚退出条件能避免模型在一个不合适的任务上强撑着用错工具。3.3 第三步编写指令主体——行为约束、知识注入与输出模板到了真正动笔写 skill 文件的环节我会把内容分成三块行为约束、知识注入、输出模板。行为约束是最核心的部分我用 DO/DONT 结构来写。DO 列出执行流程中的关键步骤和优先级DONT 列出禁止出现的行为比如“不要在没有数据支撑的情况下下结论”“不要修改原始文件”“不要在输出中夹带无关建议”。写 DO 时注意用动词开头写具体动作避免“保证质量”“提高效率”这种无法验证的空话——你无法评估模型有没有做到“保证质量”但你能检查它有没有在输出前先列出验证步骤。知识注入是给模型提供处理该领域任务所需的背景信息比如常见错误类型、行业术语、常用工具参数。知识注入这块最容易犯的错误是贪多。一个 skill 文件里塞进去几千字的领域知识模型在加载时根本抓不住重点。我的经验是只注入“本任务直接需要”的知识其他内容放到引用文档里在 DO 里告诉模型“遇到不确定的情况先去读 XX 文档”。输出模板这一步我会提供两个层面的要求结构模板和风格要求。结构模板规定输出的骨架比如背景说明、问题列表、根因分析、修复建议、附录风格要求规定表达方式比如“面向开发者的技术报告不使用营销语气”。这两者分开写模型不容易把结构上的要求和表达上的要求混在一起。最后skill 文件里必须带一个“最小可用示例”——用一个简短的输入加上期望的输出样例让模型能快速对齐目标。我自己试过很多次没有示例的 skill 和有示例的 skill首次使用的成功率差一倍以上这个成本绝不能省。3.4 第四步冷启动测试与迭代写完 skill 文件后别急着在真实项目里大规模使用先做冷启动测试。我会准备三个测试输入一个标准输入最典型的场景、一个边界输入输入很简短或者条件不完整、一个负向输入这个任务其实不应该调用本 skill。三个输入跑完之后对照预设的输出模板检查差距。冷启动测试最常见的失败模式有三种一是模型忽略了你定义的步骤直接跳到最终输出二是输出结构偏离模板三是行为约束没有生效模型还是按照自己的习惯来。遇到这些情况优先检查指令文本是否足够明确而不是直接把锅甩给模型不够聪明。很多时候问题出在“步骤写得太抽象”模型不知道怎么在一个具体输入上落地。迭代也是有节奏的不要期望一次改到位。我一般跑三轮第一轮只看行为约束是否生效第二轮检查输出结构是否符合模板第三轮才关注输出质量的具体细节。每一轮只改一个类型的错误否则你很难判断到底是哪条改动起了作用。等三轮测试都过了才会在真实项目里试用一到两周收集使用中的失败案例再回来优化。3.5 第五步版本管理与沉淀如果一个 skill 你只打算自己用一次那版本管理没那么重要。但只要这个 skill 会反复使用、会迭代优化就一定要纳入版本管理。我自己会把每个 skill 放在独立的目录下用 Git 管理变更。每次修改都写清楚 changelog哪怕只是修改一个词——因为你很可能在几周后想复盘“到底哪个改动让效果变好了”没有 changelog 这段记忆就永久丢失了。版本之外沉淀也很关键。我会在一个统一的索引文件里记录每个 skill 的状态stable、beta、deprecated。stable 代表经过三轮以上验证可以放心使用beta 是刚写完还没充分测试deprecated 是已找到替代方案。这个索引文件决定了你在面对一个新任务时多大程度上可以信任某个 skill 的输出。这里补充一个我自己踩过的坑不要频繁重构正在使用中的 skill。哪怕你看到了明显的优化空间也建议先复制一份新版本在副本上做实验等验证稳定后再替换。直接在活跃使用的 skill 上动刀一旦改坏了影响的是所有下游任务的输出质量且排查起来非常痛苦。4. 附 Review 清单把评审变成肌肉记忆Review 清单是我创建 skill 流程里最重要的一道关卡基本上决定了这个 skill 是能沉淀下来还是会被废弃。我最初写完一个 skill 之后只关注“它能不能跑通”后来才发现能跑通和合格之间差了十万八千里。后来我把评审标准固化成了清单每次创建或修改 skill都逐条过一遍大概十分钟省掉的是后面几小时的返工。4.1 功能类检查项触发、边界与失败处理功能类是基础如果一个 skill 连基本功能都不完整质量和安全都无从谈起所以我最先核对这一类。检查项通过标准常见失败触发条件清晰显式和隐式触发都能明确传达只写了显式触发换个说法就不触发输入定义完整必要输入、可选输入、环境上下文有区分混在一起模型不知道该给多少信息退出条件明确写清楚“何时不用本 skill”模型在不适用场景硬用输出偏差大失败处理有兜底输入缺失或超出边界时有预案直接崩到默认行为相当于没用 skill输出模板可验证结构固定可逐项核对只写了“输出报告”没有结构约束触发条件这块我特别提醒一句不要过度依赖关键词触发。真实场景里用户的表达千奇百怪可能输入里根本没有“分析”“评审”“总结”这类词但明显需要这个 skill 介入。所以隐式触发的描述一定要写具体要写基于场景特征的触发条件而不是基于词汇的触发条件。退出条件在功能检查里的地位也常常被低估。很多 skill 使用者抱怨模型“乱用技能”本质上是退出条件没写好。我建议在 skill 的约束部分专门留一段“终止条件”列举那些表面相关但实际上应该拒绝执行的情况。比如一个“代码评审 skill”遇到几千行的超大文件时应当主动提示需要分段评审而不是硬着头皮硬跑。4.2 质量类检查项可读性、可维护性与抽象纯度质量类检查项的思考对象不是模型而是你这个 skill 文件的作者。未来六个月后当你回头维护这个 skill 时你能否快速理解它的设计意图并做有效修改这就是质量类检查要回答的问题。可读性检查这个 skill 文件从开头到结尾是否有一条清晰的主线一个判断方法是“陌生人测试”——找一个没接触过这个 skill 的人让他看一遍文件然后复述它做什么、怎么做、什么时候不适用。如果他复述出来的内容和你设计的一致说明可读性过关。如果对方一脸茫然或者关键信息记错说明文件的逻辑顺序或重点清晰度有问题。可维护性检查修改这个 skill 的某一处行为时你需要动几个地方如果只改一个地方就能全局生效说明可维护性好如果牵一发动全身说明文件内部耦合过重。最常见的耦合问题是“把领域知识写死在行为步骤里”下次换一个业务领域你得同时改知识部分和流程部分这就很糟糕——知识应该放在独立的知识段落里通过引用关系跟流程关联。抽象纯度检查要回答的问题把具体输入和具体案例全部拿掉之后剩下的流程是否还成立具体做法是把 skill 文件里所有涉及特定技术的词替换成通用词看看整个流程是否还逻辑自洽。比如一个“Python 代码评审”的 skill能不能在替换术语后变成“任意语言代码评审”如果可以说明抽象是纯的如果流程里到处是 Python 独有的方法和库那这个 skill 的抽象纯度不高适用范围比想象中窄得多。4.3 安全类检查项防止越权、幻觉与扩散错误安全类检查项是很多人会忽略的但恰恰是 skill 和普通 prompt 最大的区别所在——skill 一旦被信任并被反复调用它的错误也会被放大。如果你在 prompt 里犯一个错影响的是这一次对话如果你在 skill 里犯一个错影响的是这个 skill 之后每一次的调用。防止越权这个 skill 所要求的操作是否在合理权限范围内它会不会诱导模型去执行本不该执行的操作比如修改生产环境配置、删除用户文件、发送网络请求我见过一些 skill 为了完成功能直接授权模型“可以执行任何命令”这是灾难级的写法。正确的做法是精确限定可执行的操作集合其他一律需要用户确认。防止幻觉扩散skill 里注入的知识如果有一部分是错误的模型会在用它处理任务的过程中把这些错误当作既定事实输出而且因为来源是 skill模型会比平时更加自信。所以每次修改知识注入部分都要单独核验一遍信息来源是否可靠、数据是否过时。如果知识部分开始变得陈旧但又没有及时维护宁可先下架这个 skill也不要留着带病运行。防止扩散错误有没有在输出模板里让模型“基于上一次结果继续推导”的步骤这种链式推导是错误扩散最快的通道——第一步结果出错后面的步骤全都会建立在错误的基础上。有这类步骤时务必在流程中加入中间验证点让模型在关键节点自检“当前结论是否有证据支撑”。输出里还要要求模型在引用数据时标注来源或置信度方便下游使用者判断可信程度。4.4 Review 清单模板以上所有检查项汇总成一份实际操作用的清单模板我每次创建或修改 skill 之后都会过一遍# Skill Review Checklist ## 1. 功能类 - [ ] 触发条件显式 隐式触发都已定义语义覆盖目标场景 - [ ] 输入定义必要输入 / 可选输入 / 环境上下文三者分离 - [ ] 退出条件不适用场景和异常场景都有明确说明 - [ ] 失败兜底输入缺失或超出边界时有预设的降级策略 - [ ] 输出模板结构固定、字段明确、可逐项核对 ## 2. 质量类 - [ ] 可读性陌生人测试通过主线清晰 - [ ] 可维护性单点修改能全局生效知识不散落在流程中 - [ ] 抽象纯度去掉具体案例后流程依然成立 - [ ] 粒度合适一个 skill 解决一个类型的任务不贪大 ## 3. 安全类 - [ ] 权限边界操作范围明确限定不包含默认授权 - [ ] 知识可靠注入的知识经过核验无误导信息 - [ ] 链式风险有中间验证点防错误扩散 - [ ] 来源可控输出中关键数据带有引用来源或置信度这份清单不是一次性做完就完了而是要形成习惯。我把这个清单本身也当成一个 skill 在使用——每次新建 skill 或者大改版本都会跑一遍跑完就在 changelog 里记录通过情况。坚持半年之后清单里的很多检查项已经内化成写 skill 时的默认约束新建的 skill 一次性通过率明显提高返工的时间也大大压缩。5. 踩坑实录我在创建 skill 过程中遇到的问题与排查再好的流程也需要靠具体的坑来验证。这一节分享几个我实际踩过、并且对流程改进有帮助的典型问题。有些问题看起来很小但影响极其恶劣而且很容易在“看起来差不多了”的时候被忽略。5.1 坑 1指令太长模型反而看不见关键约束我第一次给一个“日志分析 skill”编写指令时出于尽善尽美的心理把执行流程、领域知识、注意事项全部写在同一个文件里洋洋洒洒写了两千多字。结果测试时发现模型确实按流程执行了但最关键的“不要在根因不明时直接给修复建议”这条约束经常被无视输出里频繁出现没有证据支撑的猜测。后来我才意识到问题出在“信噪比”上。当一份指令文件过长时模型在加载时会做隐式的信息筛选它认为重要的内容被保留看起来像次要的内容就被忽略了。最关键的行为约束淹埋在大量补充材料里自然起不到作用。我的解决方案有两条一是拆分文件将行为约束放到主文件最靠前的位置把领域知识移到单独的引用文档里在主文件中用一句“遇到相关问题时翻阅 XX 文档”来引导二是精简 DONT 列表只保留真正高优先级、反复出现过的错误把不是那么关键的约束删掉——与其写十条模型可能只记住五条的规则不如写五条它每条都能记住的规则。这条经验后来也被固化进了 Review 清单的“可读性”检查项里。5.2 坑 2把个人偏好写成了通用规则这个坑非常隐蔽我花了好长时间才意识到。有一段时间我给自己做了一个“技术方案评审”的 skill里面写了一条规则“优先推荐经过时间验证的技术栈不推荐刚发布的新框架”。在当时写下这句话的时候我感觉合理极了因为这是我自己一贯的技术倾向。后来我把这个 skill 分享给团队里的另一名工程师他用了几次后反馈说这个 skill 的处理方式和他预期完全相反——他负责的是新项目技术选型而我的规则等于把所有新兴技术都排除在外了。问题出在哪我把个人偏好内化成了 skill 的“通用规则”却没有意识到它是偏好而不是铁律。在 prompt 里这么写没关系因为 prompt 是一次性的接收的人知道这是你的偏好但 skill 是要被反复使用的使用者可能根本不知道这句规则背后的语境它会变成一个看似客观的约束。修正方法是区分“事实规则”和“偏好配置”。事实规则是无论谁用都应该遵守的比如“输入数据必须经过验证”“输出必须有证据支撑”偏好配置是因人而异的比如“技术选型时更看重稳定性还是先进性”。后者应该设计成 skill 的可配置参数在使用时由用户明确指定而不是硬编码在规则里。这个思路也启发了我对 skill 整体架构的重新思考——把可变的偏好层和固定的逻辑层分离skill 的适用性会大大提升。5.3 坑 3没有定义“什么时候不要用这个 skill”我以前做一个“文章风格改写”的 skill触发的条件是用户请求“帮忙改一下文章”。结果测试的时候发现它几乎什么内容都会去改哪怕用户只是想让模型读一遍文章给点意见它也会直接重写全文。后来我在失效案例分析里才看清这个 skill 缺了一个“拒绝逻辑”它没有识别“用户只是想阅读和理解并不想修改”的场景。这个坑的根源在于我把触发条件写得太宽了。触发条件只写了“什么情况下启动”却没有写“什么情况下即使表象相似也不启动”。从那以后我在每一个新 skill 里都增加了一个独立的“终止条件”段落明确列出那些外观类似、但本质上不属于本 skill 职责范围的情况。这个改动对 skill 的实际价值提升非常明显。有了明确的退出条件之后模型在遇到边界输入时会更倾向于向用户提问、澄清需求而不是自作主张地套用 skill 的处理流程。这也从侧面验证了“一个 skill 的能力边界一半取决于它做什么一半取决于它不做什么”。5.4 坑 4只测正向路径不测边界输入初期我测试 skill 的坏习惯是只拿“标准输入”跑一遍看到了不错的结果就觉得大功告成。直到有一次一个已经测试通过的 skill 在生产环境里被用户用一个极短的输入触发了输出结果完全崩溃——文件里没有给“输入内容过短、信息不足”的情况设计处理逻辑模型在缺少必要信息的情况下硬着头皮开始了分析结果输出了一大段看起来很专业、实际完全跑偏的内容。这件事让我彻底改变了测试习惯。现在每次测试 skill我都会至少准备三个维度的输入标准输入验证正常流程、边界输入验证极端情况处理、负向输入验证拒绝逻辑。边界输入不等同于错误输入它是“满足触发条件但质量很低”的输入比如日志分析任务里只有一行日志、代码评审任务里只有十行代码。这些输入最考验一个 skill 是否真正成熟因为它们最能逼出模型在流程设计上的空白点。边界测试还有一个附带的好处它能暴露出“输出模板”中的脆弱环节。一旦你发现模型在信息不足时倾向于编造内容来填充模板字段就说明模板缺少“信息不足时显式标注未知”的规则。这类规则必须提前写进指令里不能指望模型自己学会在信息不足时变得谦虚。6. 最后再分享一点关于 taste 的思考最近社区里“taste skill”这个概念挺火我理解它强调的是 skill 要有“品味”——不只是能把任务做完而是知道什么样的结果算是好的。我在这篇文章里写的流程本质上也是在追求一种结构上的 taste触发条件变得精确、行为约束变得克制、知识注入变得干净、测试覆盖变得全面这些判断本身就是品味的一部分。对我个人来说做 skill 最大的收获还不在于 skill 本身而在于强迫自己把做事的隐性经验显性化。以前我解决一类问题的经验是模糊的、直觉式的为了写一个能用的 skill我必须把它拆成明确的步骤、约束、退出条件这个拆解的过程让我对自己擅长的事有了前所未有的清晰认知。这种“把自己的方法论抽象出来”的能力可能是做 skill 这件事最值钱的部分。回头来看方法抽象的目的从来不只是为了做一个更好的 skill而是为了让你知道自己做事的时候究竟做对了什么。