1. 从两个极端说起AI 为什么总在“问”和“做”之间反复横跳用 AI 写代码、做方案、跑流程的人大概率都遇到过这两种让人血压升高的场景。第一种你让它帮你重构一个函数它反手甩回来五个问题“请问你希望用哪种设计模式”“是否需要保留原有接口”“目标运行环境是什么版本”“有没有性能要求”“要不要加单元测试”——你只是想让它把那段重复的 if-else 抽一下结果它像个刚入职的实习生事事请示寸步难行。第二种更气人。你让它“把用户模块的登录逻辑改一下”它二话不说埋头就干改完你一看它把整个鉴权体系重写了还顺手删掉了你精心设计的限流逻辑。你问它为什么这么改它说“我理解你的需求是优化登录流程”。它确实做了但做的是它自己脑补出来的那个需求。这两个极端背后其实是同一个问题AI 缺乏对“意图确定性”的判断能力。它不知道该在什么时候停下来确认什么时候该直接推进。而这个判断能力恰恰是人类工程师和 AI 之间最大的差距之一。我写这个 Skill 的初衷很简单让 AI 学会像人一样判断——这件事我有没有把握没把握就问有把握就做做完再汇报。听起来像废话但真正把它拆成可执行的规则、写进 SKILL.md、让 Agent 稳定遵守中间踩的坑比想象中多得多。这篇文章就把整个设计思路、SKILL.md 的写法、clarify-intent 的判断逻辑、以及实际跑下来遇到的问题完整地摊开讲一遍。如果你也在做 Agent 开发或者正在被 AI 的“过度确认”和“过度自信”折磨这篇应该能帮你省不少时间。2. 核心设计思路把“该不该问”拆成可计算的信号2.1 为什么不能靠一句“不确定就问”解决问题最开始我试过最朴素的办法在系统提示词里加一句“如果你不确定用户意图请先询问”。结果呢AI 要么把“不确定”的阈值调得极低什么鸡毛蒜皮都问要么完全忽略这句话该问的时候不问。问题出在“不确定”这个词太模糊了。对人类来说“不确定”是一种主观感受对 AI 来说它需要一个可操作的判断依据。你说“不确定就问”它根本不知道什么算不确定。是信息缺失算不确定还是存在多种合理解释算不确定还是它自己没把握算不确定所以我做的第一件事是把“该不该问”从一个主观判断拆解成几个可观测的信号。这些信号包括信息完整度完成任务所需的关键参数是否齐全歧义程度当前描述是否存在两种以上同样合理的解读操作可逆性如果做错了后果是否容易撤销影响范围这个操作会波及多少下游模块或数据历史上下文之前的对话或项目里有没有相关约定这五个信号组合起来就能形成一个相对清晰的判断矩阵。不是所有信号都要满足才问而是根据权重综合判断。2.2 clarify-intent 的核心判断矩阵我把这套逻辑叫做clarify-intent直译就是“澄清意图”。它的核心是一个四象限判断信息完整度操作可逆性判断结果行为高高直接执行做完汇报高低执行前确认简要说明方案等确认低高先做合理假设执行并标注假设低低必须询问列出关键问题等回答这个矩阵看起来简单但真正让它跑起来需要解决几个关键问题。第一个问题是信息完整度怎么量化我的做法是在 SKILL.md 里为每类任务定义“必需参数清单”。比如“修改函数”这个任务必需参数包括目标函数名、修改目标、约束条件。如果用户只说了“改一下登录逻辑”那目标函数名和约束条件都缺失信息完整度就是低。第二个问题是操作可逆性怎么判断这个相对好办按操作类型分级就行。读操作、查询操作、生成新文件这些是可逆的修改现有代码、删除数据、覆盖配置这些是不可逆的。中间还有一些灰色地带比如“新增一个函数”算可逆但“修改一个被多处引用的函数签名”就算不可逆。第三个问题是当信息完整度低但操作可逆时怎么“做合理假设”这是最容易翻车的地方。我的经验是假设必须满足三个条件一是假设要显式标注出来二是假设要是最保守的那个选项三是假设不能引入新的依赖或副作用。2.3 SKILL.md 的结构设计让规则可读、可查、可执行SKILL.md 是整个 Skill 的载体。它的结构直接决定了 AI 能不能稳定遵守规则。我试过几种写法最后沉淀下来的结构是这样的# Skill: clarify-intent ## 元信息 - 名称: clarify-intent - 版本: 1.2 - 适用场景: 所有需要判断“是否询问用户”的任务 ## 核心原则 1. 宁可少问不可问错 2. 能假设则假设但假设必须显式 3. 不可逆操作必须确认 ## 判断流程 ### 第一步识别任务类型 ### 第二步检查必需参数 ### 第三步评估可逆性 ### 第四步输出判断结果 ## 各任务类型的必需参数清单 ## 可逆性分级表 ## 询问模板 ## 假设标注模板这个结构的关键在于判断流程是线性的、可逐步执行的。AI 不需要“理解”整个逻辑它只需要按步骤走。每一步都有明确的输入和输出这样稳定性就上来了。另外我把“询问模板”和“假设标注模板”也写进了 SKILL.md。因为实际跑下来发现AI 即使判断出该问问的方式也经常不对——要么问得太宽泛要么一次问太多要么问的方式让用户不舒服。模板能解决这个问题。3. 核心细节解析判断逻辑怎么写才不翻车3.1 必需参数清单的粒度控制必需参数清单是判断“信息完整度”的基础。粒度太粗判断不准粒度太细AI 记不住。我的经验是按“任务类型”而不是“具体操作”来定义。比如代码修改类目标文件/函数、修改目标、约束条件代码生成类功能描述、输入输出、运行环境方案设计类目标、约束、评估标准数据处理类数据源、处理逻辑、输出格式查询解释类查询对象、查询目的每个任务类型下面再根据实际情况细分。但总体控制在 3-5 个必需参数超过 5 个 AI 就容易漏。还有一个技巧区分“必需”和“可选”。必需参数缺失信息完整度直接判低可选参数缺失只做标注不影响判断。这样能避免 AI 因为一些边角料信息缺失就停下来问。3.2 可逆性分级的具体标准可逆性分级我分了五级从 A 到 E级别定义示例处理方式A完全可逆无副作用读取文件、查询信息直接执行B可逆但有轻微副作用生成新文件、新增函数直接执行汇报时说明C可逆但需要额外操作修改配置、调整参数执行前简要说明D不可逆但影响范围可控修改单个函数逻辑执行前确认E不可逆影响范围大删除数据、重构核心模块必须详细确认这个分级的关键在于C 和 D 的区分。C 级操作虽然可逆但撤销需要额外操作所以执行前要说明D 级操作不可逆但影响范围可控所以确认即可不需要详细讨论。实际跑下来大部分争议都发生在 C 和 D 之间。比如“修改一个函数的实现”算 C 还是 D我的判断标准是如果这个函数被多处引用算 D如果只在一处使用算 C。这个标准写进 SKILL.md 后AI 的判断就稳定多了。3.3 询问模板的设计怎么问才不让人烦询问模板是我踩坑最多的地方。最开始我让 AI“列出你不确定的地方”结果它一次列七八个问题用户看到就头大。后来改成“只问最关键的一个问题”又经常问不到点子上。最后我沉淀下来的模板是这样的在继续之前我需要确认一个关键点 [具体问题] 我之所以问这个是因为[简要说明影响]。 如果你希望我直接按[默认假设]处理也可以直接说“按默认来”。这个模板有三个关键设计第一只问一个问题。如果确实有多个问题按重要性排序只问最重要的那个。剩下的用假设处理在汇报时标注。第二说明为什么问。用户知道你为什么问才愿意回答。而且这个说明本身也是在帮用户理清思路。第三给一个默认选项。这样用户如果不想回答可以直接说“按默认来”不会卡住。实测下来这个模板的回复率比“列出所有问题”高了不止一倍。因为用户感受到的是“你在帮我做决定”而不是“你在把问题甩给我”。3.4 假设标注的写法让用户一眼看到风险当 AI 选择“做合理假设”时假设必须显式标注。标注的写法也有讲究。我试过几种写法最后固定为 假设说明我假设[具体假设内容]。如果你希望[另一种可能]请告诉我我可以调整。这个写法放在执行结果的开头用引用块突出。关键是假设内容要具体不能写“我假设了一些东西”。比如假设说明我假设你希望保留原有的错误处理逻辑。如果你希望一并重构请告诉我。这样用户一眼就能看到 AI 做了什么假设以及如果假设不对该怎么纠正。还有一个细节假设不能太多。如果一次执行标注了三个以上假设说明信息完整度确实太低应该直接问而不是硬做。我在 SKILL.md 里加了一条硬规则假设数量超过两个强制转为询问。4. 实操过程从零写一个 clarify-intent Skill4.1 环境准备与文件结构这个 Skill 不依赖任何特定框架理论上任何支持 SKILL.md 的 Agent 平台都能用。我自己的测试环境是基于常见的 Agent 开发框架文件结构如下skills/ clarify-intent/ SKILL.md examples/ case-01-code-modify.md case-02-data-process.md case-03-query.md templates/ ask-template.md assume-template.mdSKILL.md 是核心examples 放典型场景的完整对话记录templates 放询问和假设的模板。examples 很重要因为 AI 在学习 Skill 时示例比规则更容易被“理解”。4.2 SKILL.md 完整写法下面是我实际在用的 SKILL.md 核心内容去掉了一些平台特定的配置# Skill: clarify-intent ## 元信息 - 名称: clarify-intent - 版本: 1.2 - 适用场景: 所有需要判断“是否询问用户”的任务 - 优先级: 高覆盖默认的“不确定就问”行为 ## 核心原则 1. 宁可少问不可问错。问错问题比不问更伤用户体验。 2. 能假设则假设但假设必须显式标注且不超过两个。 3. 不可逆操作必须确认可逆操作直接执行。 4. 询问时只问最关键的一个问题并给出默认选项。 ## 判断流程 ### 第一步识别任务类型 从以下类型中选择最匹配的一个 - 代码修改类 - 代码生成类 - 方案设计类 - 数据处理类 - 查询解释类 - 其他按最接近的类型处理 ### 第二步检查必需参数 对照“必需参数清单”检查用户输入中是否包含所有必需参数。 - 全部包含信息完整度 高 - 缺失 1 个信息完整度 中 - 缺失 2 个及以上信息完整度 低 ### 第三步评估可逆性 对照“可逆性分级表”确定当前操作的可逆性级别。 - A/B 级可逆性 高 - C 级可逆性 中 - D/E 级可逆性 低 ### 第四步输出判断结果 根据信息完整度和可逆性查“判断矩阵”得出行为 - 高 高直接执行做完汇报 - 高 中执行前简要说明 - 高 低执行前确认 - 中 高直接执行标注假设 - 中 中执行前说明并标注假设 - 中 低询问 - 低 高直接执行标注假设不超过两个 - 低 中询问 - 低 低必须询问 ## 必需参数清单 ### 代码修改类 - 目标文件或函数 - 修改目标要改成什么样 - 约束条件不能动什么 ### 代码生成类 - 功能描述 - 输入输出 - 运行环境 ### 方案设计类 - 目标 - 约束 - 评估标准 ### 数据处理类 - 数据源 - 处理逻辑 - 输出格式 ### 查询解释类 - 查询对象 - 查询目的 ## 可逆性分级表 | 级别 | 定义 | 示例 | |-----|------|------| | A | 完全可逆无副作用 | 读取文件、查询信息 | | B | 可逆轻微副作用 | 生成新文件、新增函数 | | C | 可逆需额外操作 | 修改配置、调整参数 | | D | 不可逆影响可控 | 修改单个函数逻辑 | | E | 不可逆影响大 | 删除数据、重构核心模块 | ## 询问模板 见 templates/ask-template.md ## 假设标注模板 见 templates/assume-template.md ## 禁止行为 - 禁止一次询问超过一个问题 - 禁止在假设超过两个时仍不询问 - 禁止对 D/E 级操作不确认就执行 - 禁止询问时不给默认选项这个 SKILL.md 的核心特点是判断流程是确定性的。给定输入输出是唯一的。这样 AI 就不会“自由发挥”。4.3 三个典型场景的完整跑通记录场景一代码修改类信息完整度高可逆性中用户输入“把getUserInfo函数里的console.log都删掉。”判断过程任务类型代码修改类必需参数目标函数getUserInfo有、修改目标“删掉 console.log”有、约束条件未明确但删日志属于低风险操作可视为无特殊约束信息完整度高可逆性修改现有函数但只是删日志影响可控判 C 级判断结果高 中 → 执行前简要说明AI 输出“我将删除getUserInfo函数中的所有console.log语句不改变其他逻辑。开始执行。”执行后汇报“已删除 3 处console.log分别在第 12、18、25 行。其他逻辑未改动。”这个场景跑下来很顺用户不需要额外确认AI 也没有多问。场景二数据处理类信息完整度低可逆性高用户输入“帮我把这个 CSV 处理一下。”判断过程任务类型数据处理类必需参数数据源有但未指定具体文件、处理逻辑缺失、输出格式缺失信息完整度低可逆性生成新文件判 B 级判断结果低 高 → 直接执行标注假设不超过两个AI 输出假设说明我假设你希望去除重复行并输出为新的 CSV 文件。如果你希望做其他处理请告诉我。然后执行去重输出新文件汇报结果。这个场景的关键是AI 没有问“你想怎么处理”而是做了一个最保守的假设去重并显式标注。用户如果满意就继续不满意就纠正。实测下来大部分用户对这个处理是满意的因为“处理一下 CSV”在多数语境下就是去重或格式化。场景三代码修改类信息完整度低可逆性低用户输入“把登录逻辑改一下。”判断过程任务类型代码修改类必需参数目标函数缺失登录逻辑涉及多个函数、修改目标缺失“改一下”太模糊、约束条件缺失信息完整度低可逆性登录逻辑通常被多处引用判 D 级判断结果低 低 → 必须询问AI 输出在继续之前我需要确认一个关键点你希望修改登录逻辑的哪个方面是验证方式、错误处理、还是会话管理我之所以问这个是因为登录逻辑涉及多个模块不同方向的修改影响范围差异很大。如果你希望我直接按“优化错误提示”处理也可以直接说“按默认来”。这个场景就是典型的“必须问”。如果 AI 不问直接改很可能改错方向。4.4 参数调优阈值怎么定才合适判断矩阵里的阈值不是拍脑袋定的我调了好几轮。最开始“信息完整度”只有高/低两档结果发现很多中间状态没法处理。比如缺失一个必需参数算高还是低后来加了“中”档缺失一个算中缺失两个及以上算低。可逆性也是最开始只有高/低后来发现 C 级操作可逆但需额外操作既不能直接执行也不值得详细确认就单独拎出来作为“中”档。调参的依据是实际跑下来的误判率。我统计了 100 次判断看哪些判断和我的预期不符然后调整阈值。调整了大概三轮误判率从最初的 30% 降到了 8% 左右。剩下的 8% 主要是边界情况比如“修改一个被两处引用的函数”算 C 还是 D。这种边界情况我选择在 SKILL.md 里写明确规则而不是继续调阈值。规则明确后AI 的判断就稳定了。5. 常见问题与排查技巧实录5.1 AI 不遵守 SKILL.md 怎么办这是最常见的问题。明明写了规则AI 还是按自己的习惯来。排查思路首先检查 SKILL.md 的优先级设置。如果平台支持优先级确保 clarify-intent 的优先级高于默认行为。其次检查规则是否太复杂。如果判断流程超过四步AI 容易漏。我的经验是控制在四步以内。最后检查是否有冲突规则。比如系统提示词里如果有“不确定就问”会和 clarify-intent 冲突。需要把系统提示词里的相关规则删掉或覆盖。还有一个技巧在 SKILL.md 开头加一句“本 Skill 覆盖默认的询问行为”明确告诉 AI 以这个为准。5.2 询问模板被忽略AI 还是问一堆这个问题通常是因为模板没有放在显眼位置。我的做法是把模板直接内联在 SKILL.md 里而不是放在单独文件。虽然文件结构上不够优雅但实际效果更好。另外在“禁止行为”里明确写“禁止一次询问超过一个问题”比在模板里写“只问一个问题”更有效。因为 AI 对“禁止”的敏感度高于“应该”。5.3 假设标注不显眼用户没看到假设标注如果放在执行结果末尾用户经常看不到。我的做法是放在开头用引用块突出。如果平台支持还可以加粗。还有一个技巧在假设标注里加一句“如果你希望调整请告诉我”给用户一个明确的行动指引。这样即使假设不对用户也知道该怎么纠正。5.4 判断矩阵在边界情况下失效边界情况是难免的。我的处理方式是在 SKILL.md 里维护一个“边界情况清单”把遇到过的边界情况都写进去并明确判断结果。比如修改被多处引用的函数判 D 级生成新文件但文件名与现有文件冲突判 C 级查询操作但查询范围不明确判 B 级直接执行并标注假设这个清单会随着使用不断补充。每次遇到新的边界情况就加进去。这样 AI 的判断会越来越准。5.5 常见问题速查表问题可能原因解决方法AI 不遵守规则优先级低或规则冲突提高优先级删除冲突规则询问模板被忽略模板位置不显眼内联模板加禁止行为假设标注不显眼位置靠后放在开头用引用块边界情况判断错规则未覆盖加入边界情况清单判断流程漏步步骤太多精简到四步以内询问太多阈值太敏感调高信息完整度阈值该问不问阈值太宽松调低可逆性阈值5.6 独家避坑技巧技巧一用示例代替规则。AI 对示例的“理解”比规则好。在 examples 目录里放几个典型场景的完整对话记录比在 SKILL.md 里写一堆规则更有效。技巧二规则要短。每条规则控制在一行以内。超过一行的规则AI 容易漏掉后半句。技巧三用“禁止”代替“应该”。“禁止一次问多个问题”比“应该只问一个问题”更有效。技巧四定期回顾误判。每隔一段时间回顾一下 AI 的判断记录看哪些判断和预期不符然后调整规则。这个习惯能让 Skill 持续进化。技巧五不要追求完美。判断准确率到 90% 左右就够了剩下的 10% 边界情况用户自己会纠正。追求 100% 准确率会导致规则过于复杂反而降低稳定性。6. 这个 Skill 还能怎么扩展clarify-intent 目前只解决了“该不该问”的问题但实际使用中还有几个方向可以继续挖。第一个方向是多轮对话中的意图追踪。当前版本只看单次输入如果用户在多轮对话中逐步补充信息AI 需要能记住之前的判断避免重复询问。这个需要在 SKILL.md 里加“上下文记忆”规则。第二个方向是不同任务类型的差异化阈值。目前所有任务类型共用一套阈值但实际跑下来代码修改类和方案设计类的判断标准应该不一样。代码修改类可以更激进多假设少问方案设计类应该更保守多问少假设。这个可以通过在 SKILL.md 里为每类任务单独定义阈值来实现。第三个方向是与 Agent 执行框架的深度集成。目前 clarify-intent 是一个独立的 Skill如果能在 Agent 的执行流程里嵌入判断节点效果会更好。比如在每次工具调用前自动跑一遍 clarify-intent判断是否需要确认。第四个方向是用户反馈学习。如果用户经常纠正 AI 的假设说明假设策略需要调整。可以记录用户的纠正行为自动调整阈值。这个需要平台支持但思路是可行的。我目前在做的是第一个和第二个方向。多轮对话的意图追踪已经跑通了基本逻辑差异化阈值还在调参。等这两个方向稳定了再考虑后面两个。最后分享一个实际使用中的小体会这个 Skill 最大的价值不是让 AI 变聪明而是让 AI 的行为变得可预测。用户知道 AI 什么时候会问、什么时候会做、做错了怎么纠正这种可预测性比单纯的“智能”更重要。毕竟一个偶尔犯错的可靠助手比一个经常给你惊喜或惊吓的天才助手更让人放心。