先摊牌：我有过一段特别崩溃的日子。

我让 AI 帮我做一件挺简单的事——"把这份用户反馈整理成几类，标出优先级"。你猜它干了啥？

它没动。它先反问了我六个问题：

「你说的"用户反馈"是指原始工单描述，还是包含评论区的内容？」

「"优先级"是按营收影响排，还是按技术难度排？」

「需要区分新老用户吗？」

「输出格式用表格还是 Markdown？」

「如果同一类反馈存在冲突，以哪份为准？」

「要不要输出建议动作？」

六个问题，一个字正事没干。我当时就想：我是不是养了个客服。

更气人的是，这种"先问你一嘴"的行为越来越普遍。我让 AI 写个脚本，它问我"用什么语言"；我让它查个资料，它问我"要中文还是英文"；我甚至有一次让它帮我删掉一个文件夹里的临时文件，它问我"要确认一下是否要保留备份吗"。

那一刻我深刻意识到：AI 最大的问题不是笨，是它太像一个不敢担责的实习生。

一、它为什么这么爱问？因为它被训成了"必须先确认"

这事得怪训练流程。模型在海量"问题—回答"里学到的不只是知识，还有一种行为范式：遇到不确定，先问用户，几乎不会扣分；自作主张做错了，会被算成"幻觉"和"越权"。

所以模型的默认策略其实是这么一条:

不确定 → 提问 → 把决策权交还人类。

这在人机交互里有个专门的名字，叫 clarification seeking（主动请求澄清）。听起来很贴心对吧？它确实贴心，问题是它不区分场合。

你在做一个需要脑子的开放任务，AI 多问一句，往往能显著提升结果质量。苹果砍掉一半功能你只会觉得"太激进了"，但 AI 多问一句你会觉得"这助手真靠谱"。

可一旦你把这种互动带进批处理、自动化、流水线里，它就从优点变成了致命的阻塞点。

想象一下：你接了个定时任务，让 AI 每小时处理一批数据。它处理第一条时问了你一个问题，然后呢？

• 它等在那儿，直到你回复；
• 或者它自己猜一个默认值，继续跑——但这个默认值未必符合你的意图，而你根本不知道它猜了；
• 最糟的情况：它猜了，但没在结果里说明"我这里假设了X"，你事后才发现整个批次的处理逻辑跑偏了。

这就是我说的"上下文税"的另一面：每一轮澄清，都在向人类征收一次注意力税。你写代码那会儿，被 AI 打断三次，思路就断了。

二、我做了一组对照实验，结论有点扎心

我拿同一个任务跑了不同写法，任务本身是：给一个开源项目写一段 README 的安装说明。

版本 A（我平时的写法）：

给这个项目写一段 README 安装说明。项目用的是 Go 1.22+，
依赖 Postgres 15。我不希望文档里出现"假设你已经装好了数据库"这种话，
因为用户就是被这步卡住的。直接输出 Markdown。

结果：AI 憋了两次想追问的冲动（用了"如果你需要的话我可以补充"这种软化句式），然后给出了完整文档。中间没有一次真正的"你选哪个"。

版本 B（我偷懒的写法）：

帮我写个安装说明。

结果：反问七个问题，包括"面向什么技术水平的读者""需要覆盖哪些操作系统""要不要截图占位"。

注意这两个版本的实际信息量差距，并没有大到需要问七个问题那么多。AI 之所以问，是因为它能感觉到你给的上下文稀薄，于是本能地想补齐。信息给得越少，提问越多；这不是它谨慎，这是它在填坑。

然后我试了版本 C，这是我现在的主力写法：

给这个项目写一段 README 安装说明。

已确定的事实：
- Go 1.22+，Postgres 15（我本地就是这两个版本）
- 目标读者是第一次接触这个项目、但本身会写 Go 的开发者
- 文档必须包含：前置依赖、初始化数据库、启动、第一个请求示例
- 输出 Markdown，不要寒暄，不要"以下是一份示例"

遇到以下情况直接做决定并推进，不要提问：
- 操作系统差异 → 默认覆盖 Linux 和 macOS
- 端口/路径等细节 → 用最常规的选择
- 文档顺序 → 按"读者实际操作的顺序"排

如果真的缺少关键信息（确实无法推断的那种），一次性把问题列出来，
并在正文里先用合理默认值写完。

结果：一次通过，零提问，文档结构完整，Windows 部分被正确略过并留了一句"Windows 用户请自行适配"。

三个版本，同一个模型，同一个任务。差别不在模型，在你有没有提前把"决策权"分配好。

三、心法：不要教它"问得更好"，要教它"别问"

大部分 prompt 教程教的是"怎么问得更精确"，这没错，但解决不了"它爱问"这个问题。真正管用的是另一件事：你得显式地把决策权打包扔给它。

我沉淀了四条心法，按实用度排序：

1. 给"默认动作"，而不是给"选项"

别说"你选一个方案"，要说"默认用 A，除非……"。选项是问句，默认值是陈述句。这一个改动，提问数量直接砍半。

2. 提前声明"提问的门槛"

我常用的原话是："只有当我给的信息完全不足以完成任务时才提问，并且一次性问完。"这句是开关，不加它，模型默认会提问。

3. 明确"不许出现"的句式

AI 有个很讨厌的毛病：它爱用软化句式来假装在服务你。

"如果您需要，我也可以……"、"如果您觉得不合适，可以告诉我……"、"这里还有一些其他选项……"

这些句子在协作里是贴心，在自动化里是噪音。所以我会在 prompt 里直接点名："不要输出任何'如果你需要我可以…'类的收尾句。"——一句话，能让输出干净一半。

4. 让它"边做边标注假设"，而不是"先问再做"

这个是解决"猜错了你不知道"的关键。与其要求它必须先确认，不如要求它在不确定时选一个合理默认值继续，但在结果里用固定标记把假设列出来。

凡是做了假设的地方，用 [假设: xxx] 标注，集中在文末输出。

这样你得到的是：一个完整可用的结果 + 一张待你复核的清单，而不是一堆等着你回答才能往下走的问题。

四、行业视角：为什么现在这件事变得更重要了

过去写 prompt 是"人机对话"，你追问一句、AI 答一句，人在环里是天然成立的。

现在不一样了。

AI 正在从"聊天窗口"往"常驻进程"迁移——它住在你的终端里、你的服务器上、你的定时任务里。你写的每一句 prompt，迟早都要变成一段没人盯着跑的后台脚本。

这个转变有个致命推论：

在后台跑的 AI，必须自己拿主意。而"拿主意"这件事，恰恰是模型最不擅长、也最需要你明确授权的。

所以你会看到一个反直觉的现象：一堆团队花大力气提升模型能力，另一堆团队在拼命做"少问"工程。真正跑得久、跑得稳的系统，往往是后者赢的。

另一个正在成形的趋势：模型分层。便宜的小模型负责分类、抽取、路由，贵的大模型负责规划和决策。这时候 prompt 里就必须写死"你能自己决定什么"——因为它身上那个"停下来问你"的默认值，会成为整条链路的节流阀。

说白了，Prompt 工程的下半场，是权限工程。你不是在教它说话，你是在给它划权限边界和兜底方案。这跟当年给实习生定"哪些事可以自己拍板"是一模一样的管理动作。

五、最后，吐槽一下我自己

写完这篇我反思了一下：我之所以一开始被 AI 问得烦躁，还有一个原因是我潜意识里把"被追问"当成了"被尊重"。

这挺荒唐的。AI 问你问题，多数时候不是在尊重你，是在把自己的活儿推回给你。

真正的尊重是：你把一件界定清楚的事交出去，对方接住、干完、交付结果，附一句"这里我做了两个假设，你扫一眼"。而不是发回来一张问卷。

所以我现在给 AI 的第一句话，往往是这句：

"我给你的是一份完整的委托，不是一个待办事项。能自己定的，自己定。"

然后它就闭嘴了。挺好。

毕竟我雇的是 AI 助手，不是一个会点"发送"的客服。

最后一句留给你：如果你也在被 AI 反问折磨，试试把"给我选项"改成"给我默认值"，把"你可以问我"改成"你先做"。就这两处改动，通常就能把一场问卷变成交付。

要不要我继续帮你把某件正事一次性做完？