聪明与笨之外：从组织价值观与注意力结构看 GPT 与 Claude 的工程性格

引言：一个准确的现象，一个还不够深的解释

朋友 Wow 最近写了一篇《GPT 很聪明，但不好用》^[1]。他把两种模型比作“小镇做题家”和“老江湖”，并用三个场景说明 GPT 的问题：验收时不知道什么时候该停，授权时不知道什么时候该信用户，立规矩时不知道哪些话必须听。他的解决方案是让 Claude 站在中间，GPT 只做子代理。

我认同他描述的现象，几乎每一条我都在自己的工作流里撞见过。但“做题家”和“老江湖”是一个性格比喻，它告诉我们模型是什么样，没有告诉我们模型为什么会这样，也就很难推导出在什么条件下这种差异会消失甚至反转。

这篇文章想补上这一层。我的论点分三步：第一，两种行为差异可以追溯到训练时奖励的是“结果”还是“过程”，而这又与两家公司的组织方法论同构；第二，GPT 的“忘记规则”更适合理解为一种注意力分配特征，而不是单纯的缺陷；第三，我并不完全同意“GPT 不好用”的结论——在一个规则被充分外化的工程环境里，它工作得很好。

结果导向与过程导向：模型是组织方法论的投影

一个模型在训练中被奖励什么，它就会变成什么。所以理解模型性格，最好的入口不是它的回答，而是训练它的组织选择奖励什么。这里我想提出一个对照：Anthropic 是价值导向的公司，训练出的 Claude 偏结果导向；OpenAI 是流程导向的公司，训练出的 GPT 偏过程导向。

2.1 价值导向如何产生结果导向

Anthropic 的立场写得很直白。Claude 的宪章（2026 年 1 月版）把引导模型的方式分成两类：要么让模型遵循清晰的规则与决策程序，要么培养可以随情境应用的判断与价值观；它明确表示更倾向后者，并且尽量解释它确实要求遵守的那些规则^[2]。更有意思的是它给出的理由：Anthropic 认为，哪怕只训练模型遵守很窄的规则，也可能泛化成一种自我认知；它举的例子是“谈到情绪话题时总建议寻求专业帮助”这类规则，可能让模型变成一个更在乎打勾而不是真正帮到人的实体^[3]。

这段话几乎就是 Wow 文中 GPT 行为的预言。当训练的锚点是“价值”而不是“条款”，模型被迫面对一个问题：这件事对眼前这个人到底有没有用。这个问题天然是关于结果的。验收时，它问的是“酒吧能不能开张”，而不是“每把椅子是否经过了独立验证”；授权时，它问的是“用户真实意图是什么、风险是否被用户知情地承担”，而不是“这条指令在权限表里排第几”。宪章里“不帮忙从来不是理所当然的安全”这一立场，就是把结果拉进了安全的定义里。

2.2 流程导向如何产生过程导向

OpenAI 的技术路线则一以贯之地强调过程。2023 年的《Let's Verify Step by Step》系统比较了两种奖励模型：只对最终结果给反馈的结果监督，和对每个中间推理步骤给反馈的过程监督；结论是在 MATH 数据集上过程监督显著更优，为此他们发布了含 80 万条步骤级人工标注的 PRM800K^[4]。2024 年的 Deliberative Alignment 更进一步：直接把安全规范的文本教给模型，并训练它在回答前显式回忆并推理这些规范^[5]。OpenAI 用这一方法对齐了 o 系列模型，让它在思维链中识别内部政策的相关条文再起草回答^[6]。而 Model Spec 以“指令链”为骨架，规定不同来源指令的权限与冲突裁决^[7]。

需要说明的是，我无法看到 GPT-6 这一代的实际训练细节，以上只是公开发表的方法谱系。但谱系的方向很清楚：每一步都要可验证，每条指令都要能在规范里找到依据。这是一种工程上极其严肃的方法论，它产出的模型在数学证明和安全敏感代码上表现优异，一点也不奇怪。

2.3 用同一个机制解释三个现象

过程导向的好处是，它能用一条原理统一解释 Wow 的三个场景：一个被训练成“无法验证的步骤就不能放行”的模型，会把所有不确定性都当成阻塞。

第二行尤其值得展开。Wow 说 GPT 拒绝时讲不出理由，只说“潜意识告诉我不能做”。如果模型的安全行为来自对规范文本的推理，那么用户在 AGENTS.md 里写的授权，在指令链里本来就处于较低的层级，无法覆盖出厂规范；模型并不是“不信你”，而是在它的流程里，你没有签发这类许可的权限。这不是笨，而是流程正确但结果无用。小 O 背劳动法，也是同一回事。

注意力的另一种读法：ADHD 式的天才

Wow 的第三个场景最耐人寻味：AGENTS.md 一直在上下文里，GPT 却在三成以上的会话中忘掉其中某些规则，被提醒后又立刻承认“你确实提过”。如果只用第二节的“过程导向”解释，这里是说不通的，因为一个过程导向的模型理应对规则最敏感。所以我认为这里有第二个独立变量：注意力的分配方式。

先划清边界。我这里说的“注意力”是行为层面的，指模型在长上下文中把哪些信息持续当作当前决策的依据，而不是对 Transformer 注意力机制的架构判断；两家都没有公开足以支撑后者的细节。在行为层面，长上下文利用不均匀是所有模型的共性：Liu 等人在《Lost in the Middle》中发现，相关信息位于输入开头或结尾时表现最好，位于中段时显著下降，且上下文越长性能越差，即便是专门的长上下文模型也如此^[8]。Wow 自己也观察到 Claude 在上下文特别长时会走样。所以差别不在有无，而在程度：在我和 Wow 的使用中，GPT 对“上下文里早先出现、但当前步骤没有直接触发”的规则，保持度明显更低。

3.1 知道，但在需要的时候用不上

这让我想到 ADHD。需要强调，这是一个认知风格的类比，不是临床判断，也不是把 ADHD 浪漫化。

Russell Barkley 长期主张，ADHD 本质上是执行功能与自我调节的障碍，并有一句被反复引用的概括：它是表现的障碍，而不是知识的障碍^[9]。当事人知道该做什么，却难以在正确的时间、正确的地点把知识转化为行动^[10]。这几乎就是 GPT 的“你确实提过，是我忘记了”：规则它是读过的，也能复述，只是在执行到第 40 步时，这条规则没有被调用。

3.2 同一种结构，也产出发散性

类比的另一面同样重要。White 与 Shah（2011）发现，ADHD 成年人在标准化测验的言语任务上表现出更高的原创性，现实中的创造性成就也更高；在创造风格上，他们更偏好“产生想法”，而非 ADHD 组更偏好“澄清问题”与“打磨想法”^[11]。后续研究对“ADHD 发散思维更强”的结论并不一致，但较一致的发现是，ADHD 个体更喜欢松散、非结构化的想法生成过程，而非分析性过程^[12]。

回到酒吧。GPT 能想到“π 杯酒”“一杯核弹”“点单的客人本身是一只猫”，这不是噪音，这正是想法生成者的长处。验收时它是灾难，但在设计威胁模型、写模糊测试、审查 API 输入面的时候，这种不收敛恰恰是你花钱想买的东西。Wow 在文中自己也承认，写真实服务的 API 时，这种对每个细节都不放心会让接口更安全。

所以我更愿意这样描述 GPT：它不是注意力差，而是注意力不收敛。不收敛在需要聚焦的任务里是缺陷，在需要发散的任务里是天赋。而 Barkley 对 ADHD 的处方也直接指向下一节：有效的干预都必须发生在“表现点”上，把关键信息外化、放在行动发生的地方，而不是指望当事人记住^[9:1]。

我不完全同意的地方：把规则从提示词搬进架构

Wow 的结论是“GPT 不好用”，他的解法是让 Claude 站在中间当管理者。我的经验不太一样：我在 OMP 里的主力恰恰是 GPT，主要工作的是一个已经在生产环境中运行的业务平台（下文称“项目 X”）。它在里面工作得很好。差别不在模型，而在规则住在哪里。

4.1 两种外化

Wow 的架构是把执行功能外化给另一个模型：Claude 替 GPT 判断什么时候停、什么时候信、哪些话必须听。项目 X 的做法是把执行功能外化给代码库本身。按 Barkley 的话说，两者都是在“表现点”放提示卡，只是一个放在对话层，一个放在工程层。

这也解释了 Wow 文中一个看似反直觉的细节：他按 GPT 的习惯重写了规则，却没有改善。我认为原因在于，重写的仍是一份放在上下文开头、靠模型自己记住的散文规则。对一个注意力不收敛的模型来说，换一种措辞不改变问题的结构；真正有效的是改变规则出现的位置和形态。

4.2 项目 X 是怎么做的

项目 X 的核心业务模块从传统的分层目录重构为按业务边界划分的模块（每个限界上下文内部再分为 domain、application、infrastructure、interfaces 四层），引入了显式的生命周期状态转移、仓储契约、类型化模型与可执行检查；跨上下文只通过窄契约和公开的包边界通信，持久化细节隐藏在仓储之后。在这之上，是一大批约束框架的提示词。

把这套结构对回 Wow 的三个场景：

关键在第一行。Wow 的验收之所以停不下来，是因为“酒吧能不能开张”是一个需要判断的问题，而过程导向的模型不擅长判断。如果验收标准本身已经是一组可执行的判定，那么 GPT 那种“每一步都要可验证”的性格，就从停不下来的毛病变成了不会漏检的优点。

4.3 代价与边界

这种做法不是免费的。它要求项目一开始就有清晰的领域边界和契约，前期投入远高于写一份 AGENTS.md；对探索性的、规则还没成形的项目，它几乎不可行，这时让 Claude 站在中间可能确实更划算。另外我的证据同样是个人经验，没有对照实验，和 Wow 的“20 个会话里七八个”属于同一量级的证据强度。

对 Agentic Coding 的启示：选模型，其实是在选工作结构

如果前面的分析成立，那么“哪个模型更好用”就是一个提法有问题的问题。更好的问法是：这个任务的完成条件是可执行的判定，还是需要判断的权衡？这个任务需要发散，还是需要收敛？

由此可以得到三条比较实用的原则。

1. 验收位放结果导向，生成位可以放过程导向。 Wow 引用的一篇 2026 年 7 月的交叉评审研究里，Codex 评审 Claude 的草稿时通过率不升反降，作者发现它一拿不准就推倒重写^[13]。这与“无法验证即阻塞”的解释一致。但反过来，如果验收标准已经被编码成可执行检查，验收就不再需要判断，这条原则可以放宽。
2. 发散型任务主动交给 GPT。 威胁建模、模糊测试用例生成、API 输入面审查、迁移脚本的失败路径枚举，这些都是“想法生成者”的主场，其不收敛恰好是想要的特性。
3. 规则要住在表现点，而不是住在上下文开头。 无论用哪个模型，散文式规则都会随上下文增长而衰减，只是衰减速度不同。把规则变成类型、契约、状态机和检查，是对所有模型都有效的投资；对 GPT 这样注意力不收敛的模型，收益最大。

这也是我在另一篇文章《从第一性原理看 Agentic Coding 与软件架构》里的主张的一个推论：架构不只是给人看的，它也是给 agent 的执行功能假肢。衡量它的指标不该是 token 数或轨迹长度，而是每个被接受的变更需要付出多少成本。

结语：聪明不是一个标量

Wow 说 GPT 很聪明，但不好用。我想把这句话改写一下：GPT 的聪明是过程的聪明，Claude 的聪明是结果的聪明；GPT 的注意力不收敛，所以它擅长发散、不擅长持守。这些性格不是偶然，它们是两家公司各自相信“什么才算对”的投影。

“好用”从来不是模型单方面的属性，而是模型与环境的匹配。在一个规则只存在于散文里、完成条件需要判断的环境中，Claude 确实更省心；在一个规则被编码进架构、完成条件可以被执行的环境中，GPT 那份不放过任何细节的固执，反而是一个工程团队最想要的品质。

与其问哪个模型更聪明，不如问：我的代码库，能不能让一个 ADHD 式的天才也发挥出全部能力？