同一个模型，两种结果：差的往往不是模型，是外面那层壳
作者：陈一帆
一条推文说"模型不笨，笨的是 agent 外壳"，一篇博客说"把提示词写好就是编程"。两句话常被当成同一句转发，其实说的是两层：一层是使用者的表达习惯，一层是系统工程的搭建质量。分开看，才知道该先改什么。
一位教授和 Claude 绕了半小时
Aaron Brethorst 在博客里写了一个他旁观的场景：朋友是常春藤的文科教授，人非常聪明。那半小时里，对话一直在原地打转——每次 Claude 的回复，对"它被告知的东西"来说都合理，但总比对方真正想要的偏一点。朋友推一下，它就漂到别处去。整个过程中，那个"到底要什么"始终没有被说出来。
Brethorst 由此提出一个说法：把提示词写好，就是编程。
几乎同一时间，X 上另一条帖子给出另一个版本的答案：你的模型不笨，笨的是你的 agent 外壳。同一条推文里，两个开发者用同一个模型做同一个任务，一个做出没用的聊天机器人，一个做出能自主干活的编程 agent。差别被列成六项：上下文工程、智能工具编排、持久记忆、自愈式重试、自动评测、生产级验证。
这两条常被当成同一句话转发。其实它们说的不是一层东西。
第一层：不是它听不懂，是要求没说清
Brethorst 的论证值得跟着走一遍。他先排除三个常见解释——模型吃过大量代码、代码本身可验证、各家实验室把最好的工具投入在 coding agent 上。他认为这些都对，但都不足以解释落差，因为他自己和别的工程师在跟代码无关的事上（规划旅行、重整预算、起草基金申请）同样拿到了好结果。
接着他把程序员的习惯拆成几件事：先写下起点和目标状态；把问题切成小到每一步都显然正确的块；先想边界情况——空列表、缺字段、用户干了件你没预料的事；先决定"怎么算它成了"。
对照的例子很具体。非程序员说"整理一份 Q3 销售报告"。工程师会不假思索地补上一串：哪些数据、在哪个文件、按什么维度拆、跟哪个基线比、什么格式、季度中途重组的两个区域怎么算。
失败之后的分岔更关键。工程师会假设自己某一条指令把模型带偏了，改一个变量再跑；非程序员倾向重掷同一句话、加一句"请准确点"，或者干脆断定工具不行。 这个观察我认同：含糊的指令不会报错，模型用最可能的猜测填空，很少反问，然后交回一份看起来差不多的东西。
Brethorst 还顺手修正了自己五月的旧说法。他原先主张领域专长是真护城河，现在认为要分两种技能：知道什么是对的，是判断力；把任务说到能被执行的粒度，是另一种能力，他称之为"计算性"的。判断力要等 agent 先交出值得判断的东西才有用。
第二层：不是模型不行，是流程没搭
Meet Shah 的帖子把镜头挪到了另一个位置。他没有给模型名、任务细节或任何例子，只有一份清单和一句主张：最大的性能提升"可能"不来自更好的模型，而来自更好的工程。
这份清单是工程视角的，用日常场景翻译一下：
- 上下文工程：每次开工前把该带的资料带上，别指望它自己记得上周会议的结论。
- 工具编排：知道什么时候查数据库、什么时候读文件、什么时候该回头问人，而不是所有事都靠聊。
- 持久记忆：把项目约定写在一个它每次都读得到的地方，别每次从零解释一遍。
- 自愈式重试：测试挂了先看报错再修那一处，而不是整段重新生成。
- 自动评测：有一套能自动跑的验收清单，而不是靠"看着还行"。
- 生产级验证：上线前该走的检查照走。
六项都在模型之外。模型能力一点没变，做与不做这些，决定的是它能连着干十分钟还是连着干三小时。
两层怎么接上
Brethorst 的证据结构是"同一个工具、不同的人"，解释的是单次对话为什么会偏；Shah 的证据结构是"同一个模型、不同的系统"，解释的是偏了之后能不能自己找回来。合起来才比较完整：一个人说得含糊，好外壳可以用追问、结构化输入把它补上；一个外壳没有验收和重试，再清楚的人也得自己手动当那套检查流程。
不过要分清哪些是已经实现的机制，哪些是效果宣称。这六项在今天不少 agent 产品里都能看到对应的功能入口；但"提升了多少"，并没有公开可复现的对比数据，本轮也没找到。Shah 那条帖子的形式是观点加引流，结尾就是"Follow for more"，没有一个案例。 它被提交到 Hacker News 后是 3 分、0 条评论 ，讨论热度很低，谈不上第三方验证。
Brethorst 那边也有要打折扣的地方。"Opus 4.5 发布几周后我基本不再手写代码"是个人经验；"软件业之外没看到生产力提升"是他读到的说法，文中没给数据；他自己也写明这是"我的理论"。
落到手上的顺序
如果最近总觉得"这模型怎么这么笨"，可以先不动模型，动两处。
一是说法。开工前写一句"做完了长什么样"，把数据从哪来、结果给谁看、跟什么比、边界情况怎么算，尽量塞进第一段。这不吃技术，只吃习惯。
二是流程。把反复出现的约定固定下来——放一个文件、一段固定的开头、一份能逐条打勾的检查清单，让失败能重跑，而不是只能重聊。
真正该换模型的时刻当然存在：推理上限、上下文长度、工具调用的稳定性，这些是外壳补不上的。但在那之前，多数"笨"的感受，其实来自我们既没把要求说清，也没给它一套能自己纠错的流程。
"模型不笨，外壳才笨"这句话对了一半。它补的是工程，不是能力上限。
转载说明
本文根据以下公开资料整理，原文及配图出处见下方。
评论 0
还没有评论，来抢沙发。