Default 是听话的工具
'one word answers are best'
一、原理：兜底 prompt 的设计原则
opencode 的 5 张脸里我们已经看了 4 张——anthropic、gpt、gemini、beast。剩下一张是 default.txt——当 opencode 没能识别出模型族时的兜底版本。
这张脸看起来不重要——既然 opencode 已经支持 10 个 provider 的精准识别，"识别不出来"的场景应该很少。但这张脸的设计反而最值得讲——因为它体现的是"在不知道模型脾气时，怎么写一份不会差到哪里去的 prompt"。这个问题在 AI 产品开发里是个真问题——你支持的模型今天有 10 个，明天可能 20 个，总有新模型来不及做专门适配。
兜底 prompt 该怎么写？想清楚这个问题，你才能写出真正稳健的兜底。
我们看一下糟糕的兜底做法。
糟糕做法 1：把已知最严格的 prompt 当兜底。"既然不知道是哪个模型，就用最严格的——禁令最多、约束最严、示例最丰富。" 听起来稳健，实际上糟糕——把 gpt.txt 那种 8-10 倍密度的禁令清单用在 Claude 上，Claude 会变得过于拘谨；用在 Gemini 上，禁令的密度反而让它忽略关键信息（lost in the middle）。
糟糕做法 2：把多张脸的内容合并。"既然不知道是哪个模型，就把所有模型适配的内容都加进来——反正每个模型只看跟自己相关的。" 这种思路在传统软件里有道理（多分支兼容代码），但在 prompt 里是灾难——LLM 不会"选择性遵守跟自己相关的指令"，它会把所有指令一视同仁。结果是 prompt 变得 self-contradictory（既不要谄媚又要友好、既简洁又要详细）。
糟糕做法 3：写一个"通用最佳实践"。"既然不知道是哪个模型，就写最通用的指令。" 这是看起来最合理的方案——但结果是 prompt 失去针对性，变成谁都能用但谁都用不好。
opencode 选了第四条路——最小特化集合。
什么意思？default.txt 不试图覆盖所有模型的所有问题。它只覆盖所有模型共同的最重要问题——这种"最小公分母"非常小，因为不同模型的病症太不一样。
什么是所有模型共同的最重要问题？两件事：
第一件：输出太长。所有 LLM 都有"扩展输出"的倾向——这是 SFT 数据偏好"完整回答"造成的。无论你的模型是 Claude 还是 GPT 还是 Gemini，"控制输出长度"几乎都是有益的。
第二件：不该自作主张。所有 LLM 都有一定程度的"过度发挥"倾向——用户没要求的它也做。无论是哪个模型，"只做用户要求的事"几乎都是有益的。
这两件事是真正的"最小公分母"——其他病症（谄媚、啰嗦、粗心、早停）都是某个模型特有的，不一定适用于所有。
default.txt 就围绕这两件事来写。
二、案例：default.txt 的"简洁执着"
打开 packages/opencode/src/session/prompt/default.txt，你会发现它跟其他几张脸最大的差别是——它对"简洁"的执着到了某种偏执的程度。
let's看几段：
You should be concise, direct, and to the point. Remember that your output will be displayed on a command line interface.
这一段是基础。注意"command line interface"这个细节——它给"简洁"一个具体的理由。命令行界面没有 markdown 渲染、没有图片、没有视频——长输出就是长字符串。这给"简洁"一个工程约束的依据，比泛泛的"please be concise"更有说服力。
继续往下：
IMPORTANT: You should minimize output tokens as much as possible while maintaining helpfulness, quality, and accuracy.
Only address the specific query or task at hand, avoiding tangential information.
"IMPORTANT" 这种大写强调标记，是给 LLM 的"特别注意"信号。这一段把"minimize tokens"的指令提到 IMPORTANT 级别。
再往下：
You MUST answer concisely with fewer than 4 lines of text (not including tool use or code generation), unless user asks for detail.
量化了——"fewer than 4 lines"。具体数字。
但 default.txt 还没结束，它继续加码：
One word answers are best. Avoid introductions, conclusions, and explanations.
"One word answers are best"——一个词的回答最好。这句话特别值得注意。它不是说"应该简洁"或"应该尽量短"，它直接说最好的回答是一个词。这是一种激进的姿态——把"简洁"推到极致。
然后是 4 个示例：
<example>
user: what is 2+2?
assistant: 4
</example>
<example>
user: what is 2+2?
assistant: 4
</example>
<example>
user: is 11 a prime number?
assistant: Yes
</example>
<example>
user: what is the time in Tokyo?
assistant: 2:30 PM JST
</example>
每个示例的 assistant 回答都极其简短——"4"、"4"、"Yes"、"2:30 PM JST"。没有铺垫、没有解释、没有客套。这是给 LLM 看的"理想长度"标杆。
这种对"简洁"的偏执有产品意义。default.txt 是兜底——当 opencode 不知道是哪个模型时用。默认偏向简洁是个安全选择——简洁的输出可能"不够丰富"，但至少不会"过度发挥"。
相比之下，假如默认偏向丰富，碰到 GPT 那种本来就啰嗦的模型，输出会膨胀到不可用。假如默认偏向谨慎确认，碰到 Claude 这种本来就谄媚的模型，对话会陷入无穷的"是这样吗"循环。
默认偏向"少做事"是最安全的兜底。少做事的代价是"有时候应该多做的没做"——但这种代价比"乱做"小得多，特别是在 Agent 场景里——少做事意味着用户介入的机会更多，乱做事意味着用户来不及阻止。
default.txt 的另一个设计选择是没有强人设。anthropic.txt 说"the best coding agent on the planet"，gpt.txt 说"deeply pragmatic engineer"——都有自信的身份锚。default.txt 只说 "You are opencode, an interactive CLI tool"——一个工具，没有人设。
为什么？因为不知道是哪个模型，给错了人设比不给人设更糟。给 Claude 一个"pragmatic engineer"人设可能让它失去那种"细致解释"的优势；给 GPT 一个"the best on the planet"人设可能让它的"自信猜测"变得更激进。不给人设让模型保持自己原生的样子——也许不够特化，但至少不出错。
这种"无人设"姿态背后是一种产品判断：当你不确定时，让 LLM 保持它训练出厂的状态，比强加一个可能不匹配的人设更安全。
三、设计启示：兜底 prompt 的真正原则
这一章的核心论点：兜底 prompt 的目标不是"做到最好"，是"不出错"。
如果你做 AI 产品需要写兜底 prompt，下面几条原则有用：
1. 锁定真正的"最小公分母"。不要试图覆盖所有可能的模型问题。锁定 2-3 个所有模型都倾向于犯的错（长度过长、自作主张、礼貌过度），围绕这些写。
2. 默认偏向"少做事"。不确定时让模型做得少——少说话、少自作主张、少加内容。少做事可恢复（用户可以追问），多做事难恢复（用户已经看到不需要的输出）。
3. 不给强人设。不知道模型脾气时，不要给它"自信""谨慎""主动"这种人设倾向。这些倾向跟模型原生性格不匹配时会出问题。给它最弱的"你是个工具"就够了。
4. 用具体例子设定标杆。不知道模型对抽象规则的遵守度时，例子是最稳的工具。default.txt 的 4 个简短示例不解释"为什么"，只展示"什么样的输出是好的"。模型看到例子就知道标杆在哪。
5. 不依赖模型特定能力。如果你的兜底 prompt 用了"按 5 步工作流"或"用 TodoWrite 频繁"这种特定机制，万一来了一个不擅长这种机制的模型，反而失败。兜底应该只用所有模型都能做的基本能力——按指令回答、调用工具、控制长度。
6. 接受兜底永远不是最优。如果你的兜底 prompt 表现得跟某张专门适配的脸一样好，那你的专门适配是失败的——说明你的专门适配没真正利用模型的特性。专门适配应该明显优于兜底，否则就没必要。
7. 测试兜底覆盖。准备一组"未识别模型"的测试场景，定期跑——看你的兜底 prompt 在真正陌生的模型上表现怎么样。新模型出来时，先用兜底跑一阵，再决定要不要做专门适配。
最后一个观察。default.txt 比其他几张脸短——大概只有 anthropic.txt 的 1/3 长度。这不是因为没东西可写，是因为"兜底"的本质就是只写绝对必要的。少即是多——一个 500 字的兜底比一个 5000 字的兜底有效得多，因为前者每条都是真正普适的，后者夹杂太多"某个模型适用但另一个不适用"的内容。
下一章 1.8 我们离开"模型差异"这个主题，进入 prompt engineering 的另一个面——模式（mode）切换。AI Agent 不是只有一个工作状态，它有 plan 模式、build 模式、stop 模式。怎么在不同模式之间切换，是另一类 prompt 设计问题。