1. 从两个极端说起AI 为什么总在“问太多”和“做太错”之间反复横跳用 AI Agent 干活的人大概率都经历过这两种让人血压升高的场景。第一种你让它帮你把一段会议纪要整理成待办清单它反手甩回来五个问题“请问待办事项需要包含负责人吗”“截止日期格式用哪种”“优先级怎么定义”“输出用表格还是列表”“需要同步给相关人吗”——你只是想省五分钟结果花了十五分钟回答它的问卷。第二种更气人你让它把项目里所有console.log清理掉再提交它闷头一顿操作把测试文件里的断言日志也删了还顺手改了三个你没让它碰的配置文件。你 review diff 的时候只想顺着网线过去问它你刚才为什么不问我一句这两个极端背后其实是同一个问题Agent 缺少对“意图确定性”的判断能力。它不知道自己现在掌握的信息够不够支撑行动也不知道哪些操作属于“可逆的低风险动作”、哪些属于“一旦做错就要花半小时回滚的高危动作”。于是它只能靠一个固定的系统提示词来决定行为倾向——要么被写成“遇到不确定就问”要么被写成“尽量自主完成”然后就在某个极端上一路走到黑。我写这个 Skill 的出发点很朴素把“什么时候该问、什么时候该直接做”变成一套可复用的判断规则而不是每次靠临时改提示词碰运气。它不绑定某个特定 Agent 框架本质上是一份结构化的行为约束文档配合SKILL.md这种约定俗成的描述文件让 Agent 在每次决策前先过一遍“意图清晰度检查”。下面我把整套设计思路、判断逻辑、落地方式和踩过的坑完整拆开讲如果你正在做 Agent 开发、或者天天用 AI 编程工具被它的“过度确认”和“擅自行动”折磨这篇应该能直接抄作业。2. 整体设计思路把“该不该问”拆成可计算的判断维度2.1 为什么不是简单加一句“不确定就问”最直觉的方案是在系统提示词里加一句“如果你不确定用户的意图请先询问”。我试过效果很差。原因是“不确定”这个词对模型来说太模糊了它没有一个可操作的阈值。结果就是模型对“不确定”的判定极度保守——只要有任何一点信息缺失它就归类为“不确定”然后开始问问题。这就是“问一堆”的根源。反过来如果写“尽量自主完成不要频繁打断用户”模型又会走向另一个极端它会把“信息缺失”这件事直接忽略掉用自己脑补的默认值填上然后闷头执行。这就是“做错”的根源。所以核心思路不是调整“不确定”的敏感度而是把“不确定”拆解成几个独立的、可分别判断的维度。每个维度单独看可能都不致命但组合起来就能给出一个相对清晰的行为建议。这就像医生诊断不是只问“你难受吗”而是分科室、分指标逐项排查。2.2 四个核心判断维度我把意图确定性拆成了四个维度每个维度用高/中/低三档来评估维度含义高确定性表现低确定性表现目标清晰度用户想要达成的最终结果是否明确“把这份纪要转成待办清单”“帮我处理一下这个文档”范围边界操作涉及的文件、模块、数据范围是否明确“只改 src/utils 下的文件”“优化一下项目代码”风险等级操作是否可逆、影响面是否可控读取、分析、生成草稿删除、覆盖、批量修改、对外发送默认值合理性信息缺失时行业惯例或上下文能否给出安全默认值日期格式用 ISO 8601用户说“发给团队”但没说哪个团队判断逻辑是这样的目标清晰度和范围边界决定“要不要问”风险等级和默认值合理性决定“能不能直接做”。如果目标清晰但范围模糊且操作风险低那可以先做一版草稿再确认如果目标模糊但操作风险高那必须先问清楚再动手。2.3 为什么用 Skill 而不是硬编码有人会问这套逻辑为什么不直接写进 Agent 的代码里而要做成一个 Skill我的考虑有三点。第一可移植性。Skill 本质上是一份 Markdown 格式的行为描述文档不依赖特定框架的 API。你今天用这个 Agent 框架明天换一个Skill 文件可以直接带走。第二可迭代性。判断规则需要根据实际使用反馈不断调整改一份 Markdown 比改代码、重新部署快得多。第三可组合性。一个 Agent 可以同时加载多个 Skill意图判断 Skill 可以和代码审查 Skill、文档生成 Skill 叠加使用互不冲突。SKILL.md这个命名约定现在在 Agent 开发圈子里已经比较通用了它的作用是让 Agent 在启动时自动扫描并加载技能描述。文件里通常包含技能名称、触发条件、行为规则、示例对话等部分。我这份 Skill 的核心内容就是上面那四个维度的判断规则加上具体的决策树和示例。3. 核心细节解析判断规则怎么写才不会被模型忽略3.1 规则要写成“如果……那么……”而不是“应该……”这是我在反复调试中最大的一个心得。模型对“应该”“尽量”“建议”这类软性词汇的遵循度很低尤其是在长上下文里这些词很容易被淹没。但“如果 X 成立那么执行 Y”这种条件句式模型的遵循度明显更高。举个例子我最初的写法是“当用户意图不明确时应该先询问再行动。”实测下来模型经常忽略。后来改成“如果目标清晰度为低且风险等级为高那么必须先向用户确认目标后再执行。”遵循度立刻上来了。再比如默认值这块我写的是“如果信息缺失但存在行业通用默认值且风险等级为低或中那么使用默认值执行并在输出中标注‘此处使用了默认值 X如需调整请告知’。”这样模型既不会闷头做错也不会因为一个小格式问题就停下来问。3.2 风险等级需要具体枚举不能抽象描述“高风险操作”这种说法对模型来说太抽象了。什么算高风险改一个变量名算吗删一个文件算吗我后来把风险等级做成了具体操作的枚举清单高风险操作必须先确认删除文件、目录或数据记录覆盖已有文件内容非追加模式批量修改超过 10 个文件执行对外发送操作邮件、消息、API 调用修改配置文件、环境变量、密钥执行数据库写操作安装或卸载依赖包中风险操作可先做草稿再确认修改 3-10 个文件重构函数签名修改测试用例生成新文件低风险操作可直接执行读取、搜索、分析文件生成草稿、建议、示例格式化代码不改变逻辑添加注释这份清单不是拍脑袋定的是我在实际使用中根据“回滚成本”来划分的。回滚一个删除操作可能要翻备份回滚一个格式化操作只需要git checkout。回滚成本越高风险等级越高越需要提前确认。3.3 默认值的使用要有“标注义务”允许模型使用默认值但必须附带一个“标注义务”——在输出中明确告诉用户“我在这里用了默认值”。这个设计很关键它解决了“闷头做错”的问题。模型可以自主决策但决策必须是透明的。比如用户说“帮我把这个 JSON 转成 CSV”没说分隔符用什么。模型可以用逗号作为默认分隔符但输出时要加一句“默认使用逗号作为分隔符如果数据中包含逗号建议改用分号或制表符。”这样用户一眼就能看到模型的假设如果不对可以立刻纠正而不是等到导入数据失败才发现问题。3.4 询问要“批量”不要“逐个”这是解决“问一堆”的关键技巧。如果模型判断需要询问不要问一个问题等一个回答再问下一个而是把所有需要确认的点一次性列出来。我在这份 Skill 里写了一条规则“如果需要询问将所有待确认项整理为一个编号列表一次性提出避免多轮往返。”实测效果很明显。以前模型会问“请问输出格式是什么”你回答“Markdown”它又问“需要包含代码示例吗”你回答“需要”它再问“代码语言用什么”现在它会一次性问“请确认以下三点1. 输出格式Markdown/纯文本/表格2. 是否需要代码示例3. 代码语言偏好。”用户体验完全不一样。4. 实操过程从零写一份可用的意图判断 Skill4.1 文件结构设计一份完整的 Skill 目录结构大概是这样skills/ clarify-intent/ SKILL.md # 主描述文件 rules/ risk-levels.md # 风险等级枚举 defaults.md # 默认值清单 examples/ ask-first.md # 该问的示例 act-first.md # 该直接做的示例SKILL.md是入口文件Agent 启动时读取这个文件来了解技能的存在和行为概要。rules/目录下放具体的规则细节examples/目录下放正反示例。这种拆分的好处是主文件保持简洁Agent 不会因为一次性加载太多内容而忽略关键规则。4.2 SKILL.md 的核心内容主文件我控制在 200 行以内结构如下# Skill: clarify-intent ## 触发条件 每次接收到用户请求后在执行任何操作前先运行意图判断流程。 ## 判断流程 1. 评估目标清晰度高/中/低 2. 评估范围边界高/中/低 3. 评估风险等级高/中/低 4. 评估默认值合理性高/中/低 5. 根据组合结果决定行为 ## 决策矩阵 | 目标 | 范围 | 风险 | 默认值 | 行为 | |------|------|------|--------|------| | 高 | 高 | 任意 | 任意 | 直接执行 | | 高 | 低 | 低/中 | 高 | 使用默认值执行并标注 | | 高 | 低 | 高 | 任意 | 先确认范围 | | 低 | 任意 | 低/中 | 高 | 使用默认值执行并标注 | | 低 | 任意 | 高 | 任意 | 先确认目标 | | 任意 | 任意 | 任意 | 低 | 先确认缺失信息 | ## 询问规范 - 一次性列出所有待确认项 - 每个确认项给出推荐选项 - 避免开放式问题尽量用选择题这个决策矩阵是整个 Skill 的核心。它把四个维度的组合映射到了具体行为上模型只需要按表查就行不需要自己推理。这比让模型“自己判断”可靠得多。4.3 风险等级枚举文件的写法rules/risk-levels.md里我把常见操作按风险等级分类并且给每个等级配了处理方式# 风险等级定义 ## 高风险 处理方式必须先获得用户明确确认确认前不得执行。 操作清单 - 删除操作文件、目录、数据记录 - 覆盖写入非追加 - 批量修改10 个文件 - 对外发送邮件、消息、API 调用 - 配置修改配置文件、环境变量、密钥 - 数据库写操作 - 依赖变更安装、卸载、升级 ## 中风险 处理方式可先执行草稿版本输出后请用户确认再落地。 操作清单 - 修改 3-10 个文件 - 重构函数签名 - 修改测试用例 - 生成新文件 ## 低风险 处理方式可直接执行无需确认。 操作清单 - 读取、搜索、分析 - 生成草稿、建议、示例 - 格式化不改变逻辑 - 添加注释这份清单需要根据你的实际使用场景调整。比如如果你做的是数据分析 Agent那“数据库写操作”可能还要细分成“写入临时表”和“写入生产表”前者中风险后者高风险。4.4 默认值清单的维护rules/defaults.md里记录的是“信息缺失时可以安全使用的默认值”。这份清单需要持续维护每次发现模型用了一个不合适的默认值就把它加进去或者修正。# 默认值清单 ## 格式类 - 日期格式ISO 8601YYYY-MM-DD - 时间格式24 小时制HH:mm:ss - 编码UTF-8 - 换行符LF - JSON 缩进2 空格 - CSV 分隔符逗号数据含逗号时改用分号 ## 命名类 - 变量命名camelCaseJavaScript/Java - 变量命名snake_casePython - 文件名kebab-case - 类名PascalCase ## 行为类 - 代码注释语言与代码库现有注释保持一致 - 提交信息语言与代码库现有提交记录保持一致 - 输出语言与用户输入语言一致这份清单的价值在于它把“模型自己猜”变成了“查表”。查表的结果是确定的、可审计的而模型自己猜的结果每次可能都不一样。4.5 示例文件的写法examples/目录下的示例文件是给模型看的“参考答案”。我每个文件放 3-5 个例子格式统一# 该先问的示例 ## 示例 1 用户输入帮我把项目里的日志清理一下 判断目标清晰度低“清理”含义模糊范围边界低“项目里”范围太大风险等级高可能删除文件 行为先确认。询问内容 1. 清理方式删除日志文件 / 清空日志内容 / 降低日志级别 2. 清理范围仅 src 目录 / 整个项目 / 指定模块 3. 是否需要保留最近 N 天的日志 ## 示例 2 用户输入把这个函数改成异步的 判断目标清晰度高范围边界高指定了函数风险等级中修改代码逻辑 行为先做草稿输出修改后的代码请用户确认后再写入文件。# 该直接做的示例 ## 示例 1 用户输入把这个 JSON 文件转成 CSV 判断目标清晰度高范围边界高指定了文件风险等级低生成新文件默认值合理性高分隔符、编码有通用默认值 行为直接执行输出时标注使用的默认值。 ## 示例 2 用户输入帮我看看这段代码有什么问题 判断目标清晰度高代码审查范围边界高指定了代码段风险等级低只读分析 行为直接执行输出分析结果。这些示例的作用是给模型提供“模式匹配”的锚点。当模型遇到类似场景时会倾向于模仿示例中的行为而不是自己重新推理。5. 常见问题与排查技巧实录5.1 模型仍然问太多怎么办这是最常见的问题。即使写了决策矩阵模型有时候还是会过度询问。我的排查思路是先检查决策矩阵的覆盖度。如果用户请求落在矩阵的“直接执行”区间但模型还是问了那说明矩阵的某个维度评估标准不够明确。比如“目标清晰度”怎么算高我后来加了一条量化标准“如果用户请求中包含了明确的动词转换、删除、修改、生成和明确的对象文件名、函数名、模块名则目标清晰度为高。”再检查示例文件是否足够。模型很依赖示例来校准行为。如果示例里“该直接做”的例子太少模型会倾向于保守。我后来把“该直接做”的示例增加到了 8 个覆盖了常见的低风险操作场景过度询问的情况明显减少。还有一个技巧是在 Skill 里加一条“询问成本”规则“如果询问一个问题所花费的用户时间超过了直接执行并让用户检查结果的时间则倾向于直接执行。”这条规则对低风险操作特别有效。5.2 模型仍然闷头做错怎么办如果模型该问的时候不问直接执行了高风险操作排查方向反过来先检查风险等级枚举是否覆盖了那个操作。很多时候是枚举清单不全模型遇到了清单外的操作不知道该怎么定级就默认按低风险处理了。解决办法是定期 review 模型的执行记录把遗漏的操作补进清单。再检查“标注义务”是否被执行。如果模型用了默认值但没标注用户就失去了纠正的机会。我在 Skill 里把标注格式固定成了[默认值: X]这种标记方便用户一眼识别也方便后续用脚本检查模型是否履行了标注义务。还有一个容易被忽略的点是上下文继承。如果用户在对话开头说了“今天只处理测试环境”但后面又提了一个新请求模型可能会忘记前面的约束。我在 Skill 里加了一条“每次新请求都要重新评估范围边界不要默认继承上一轮的约束除非用户明确说‘继续’或‘同上’。”5.3 常见问题速查表问题现象可能原因排查方向解决方式问太多决策矩阵覆盖不全检查请求落在哪个区间补充矩阵规则或量化标准问太多示例偏向保守统计示例中“该问”和“该做”的比例增加“该直接做”的示例做太错风险枚举不全检查出错操作是否在清单中补充风险等级枚举做太错默认值不合理检查模型用了什么默认值修正默认值清单做太错上下文约束丢失检查对话历史中的约束条件加“每轮重新评估”规则该问不问目标清晰度误判检查模型对“清晰”的判定标准加量化判定标准该做不做风险等级误判检查操作是否被过度定级调整风险等级划分5.4 几个踩过的坑第一个坑是规则太多导致模型忽略。我一开始写了 50 多条规则结果模型只记住了前几条后面的全忽略了。后来精简到 20 条以内把次要规则移到子文件里按需加载遵循度才上来。经验是主文件里的规则不要超过 25 条超过就拆分。第二个坑是示例太抽象。我最初写的示例是“用户请求模糊时先询问”模型看了跟没看一样。后来改成具体的用户输入和具体的询问内容模型的行为立刻变得可预测了。示例一定要具体到“用户说了什么、模型应该回什么”这个粒度。第三个坑是没有处理“用户拒绝回答”的情况。有时候模型问了用户说“你看着办”。这时候模型会卡住不知道是该继续问还是该自己决定。我在 Skill 里加了一条“如果用户表示‘你决定’或‘随便’则使用默认值执行并在输出中标注所有使用的默认值同时提示用户‘如需调整请告知’。”第四个坑是跨轮次的状态丢失。在多轮对话中模型有时候会忘记上一轮已经确认过的信息重复询问。解决办法是在 Skill 里加一条“在询问前先检查对话历史中是否已经包含该信息避免重复询问。”6. 进阶玩法让 Skill 自己进化6.1 用执行日志反哺规则这套 Skill 最大的价值不是一次写成的规则而是它可以持续迭代。我的做法是每次模型出现“该问不问”或“不该问却问”的情况就把当时的用户输入、模型行为、期望行为记录下来定期整理成新的规则或示例补进 Skill 里。比如我发现在处理“重命名变量”这个操作时模型有时候直接改了有时候又问“改成什么名字”。后来我加了一条规则“如果用户说‘重命名 X 为 Y’目标清晰度为高直接执行如果用户说‘重命名 X’目标清晰度为低先询问新名称。”这种细粒度的规则只能从实际使用中总结出来。6.2 和其他 Skill 的组合意图判断 Skill 可以和很多其他 Skill 组合使用。比如配合代码审查 Skill在审查前先判断“用户是想让我审查并直接修复还是只审查不修复”。配合文档生成 Skill判断“用户是要生成 API 文档还是用户手册”。组合的关键是明确 Skill 之间的优先级。我的做法是在每个 Skill 的SKILL.md里声明“前置条件”和“后置条件”。意图判断 Skill 的前置条件是“无”后置条件是“输出行为决策直接执行/先确认/先草稿”。其他 Skill 的前置条件里写上“需要 clarify-intent 的输出”这样 Agent 就知道要先跑意图判断再跑其他技能。6.3 量化评估效果光靠感觉说“好像好了一点”不够我建了一个简单的评估集20 个典型用户请求每个请求标注了期望行为直接执行/先确认/先草稿。每次修改 Skill 后让 Agent 跑一遍这 20 个请求统计行为匹配率。版本匹配率主要问题v1.065%问太多v1.575%高风险操作偶尔漏问v2.085%默认值标注偶尔遗漏v2.590%跨轮次状态偶尔丢失v3.095%基本稳定这个评估集不需要很大20 个请求就够用了。关键是每个请求都要有明确的期望行为这样才能客观衡量。我建议每个做 Agent 开发的人都建一个自己的评估集哪怕只有 10 个用例也比凭感觉调参强得多。6.4 一个容易被忽略的细节询问的语气Skill 里除了判断逻辑我还加了一段关于询问语气的规则。原因是模型有时候虽然问对了问题但语气让用户不舒服。比如“你确定要删除这个文件吗”听起来像在质疑用户。改成“删除操作不可逆请确认是否继续”就专业很多。规则是这样的“询问时使用中性、专业的语气避免反问句和质疑性表达。提供选项时给出推荐项减少用户的决策负担。”这个细节看起来小但实际使用中体验差异很大。7. 我个人在实际操作中的体会这套 Skill 我从最初的一个想法到现在相对稳定前后改了大概十几个版本。最大的体会是不要试图让模型“理解”你的意图而是给它一套它“能执行”的规则。模型不擅长模糊判断但擅长按规则办事。你把规则写清楚、写具体、写成条件句式它的表现就会稳定很多。另一个体会是示例比规则更重要。我花在写示例上的时间比写规则多得多但效果也明显得多。模型对示例的模仿能力很强一个好的示例能顶十条抽象规则。如果你刚开始做 Skill建议先把示例写够再补规则。最后分享一个小技巧在 Skill 里加一条“自检”规则让模型在输出前自己检查一遍——“我是否使用了默认值是否标注了是否遗漏了需要确认的高风险操作”这条自检规则不需要模型真的“思考”它只是让模型在生成最终输出前多跑一遍规则匹配能拦住不少低级错误。实测下来加了自检之后默认值标注的遗漏率从 15% 降到了 3% 左右。这个 Skill 后续还可以往几个方向扩展一是加入“用户偏好学习”记录用户经常纠正的默认值下次自动调整二是加入“团队规范继承”从项目的配置文件里读取团队的代码规范作为默认值来源三是加入“风险等级自适应”根据用户的历史操作习惯动态调整风险判定阈值。这些方向我还在摸索有进展再另开一篇聊。
AI Agent意图判断Skill：解决过度询问与擅自行动
1. 从两个极端说起AI 为什么总在“问太多”和“做太错”之间反复横跳用 AI Agent 干活的人大概率都经历过这两种让人血压升高的场景。第一种你让它帮你把一段会议纪要整理成待办清单它反手甩回来五个问题“请问待办事项需要包含负责人吗”“截止日期格式用哪种”“优先级怎么定义”“输出用表格还是列表”“需要同步给相关人吗”——你只是想省五分钟结果花了十五分钟回答它的问卷。第二种更气人你让它把项目里所有console.log清理掉再提交它闷头一顿操作把测试文件里的断言日志也删了还顺手改了三个你没让它碰的配置文件。你 review diff 的时候只想顺着网线过去问它你刚才为什么不问我一句这两个极端背后其实是同一个问题Agent 缺少对“意图确定性”的判断能力。它不知道自己现在掌握的信息够不够支撑行动也不知道哪些操作属于“可逆的低风险动作”、哪些属于“一旦做错就要花半小时回滚的高危动作”。于是它只能靠一个固定的系统提示词来决定行为倾向——要么被写成“遇到不确定就问”要么被写成“尽量自主完成”然后就在某个极端上一路走到黑。我写这个 Skill 的出发点很朴素把“什么时候该问、什么时候该直接做”变成一套可复用的判断规则而不是每次靠临时改提示词碰运气。它不绑定某个特定 Agent 框架本质上是一份结构化的行为约束文档配合SKILL.md这种约定俗成的描述文件让 Agent 在每次决策前先过一遍“意图清晰度检查”。下面我把整套设计思路、判断逻辑、落地方式和踩过的坑完整拆开讲如果你正在做 Agent 开发、或者天天用 AI 编程工具被它的“过度确认”和“擅自行动”折磨这篇应该能直接抄作业。2. 整体设计思路把“该不该问”拆成可计算的判断维度2.1 为什么不是简单加一句“不确定就问”最直觉的方案是在系统提示词里加一句“如果你不确定用户的意图请先询问”。我试过效果很差。原因是“不确定”这个词对模型来说太模糊了它没有一个可操作的阈值。结果就是模型对“不确定”的判定极度保守——只要有任何一点信息缺失它就归类为“不确定”然后开始问问题。这就是“问一堆”的根源。反过来如果写“尽量自主完成不要频繁打断用户”模型又会走向另一个极端它会把“信息缺失”这件事直接忽略掉用自己脑补的默认值填上然后闷头执行。这就是“做错”的根源。所以核心思路不是调整“不确定”的敏感度而是把“不确定”拆解成几个独立的、可分别判断的维度。每个维度单独看可能都不致命但组合起来就能给出一个相对清晰的行为建议。这就像医生诊断不是只问“你难受吗”而是分科室、分指标逐项排查。2.2 四个核心判断维度我把意图确定性拆成了四个维度每个维度用高/中/低三档来评估维度含义高确定性表现低确定性表现目标清晰度用户想要达成的最终结果是否明确“把这份纪要转成待办清单”“帮我处理一下这个文档”范围边界操作涉及的文件、模块、数据范围是否明确“只改 src/utils 下的文件”“优化一下项目代码”风险等级操作是否可逆、影响面是否可控读取、分析、生成草稿删除、覆盖、批量修改、对外发送默认值合理性信息缺失时行业惯例或上下文能否给出安全默认值日期格式用 ISO 8601用户说“发给团队”但没说哪个团队判断逻辑是这样的目标清晰度和范围边界决定“要不要问”风险等级和默认值合理性决定“能不能直接做”。如果目标清晰但范围模糊且操作风险低那可以先做一版草稿再确认如果目标模糊但操作风险高那必须先问清楚再动手。2.3 为什么用 Skill 而不是硬编码有人会问这套逻辑为什么不直接写进 Agent 的代码里而要做成一个 Skill我的考虑有三点。第一可移植性。Skill 本质上是一份 Markdown 格式的行为描述文档不依赖特定框架的 API。你今天用这个 Agent 框架明天换一个Skill 文件可以直接带走。第二可迭代性。判断规则需要根据实际使用反馈不断调整改一份 Markdown 比改代码、重新部署快得多。第三可组合性。一个 Agent 可以同时加载多个 Skill意图判断 Skill 可以和代码审查 Skill、文档生成 Skill 叠加使用互不冲突。SKILL.md这个命名约定现在在 Agent 开发圈子里已经比较通用了它的作用是让 Agent 在启动时自动扫描并加载技能描述。文件里通常包含技能名称、触发条件、行为规则、示例对话等部分。我这份 Skill 的核心内容就是上面那四个维度的判断规则加上具体的决策树和示例。3. 核心细节解析判断规则怎么写才不会被模型忽略3.1 规则要写成“如果……那么……”而不是“应该……”这是我在反复调试中最大的一个心得。模型对“应该”“尽量”“建议”这类软性词汇的遵循度很低尤其是在长上下文里这些词很容易被淹没。但“如果 X 成立那么执行 Y”这种条件句式模型的遵循度明显更高。举个例子我最初的写法是“当用户意图不明确时应该先询问再行动。”实测下来模型经常忽略。后来改成“如果目标清晰度为低且风险等级为高那么必须先向用户确认目标后再执行。”遵循度立刻上来了。再比如默认值这块我写的是“如果信息缺失但存在行业通用默认值且风险等级为低或中那么使用默认值执行并在输出中标注‘此处使用了默认值 X如需调整请告知’。”这样模型既不会闷头做错也不会因为一个小格式问题就停下来问。3.2 风险等级需要具体枚举不能抽象描述“高风险操作”这种说法对模型来说太抽象了。什么算高风险改一个变量名算吗删一个文件算吗我后来把风险等级做成了具体操作的枚举清单高风险操作必须先确认删除文件、目录或数据记录覆盖已有文件内容非追加模式批量修改超过 10 个文件执行对外发送操作邮件、消息、API 调用修改配置文件、环境变量、密钥执行数据库写操作安装或卸载依赖包中风险操作可先做草稿再确认修改 3-10 个文件重构函数签名修改测试用例生成新文件低风险操作可直接执行读取、搜索、分析文件生成草稿、建议、示例格式化代码不改变逻辑添加注释这份清单不是拍脑袋定的是我在实际使用中根据“回滚成本”来划分的。回滚一个删除操作可能要翻备份回滚一个格式化操作只需要git checkout。回滚成本越高风险等级越高越需要提前确认。3.3 默认值的使用要有“标注义务”允许模型使用默认值但必须附带一个“标注义务”——在输出中明确告诉用户“我在这里用了默认值”。这个设计很关键它解决了“闷头做错”的问题。模型可以自主决策但决策必须是透明的。比如用户说“帮我把这个 JSON 转成 CSV”没说分隔符用什么。模型可以用逗号作为默认分隔符但输出时要加一句“默认使用逗号作为分隔符如果数据中包含逗号建议改用分号或制表符。”这样用户一眼就能看到模型的假设如果不对可以立刻纠正而不是等到导入数据失败才发现问题。3.4 询问要“批量”不要“逐个”这是解决“问一堆”的关键技巧。如果模型判断需要询问不要问一个问题等一个回答再问下一个而是把所有需要确认的点一次性列出来。我在这份 Skill 里写了一条规则“如果需要询问将所有待确认项整理为一个编号列表一次性提出避免多轮往返。”实测效果很明显。以前模型会问“请问输出格式是什么”你回答“Markdown”它又问“需要包含代码示例吗”你回答“需要”它再问“代码语言用什么”现在它会一次性问“请确认以下三点1. 输出格式Markdown/纯文本/表格2. 是否需要代码示例3. 代码语言偏好。”用户体验完全不一样。4. 实操过程从零写一份可用的意图判断 Skill4.1 文件结构设计一份完整的 Skill 目录结构大概是这样skills/ clarify-intent/ SKILL.md # 主描述文件 rules/ risk-levels.md # 风险等级枚举 defaults.md # 默认值清单 examples/ ask-first.md # 该问的示例 act-first.md # 该直接做的示例SKILL.md是入口文件Agent 启动时读取这个文件来了解技能的存在和行为概要。rules/目录下放具体的规则细节examples/目录下放正反示例。这种拆分的好处是主文件保持简洁Agent 不会因为一次性加载太多内容而忽略关键规则。4.2 SKILL.md 的核心内容主文件我控制在 200 行以内结构如下# Skill: clarify-intent ## 触发条件 每次接收到用户请求后在执行任何操作前先运行意图判断流程。 ## 判断流程 1. 评估目标清晰度高/中/低 2. 评估范围边界高/中/低 3. 评估风险等级高/中/低 4. 评估默认值合理性高/中/低 5. 根据组合结果决定行为 ## 决策矩阵 | 目标 | 范围 | 风险 | 默认值 | 行为 | |------|------|------|--------|------| | 高 | 高 | 任意 | 任意 | 直接执行 | | 高 | 低 | 低/中 | 高 | 使用默认值执行并标注 | | 高 | 低 | 高 | 任意 | 先确认范围 | | 低 | 任意 | 低/中 | 高 | 使用默认值执行并标注 | | 低 | 任意 | 高 | 任意 | 先确认目标 | | 任意 | 任意 | 任意 | 低 | 先确认缺失信息 | ## 询问规范 - 一次性列出所有待确认项 - 每个确认项给出推荐选项 - 避免开放式问题尽量用选择题这个决策矩阵是整个 Skill 的核心。它把四个维度的组合映射到了具体行为上模型只需要按表查就行不需要自己推理。这比让模型“自己判断”可靠得多。4.3 风险等级枚举文件的写法rules/risk-levels.md里我把常见操作按风险等级分类并且给每个等级配了处理方式# 风险等级定义 ## 高风险 处理方式必须先获得用户明确确认确认前不得执行。 操作清单 - 删除操作文件、目录、数据记录 - 覆盖写入非追加 - 批量修改10 个文件 - 对外发送邮件、消息、API 调用 - 配置修改配置文件、环境变量、密钥 - 数据库写操作 - 依赖变更安装、卸载、升级 ## 中风险 处理方式可先执行草稿版本输出后请用户确认再落地。 操作清单 - 修改 3-10 个文件 - 重构函数签名 - 修改测试用例 - 生成新文件 ## 低风险 处理方式可直接执行无需确认。 操作清单 - 读取、搜索、分析 - 生成草稿、建议、示例 - 格式化不改变逻辑 - 添加注释这份清单需要根据你的实际使用场景调整。比如如果你做的是数据分析 Agent那“数据库写操作”可能还要细分成“写入临时表”和“写入生产表”前者中风险后者高风险。4.4 默认值清单的维护rules/defaults.md里记录的是“信息缺失时可以安全使用的默认值”。这份清单需要持续维护每次发现模型用了一个不合适的默认值就把它加进去或者修正。# 默认值清单 ## 格式类 - 日期格式ISO 8601YYYY-MM-DD - 时间格式24 小时制HH:mm:ss - 编码UTF-8 - 换行符LF - JSON 缩进2 空格 - CSV 分隔符逗号数据含逗号时改用分号 ## 命名类 - 变量命名camelCaseJavaScript/Java - 变量命名snake_casePython - 文件名kebab-case - 类名PascalCase ## 行为类 - 代码注释语言与代码库现有注释保持一致 - 提交信息语言与代码库现有提交记录保持一致 - 输出语言与用户输入语言一致这份清单的价值在于它把“模型自己猜”变成了“查表”。查表的结果是确定的、可审计的而模型自己猜的结果每次可能都不一样。4.5 示例文件的写法examples/目录下的示例文件是给模型看的“参考答案”。我每个文件放 3-5 个例子格式统一# 该先问的示例 ## 示例 1 用户输入帮我把项目里的日志清理一下 判断目标清晰度低“清理”含义模糊范围边界低“项目里”范围太大风险等级高可能删除文件 行为先确认。询问内容 1. 清理方式删除日志文件 / 清空日志内容 / 降低日志级别 2. 清理范围仅 src 目录 / 整个项目 / 指定模块 3. 是否需要保留最近 N 天的日志 ## 示例 2 用户输入把这个函数改成异步的 判断目标清晰度高范围边界高指定了函数风险等级中修改代码逻辑 行为先做草稿输出修改后的代码请用户确认后再写入文件。# 该直接做的示例 ## 示例 1 用户输入把这个 JSON 文件转成 CSV 判断目标清晰度高范围边界高指定了文件风险等级低生成新文件默认值合理性高分隔符、编码有通用默认值 行为直接执行输出时标注使用的默认值。 ## 示例 2 用户输入帮我看看这段代码有什么问题 判断目标清晰度高代码审查范围边界高指定了代码段风险等级低只读分析 行为直接执行输出分析结果。这些示例的作用是给模型提供“模式匹配”的锚点。当模型遇到类似场景时会倾向于模仿示例中的行为而不是自己重新推理。5. 常见问题与排查技巧实录5.1 模型仍然问太多怎么办这是最常见的问题。即使写了决策矩阵模型有时候还是会过度询问。我的排查思路是先检查决策矩阵的覆盖度。如果用户请求落在矩阵的“直接执行”区间但模型还是问了那说明矩阵的某个维度评估标准不够明确。比如“目标清晰度”怎么算高我后来加了一条量化标准“如果用户请求中包含了明确的动词转换、删除、修改、生成和明确的对象文件名、函数名、模块名则目标清晰度为高。”再检查示例文件是否足够。模型很依赖示例来校准行为。如果示例里“该直接做”的例子太少模型会倾向于保守。我后来把“该直接做”的示例增加到了 8 个覆盖了常见的低风险操作场景过度询问的情况明显减少。还有一个技巧是在 Skill 里加一条“询问成本”规则“如果询问一个问题所花费的用户时间超过了直接执行并让用户检查结果的时间则倾向于直接执行。”这条规则对低风险操作特别有效。5.2 模型仍然闷头做错怎么办如果模型该问的时候不问直接执行了高风险操作排查方向反过来先检查风险等级枚举是否覆盖了那个操作。很多时候是枚举清单不全模型遇到了清单外的操作不知道该怎么定级就默认按低风险处理了。解决办法是定期 review 模型的执行记录把遗漏的操作补进清单。再检查“标注义务”是否被执行。如果模型用了默认值但没标注用户就失去了纠正的机会。我在 Skill 里把标注格式固定成了[默认值: X]这种标记方便用户一眼识别也方便后续用脚本检查模型是否履行了标注义务。还有一个容易被忽略的点是上下文继承。如果用户在对话开头说了“今天只处理测试环境”但后面又提了一个新请求模型可能会忘记前面的约束。我在 Skill 里加了一条“每次新请求都要重新评估范围边界不要默认继承上一轮的约束除非用户明确说‘继续’或‘同上’。”5.3 常见问题速查表问题现象可能原因排查方向解决方式问太多决策矩阵覆盖不全检查请求落在哪个区间补充矩阵规则或量化标准问太多示例偏向保守统计示例中“该问”和“该做”的比例增加“该直接做”的示例做太错风险枚举不全检查出错操作是否在清单中补充风险等级枚举做太错默认值不合理检查模型用了什么默认值修正默认值清单做太错上下文约束丢失检查对话历史中的约束条件加“每轮重新评估”规则该问不问目标清晰度误判检查模型对“清晰”的判定标准加量化判定标准该做不做风险等级误判检查操作是否被过度定级调整风险等级划分5.4 几个踩过的坑第一个坑是规则太多导致模型忽略。我一开始写了 50 多条规则结果模型只记住了前几条后面的全忽略了。后来精简到 20 条以内把次要规则移到子文件里按需加载遵循度才上来。经验是主文件里的规则不要超过 25 条超过就拆分。第二个坑是示例太抽象。我最初写的示例是“用户请求模糊时先询问”模型看了跟没看一样。后来改成具体的用户输入和具体的询问内容模型的行为立刻变得可预测了。示例一定要具体到“用户说了什么、模型应该回什么”这个粒度。第三个坑是没有处理“用户拒绝回答”的情况。有时候模型问了用户说“你看着办”。这时候模型会卡住不知道是该继续问还是该自己决定。我在 Skill 里加了一条“如果用户表示‘你决定’或‘随便’则使用默认值执行并在输出中标注所有使用的默认值同时提示用户‘如需调整请告知’。”第四个坑是跨轮次的状态丢失。在多轮对话中模型有时候会忘记上一轮已经确认过的信息重复询问。解决办法是在 Skill 里加一条“在询问前先检查对话历史中是否已经包含该信息避免重复询问。”6. 进阶玩法让 Skill 自己进化6.1 用执行日志反哺规则这套 Skill 最大的价值不是一次写成的规则而是它可以持续迭代。我的做法是每次模型出现“该问不问”或“不该问却问”的情况就把当时的用户输入、模型行为、期望行为记录下来定期整理成新的规则或示例补进 Skill 里。比如我发现在处理“重命名变量”这个操作时模型有时候直接改了有时候又问“改成什么名字”。后来我加了一条规则“如果用户说‘重命名 X 为 Y’目标清晰度为高直接执行如果用户说‘重命名 X’目标清晰度为低先询问新名称。”这种细粒度的规则只能从实际使用中总结出来。6.2 和其他 Skill 的组合意图判断 Skill 可以和很多其他 Skill 组合使用。比如配合代码审查 Skill在审查前先判断“用户是想让我审查并直接修复还是只审查不修复”。配合文档生成 Skill判断“用户是要生成 API 文档还是用户手册”。组合的关键是明确 Skill 之间的优先级。我的做法是在每个 Skill 的SKILL.md里声明“前置条件”和“后置条件”。意图判断 Skill 的前置条件是“无”后置条件是“输出行为决策直接执行/先确认/先草稿”。其他 Skill 的前置条件里写上“需要 clarify-intent 的输出”这样 Agent 就知道要先跑意图判断再跑其他技能。6.3 量化评估效果光靠感觉说“好像好了一点”不够我建了一个简单的评估集20 个典型用户请求每个请求标注了期望行为直接执行/先确认/先草稿。每次修改 Skill 后让 Agent 跑一遍这 20 个请求统计行为匹配率。版本匹配率主要问题v1.065%问太多v1.575%高风险操作偶尔漏问v2.085%默认值标注偶尔遗漏v2.590%跨轮次状态偶尔丢失v3.095%基本稳定这个评估集不需要很大20 个请求就够用了。关键是每个请求都要有明确的期望行为这样才能客观衡量。我建议每个做 Agent 开发的人都建一个自己的评估集哪怕只有 10 个用例也比凭感觉调参强得多。6.4 一个容易被忽略的细节询问的语气Skill 里除了判断逻辑我还加了一段关于询问语气的规则。原因是模型有时候虽然问对了问题但语气让用户不舒服。比如“你确定要删除这个文件吗”听起来像在质疑用户。改成“删除操作不可逆请确认是否继续”就专业很多。规则是这样的“询问时使用中性、专业的语气避免反问句和质疑性表达。提供选项时给出推荐项减少用户的决策负担。”这个细节看起来小但实际使用中体验差异很大。7. 我个人在实际操作中的体会这套 Skill 我从最初的一个想法到现在相对稳定前后改了大概十几个版本。最大的体会是不要试图让模型“理解”你的意图而是给它一套它“能执行”的规则。模型不擅长模糊判断但擅长按规则办事。你把规则写清楚、写具体、写成条件句式它的表现就会稳定很多。另一个体会是示例比规则更重要。我花在写示例上的时间比写规则多得多但效果也明显得多。模型对示例的模仿能力很强一个好的示例能顶十条抽象规则。如果你刚开始做 Skill建议先把示例写够再补规则。最后分享一个小技巧在 Skill 里加一条“自检”规则让模型在输出前自己检查一遍——“我是否使用了默认值是否标注了是否遗漏了需要确认的高风险操作”这条自检规则不需要模型真的“思考”它只是让模型在生成最终输出前多跑一遍规则匹配能拦住不少低级错误。实测下来加了自检之后默认值标注的遗漏率从 15% 降到了 3% 左右。这个 Skill 后续还可以往几个方向扩展一是加入“用户偏好学习”记录用户经常纠正的默认值下次自动调整二是加入“团队规范继承”从项目的配置文件里读取团队的代码规范作为默认值来源三是加入“风险等级自适应”根据用户的历史操作习惯动态调整风险判定阈值。这些方向我还在摸索有进展再另开一篇聊。
