你问了一个具体问题——“这个业务该用 Postgres 还是 DynamoDB？“——然后收获四段”这要看你的访问模式、规模需求、团队熟悉度和预算”。这不是分析，这是模型在镜像开放问题给出开放回答。回答泛几乎总是 prompt 形状的问题，不是模型能力问题：同一个模型，面对”我该怎么设计 App”会打太极，但面对”日活 1 万、主要是 key-value 查询、团队会 SQL——Postgres 还是 DynamoDB？3 句话内决定”就会给出锋利答案。
本文梳理六种导致输出泛的 prompt 形状，以及把模型从外交辞令拉回真实判断的改写方法。
常见原因
按命中率排序。
1. 问题开放，没有决策点
典型反面：
"我的 React App 该怎么组织？"
"鉴权该怎么处理比较好？"
"数据库选型你有啥想法？"模型没有要选的对象，于是把选项空间巡视一遍，不做选择。你拿到的是”考虑清单”，不是”决定”。
如何判断：你的 prompt 没列出两个或更多具体选项，也没有以一个模型必须执行的动词结尾（“选”、“写”、“排序”、“决定”）。
2. 没给上下文，模型只能猜场景
如果你只问”最好的缓存策略是什么”，没说流量、读写比、现有技术栈，模型默认回”看情况”——因为它脑补了一堆听众，任何具体答案对其中一半都是错的。这种含糊是它的”校准”。
如何判断：把 prompt 当成你完全不了解项目的人去读。如果你判断不出哪个选项肯定错，模型也判断不出。
3. 没成功标准
“给个好答案”——这里”好”是什么意思？具体步骤？排序列表？50 行内的代码片段？没有靶子，模型就交出”所有可能的好答案的中位数”，那就是糊。
如何判断：prompt 里没写答案应该是什么形状、多长、读完用户该能做什么。
4. RLHF 让模型对观点题过于谨慎
现代 chat 模型被训练得在主观问题上打太极，避免观点偏激冒犯用户。你把问题写成征询意见的样子（“你怎么看 Tailwind”）就触发外交模式。
如何判断：回答有”两边都有道理”的气味。修法是写成”模型必须做出并辩护的绑定决定”，不是”分享想法”。
5. 要”全面综述”
“comprehensive”、“完整指南”、“你需要知道的一切”这类词推模型走宽度而不是深度。结果是 12 条要点每条 1 句话，而不是 3 条要点每条 4 句话。
如何判断：数输出里的具体工件（文件路径、数字、代码、命令）。少于 3 个就是宽度吃掉深度。
6. 前轮建立了”调研”框架
如果你第一轮问的是”对比 A、B、C”，后续轮次会继承对比框架。“现在选一个”得到的是带 caveat 的排序，不是决定。
如何判断：往上翻对话。最近几轮是在讲选项和权衡，那模型就在调研模式里，无论你这轮怎么问。
动手前先确认
- 确认问题是在本地、预览还是生产环境出现；只在一个环境出现时，先查环境变量、缓存和部署产物。
- 记录一条可复现路径：具体 prompt、模型、temperature、对话历史。
- 把含糊的输出原样保存，方便和改写后的输出对照。
需要收集的信息
- 完整的 prompt 文本和 system prompt（如果有）。
- 模型名称版本、temperature、max tokens。
- 对话历史（前面的轮次会影响框架）。
- 你拿到的输出 vs 你想要的输出。
- 模型给出锋利答案所需要知道的领域背景。
最短修复路径
按收益排序，前 3 步通常能解 80% 的情况。
Step 1：把”怎么”改成”选”
把开放询问改成绑定决策：
| 含糊 prompt | 锋利 prompt |
|---|---|
| ”我的 React App 该怎么组织？" | "12 条路由，4 条需鉴权。选：单 app router vs 嵌套 layouts。3 句话内辩护。" |
| "用什么数据库？" | "负载：每天 1 万写、90% 读、需要 join。选 Postgres 还是 DynamoDB。2 句话给决定因素。" |
| "测试策略有啥想法？" | "选：Vitest 主导的单测 vs Playwright 主导的集成。基于 3 人团队、每周发版的场景辩护。” |
模型现在有”可能选错”这件事——这逼它真的去推理。
Step 2：前置 5 行上下文
提问前先粘这个模板：
技术栈：<运行时、框架、关键依赖含版本>
规模：<用户量、QPS、数据量>
约束：<预算、deadline、人数、部署目标>
试过：<已经尝试什么、为什么失败>
目标：<要交付什么，附成功标准>例子：
技术栈：Next.js 14、Supabase、Vercel
规模：日活 2000，峰值 200 写/分
约束：50 美金/月基础设施预算，单人开发
试过：PgBouncer 连接池；峰值还是耗尽
目标：一处具体配置或架构改动让峰值跑通，diff <30 行
问题：……5 行上下文把”看情况”翻成”给定 X，做 Y”。
Step 3：显式禁用打太极词汇
附加：
答案约束：
- 禁用："看情况"、"可以考虑"、"也许"、"或许"、"各种"
- 选一个并辩护
- 至少包含 2 项：文件路径、命令、代码片段、具体数字、版本号
- 不超过 200 字这招意外有效——RLHF 反而让模型很擅长服从明确写出来的负面约束。
Step 4：要工件，不要建议
把”解释怎么 X”换成”产出 X”。要正则就要正则字符串，不要正则教程。要配置就要 YAML 文件，不要讨论配置项。
差： "这个 nginx 路由该怎么配？"
好： "写出 nginx 的 server 块。只包含必要的 location。无解释注释。"Step 5：还泛？反问它缺什么
如果模型确实因为缺信息答不出，让它告诉你缺什么：
"要给出具体而非通用回答，你还需要我提供哪些最少信息？列 3-5 个问题。"然后你回答这些问题，粘进去，重问。一次性含糊回答就变成两轮锋利回答。
Step 6：调研框架卡住时就重置对话
前轮建立了对比框架时，新开一个对话，只粘相关上下文。长会话会累积框架包袱，单次追问消不掉。
怎么确认已经修好
- 新回答前 2 句就指明具体选择。
- 输出里至少有一个可执行工件（代码、命令、配置）。
- 同事读完能直接干活，不需要追问。
- 全文”看情况/也许/可能”出现 0 次。
如果还是没修好
- 缩到最小 prompt：一句上下文 + 一个决策动词。
- 换更强的模型（Opus、GPT-5 Pro）；有时含糊是小模型能力上限。
- 观点题试 temperature 0.7——过低反而过度打太极。
- 从 chat UI 切到 API 调用并用 system prompt 控制；UI 有它自己的中立性偏置。
预防建议
- 把每个 prompt 当成”有返回类型的函数”——写 prompt 前先想好返回类型。
- 维护一个个人”反打太极”后缀，每次问观点题就粘上。
- 调研类问题分两轮：“综述”轮和”决定”轮永远不要合在一起。
- 审最近 10 个 prompt 里的”怎么”——每个”怎么”都该改成”做”或”选”。
- 新任务类型先用 few-shot 展示锋利答案的样子。
相关阅读
- 长 Prompt 反而变差
- “best” 没定义的 prompt
- Prompt 没写成功标准
- 要执行结果，AI 却给了清单
- 输出听着精致但不可执行
- Prompt 触发了拒答——怎么换个写法
- 示例太多反而压住任务：4 个原因 + 对症修复
标签: #排查 #Prompt #Prompt 质量 #回答太泛