AI Agent 要么问一堆、要么闷头做错我写了个 Skill教它什么时候该问、什么时候该直接做最近被 AI Agent 折腾得够呛。我让它帮我整理一份调研报告它先问“目标读者是谁”“格式要 PDF 还是 Word”“要不要带数据图表”一连串问题砸过来我回完基本信息它又问“引用的文献范围要不要限定近三年”——那一刻我差点把电脑合上。反过来让它修改一个配置文件它什么也不问直接按自己的理解把参数改了结果环境起不来我排查了半天才发现它把“开发环境”和“生产环境”的配置混在一起了。相信用过 AI 编程助手、AI Agent 这类工具的人都有同感要么问东问西拖慢进度要么闷头闷脑做错方向真正懂得把握“问与不问”分寸的太少。后来我琢磨了很久问题的根源不在于模型本身笨而在于我们从来没告诉过它“什么时候该问、什么时候该直接做”这套判断规则。于是我写了一个 Skill——一个专门教 AI 判断提问时机和执行策略的技能包。这个东西不是什么高深算法就是一套结构化的决策规则加执行策略把它挂到 AI Agent 或者支持 Skill 机制的 AI 工具上就能显著减少“无脑追问”和“闷头做错”两类问题。今天把整个设计思路、核心逻辑、完整实操和踩坑记录都整理出来给同样被这个问题困扰的人一个可直接复用的方案。1. 先拆解问题AI 的“问与不问”为什么这么难拿捏1.1 两个极端是怎么形成的我接触过不少 AI Agent 产品也自己在代码里调过各种大模型 API。观察下来AI 表现出的两种极端行为背后各有成因。“问太多”的 Agent通常是开发者或用户给它灌输了过度强调“准确性”和“用户确认”的指令。比如系统提示词里写了“在执行任何操作前必须确认用户意图”“不确定时要向用户澄清”——这类指令的本意是防止 AI 乱做但模型没有人类那种“小事别烦我”的分寸感于是一切都成了不确定什么都问你。我见过最夸张的案例一个 Agent 在删除临时文件前居然弹了三次确认框连“是否确定删除 /tmp 下的缓存”都来问这已经不是智能助理是强迫症患者。“闷头做错”的 Agent 则走了另一个极端。系统提示词里写了“尽可能自主完成减少用户打扰”模型就把“自主”理解成了“按最可能的默认假设执行”。它确实不问了但也不验证了。更麻烦的是这种 Agent 出错之后往往没留下解释用户根本不知道它当时为什么做那个决定排查起来全靠猜。这两类问题本质上是同一个能力的缺失模型缺少一套稳定的、可解释的风险评估与决策框架。人做事的直觉是“小事直接办、大事先问清”模型没有这个直觉它只有概率。你给它“自主”的词它就激进你给它“确认”的词它就保守。如果我们能把人的这套分寸感转化成显式的规则教给它问题就能缓解一大半。1.2 Skill 到底是个什么角色在讲我的方案之前先对齐一下概念。这里的 Skill 不是一个严格统一的标准名词不同工具里叫法不一样有些平台叫“插件Plugin”有些叫“技能Skill”有些叫“自定义指令Custom Instructions”底层机制大同小异——都是给模型额外配置一套“领域知识 行为规则 执行流程”让它在特定场景下表现得像一个有经验的专家而不是一个只会接话的通用聊天机器人。用生活里的话说Skill 就像是给一个很聪明但不懂行规的新员工发的“岗位手册”。新人本身学习能力强但没有手册的时候他做决定全凭临场发挥时好时坏。有了手册他就知道“遇到 A 类情况走流程 A遇到 B 类情况先汇报再动手”行为一下就稳定了。所以我的思路很直接我写的这个 Skill就是一份“提问与执行决策手册”。它不教 AI 怎么做事教的是 AI 怎么判断“这件事我能不能直接做”。把这个判断能力补上Agent 的行为质量会有一个很明显的提升。1.3 理想状态像一位靠谱的同事我给自己定的目标很简单让 AI 的行为向“一位经验丰富又懂分寸的同事”靠近。这位同事什么样交代一句“帮我把上个月的数据整理成表格发我”——他会直接做不追问“您要什么格式”这种废话最多在完成后说一句“我按 Excel 导出了如需 CSV 我可以再转换”。但如果我对他说“帮我把项目的客户关系理一理”——他会先问清楚是梳理客户分级还是整理联系方式还是跟进状态因为这个任务歧义太大做错了就是整份返工。把这种“靠谱同事感”拆解成可写进 Skill 的规则就是我要做的事。下面详细讲这套规则是怎么设计的。2. 决策框架设计四个维度判断“问”还是“做”2.1 影响判断的关键变量我研究了大量 Agent 翻车案例也复盘了自己用 AI 工具时最烦的场景最后提炼出四个核心判断维度任务风险、操作可逆性、需求明确度、上下文完整度。这四个维度基本覆盖了“该不该问”的所有关键信号。任务风险指这个任务做错了会造成多大损失。给文件重命名错了改回来就行风险低删除一批数据库记录错了可能找不回风险高给客户发正式邮件措辞不当影响合作关系风险更高。风险越高越倾向于先问。操作可逆性指这个操作能不能无损撤销。改代码可以 git revert可逆发出去的邮件撤不回来不可逆修改线上数据库配置就算能回滚也可能造成短暂服务中断算“部分可逆”。不可逆的操作必须提前确认。需求明确度指用户原始指令里的信息是否足够确定执行结果。注意这里的“明确”不是指用户说了多少字而是指“有没有歧义”。用户说“帮我把文件压缩一下”指令很短但很明确用户说“帮我优化一下这个项目的性能”信息量看着不小但“优化到什么程度、优先优化哪一块、是否有性能指标”全是歧义。上下文完整度指 AI 当时掌握的信息是否足以支撑正确决策。用户给了一张截图说要“修改这里的文案”但截图上文字被截断了上下文就不完整用户在对话里已经交代了背景和偏好那后续任务上下文就是完整的。上下文不足时与其猜测不如把缺口问出来。2.2 组合判断的决策矩阵四个维度不是孤立的它们之间会互相影响。我的做法是建立一套组合决策规则而不是单看某一个指标。下面这张表是我在 Skill 里实际用的决策矩阵也是整个技能最核心的部分。风险等级可逆性需求明确度上下文完整度决策结果低可逆明确完整直接执行低可逆有歧义完整直接执行基于最合理假设并在交付时说明中可逆明确完整直接执行完成后主动汇报关键结果中不可逆明确完整执行前做一次简短确认高不可逆明确完整必须确认且确认时要说明风险和备选方案高不可逆有歧义不足不执行先问清楚关键缺口任何任何有歧义不足优先补齐上下文再评估是否执行低可逆有歧义不足可以先做一个最小验证版本再按反馈修正这张表看起来简单但它解决了两个关键问题一是把“问不问”从玄学变成了可判定的规则二是给模型一个明确的“兜底路径”——当多个维度互相矛盾时比如风险低但上下文不足应该选什么动作。实际使用下来模型的决策稳定性确实比之前强很多。2.3 规则背后的核心逻辑这套矩阵不是凭空拍脑袋定的它的逻辑基础是“错误成本对比”。我算过一笔账AI 多问一次用户损失的大约是 10 到 30 秒的回复时间AI 做错一件事用户损失的可能是几分钟的返工也可能是几小时的排查甚至是一次不可逆的线上事故。当“问的成本”远低于“错的成本”时就该问当“问的成本”高于“错的成本”时就该直接做。但这还不够。真正关键的是第三类情况最省事的往往不是“问”或“做”而是“基于合理假设做但把假设说出来”。比如用户让 AI “整理一下项目文档”文档目录结构很清楚AI 完全可以按常见规则整理然后在交付时补一句“我按主题分了四个文件夹如果你们团队有固定的命名规范告诉我我马上调整”。这种方式既没有打断用户又给了用户纠错的机会体验远好于先问一堆问题。这个思路贯穿了整个 Skill 的设计。我在规则里专门加了一条“假设声明机制”AI 可以直接做但必须在交付时显式声明自己做了哪些假设。这就把“闷头做错”变成了“有交代地做”即使假设不对用户也能快速发现问题不用从结果里反推 AI 的思路。3. Skill 的核心结构设计3.1 整体框架三块内容缺一不可确定了决策逻辑之后就要把它落成一个能被 AI 读取、理解和执行的 Skill 文件。我在实践中摸索出一套三块结构目前用下来效果最稳定。第一块是元信息定义包括技能的用途、适用场景、触发条件。这一块的作用是让 Agent 知道“什么时候该启用这个技能”。第二块是决策规则就是上一节说的那套矩阵但要改写成模型更容易执行的表述形式。第三块是执行规范和输出模板告诉模型“决定直接做之后怎么执行”“决定要问之后怎么问”以及各种情况下交付结果的格式。三块缺一不可。少了元信息Agent 可能在不需要的场景也套用这套规则反而显得啰嗦少了决策规则整个技能就没有灵魂少了执行规范模型即使判断对了表达方式也可能不统一用户体验还是很乱。3.2 决策规则的提示词写法决策矩阵本身就是给人看的直接丢给模型也能懂个七八分但效果不够好。我在反复测试之后把矩阵改写成了“条件列表 行动指令”的提示词形式模型执行得更准确。核心写法是这样在收到用户任务后先按以下顺序完成风险预判 1. 识别任务类型是信息查询、内容生成、代码操作、文件处理还是外部系统操作 2. 评估风险等级操作是否影响不可恢复的数据是否涉及外部真实系统是否代表用户对外沟通是否消耗大量资源 3. 检查歧义点用户指令中是否存在多个合理理解若有列出具体歧义。 4. 检查上下文当前对话、用户历史偏好、关联文件中是否有足够的决策信息 完成预判后按以下规则行动 - 如果风险低、可逆、无歧义、上下文充分直接执行不做任何确认。 - 如果风险中低、可逆、存在次要歧义基于最合理假设执行但必须在交付中说明假设内容。 - 如果风险中高或不可逆即使指令看似明确也必须用一句话向用户确认关键风险点。 - 如果上下文不足或歧义重大先一次性问清所有缺口不要连环追问。这段描述看着不复杂但它把模型的思考过程拆成了有顺序的步骤。我对比过给模型一个“步骤化判断流程”比给一张静态矩阵表效果好得多模型会更有条理地收集信息不会跳过关键评估项。3.3 执行与确认的输出规范判断完了怎么“问”也是有讲究的。我在这个 Skill 里专门定义了提问和交付的格式避免出现“问一堆问题”的失控场面。提问规范的核心是“一次性问完 给出建议默认值”。模型要问就把所有需要的信息缺口一次性列出来不要问一个等一个同时每个问题后面带上 AI 自己的建议默认值用户如果不在意直接回复“按你的建议来”就能推进。这个设计极大减少了来回对话的次数。执行规范的核心是“假设声明 结果摘要”。直接执行的任务交付时先说明“我做了哪些假设”再给结果。特别是代码改动、文件操作这类任务还要附上关键变更摘要方便用户快速检查。这里我强烈建议加一条“不询问是否继续除非有不可逆操作”——这是整个 Skill 里最能提升效率的一条规则。输出模板我定为统一的三段式动作声明做了什么/准备做什么、假设列表基于什么前提、结果交付成果物或下一步请求。这套模板不仅让 AI 的行为更规范用户也更容易发现 AI 的判断是否合理方便反馈纠偏。4. 完整实操手把手写出并接入这个 Skill4.1 第一步定义技能元信息与触发条件我用的环境是支持 Skill 机制的 AI Agent 工具具体哪种不重要关键是 Skill 文件通常是一个 Markdown 或 YAML 格式的配置包含 name、description、when_to_use 等字段。第一步是把元信息写清楚尤其是触发条件否则后面全乱。name: ask-vs-act-decision description: 当AI Agent需要执行用户任务时先判断是否应该向用户提问确认还是直接执行。适用于所有涉及实际操作、内容生成、代码修改、文件处理的任务类型。 when_to_use: - 用户提出一个可执行的任务请求 - 用户指令存在潜在的歧义或信息缺口 - Agent准备执行任何可能影响系统、文件、代码或对外沟通的操作 when_not_to_use: - 用户正在进行纯闲聊 - 用户已经明确指示不要提问直接执行 - 这是一个连续任务链条中上下文已经完整承接的后续步骤这里有一个特别容易被忽略的坑连续任务链条中的后续步骤不要重复走决策流程。用户在前面对话里已经说清楚了需求和偏好Agent 执行后续操作时再问一遍会让人非常恼火。我在元信息里单独加了“when_not_to_use”这一条就是为了防止这个问题。4.2 第二步编写完整的决策规则文件这一步是核心。我把前面讲的决策矩阵、判断步骤、提问规范和输出模板全部写进一个 Markdown 文件命名成 SKILL.md这是目前比较通用的 Skill 文件格式。完整内容我精简后大概是这个结构# Ask vs Act 决策技能 ## 核心目标 在执行用户任务时用最少的问题换取最高的执行准确率。 宁可多做一步假设验证也不要用连环提问消耗用户耐心。 ## 决策流程 Step 1: 识别任务类型与涉及的操作范围。 Step 2: 从风险、可逆性、明确度、上下文完整性四个维度评估。 Step 3: 对照决策矩阵确定行动类型。 Step 4: 按行动类型执行对应的输出规范。 ## 决策矩阵 此处放上一节那张表格的完整版 ## 提问规范 1. 只有在确认信息缺口无法用合理假设填补时才发起提问。 2. 所有问题必须一次性列出禁止连环追问。 3. 每个问题后附建议默认值用户可以一键采纳。 4. 提问前先说一句“我整理了几个关键信息需要确认”让用户有预期。 ## 执行规范 1. 直接执行的任务不要请求确认。 2. 执行完成后按“动作声明 - 假设列表 - 结果交付”三段式汇报。 3. 遇到不可逆操作执行前必须确认确认时同时说明备选方案。 4. 如果用户后续说“你看着办”立即切换到完全自主模式并关闭后续确认请求。这个文件我迭代了很多版。刚开始写得特别长各种边界情况都列了一堆结果模型反而被冗长的规则干扰判断效率下降。后来我精简到“决策流程 决策矩阵 提问规范 执行规范”四块效果反而明显提升。教训是Skill 文件不是越详细越好模型能稳定执行的规则才是好规则。4.3 第三步接入 Agent 并建立测试集Skill 文件写完之后把它放到 Agent 指定的 skills 目录下一般就能自动加载。但接入只是开始真正花时间的是测试。我建了一个测试集包含十几种典型的用户指令场景模糊的中等风险任务、明确的高风险任务、上下文完整但指令简短的日常任务、矛盾指令等等。每次修改 Skill 之后就跑一遍测试集看 AI 的决策是否符合预期。测试场景我举几个例子比如“帮我把 /tmp 下超过 100MB 的日志文件清理掉”这属于“中高风险 不可逆 指令明确”正确行为是执行前确认并说明风险再比如“帮我写一封邮件给王总提醒他明天下午开会”这是“中风险 不可逆 信息较完整”正确行为是直接写并给用户预览而不是先问“您想用什么语气”之类的废话。我建议所有想调这个 Skill 的人都建类似的测试集。没有测试集的迭代等于瞎调你今天觉得“它问得少了”明天它可能就“闷头做错”了。只有把常见场景固定下来每次改动才能看出是进步还是退步。5. 常见问题与排查技巧实录5.1 问题一AI 还是问个不停这是我最开始遇到的最大问题。明明规则里写了“低风险直接执行”AI 还是在小事上反复确认。排查下来发现原因很隐蔽模型对“低风险”的理解和我不一样。在它看来改一行代码也好、发送一封邮件也好都是“重要操作”应该确认。解决办法是在 Skill 里增加一个“常见低风险操作清单”直接告诉模型哪些操作属于“闭眼做”的范畴。比如读取文件、生成草稿内容、修改本地且已被版本控制的文件、整理格式、搜索资料——这些都属于低风险禁止提问。有了这份白名单模型的表现一下就正常了。这个思路其实和人类带新人很像光说“小事别问我”没用得举例子告诉他哪些算“小事”。5.2 问题二AI 该问的时候不问反过来另一个极端是 AI 过于激进删库、发邮件、改线上配置都不带确认的。这通常是因为模型过度优化了“自主性”这个目标忽略了风险维度。我的排查方法是看 Agent 的日志找到它执行前的“思考过程”确认它到底有没有走决策流程。很多时候发现它根本跳过了前置评估步骤直接拿用户的指令就去执行了。解决办法是两条一是在 Skill 开头加一条强制指令——“在收到任何包含外部副作用的任务时必须输出一行评估结果格式风险xx可逆性xx行动xx”让模型的决策过程显式暴露出来二是在 Agent 工具层面对高风险操作加硬限制比如执行删除、发送、修改线上配置前工具本身要求二次确认。Skill 层和工具层双保险才能堵住这个漏洞。5.3 问题三上下文判断失误还有一种情况让我印象很深用户在对话前面已经详细交代过偏好后面提了个新任务AI 却把它当“上下文不足”来处理又开始提问。用户气得直接说“之前不是说了吗”。这实际上是模型对“历史上下文”和“当前任务”关联性的判断不够。我的解决办法是在决策流程里加了一条规则如果在当前对话的历史中能找到与本次任务相关的明确信息优先视为“上下文完整”只有确认历史信息无法回答当前需求缺口时才发起提问。同时要求模型在提问前先自检一句“用户之前是否已经直接或间接回答过这个问题”这个自检步骤简单有效能消除一大半“明明说过又问一遍”的情况。5.4 快速排查速查表我把实操中遇到的高频问题整理成一个速查表方便大家直接对照排查。症状可能原因排查方向解决方案小事反复确认风险等级判断过严查看思考过程中对风险的评估值增加“低风险操作白名单”大事不做声决策流程被跳过查看是否输出了显式的评估结果强制要求输出评估行工具层加硬确认连环追问提问规范缺失查看提问是否分批进行一次性列出所有问题并附默认值忽略历史信息上下文关联判断弱查看是否检索了历史对话增加“历史自检”步骤做了但不解释输出规范不完整查看交付格式使用三段式输出模板无法关闭提问模式缺少模式切换机制查看是否响应用户“你看着办”指令增加“完全自主模式”切换规则这个表是我自己排查时用的现在分享出来。遇到问题时别急着改一大堆配置先定位是哪个环节出了问题对症下药远比大改有效。6. 一些打磨经验和后续扩展方向这套 Skill 我用了大概两个月中间迭代了差不多十几个版本。整体感受是它没法把 AI 变成一个完美判断者但确实能把“问太多”和“做太错”这两类问题的发生频率降低一个数量级。真正的价值在于它让 AI 的决策过程变得可预期、可检查、可修正——用户不再觉得 AI 是个“薛定谔的助手”开盲盒式地碰运气。最后分享一个小技巧不要让 Skill 试图覆盖所有场景。我一开始贪大求全写了各种行业、各种任务的细粒度规则结果模型执行起来反而混乱。后来我采用“核心规则通用化 场景规则可插拔”的方式——核心决策矩阵保持通用某个特定场景比如邮件撰写、代码重构、数据处理再单独挂场景专用的补充规则。这样既保留了通用性又能针对性地提升特定任务的体验维护起来也轻松得多。如果你也想给自己用的 AI Agent 加上这套能力建议从最简单的版本开始先只定义决策矩阵和输出规范跑一周收集实际翻车案例再有针对性地补充规则。不要一次加太多AI 的行为调教会滞后你需要留出观察窗口才能知道每条规则到底起没起作用。