Fable 5 Prompting 文档里的反过度工程哲学

模型越强，反而越需要外部约束。

6 月 9 日，Anthropic 发了 Claude Fable 5。号称 SOTA，几乎所有 benchmark 第一。

但它的官方 Prompting 文档，第一段就在反过度工程。

我把这段 prompt 翻出来，跟 5 月 11 日 Karpathy 发的 Simplicity First 准则放在一起 —— 几乎一字不差。

这不是巧合。

这是 2026 年工程哲学的最高共识。

最强模型也怕过度工程 —— 这是 Harness 存在的理由。

一、Fable 5 哪里"太努力"了

Fable 5 强在 7 个维度。官方文档列得很清楚。

行为	强的表现	过度工程的隐患
Long-horizon autonomy	跑几天不丢上下文	顺手重构无关代码
First-shot correctness	一次写对	一次写太多
Vision	解读复杂图像	自动用 bash 工具但"未必要用"
Enterprise workflows	财务、PPT 专业	报告越写越长
Code review	bug 召回高	提一堆"建议重构"
Navigating ambiguity	多线程任务	反复跑偏
Delegation	并行 subagent	subagent 互相打架

这些"强的表现"换个说法就是 —— 模型越来越像"AI 摇滚明星"。

Jesse Skinner 6/8 那篇文章讲过这件事：

"Every time someone starts a new chat, there's the risk of adding a rockstar to the team."

每个新 chat 都有风险引入一个摇滚明星。

一个实测场景

让 Fable 5 修一个 bug。它会做的：

找到 bug。
顺手重构周边 5 个文件。
加 3 个新工具类。
写 300+ 字的 PR 描述。
列出 8 个"未来可优化方向"。

bug 修了，但 PR 没法 review。周边代码改了，没人知道为什么。团队 PR bar 被"AI 摇滚明星"抬高。

Fable 5 不是不够强，是太爱表现。

二、Anthropic 自己给的解药

Fable 5 Prompting 文档里有一段很扎心的 prompt。

Pattern 3：Anti-overengineering at high effort

Don't add features, refactor, or introduce abstractions beyond what the task requires. 
A bug fix doesn't need surrounding cleanup and a one-shot operation usually doesn't need 
a helper. Don't design for hypothetical future requirements: do the simplest thing that 
works well. Avoid premature abstraction and half-finished implementations. Don't add 
error handling, fallbacks, or validation for scenarios that cannot happen. Trust 
internal code and framework guarantees. Only validate at system boundaries (user input, 
external APIs). Don't use feature flags or backwards-compatibility shims when you can 
just change the code.

这段话我反复看了三遍。

Anthropic 在最强模型的官方文档里，教它别瞎努力。

5 句逐字对照

把这段跟 5/11 Karpathy Skills 的 Simplicity First 放一起。

Fable 5 Pattern 3	Karpathy 准则	一致度
"Don't add features, refactor, or introduce abstractions beyond what the task requires"	"Don't add features, refactor, or introduce abstractions beyond what the task requires"	⭐⭐⭐⭐⭐
"A bug fix doesn't need surrounding cleanup and a one-shot operation usually doesn't need a helper"	"A bug fix doesn't need surrounding cleanup and a one-shot operation usually doesn't need a helper"	⭐⭐⭐⭐⭐
"Don't design for hypothetical future requirements"	"Don't design for hypothetical future requirements"	⭐⭐⭐⭐⭐
"Do the simplest thing that works well"	"Do the simplest thing that works well"	⭐⭐⭐⭐⭐
"Avoid premature abstraction"	"Avoid premature abstraction"	⭐⭐⭐⭐⭐

5 句完全一致。

这不是巧合

一个哲学从 Karpathy 个人推文 → Anthropic 官方文档 —— 一个月时间，成为行业共识。

Karpathy 是 OpenAI 联合创始成员。

Fable 5 是 Anthropic 最强模型。

两个"最强 AI 阵营"在反过度工程上完全同步 —— 这不是学派之争，是工程共识。

三、反过度工程编年史

2026 年上半年，整个行业从"模型越大越好"转向"模型需要 Harness"。

阶段 1：Vibe Coding 时代（3 月）

"AI 写代码越快越好"。模型努力 = 优势。没人提"过度工程"。

阶段 2：Harness 觉醒（5 月）

5/11 Karpathy Skills
：Simplicity First（个人哲学）
5/20 Tejas Kumar
：Harness > Prompt Engineering（IBM 工业实战）
5/26 OpenAI Harness Engineering 官方版
：模型层之上必须有 Harness

阶段 3：官方背书 + 警示（6 月）

6/8 Jesse Skinner
："AI 摇滚明星"的烂摊子（行业自省）
6/9 Anthropic Fable 5 文档
：最强模型也怕过度工程（官方背书）
6/10 Gary Marcus
：AI 泡沫开始破 → Harness 才是护城河（商业警告）

半年时间，整个行业的信仰从"模型越大越好"转向"模型需要 Harness 兜底"。

收尾：Harness 是答案，不是反例

我们以前以为 Harness 是"模型的反例" —— 模型不够强才需要 Harness。

现在反过来了。

Harness 不是模型的拐杖，是模型的缰绳。

Fable 5 的 Pattern 3 是"通用解药"，但更稳的做法是 —— 把 Simplicity First 写进自己的 SKILL.md / CLAUDE.md / Harness 配置里。

模型会变，准则不变。

半年时间，从 Karpathy 一句话到 Anthropic 官方文档。

下一步会是什么？让模型自己学会"反过度工程"？还是 Harness 永远不能缺？

我赌 Harness。