1. 从两个极端说起AI 为什么总在“问”和“做”之间反复横跳用 AI 写代码、做方案、处理文档的人大概率都遇到过这两种让人血压升高的场景。第一种你让它帮你重构一个函数它反手甩回来五个问题“请问你希望用什么语言”“这个函数的输入输出格式是什么”“有没有性能要求”“是否需要保留原有注释”“目标运行环境是什么”——你明明已经把代码贴上去了它还在问。第二种你给它一句“帮我写个用户登录模块”它二话不说开始输出代码结果用了一个你项目里根本不存在的框架数据库字段名全是它自己编的你看着那两百行代码删也不是改也不是。这两个极端背后其实是同一个问题AI 对“意图确定性”的判断能力不足。它不知道该在什么时候停下来确认也不知道哪些信息已经足够支撑它直接动手。问太多是因为它把所有不确定性都当成了必须澄清的阻塞项闷头做错是因为它把“用户没说”直接等同于“用户没要求”然后用自己的默认值填满了所有空白。我管这个叫AI 的“意图边界感”缺失。一个合格的协作对象不管是人还是 AI都应该具备这种能力知道哪些信息是必须问清楚的哪些是可以自己合理推断的哪些是即使猜错了也不会造成严重后果的。这种判断力在 Agent 开发领域有一个专门的方向叫clarify-intent也就是意图澄清。我最近花了不少时间在这件事上写了一个 Skill核心目标就一个教 AI 在动手之前先判断自己该不该问。这个 Skill 不是什么复杂的框架本质上就是一套结构化的判断规则写在SKILL.md文件里配合 Agent 的调用逻辑来生效。但就是这么一套规则把我日常用 AI 干活的返工率降了一大截。这篇文章我会把这个 Skill 的设计思路、核心判断逻辑、SKILL.md的写法、实际接入 Agent 的过程以及踩过的坑全部拆开讲清楚。如果你也在做 Agent 开发或者只是想让日常用 AI 的效率高一点这套东西可以直接抄作业。2. 核心设计思路把“该不该问”变成一道可计算的判断题2.1 为什么不是“多问”也不是“少问”而是“问对”很多人第一反应是那就让 AI 少问点呗别那么啰嗦。但实际用下来你会发现单纯让 AI “少问”会导致更严重的后果——它开始瞎猜而且猜得理直气壮。反过来让 AI “多问”也不行你每做一步都被打断效率还不如自己写。所以核心不是问多问少而是问对。什么叫问对我总结了一个判断标准一个问题值得被问出来当且仅当这个信息的缺失会导致输出结果产生不可逆的方向性错误且这个信息无法从已有上下文中合理推断。注意两个关键词不可逆和无法推断。如果猜错了可以轻松改回来那就不值得问直接做做完让用户确认就行。如果虽然用户没说但从上下文能推断出合理默认值那也不值得问直接用推断值但在输出里标注清楚“我假设了 XXX”。这个判断标准听起来简单但要让 AI 真的能执行需要把它拆解成更具体的、可操作的规则。2.2 三层判断模型阻塞项、推断项、默认项我把所有信息需求分成三类对应三种处理策略第一类阻塞项Blocker。这类信息缺失时任何输出都是浪费。比如用户说“帮我改一下这个配置文件”但没贴配置文件内容——这不是问不问的问题是根本没法做。阻塞项的特征是缺失时任务无法启动或者启动后必然产生完全错误的结果。第二类推断项Inferable。这类信息用户没说但从上下文、项目结构、行业惯例可以合理推断。比如用户让你写一个 Python 函数处理 CSV 文件没说要用什么库——那 pandas 就是合理推断。推断项的处理方式是直接推断但在输出中显式标注假设。第三类默认项Defaultable。这类信息即使猜错了修改成本也极低或者有广泛接受的默认值。比如代码缩进用 4 个空格还是 2 个空格变量命名用驼峰还是下划线——这些不值得问直接用最常见默认值用户不满意自己会改。这三类的判断逻辑就是整个 Skill 的核心。2.3 为什么选择 Skill 而不是 Prompt 模板你可能会问这不就是写一段好的 System Prompt 吗为什么要搞成 Skill区别在于可复用性和可组合性。Prompt 模板是每次都要手动粘贴的而且不同任务需要不同的澄清策略。Skill 的好处是它可以被 Agent 自动调用而且可以和其他 Skill 组合。比如我有一个专门做代码审查的 Skill一个专门做文档总结的 Skillclarify-intent 这个 Skill 可以在它们之前自动运行先判断当前任务的信息完整度再决定是否进入主流程。另外SKILL.md这种格式本身就有结构化优势。它可以用 Markdown 的标题层级来组织判断规则用表格来列举常见场景用代码块来给出判断逻辑的伪代码。Agent 在读取这个文件时能比读一段纯文本 Prompt 更准确地提取规则。3. SKILL.md 怎么写从判断规则到可执行逻辑3.1 文件结构设计我的SKILL.md整体结构是这样的# Clarify Intent Skill ## 触发条件 ## 判断流程 ### 第一步任务类型识别 ### 第二步信息完整度评估 ### 第三步阻塞项检测 ### 第四步推断项处理 ### 第五步输出策略选择 ## 常见场景速查表 ## 输出格式规范这个结构的关键在于判断流程是线性的、有顺序的。Agent 不需要一次性做复杂判断而是按步骤走每一步只做一个简单决策。这比让 AI “综合考虑”要可靠得多。3.2 第一步任务类型识别不同类型的任务对信息完整度的要求完全不同。我粗略分了几大类任务类型典型特征信息容忍度澄清倾向代码生成需要明确语言、框架、接口低倾向多问文档总结输入即全部信息高倾向直接做方案设计需要明确目标和约束中先问目标再动手数据转换需要明确输入输出格式低格式必须问清创意写作风格和方向可推断高直接做做完再调问题排查需要错误信息和环境低必须问清现象这个表的作用是给 Agent 一个初始的“澄清倾向”基线。比如识别到是“文档总结”类任务那默认策略就是“直接做不问”因为输入文档本身就是全部信息。识别到是“代码生成”默认策略就是“先检查关键信息是否齐全”。3.3 第二步信息完整度评估这一步是核心。我设计了一个简单的评分机制让 Agent 对当前任务的信息完整度打分# 伪代码实际写在 SKILL.md 里是自然语言描述 def assess_completeness(task): score 0 # 目标明确性用户是否说清楚了要做什么 if task.goal_is_clear: score 30 # 输入明确性用户是否提供了必要的输入材料 if task.input_is_provided: score 30 # 约束明确性用户是否说明了限制条件 if task.constraints_are_clear: score 20 # 输出格式明确性用户是否指定了期望的输出形式 if task.output_format_is_specified: score 20 return score评分低于 50 分说明信息严重不足必须进入澄清流程。50 到 70 分之间说明有部分信息缺失但可能可以推断进入推断流程。70 分以上直接执行在输出中标注假设即可。这个评分机制的好处是可解释。当 Agent 决定要问问题时它可以告诉用户“因为你的任务信息完整度评分只有 40 分主要缺失在输入材料和输出格式上”而不是莫名其妙地甩一堆问题过来。3.4 第三步阻塞项检测阻塞项是必须问的没有商量余地。我在SKILL.md里列了一个阻塞项清单输入缺失用户说“帮我改一下”但没给要改的东西目标矛盾用户的要求自相矛盾比如“要快但要零延迟”关键参数缺失比如数据转换任务没说目标格式环境依赖缺失比如代码任务没说运行环境且无法从上下文推断检测到阻塞项时Agent 应该只问阻塞项相关的问题不要顺带问一堆非阻塞的。比如用户没给配置文件那就只问“请提供配置文件内容”不要同时问“你希望用什么格式输出”“有没有性能要求”之类的。注意阻塞项问题要一次性问完不要挤牙膏。用户最烦的就是回答完一个问题AI 又问一个来回好几轮。把所有阻塞项列在一起让用户一次回答完。3.5 第四步推断项处理推断项的处理原则是能推断就推断推断后标注。我在SKILL.md里写了一段推断规则当遇到以下情况时使用合理推断而非询问 - 编程语言未指定但上下文中有代码片段 → 使用代码片段中的语言 - 库/框架未指定但任务类型有主流选择 → 使用主流选择如 Python 数据处理用 pandas - 命名风格未指定 → 使用项目现有风格无项目上下文则使用语言社区惯例 - 输出格式未指定 → 使用该任务类型最常见的格式关键点是推断必须基于证据不能凭空捏造。如果上下文里没有任何线索那这个信息可能应该被归为阻塞项而不是推断项。3.6 第五步输出策略选择根据前面的判断最终输出策略有三种策略 A直接执行。信息完整度评分 ≥ 70无阻塞项。直接输出结果在开头用一句话标注所有推断的假设。策略 B推断后执行。信息完整度评分 50-70无阻塞项。先列出推断的假设然后执行输出结果。策略 C澄清后执行。存在阻塞项或信息完整度评分 50。列出需要澄清的问题等待用户回答后再执行。这三种策略的选择逻辑是整个 Skill 的最终输出。4. 接入 Agent从文件到实际生效4.1 Agent 如何读取和调用 Skill不同的 Agent 框架对 Skill 的支持方式不同。我用过的几种方式方式一System Prompt 注入。最简单的方式把SKILL.md的内容直接拼接到 System Prompt 里。适合轻量级场景缺点是每次对话都要带上一大段文本消耗 token。方式二工具调用Tool Use。把 Skill 包装成一个工具Agent 在需要时调用。比如定义一个clarify_intent工具输入是当前任务描述输出是判断结果和建议策略。这种方式更灵活但需要 Agent 框架支持工具调用。方式三前置处理层。在 Agent 主流程之前加一个预处理步骤专门运行 clarify-intent 判断。这种方式对 Agent 本身侵入最小适合已有成熟 Agent 想加装这个能力的场景。我目前用的是方式二和方式三结合日常对话用方式二复杂任务流用方式三。4.2 实际接入的配置示例以方式二为例工具定义大概长这样{ name: clarify_intent, description: 判断当前任务是否需要向用户澄清信息返回建议的执行策略, parameters: { type: object, properties: { task_description: { type: string, description: 当前任务的完整描述 }, context: { type: string, description: 可用的上下文信息 } }, required: [task_description] } }Agent 在接到用户请求后先调用这个工具根据返回的策略决定下一步。如果返回“直接执行”就进入主流程如果返回“澄清后执行”就把需要问的问题展示给用户。4.3 判断逻辑的代码化实现虽然SKILL.md是自然语言写的但实际运行时可以把它转成更确定的代码逻辑。我用 Python 写了一个简单的判断函数def decide_strategy(task_desc, context): # 识别任务类型 task_type classify_task(task_desc) # 评估信息完整度 completeness assess_completeness(task_desc, context) # 检测阻塞项 blockers detect_blockers(task_desc, context) if blockers: return { strategy: clarify, questions: blockers, reason: 存在阻塞项必须澄清 } if completeness 70: return { strategy: execute, assumptions: extract_assumptions(task_desc, context), reason: 信息完整直接执行 } if completeness 50: return { strategy: infer_and_execute, assumptions: infer_missing_info(task_desc, context), reason: 部分信息缺失使用推断值执行 } return { strategy: clarify, questions: generate_questions(task_desc, context), reason: 信息严重不足需要澄清 }这段代码的核心逻辑就是前面说的三层判断模型。实际部署时classify_task和assess_completeness可以用简单的规则引擎实现也可以用一个小模型来做分类。5. 常见问题与排查技巧实录5.1 问题速查表问题现象可能原因排查方法解决方案AI 还是问太多阻塞项清单太宽泛检查哪些问题被归为阻塞项收紧阻塞项定义只保留真正必须的AI 不问直接做错推断规则太激进检查推断项是否基于足够证据增加推断的证据要求无证据时归为阻塞项判断结果不稳定任务类型识别不准用相同输入多次测试增加任务类型的关键词匹配规则用户嫌问题太多问题没有合并检查是否一次性问完把所有阻塞项合并成一条消息推断假设没标注输出格式没约束检查输出模板强制在输出开头标注假设5.2 踩过的坑坑一把“用户没说”当成“用户没要求”。早期版本里用户没说输出格式AI 就直接用默认格式输出结果用户其实心里有明确期望只是忘了说。后来我加了一条规则如果输出格式会影响用户后续使用比如要导入其他系统那格式就是阻塞项必须问。坑二推断规则太具体导致过拟合。我一开始写了很多具体推断规则比如“如果用户提到 Excel 就用 openpyxl”。结果遇到用户说“表格”但实际是 CSV 的情况AI 就推断错了。后来改成更抽象的规则“根据任务类型选择主流工具如果有上下文线索则优先使用上下文线索”。坑三问题太多导致用户直接放弃。有一次 AI 一次性问了 8 个问题用户直接回了一句“算了我自己写”。后来我加了一个硬限制单次澄清最多问 3 个问题超过 3 个说明任务描述本身太模糊应该建议用户重新组织需求。坑四Skill 和主流程冲突。有些 Agent 本身就有澄清机制加上这个 Skill 后出现了双重询问。解决办法是在 Skill 里加一个检测如果 Agent 已经有澄清机制则 Skill 只做判断不直接输出问题而是把判断结果传给 Agent 的澄清机制。5.3 独家避坑技巧技巧一用“假设清单”代替“问题清单”。当信息缺失但可以推断时不要问“你希望用什么格式”而是直接说“我将使用 JSON 格式输出如果你需要其他格式请告诉我”。这样用户不需要回答只需要在不对的时候纠正。这比问问题效率高得多。技巧二给问题加优先级。如果确实要问多个问题标注哪些是“必须回答”的哪些是“不回答我就用默认值”。用户可以选择只回答必须的其他的让 AI 自己决定。技巧三记录用户的澄清偏好。如果用户多次对某类问题给出相同回答比如每次都选 JSON 格式那下次就直接用 JSON不再问。这个可以通过简单的用户偏好记录来实现。技巧四用“反向澄清”处理模糊需求。当用户需求特别模糊时不要问“你想要什么”而是给出 2-3 个具体方案让用户选。比如“我理解你可能是想要 A 方案特点...或 B 方案特点...你倾向哪个”这比开放式问题更容易得到有效回答。6. 实际效果与适用边界6.1 效果数据我在自己的日常工作中用了大概两个月粗略统计了一下代码生成任务的返工率从大概 40% 降到了 15% 左右文档处理任务的澄清轮次从平均 2.3 轮降到了 0.8 轮用户主动中断任务的比例从 12% 降到了 4%这些数字不是严格实验得出的只是我个人的使用记录但趋势很明显该问的时候问不该问的时候不问整体效率提升是显著的。6.2 适用边界这个 Skill 不是万能的。它最适合的场景是信息需求相对明确、任务类型可分类的工作比如代码生成、数据处理、文档转换。对于高度创意性的任务比如“帮我写个故事”信息完整度评估本身就不太适用因为创意任务的信息缺失是常态而且缺失的信息往往需要通过迭代来发现而不是通过澄清来补全。另外这个 Skill 的效果高度依赖任务类型识别的准确性。如果任务类型识别错了后面的判断全都会偏。所以我在实际使用中会把任务类型识别做得比较保守不确定的时候归为“通用任务”使用中等澄清倾向。6.3 后续可以扩展的方向这个 Skill 目前还是规则驱动的判断逻辑都是手写的。后续可以考虑用一个小模型来做任务类型识别和信息完整度评估这样能处理更复杂的场景。另外用户偏好记录目前还是简单的键值对可以做成更结构化的用户画像让推断更准确。还有一个有意思的方向是跨会话的意图连续性。比如用户昨天让你写了一个 Python 脚本今天说“再改一下”这时候“改什么”是阻塞项但“用什么语言”就是推断项——因为昨天已经确定了。这种跨会话的上下文利用目前还比较粗糙值得继续打磨。我个人在实际操作中的体会是写这个 Skill 最大的收获不是那套判断规则本身而是被迫想清楚了一件事AI 协作的本质不是让 AI 更聪明而是让 AI 更懂边界。知道什么时候该问、什么时候该做、什么时候该猜这比单纯提升模型能力更能解决实际问题。这套SKILL.md我还在持续迭代每次遇到新的误判场景就加一条规则慢慢打磨下来它已经成了我日常用 AI 干活时最离不开的一个基础能力。