1. 从“AI 要么问一堆、要么闷头做错”说起用 AI 写代码、做方案、跑流程的人大概率都遇到过这两种极端。第一种是“话痨型”你让它改一个函数它先反问你五个问题——目标语言是什么、要不要兼容旧版本、命名风格偏好、有没有测试覆盖、要不要顺便重构。你只是想让它把if里的判断反过来它却像刚入职的实习生一样谨慎到让人抓狂。第二种是“闷头型”你让它给一个模块加日志它二话不说把整个文件重写了一遍顺手改了两个你没让它动的函数还删了一行你觉得“看起来没用但其实是兜底”的判断。等你发现的时候diff 已经几百行了。这两种表现看起来是性格差异本质上是同一个问题AI 没有判断“该不该问”的能力。它要么把“不确定”全部外化成提问要么把“不确定”全部内化成猜测。而人类工程师在这件事上有一套非常成熟的直觉——什么时候该停下来确认什么时候该按惯例直接做什么时候该先做一版再让人 review。这套直觉就是我想用一个 Skill 去教给 AI 的东西。这篇内容适合三类人看一是天天和 AI 结对编程、被它的“问”和“猜”反复折磨的开发者二是正在做 Agent 开发、需要设计“澄清意图”环节的工程师三是想理解 Skill 机制到底能解决什么问题的技术人。我会把整个 Skill 的设计思路、SKILL.md 怎么写、判断逻辑怎么落地、实测中踩了哪些坑全部摊开讲。核心关键词就几个Skill、clarify-intent、SKILL.md、Agent。读完你应该能自己写一个类似的 Skill塞进你的 Agent 工作流里。先说结论这个 Skill 不复杂核心就是一张“该问 / 不该问”的判断表加上一套把“问”的成本压到最低的提问模板。难的不是写代码难的是想清楚边界在哪。下面我按“为什么要做 → 判断逻辑怎么设计 → SKILL.md 怎么写 → 实测踩坑 → 怎么扩展”这个顺序讲中间会穿插大量我自己的取舍过程。2. 为什么“该不该问”是个值得单独做成 Skill 的问题2.1 澄清意图的成本被大多数人低估了很多人觉得“多问一句总没错”但在 Agent 场景里问一句的成本远比想象中高。一次提问意味着一次交互往返意味着用户要重新进入上下文、理解 AI 在问什么、组织语言回答。如果这个 Agent 是跑在自动化流程里的一次提问可能直接导致流程中断需要人工介入。我做过一个粗略统计在一个中等复杂度的代码修改任务里如果 AI 平均问 3 个问题用户的实际操作时间会增加 40% 以上因为每次回答都要重新读一遍 AI 的问题描述。反过来“闷头做错”的成本更高。错误的理解会导致错误的产出错误的产出需要 review 才能发现发现之后还要回滚、重做。更麻烦的是有些错误是“看起来对”的——AI 改了一个它以为等价、实际上改变了边界行为的判断测试可能都测不出来上线之后才炸。这种隐性成本比多问几句可怕得多。所以真正的问题不是“问还是不问”而是在什么条件下问、问什么、怎么问。这三件事想清楚了AI 的行为就会从“随机”变成“可预期”。2.2 Skill 机制为什么适合承载这种判断Skill 的本质是一段可复用的、带触发条件的指令集。它和普通的 prompt 最大的区别在于Skill 有明确的触发场景和执行边界。你可以把它理解成一个“插件化的行为准则”——当 Agent 判断当前任务落在这个 Skill 的适用范围内时就加载这套准则来约束自己的行为。用 Skill 来承载“该不该问”的判断有几个天然优势。第一它是声明式的你可以把判断规则写成清晰的条目而不是散落在系统提示词里。第二它是可组合的一个 Agent 可以同时挂载“澄清意图 Skill”和“代码风格 Skill”各管各的。第三它是可迭代的你发现某类问题 AI 总是判断错直接改 SKILL.md 里对应的条目就行不用动整个系统提示词。这也是为什么我选择用 SKILL.md 这种格式来写。它足够简单纯文本、结构化、人和模型都能读又足够灵活可以塞进判断表、示例、反例、边界条件。下面我会详细讲这个文件的结构。2.3 一个反直觉的观察AI 问得越多往往说明它越“没底”我观察过很多次 AI 的提问行为发现一个规律AI 提问的数量和它对任务的理解程度成反比。当它完全理解任务时它几乎不问当它完全不理解时它会问一堆泛泛的问题最危险的是中间状态——它以为自己理解了问了一两个“看起来专业”的问题然后基于错误的假设闷头做下去。这个观察直接影响了我的 Skill 设计。我不追求“让 AI 少问”我追求的是让 AI 在真正关键的分歧点上问在无关紧要的细节上自己拍板。换句话说判断标准不是“问的数量”而是“问的质量”。一个高质量的提问应该指向一个“如果猜错会导致返工”的决策点一个低质量的提问问的是“你希望我用 tab 还是空格”这种猜错了也无所谓的事。3. 判断逻辑的核心把“不确定”分成四类3.1 四象限分类法我把 AI 在任务中遇到的所有“不确定”分成四类对应四种处理策略。这个分类是整个 Skill 的骨架。不确定类型特征处理策略举例高影响 低可逆猜错代价大且难以回滚必须问删除数据、修改对外接口、改变核心业务逻辑高影响 高可逆猜错代价大但容易改回来先做做完标注重构、调整架构、改命名规范低影响 低可逆猜错代价小但难回滚问但给默认选项配置文件格式、日志级别低影响 高可逆猜错代价小容易改直接做不问代码格式、注释风格、变量命名这张表看起来简单但真正落地的时候难点在于判断“影响”和“可逆性”。AI 不是人它没有“这个改动会不会影响线上”的直觉。所以我在 Skill 里加了一条硬规则任何涉及“删除”“覆盖”“对外暴露”的操作一律归为高影响。这条规则牺牲了一点效率但极大降低了灾难性错误的概率。3.2 为什么“可逆性”比“影响”更重要很多人设计这类判断逻辑时只看“影响大小”忽略“可逆性”。但实测下来可逆性才是更关键的维度。原因很简单高影响但可逆的错误成本是“改回来”高影响且不可逆的错误成本是“无法挽回”。前者最多浪费一点时间后者可能造成真实损失。举个我踩过的坑。有一次我让 AI 帮我整理一个项目的依赖它判断“某个依赖看起来没被引用”直接把它从package.json里删了。这个操作影响不算特别大但不可逆——它没有先备份也没有在 diff 里高亮这个删除。结果那个依赖是通过动态加载引用的静态扫描扫不出来删完之后构建直接挂了。从那以后我在 Skill 里加了一条任何删除操作必须先列出“将要删除的内容”等确认后再执行。这条规则让 AI 在删除场景下从“闷头做”变成了“先问”。3.3 默认值策略让“问”变得便宜光判断“该不该问”还不够还得解决“怎么问才不烦人”。我的做法是凡是需要问的必须同时给出默认选项。用户可以直接说“用默认”或者只回答有分歧的那一项。比如 AI 需要确认日志级别它不应该问“你希望日志级别是什么”而应该问我准备把日志级别设为info默认因为这是大多数生产环境的惯例。如果你需要debug或warn告诉我。这样用户如果同意默认值一个字都不用回如果有不同意见只需要说“改成 warn”。实测下来这种“带默认值的提问”能把用户的回答成本降低 60% 以上因为大部分情况下默认值就是对的。3.4 一个容易忽略的点问的时机“该不该问”之外还有一个维度是“什么时候问”。我的经验是能批量问的不要分散问。如果 AI 在执行任务过程中发现三个需要确认的点不要做一步问一次而是先把能做的做完把三个问题攒在一起一次性问清楚。这样做的好处是减少交互往返次数。用户回答一次AI 继续执行而不是被打断三次。实现上我在 Skill 里定义了一个“待确认队列”AI 遇到需要问的点时先记下来继续执行不受影响的部分等执行到必须停下来的时候把队列里的问题一起抛出来。4. SKILL.md 怎么写结构、字段与示例4.1 文件整体结构我的 SKILL.md 分成五个部分元信息、触发条件、判断规则、提问模板、反例。下面逐段讲。--- name: clarify-intent description: 判断 AI 在任务执行中应该主动提问还是直接执行 trigger: 当任务涉及代码修改、文件操作、配置变更时 --- # Clarify Intent Skill ## 判断规则 四象限分类法的具体条目 ## 提问模板 带默认值的提问格式 ## 反例 不该问的情况、不该猜的情况元信息部分用 YAML front matter这是 SKILL.md 的常见约定。trigger字段很关键它决定了这个 Skill 什么时候被加载。我把它限定在“代码修改、文件操作、配置变更”这三类场景因为这三类是最容易出“不可逆错误”的。4.2 判断规则怎么写才可执行判断规则不能写成“要谨慎”“要判断影响”这种空话必须写成可匹配的条件。我的写法是“条件 → 动作”的形式## 判断规则 ### 必须提问的情况 - 操作涉及删除文件、删除代码块、删除配置项 - 操作会修改对外接口函数签名、API 路径、数据结构 - 操作会改变核心业务逻辑的判断条件 - 存在两种以上合理解释且不同解释会导致不同实现 ### 直接执行的情况 - 代码格式调整缩进、空格、换行 - 注释补充、文档字符串完善 - 变量重命名局部作用域内 - 添加日志、添加类型标注 ### 先执行后标注的情况 - 重构保持行为不变的前提下 - 调整文件组织结构 - 优化性能不改变对外行为这里的关键是每条规则都要能被具体匹配。“删除文件”是明确的“谨慎处理”是模糊的。AI 对模糊指令的执行效果很差对明确条件的执行效果很好。4.3 提问模板的设计细节提问模板我改了七八版最后稳定下来的格式是这样的## 提问模板 当需要提问时按以下格式 1. 一句话说明当前情况 2. 列出我准备采用的默认方案及理由 3. 列出需要确认的具体点不超过 3 个 4. 说明如果不确认我会按默认方案继续 示例 我准备重构 utils/parser.js把解析逻辑拆成三个函数。 默认方案保持对外接口不变只调整内部结构。 需要确认拆分粒度是否按“词法/语法/语义”三层 如果不回复我按默认方案继续完成后你可以 review diff。这个模板的核心是降低用户的决策负担。用户看到这段话第一反应是“哦它知道自己在干什么”第二反应是“我只需要确认一个点”。而不是“它又问我一大堆”。4.4 反例部分为什么不能省反例是 SKILL.md 里最容易被忽略、但效果最好的部分。因为 AI 对“不要做什么”的学习往往比“要做什么”更深刻。我列的反例包括不要问“你希望我用什么命名风格”这种猜错也无所谓的问题不要在已经给出明确指令的情况下再问一遍确认不要问“你确定吗”这种没有信息量的确认不要在任务刚开始就问一堆问题先做能做的这些反例都是我从实际踩坑里总结出来的。比如“不要问‘你确定吗’”是因为我发现 AI 有时候会在我已经说得很清楚的情况下再问一句“你确定要这样做吗”这纯粹是浪费交互。5. 实测这个 Skill 在真实任务里表现如何5.1 测试场景设计我设计了五个典型场景来测试这个 Skill 的效果覆盖“该问”“不该问”“先做后标”三类情况。场景任务描述期望行为场景 A删除一个未使用的函数提问确认场景 B给函数加日志直接执行场景 C重构一个模块的内部结构先执行后标注场景 D修改 API 返回字段提问确认场景 E调整代码缩进直接执行5.2 实测结果与偏差分析场景 A 和 D 表现符合预期AI 都主动提问了而且提问格式符合模板。场景 B 和 E 也符合预期直接执行没有多余提问。问题出在场景 C。AI 判断“重构”属于“先执行后标注”但它执行的时候顺手把一个它认为“冗余”的边界判断删掉了。这个删除属于“高影响 不可逆”按规则应该提问但 AI 没有识别出来因为它把“重构”和“删除”当成了两个独立操作没有意识到重构过程中包含了删除。这个偏差让我意识到规则之间会有交叉AI 需要判断“复合操作”里是否包含高风险子操作。我在 SKILL.md 里补了一条### 复合操作的处理 - 如果一个操作包含多个子操作按子操作中风险最高的那个来决定策略 - 重构、优化、整理类操作如果过程中涉及删除按“删除”规则处理补完这条之后场景 C 的表现就正常了。5.3 一个意外收获AI 开始“解释自己的判断”加了 Skill 之后我发现 AI 不仅行为变了还会主动解释自己的判断。比如它会说“这个操作涉及删除按规则我需要先确认”。这种“解释”本身很有价值因为它让用户能理解 AI 的决策逻辑而不是觉得 AI 在随机行为。这个效果不是我刻意设计的是 Skill 的结构自然带来的——因为 SKILL.md 里写了明确的规则AI 在执行时会“引用”这些规则来解释自己的行为。这算是意外之喜。6. 踩过的坑那些让我改了好几版的细节6.1 坑一规则太细AI 反而不会判断了第一版 SKILL.md 我写了 30 多条规则覆盖各种细枝末节。结果 AI 执行的时候经常在两条规则之间犹豫最后选了一个奇怪的折中方案。后来我砍到 12 条只保留最核心的判断效果反而好了。教训是Skill 的规则要“少而硬”不要“多而软”。宁可漏掉一些边缘情况也不要让规则之间互相打架。6.2 坑二默认值给得太随意用户不信任早期我在提问模板里给的默认值有时候是随便选的。结果用户发现默认值经常不对就开始不信任默认值每次都要手动改。后来我规定默认值必须是“大多数情况下正确”的选择并且要给出理由。比如“默认用 info 级别因为这是生产环境惯例”而不是“默认用 info”。6.3 坑三忘了处理“用户明确说不用问”的情况有一次用户明确说“你直接做不用问我”但 AI 还是按 Skill 规则提问了。这是因为 Skill 的优先级高于用户的即时指令。后来我在 SKILL.md 开头加了一条### 优先级 - 用户的明确指令 本 Skill 规则 - 如果用户说“直接做”“不用问”跳过所有提问环节这条规则很重要因为 Skill 是“默认行为准则”不是“强制约束”。用户永远有最终决定权。6.4 坑四不同模型对 Skill 的遵循程度不一样我分别在几个不同的模型上测试了同一个 SKILL.md发现遵循程度差异很大。有的模型几乎完全按规则执行有的模型会“选择性忽略”一些它觉得不重要的规则。这个差异目前没有特别好的解决办法只能针对主要使用的模型做调优。我的经验是规则写得越具体、越接近“可执行代码”模型的遵循程度越高。7. 怎么把这个 Skill 扩展到你自己的场景7.1 从“代码修改”扩展到“文档写作”这套判断逻辑不限于代码场景。比如 AI 帮你写文档时“删除一个章节”是高影响不可逆应该问“调整段落顺序”是高影响可逆可以先做后标“改错别字”是低影响可逆直接做。你只需要把 SKILL.md 里的判断规则换成文档场景的条目就行。7.2 从“单 Skill”扩展到“Skill 组合”这个 Skill 可以和别的 Skill 组合使用。比如你有一个“代码风格 Skill”和一个“澄清意图 Skill”前者管“怎么写”后者管“该不该问”。两个 Skill 各管各的互不干扰。组合的关键是触发条件不要重叠否则会出现规则冲突。7.3 一个可以立刻上手的起步方案如果你想自己试我建议从最小版本开始。先写三条规则删除必问、接口变更必问、格式调整不问。跑一周看看 AI 在哪些场景下判断错了再针对性补规则。不要一上来就写 20 条那样你根本不知道哪条规则在起作用。7.4 关于“教 AI 判断”这件事的一点个人体会我做了这么久 Agent 相关的东西最大的体会是不要试图让 AI 拥有“判断力”而是给它一套“判断规则”。判断力是模糊的、依赖经验的AI 学不会判断规则是明确的、可执行的AI 能学会。这个 Skill 的本质就是把人类工程师脑子里的那套“该不该问”的直觉翻译成 AI 能执行的规则。翻译得好不好直接决定了 AI 的行为是“靠谱”还是“添乱”。最后分享一个我一直在用的小技巧每次 AI 判断错了不要只改规则还要把这次错误记下来作为反例加到 SKILL.md 里。反例积累到一定数量AI 的判断准确率会有明显提升。这比单纯加规则有效得多因为反例告诉 AI“这种情况下你上次错了”比“这种情况下你应该怎么做”更有约束力。 用 Skill 教 AI 判断该不该问：clarify-intent 设计实践
1. 从“AI 要么问一堆、要么闷头做错”说起用 AI 写代码、做方案、跑流程的人大概率都遇到过这两种极端。第一种是“话痨型”你让它改一个函数它先反问你五个问题——目标语言是什么、要不要兼容旧版本、命名风格偏好、有没有测试覆盖、要不要顺便重构。你只是想让它把if里的判断反过来它却像刚入职的实习生一样谨慎到让人抓狂。第二种是“闷头型”你让它给一个模块加日志它二话不说把整个文件重写了一遍顺手改了两个你没让它动的函数还删了一行你觉得“看起来没用但其实是兜底”的判断。等你发现的时候diff 已经几百行了。这两种表现看起来是性格差异本质上是同一个问题AI 没有判断“该不该问”的能力。它要么把“不确定”全部外化成提问要么把“不确定”全部内化成猜测。而人类工程师在这件事上有一套非常成熟的直觉——什么时候该停下来确认什么时候该按惯例直接做什么时候该先做一版再让人 review。这套直觉就是我想用一个 Skill 去教给 AI 的东西。这篇内容适合三类人看一是天天和 AI 结对编程、被它的“问”和“猜”反复折磨的开发者二是正在做 Agent 开发、需要设计“澄清意图”环节的工程师三是想理解 Skill 机制到底能解决什么问题的技术人。我会把整个 Skill 的设计思路、SKILL.md 怎么写、判断逻辑怎么落地、实测中踩了哪些坑全部摊开讲。核心关键词就几个Skill、clarify-intent、SKILL.md、Agent。读完你应该能自己写一个类似的 Skill塞进你的 Agent 工作流里。先说结论这个 Skill 不复杂核心就是一张“该问 / 不该问”的判断表加上一套把“问”的成本压到最低的提问模板。难的不是写代码难的是想清楚边界在哪。下面我按“为什么要做 → 判断逻辑怎么设计 → SKILL.md 怎么写 → 实测踩坑 → 怎么扩展”这个顺序讲中间会穿插大量我自己的取舍过程。2. 为什么“该不该问”是个值得单独做成 Skill 的问题2.1 澄清意图的成本被大多数人低估了很多人觉得“多问一句总没错”但在 Agent 场景里问一句的成本远比想象中高。一次提问意味着一次交互往返意味着用户要重新进入上下文、理解 AI 在问什么、组织语言回答。如果这个 Agent 是跑在自动化流程里的一次提问可能直接导致流程中断需要人工介入。我做过一个粗略统计在一个中等复杂度的代码修改任务里如果 AI 平均问 3 个问题用户的实际操作时间会增加 40% 以上因为每次回答都要重新读一遍 AI 的问题描述。反过来“闷头做错”的成本更高。错误的理解会导致错误的产出错误的产出需要 review 才能发现发现之后还要回滚、重做。更麻烦的是有些错误是“看起来对”的——AI 改了一个它以为等价、实际上改变了边界行为的判断测试可能都测不出来上线之后才炸。这种隐性成本比多问几句可怕得多。所以真正的问题不是“问还是不问”而是在什么条件下问、问什么、怎么问。这三件事想清楚了AI 的行为就会从“随机”变成“可预期”。2.2 Skill 机制为什么适合承载这种判断Skill 的本质是一段可复用的、带触发条件的指令集。它和普通的 prompt 最大的区别在于Skill 有明确的触发场景和执行边界。你可以把它理解成一个“插件化的行为准则”——当 Agent 判断当前任务落在这个 Skill 的适用范围内时就加载这套准则来约束自己的行为。用 Skill 来承载“该不该问”的判断有几个天然优势。第一它是声明式的你可以把判断规则写成清晰的条目而不是散落在系统提示词里。第二它是可组合的一个 Agent 可以同时挂载“澄清意图 Skill”和“代码风格 Skill”各管各的。第三它是可迭代的你发现某类问题 AI 总是判断错直接改 SKILL.md 里对应的条目就行不用动整个系统提示词。这也是为什么我选择用 SKILL.md 这种格式来写。它足够简单纯文本、结构化、人和模型都能读又足够灵活可以塞进判断表、示例、反例、边界条件。下面我会详细讲这个文件的结构。2.3 一个反直觉的观察AI 问得越多往往说明它越“没底”我观察过很多次 AI 的提问行为发现一个规律AI 提问的数量和它对任务的理解程度成反比。当它完全理解任务时它几乎不问当它完全不理解时它会问一堆泛泛的问题最危险的是中间状态——它以为自己理解了问了一两个“看起来专业”的问题然后基于错误的假设闷头做下去。这个观察直接影响了我的 Skill 设计。我不追求“让 AI 少问”我追求的是让 AI 在真正关键的分歧点上问在无关紧要的细节上自己拍板。换句话说判断标准不是“问的数量”而是“问的质量”。一个高质量的提问应该指向一个“如果猜错会导致返工”的决策点一个低质量的提问问的是“你希望我用 tab 还是空格”这种猜错了也无所谓的事。3. 判断逻辑的核心把“不确定”分成四类3.1 四象限分类法我把 AI 在任务中遇到的所有“不确定”分成四类对应四种处理策略。这个分类是整个 Skill 的骨架。不确定类型特征处理策略举例高影响 低可逆猜错代价大且难以回滚必须问删除数据、修改对外接口、改变核心业务逻辑高影响 高可逆猜错代价大但容易改回来先做做完标注重构、调整架构、改命名规范低影响 低可逆猜错代价小但难回滚问但给默认选项配置文件格式、日志级别低影响 高可逆猜错代价小容易改直接做不问代码格式、注释风格、变量命名这张表看起来简单但真正落地的时候难点在于判断“影响”和“可逆性”。AI 不是人它没有“这个改动会不会影响线上”的直觉。所以我在 Skill 里加了一条硬规则任何涉及“删除”“覆盖”“对外暴露”的操作一律归为高影响。这条规则牺牲了一点效率但极大降低了灾难性错误的概率。3.2 为什么“可逆性”比“影响”更重要很多人设计这类判断逻辑时只看“影响大小”忽略“可逆性”。但实测下来可逆性才是更关键的维度。原因很简单高影响但可逆的错误成本是“改回来”高影响且不可逆的错误成本是“无法挽回”。前者最多浪费一点时间后者可能造成真实损失。举个我踩过的坑。有一次我让 AI 帮我整理一个项目的依赖它判断“某个依赖看起来没被引用”直接把它从package.json里删了。这个操作影响不算特别大但不可逆——它没有先备份也没有在 diff 里高亮这个删除。结果那个依赖是通过动态加载引用的静态扫描扫不出来删完之后构建直接挂了。从那以后我在 Skill 里加了一条任何删除操作必须先列出“将要删除的内容”等确认后再执行。这条规则让 AI 在删除场景下从“闷头做”变成了“先问”。3.3 默认值策略让“问”变得便宜光判断“该不该问”还不够还得解决“怎么问才不烦人”。我的做法是凡是需要问的必须同时给出默认选项。用户可以直接说“用默认”或者只回答有分歧的那一项。比如 AI 需要确认日志级别它不应该问“你希望日志级别是什么”而应该问我准备把日志级别设为info默认因为这是大多数生产环境的惯例。如果你需要debug或warn告诉我。这样用户如果同意默认值一个字都不用回如果有不同意见只需要说“改成 warn”。实测下来这种“带默认值的提问”能把用户的回答成本降低 60% 以上因为大部分情况下默认值就是对的。3.4 一个容易忽略的点问的时机“该不该问”之外还有一个维度是“什么时候问”。我的经验是能批量问的不要分散问。如果 AI 在执行任务过程中发现三个需要确认的点不要做一步问一次而是先把能做的做完把三个问题攒在一起一次性问清楚。这样做的好处是减少交互往返次数。用户回答一次AI 继续执行而不是被打断三次。实现上我在 Skill 里定义了一个“待确认队列”AI 遇到需要问的点时先记下来继续执行不受影响的部分等执行到必须停下来的时候把队列里的问题一起抛出来。4. SKILL.md 怎么写结构、字段与示例4.1 文件整体结构我的 SKILL.md 分成五个部分元信息、触发条件、判断规则、提问模板、反例。下面逐段讲。--- name: clarify-intent description: 判断 AI 在任务执行中应该主动提问还是直接执行 trigger: 当任务涉及代码修改、文件操作、配置变更时 --- # Clarify Intent Skill ## 判断规则 四象限分类法的具体条目 ## 提问模板 带默认值的提问格式 ## 反例 不该问的情况、不该猜的情况元信息部分用 YAML front matter这是 SKILL.md 的常见约定。trigger字段很关键它决定了这个 Skill 什么时候被加载。我把它限定在“代码修改、文件操作、配置变更”这三类场景因为这三类是最容易出“不可逆错误”的。4.2 判断规则怎么写才可执行判断规则不能写成“要谨慎”“要判断影响”这种空话必须写成可匹配的条件。我的写法是“条件 → 动作”的形式## 判断规则 ### 必须提问的情况 - 操作涉及删除文件、删除代码块、删除配置项 - 操作会修改对外接口函数签名、API 路径、数据结构 - 操作会改变核心业务逻辑的判断条件 - 存在两种以上合理解释且不同解释会导致不同实现 ### 直接执行的情况 - 代码格式调整缩进、空格、换行 - 注释补充、文档字符串完善 - 变量重命名局部作用域内 - 添加日志、添加类型标注 ### 先执行后标注的情况 - 重构保持行为不变的前提下 - 调整文件组织结构 - 优化性能不改变对外行为这里的关键是每条规则都要能被具体匹配。“删除文件”是明确的“谨慎处理”是模糊的。AI 对模糊指令的执行效果很差对明确条件的执行效果很好。4.3 提问模板的设计细节提问模板我改了七八版最后稳定下来的格式是这样的## 提问模板 当需要提问时按以下格式 1. 一句话说明当前情况 2. 列出我准备采用的默认方案及理由 3. 列出需要确认的具体点不超过 3 个 4. 说明如果不确认我会按默认方案继续 示例 我准备重构 utils/parser.js把解析逻辑拆成三个函数。 默认方案保持对外接口不变只调整内部结构。 需要确认拆分粒度是否按“词法/语法/语义”三层 如果不回复我按默认方案继续完成后你可以 review diff。这个模板的核心是降低用户的决策负担。用户看到这段话第一反应是“哦它知道自己在干什么”第二反应是“我只需要确认一个点”。而不是“它又问我一大堆”。4.4 反例部分为什么不能省反例是 SKILL.md 里最容易被忽略、但效果最好的部分。因为 AI 对“不要做什么”的学习往往比“要做什么”更深刻。我列的反例包括不要问“你希望我用什么命名风格”这种猜错也无所谓的问题不要在已经给出明确指令的情况下再问一遍确认不要问“你确定吗”这种没有信息量的确认不要在任务刚开始就问一堆问题先做能做的这些反例都是我从实际踩坑里总结出来的。比如“不要问‘你确定吗’”是因为我发现 AI 有时候会在我已经说得很清楚的情况下再问一句“你确定要这样做吗”这纯粹是浪费交互。5. 实测这个 Skill 在真实任务里表现如何5.1 测试场景设计我设计了五个典型场景来测试这个 Skill 的效果覆盖“该问”“不该问”“先做后标”三类情况。场景任务描述期望行为场景 A删除一个未使用的函数提问确认场景 B给函数加日志直接执行场景 C重构一个模块的内部结构先执行后标注场景 D修改 API 返回字段提问确认场景 E调整代码缩进直接执行5.2 实测结果与偏差分析场景 A 和 D 表现符合预期AI 都主动提问了而且提问格式符合模板。场景 B 和 E 也符合预期直接执行没有多余提问。问题出在场景 C。AI 判断“重构”属于“先执行后标注”但它执行的时候顺手把一个它认为“冗余”的边界判断删掉了。这个删除属于“高影响 不可逆”按规则应该提问但 AI 没有识别出来因为它把“重构”和“删除”当成了两个独立操作没有意识到重构过程中包含了删除。这个偏差让我意识到规则之间会有交叉AI 需要判断“复合操作”里是否包含高风险子操作。我在 SKILL.md 里补了一条### 复合操作的处理 - 如果一个操作包含多个子操作按子操作中风险最高的那个来决定策略 - 重构、优化、整理类操作如果过程中涉及删除按“删除”规则处理补完这条之后场景 C 的表现就正常了。5.3 一个意外收获AI 开始“解释自己的判断”加了 Skill 之后我发现 AI 不仅行为变了还会主动解释自己的判断。比如它会说“这个操作涉及删除按规则我需要先确认”。这种“解释”本身很有价值因为它让用户能理解 AI 的决策逻辑而不是觉得 AI 在随机行为。这个效果不是我刻意设计的是 Skill 的结构自然带来的——因为 SKILL.md 里写了明确的规则AI 在执行时会“引用”这些规则来解释自己的行为。这算是意外之喜。6. 踩过的坑那些让我改了好几版的细节6.1 坑一规则太细AI 反而不会判断了第一版 SKILL.md 我写了 30 多条规则覆盖各种细枝末节。结果 AI 执行的时候经常在两条规则之间犹豫最后选了一个奇怪的折中方案。后来我砍到 12 条只保留最核心的判断效果反而好了。教训是Skill 的规则要“少而硬”不要“多而软”。宁可漏掉一些边缘情况也不要让规则之间互相打架。6.2 坑二默认值给得太随意用户不信任早期我在提问模板里给的默认值有时候是随便选的。结果用户发现默认值经常不对就开始不信任默认值每次都要手动改。后来我规定默认值必须是“大多数情况下正确”的选择并且要给出理由。比如“默认用 info 级别因为这是生产环境惯例”而不是“默认用 info”。6.3 坑三忘了处理“用户明确说不用问”的情况有一次用户明确说“你直接做不用问我”但 AI 还是按 Skill 规则提问了。这是因为 Skill 的优先级高于用户的即时指令。后来我在 SKILL.md 开头加了一条### 优先级 - 用户的明确指令 本 Skill 规则 - 如果用户说“直接做”“不用问”跳过所有提问环节这条规则很重要因为 Skill 是“默认行为准则”不是“强制约束”。用户永远有最终决定权。6.4 坑四不同模型对 Skill 的遵循程度不一样我分别在几个不同的模型上测试了同一个 SKILL.md发现遵循程度差异很大。有的模型几乎完全按规则执行有的模型会“选择性忽略”一些它觉得不重要的规则。这个差异目前没有特别好的解决办法只能针对主要使用的模型做调优。我的经验是规则写得越具体、越接近“可执行代码”模型的遵循程度越高。7. 怎么把这个 Skill 扩展到你自己的场景7.1 从“代码修改”扩展到“文档写作”这套判断逻辑不限于代码场景。比如 AI 帮你写文档时“删除一个章节”是高影响不可逆应该问“调整段落顺序”是高影响可逆可以先做后标“改错别字”是低影响可逆直接做。你只需要把 SKILL.md 里的判断规则换成文档场景的条目就行。7.2 从“单 Skill”扩展到“Skill 组合”这个 Skill 可以和别的 Skill 组合使用。比如你有一个“代码风格 Skill”和一个“澄清意图 Skill”前者管“怎么写”后者管“该不该问”。两个 Skill 各管各的互不干扰。组合的关键是触发条件不要重叠否则会出现规则冲突。7.3 一个可以立刻上手的起步方案如果你想自己试我建议从最小版本开始。先写三条规则删除必问、接口变更必问、格式调整不问。跑一周看看 AI 在哪些场景下判断错了再针对性补规则。不要一上来就写 20 条那样你根本不知道哪条规则在起作用。7.4 关于“教 AI 判断”这件事的一点个人体会我做了这么久 Agent 相关的东西最大的体会是不要试图让 AI 拥有“判断力”而是给它一套“判断规则”。判断力是模糊的、依赖经验的AI 学不会判断规则是明确的、可执行的AI 能学会。这个 Skill 的本质就是把人类工程师脑子里的那套“该不该问”的直觉翻译成 AI 能执行的规则。翻译得好不好直接决定了 AI 的行为是“靠谱”还是“添乱”。最后分享一个我一直在用的小技巧每次 AI 判断错了不要只改规则还要把这次错误记下来作为反例加到 SKILL.md 里。反例积累到一定数量AI 的判断准确率会有明显提升。这比单纯加规则有效得多因为反例告诉 AI“这种情况下你上次错了”比“这种情况下你应该怎么做”更有约束力。