你问”创业公司工程团队怎么 scale 最好？“，得到 800 字、覆盖招聘、文化、流程、工具、远程的答案。这答案严格说没错，适用于历史上每一家创业公司——也就是说，不适用于你这一家。
最快修复：补上范围（一个数字）、约束、决策方和一句话成功标准，再把开放动词（“我该怎么…”）换成决策动词（“在这三个里选一个，用三句话辩护”）。光这一步改写通常就够了。后面是它不够时的完整清单。
宽问题必产宽答案，因为模型得写一个在你问题所允许的整个输入空间里都站得住的东西。输入空间一大，唯一安全的输出就是常规建议的平均态——按定义就是平庸。这不是”换更强的模型、prompt 写得更狠”就能绕过的限制——GPT-5.5、Claude Opus 4.7 或 Gemini 3.1 Pro 只会把这份平均态写得更漂亮。真正的解法是把输入空间缩小到只有一个答案正确。Anthropic 把这套思路叫 context engineering（上下文工程）：有用的上下文不是”更多文字”，而是那一小撮能改变”好答案长什么样”的细节——受众、目标、约束、优先级。
你属于哪一类？
改写前先把你的 prompt 过一遍下表。大多数宽 prompt 会同时栽在两三行上。
| 缺的要素 | prompt 里的征兆 | 一句话修法 |
|---|---|---|
| 规模 / 范围 | 没数字（3 人还是 300 人？） | 写明规模、量级或阶段 |
| 约束 | 没有”给定 X”或”受 Y 约束” | 补预算、deadline、技术栈、人数 |
| 决策方 | 没点名角色 | 写明谁决定、他优化什么 |
| 成功标准 | 没有”好的输出长这样…” | 用 2-3 条可测项定义成功 |
| 输入数据 | 0 个具体数字、名字或文件 | 粘上 5+ 条你的具体事实 |
| 决策动词 | 问的是”怎么/哪个最好”，不是”选/排/挑” | 从点名的候选里逼出一个选择 |
常见原因（展开）
1. 没规模 / 范围
“怎么组织工程团队”可以是 3 人，也可以是 300 人。模型写一个两边都覆盖的答案，结果两边都不贴。
如何判断：你的问题没数字。
2. 没约束
“用什么数据库最好”——没流量、没成本上限、没团队熟悉度。模型没有任何东西可以拿来排除选项，于是把所有选项都列一遍。
如何判断：开放问题，没有”给定 X”或”受 Y 约束”的子句。
3. 没决策方
“我们 roadmap 该怎么选”——给谁选？CEO 的标准和 eng lead 的不一样。没声明决策方，模型就在所有人之间取平均。
如何判断：prompt 里没点名角色。
4. 没成功标准
“帮我想想 X”，但没说什么算”帮上忙”。模型写综述，因为综述谁都挑不出错。
如何判断：prompt 里没有”好的输出长什么样”的子句。
5. 没输入数据
要建议，但没给你的具体情况，模型只能泛写。
如何判断：prompt 里 0 个具体数字、名字、文件、数据点。
最短修复路径
Step 1：开放动词换成决策动词
差： "工程团队 scale 怎么做最好？"
好： "我们 8 个工程师做 B2B SaaS，目前 2 个 squad，
PR 到 prod 的 lead time 是 4 天。我们想在 1 个季度内把 lead time 砍半。
在以下三条里选 1 个干预，用 3 句话辩护：
(a) 切到 trunk-based 开发
(b) 加 1 个专职 platform 工程师
(c) 把 PR 大小限制在 200 行以内"决策动词（“选”）+ 点名的候选 + 标准，三者合起来逼出具体答案。“从这些选项里选/排/挑”远比”我该怎么”或”哪个最好”更难 hedge。
Step 2：加 5 行具体上下文
技术栈：<运行时、框架、关键依赖含版本>
规模：<用户数、QPS、数据量>
约束：<预算、deadline、人数>
试过：<已经失败的方案>
目标：<带成功标准的交付物>这个模板把泛 prompt 翻成具体的。把这些约束前置，模型就不用自己脑补假设——2026 年的多篇实践复盘一致反馈：点明受众和使用场景，能把所需的来回迭代次数大致砍半。
两家厂商都建议给段落打标签，而不是写成一大段。模型处理结构化 prompt 比处理一大坨文字更可靠，所以用 CONTEXT:、TASK:、FORMAT: 这类朴素标题，或 Anthropic 给 Claude 推荐的 XML 式标签（<context>…</context>）。
Step 3：点名决策方
"这个决定由 eng lead 拍板、CTO 复审。
eng lead 优化交付速度。CTO 优化留存风险。"stakeholder + 他的优先级，把答案校准到一个具体读者，而不是所有读者的平均。
Step 4：用数字定义成功
本次回答的成功标准：
- 只提 1 项具体干预（不是清单）。
- 辩护在 100 字以内。
- 标出 1 个风险 + 缓解办法。
- 给 1 个 2 周内能观察的先行指标。可测的标准让模型没法 hedge 回综述。这是最可靠的一根杠杆，也是大多数 prompt 最常漏的一根。
Step 5：还泛就问模型缺什么
"要给具体而不是泛泛的答案，你还需要我提供哪 3 个数据点？"回答这些、粘回去、重问。两轮几乎每次都胜过一次性的泛 prompt，因为是模型自己把缺的上下文点出来了。
Step 6：宽拆窄（prompt chaining）
如果问题真的很大（“我们怎么 scale”），就拆。把一个宽 prompt 分解成一串窄 prompt——每一步的输出喂给下一步——这是有文献记录的技术，在多步问题上可测地优于一次性 prompt，因为每一步目标清晰，且你能在往下走之前先验证它：
- Prompt 1：基于我们的具体数据，识别 top 3 瓶颈。
- Prompt 2：针对头号瓶颈，选一个干预。
- Prompt 3：为这个干预设计 rollout。
3 个窄 prompt 产出的可执行内容，远多于 1 个宽 prompt，而且你能在第 1 步就抓到方向错误，而不是淹在 800 字的大墙里。
怎么确认已经修好
- 答案指明 1 项具体干预，不是一份清单。
- 答案引用了你的具体事实（换一家公司就不成立）。
- 换一支数据不同的团队，会得到不同的答案——如果不会，说明你的 prompt 还是太泛。
- 同事能直接照着做，不用追问。
- 输出字数集中在建议上，而不是在罗列选项的综述上。
如果还是没修好
- 上下文可能还缺——再多加你情况的具体信息。
- 告诉模型要忽略什么（如”忽略通用创业建议；假设我已经懂基础”）。
- 强制二选一（“A 还是 B”）；二元比开放问题更难 hedge。
- 如果以你当前的数据，这问题本就没答案，那瓶颈在数据收集，不在 prompt——再怎么改写都没用。
常见问题
换更强的模型为什么修不好宽 prompt？ 因为问题出在输入空间的大小，不在模型的智力。GPT-5.5 或 Claude Opus 4.7 会把那份平均态写得更流畅，但它依然是平均态。收窄问题才是唯一能改变答案种类的杠杆。
具体到什么程度才够？ 够到”换一家公司的事实，建议就会变”。如果同一个答案能让任何读者满意，说明你还没收窄。至少要有一个数字（规模）、一个约束、一个点名的决策方。
长 prompt 等于具体 prompt 吗？ 不等于。长度和具体度是两根不同的轴。长 prompt 一样可能很泛，灌水的 prompt 还会把真正要紧的约束埋掉。要加的是能改变答案的细节，不是体量。如果你的 prompt 已经很长却还是泛，见 长 prompt 反而拉低输出质量。
该一开始就收窄，还是让模型来问我？ 你知道约束时就前置——更快，也省掉来回。不确定缺什么时，用 Step 5，让模型告诉你它需要哪 3 个数据点。
那我就是想开放地探索一个话题呢？ 那就先要一个具体的稻草人（“先给一个有立场的方案，哪怕不完美”），再拿它来迭代。稻草人给了模型一个明确立场去辩护，比一份四平八稳的综述有用得多。
预防建议
- 默认窄 prompt：永远包含范围、约束、决策方、成功标准。
- 发送前过一遍 checklist：谁决定、用什么数据、优化什么、好输出长什么样。
- 探索型，先要 1 个具体稻草人，再拿它迭代。
- 审一审自己”爱问宽问题”的习惯：每个”X 怎么做最好”都该触发一次收窄。
- 团队工作流就建一个”窄 prompt”模板，含范围、约束、决策动词。
- 想问宽时，反问自己”我能问的最小的那个具体决策是什么？”。
想看更深的背景，Anthropic 的 effective context engineering 和 OpenAI 的 prompt engineering guide 都讲的是同一件事：具体、结构化的上下文，胜过花哨的措辞。
相关阅读
标签: #排查 #Prompt #Prompt 质量 #回答太泛