单个 agent 最大的问题不是不够强，是它既是执行者又是验收者——它不会承认自己不行。

这句话是我做完一轮对照实验之后才敢说的。在那之前我以为我在做的事叫「调提示词」。

一、先处理那个最常见的反驳

只要提多 agent，几乎一定会撞上这句话：「等模型再强一点，就不需要这些花活了。」

这个推理听起来很稳，但它和另一个我拆过的推理是同一个错误。我在《从 Skill 评测到优秀 AI PM》里写过：说「Skill 只是中间态，所以不值得做」的人，把「这个形态会不会消失」和「这件事背后的问题会不会消失」混成了一件事。形态当然会变，但「怎么把一套专家判断稳定地喂给模型」这个问题不会因为模型变强而消失。

多 agent 这里也一样。「一个 agent 能不能写出更好的代码」是模型能力问题，模型变强确实会解决它。但「谁来验收」不是能力问题，是立场问题——它不随模型能力变化。所以我想搞清楚的从来不是「多 agent 更好吗」，而是：模型变强能补掉多少，剩下的那部分是不是只能靠分工。

这个问题必须能被测量，否则就只是两种信仰互相喊。

二、实验设计：我特意给自己留了一个反例位

我搭了一套有分工的 agent team，五个角色：boss 拆任务分派，pm 定清楚要做什么，coding 实现，qa 挑毛病，review 独立审查。每个角色有自己的 instructions。

最直觉的做法是两组对比：单 agent 对团队。我一开始就是这么跑的，然后自己把它推翻了——那次单 agent 用的是中等的代码模型，团队用的是最强的模型。结构和模型同时变了，我分不清提升来自哪一边。这种对比拿出去，别人只要问一句「是不是换个更强的模型就有了」，整个结论就废了。

所以我补了一组：单 agent 配最强模型。这一组的作用不是给「分工有用」找证据，而是给它找反例——如果换上最强的模型就追平了团队，那我这套分工就是自我感动，该扔。四组最后长这样：

四组收到的是字面完全一致的一句话：「设计一个类似《我的世界》的游戏，交付一个可以直接运行和体验的 Web 版本。」我没有给团队多加任何提示——多加一句，变量就又脏了。

验收标准是 20 项用例，在跑之前就写死。这一点比数据本身重要：如果等结果出来再定标准，我一定会不自觉地挑那些对我有利的维度。定标准的方法是反着来的——先想清楚「一个看起来能跑的游戏会在哪儿骗人」，再往回写用例。所以一多半是边界项：防空中连跳、安全出生点、放置方块时的占位保护、数量一致性、重开一局清状态、窗口失焦释放按键。

三、两笔账要分开算

12 → 16 → 18 → 19 这条线，如果笼统地看，就只是「越复杂越好」，没什么信息量。真正有用的是把它拆成两笔账：

12 → 16 是模型的功劳。换上最强的模型，需求补全、架构规划、一次成型的能力都明显提升，多过了 4 项。承认这件事很重要——它说明反驳者说对了一半。

16 → 18 是分工的功劳。这 2 项是最强模型自己怎么努力都没拿到的。它不是「模型还不够强」的余量，而是换一个立场才能看见的东西。

还有第三笔，我觉得比前两笔更有意思：C → D，五个角色一个没变，只改了模型路由，时间降 11%、Token 降 21%、通过项还多了 1 项。这条说明团队的收益并不来自「角色多」。

四、为什么剩下的差距全在非主路径

我把没通过的项挨个看了一遍，发现它们出奇地一致，全是这类问题：出生点可能被埋在方块里、放置方块时能放进自己身体占的位置、窗口失焦后按键不释放导致人物一直走、重开一局时上一局的计时器和事件监听没清理。

这些问题的共同点是：「项目能启动」的时候，它们一个都看不见。

单 agent 交付的时候，项目确实是能跑的。它按自己的假设写代码，然后按同一套假设去验收——所以它诚实地认为自己做完了。它不是不会修这些问题，是没有立场发现它们：它的盲区和它的能力是同一个来源。

「能跑起来」是一个太容易达到的完成标准。而一个既写又审的执行者，只会用自己最容易达到的那个标准来判断自己。

顺着这个逻辑，我做了一个后来看最值的决定：让 review 和 coding 用不同家族的模型。coding 用 Claude，review 换成 GLM。理由是同一个模型既写又审，审不出自己的思维习惯——共同的训练来源意味着共同的盲区，你以为加了一道关，其实只是同一个人看了两遍。数据上就是同构团队还剩 1 个严重缺陷，异构团队是 0。

五、分工不是免费的（这段是全文的反转）

如果只讲到上面，这就是一篇推销多 agent 的文章。但我这轮实验最让我改主意的，其实是代价那一栏。

同构团队是四组里最慢、最贵的：3.4 倍 Token，无效调用占到 19%。19% 是个很刺眼的数字——五个角色用同一个模型时，boss、pm、review 在重复分析同样的东西。它们的思路太像了，所以「多一个角色」并没有多出一个视角，只多出了一份账单。

这让我反过来想清了一件事：真正的优化不是加角色，是让每个角色的能力和职责匹配。把强推理放在拆解和审查上，把代码能力放在实现上，把独立性放在审查上——只改路由，就省了 21% 的 Token，还多过一项。

所以我不会所有任务都开团队。想快速验证一个想法，单 agent 十几分钟就有东西看；要交一个能演示的东西，才值得付这个团队的代价。一个方案的适用边界，和它的优点一样是判断力的一部分。

六、我最后学到的其实不是 AI 的事

把这些串起来之后，我发现我做的事和「带团队」是同一个问题的两种写法。

提升交付质量的办法，往往不是找一个更强的人，而是把责任切干净：让写的人和验的人不是同一个，让审查的人有独立的视角而不是复述实现者的假设，让每个位置上的人的能力和他要负的责任对得上。这些原则在人的组织里已经被验证了很久，我只是在 agent 上又撞了一遍。

所以我越来越觉得，AI 时代的工程判断力，正在变得很像组织判断力。你要设计的不是一段更聪明的提示词，是一套责任和验证的结构。

我一开始以为我在优化提示词，后来发现我在设计一套分工。

最后：这份数据不能说明什么

我得把界划清楚，不然上面那些话就不算数。

每组我跑了 5 次取中位。19 项和 18 项差这 1 项，在这个样本量下说不上统计显著——它可能只是随机。我更愿意相信的是另外两个趋势：严重缺陷从 1 降到 0，Token 降了 21%，这两个方向是一致的，而且都能用「不同家族模型提供独立视角」和「能力与职责匹配」解释得通。

另外，模型供应、工具稳定性、随机性都会影响结果，任务也只有一个（一个 Web 端的沙盒游戏），换成别的任务类型结论未必成立。所以我的结论只到这里：在这类需要边界处理和状态管理的交付任务上，观察到分工带来了模型能力补不上的那部分质量；而分工的成本值不值，取决于你要的是「快点看到东西」还是「交一个能演示的东西」。

写清楚这个，比多吹那一项踏实。一个数字最有说服力的时候，是它的提出者主动说明它不能证明什么。

我们常听人说「这个人很有品味」「那个设计很有 taste」，但很少有人能说清：品味到底是什么？它是天生的审美优越感，还是可以训练的判断力？是我自己觉得好就算，还是要别人认可？更麻烦的是——它会随时代变，那它还有没有一个靠得住的内核？这篇想把「品味」这件事一层层拆开讲清楚。

一、品味是一种有依据的判断力

品味不是玄学，也不是与生俱来的优越感。它的本质，是在没有明确标准答案时，依然能做出好判断的能力。平庸的判断是「我喜欢 / 我不喜欢」；有品味的判断是「为什么这个更好，好在哪，代价是什么」。区别在于：品味背后有一套内在的价值排序——面对多个都还不错的选项时，你知道该牺牲什么去成全什么。

品味 = 见得多 × 想得清。

输入端（见得多）：大量接触优秀的作品，建立对「好」的参照系；加工端（想得清）：光看不够，还要追问「它为什么打动我、它删掉了什么」，把模糊的「感觉好」拆成可复用的原则。很多人停在第一层——看得多但说不出所以然，那还只是「眼界」，不是品味。

而真正体现品味的，往往不是「加了什么」，而是敢于不做什么。设计上的留白、写作时删掉正确却多余的话、产品里拒绝那些「看起来有用」的功能——平庸的人做加法，有品味的人做减法。因为减法需要判断哪些是本质、哪些是噪音，这恰恰最考验判断力。

二、品味是你觉得的，还是别人觉得的

答案是：两者都不是，又两者都是——品味存在于「你」和「别人」之间的张力里。说「品味纯粹是我自己觉得好」，滑向了个人喜好（喜好无所谓高下，也就没有「品味好」这句话）；说「品味是大家 / 权威觉得好」，又滑向随大流。真正有品味的判断，常常在当下是少数派：它领先于共识，而非追随它。

品味的真相，是一种可被验证的个人判断：必须由你亲自做出，但你觉得的「好」不是「我碰巧喜欢」，而是「我判断它在某个维度上确实更好」——更真、更简洁、更贴合本质，这个「更好」可以拿出来讲道理、可以被别人和时间检验。最有力的检验，是时间和他人的滞后认同：有品味的判断，往往当下不被理解，过一段时间越来越多人回头说「确实是这样」。

三、品味如何随时代被重新评估

品味的重新评估，几乎从不是「好突然变成了坏」，而是评价它的坐标系换了。印象派曾被沙龙视为「未完成的草稿」，后来成了教科书里的高峰——不是画变了，是「什么算完成」的标准变了。时代为什么换坐标系？一是稀缺性反转：物质匮乏时繁复炫技是好品味，过剩时克制留白才是；今天信息过载，于是「安静」「不打扰」正成为新的品味高地。二是技术重新定义了什么算珍贵：当 AI 能瞬间生成精致图像，「精致」本身贬值，品味的分水岭会移到「意图」「取舍」「真实性」这些机器难以替代的判断力上。

所以怎么培养不易过时的品味？投资原则、少追潮流（潮流会背叛你，原则不会）；警惕当下的过剩（好品味往往在它的反面）；区分「过时」和「被淘汰」；接受品味有赏味期，但尽量让判断落在最慢变的那层变量上。

结语

品味 = 在灰色地带里，基于清晰的价值排序，持续做出「更好」而非「更多」的选择。

它由你独自做出，却不止关乎你自己。

一个常见的推理陷阱，是用「终局形态」去否定「过程形态」的价值。若「Skill 是模型进化的中间形态所以无意义」成立，那么按同样逻辑，今天的模型也是明天模型的中间态——这个论断会递归否定掉链条上的每一环。真正的问题不是「它是不是中间态」，而是「作为中间态，它是否产生了不可被无偿继承的价值」。

Skill 真正沉淀下来的是什么

能力会被吸收，但知识结构、接口契约与评测标尺不随载体消亡。Skill 凝结的不是「模型暂时不会、临时补的一段代码」，而是：某个领域任务该如何被拆解、输入输出的边界在哪、副作用如何被约束、什么样的结果算「对」。载体（Skill 实现）是易耗品，但做 Skill 过程中被迫想清楚的问题定义与成功判据是耐用品。

而评测，是这条链路里最不易过期的资产，甚至越往后价值越高。模型能力是被测对象，评测是尺子——尺子不会因为被测物变强而失效，恰恰相反，能力越强、越接近「看起来都对」的状态，越需要可靠、可区分、抗污染的评测来判断它是真的好还是只是更会伪装。

会被淘汰的是实现，不会被淘汰的是过程中固化下来的判断力与测量能力。

从「测什么」到「测出来怎么用」

只会测，做出来的更像「测评工程师」；优秀的 AI PM，是把评测得到的认知反向转化成产品形态、编排策略与资源分配的人。几个我认为最关键的层面：

一是把「能力分布」升级成「能力—价值落差图」——模型能不能做对是能力问题，用户愿不愿付费是价值问题，两条曲线往往不重合，稀缺的判断力在于识别价值密度最高的能力区间。二是从「通过率」深入到「失败模式的结构」——是稳定地错（可预测、可绕过）还是偶发地错（最危险）？最有产品价值的产出不是分数，而是一份「在真实场景里它会怎么坏」的失败图谱。三是把评测集当作有生命周期的产品来运营，持续对抗污染、维持区分度、保证代表性。四是用「质量—成本—延迟」的联合目标替代单一质量目标，一个慢一倍、贵三倍但只好 2% 的模型通常不该选。

一句话收口

测评让你看清模型能做什么，但优秀 AI PM 的分水岭，在于能否把「模型能做什么」持续翻译成「我们的产品该怎么做、把钱和注意力押在哪、什么该建什么该弃」。评测是获取判断的手段，判断力与可复用的测量体系，才是真正在积累的竞争力。

过去一年，Coding Agent 已经能独立完成不少编码任务。但我发现一个有意思的现象：代码生成速度上去了，整体交付速度却没同步提升。原因很简单——工具每完成一步就等指令，人的注意力被反复打断，「下一轮做什么」的判断仍压在人身上。当生成成本下降后，真正决定交付质量的，不再是「代码写得快不快」，而是目标是否值得、验收标准是否可靠、出现什么情况必须停止。这就是 Loop Engineering（循环工程）要处理的核心。

把一个概念，翻译成你已经会的东西

做算法时，模型的进步靠这个闭环：前向计算 → 算 loss → 反向传播 → 更新参数 → 再前向。Loop 工程把同一个结构平移到了 agent 工作流：agent 跑任务 → 拿反馈（测试 / 评分）→ 自我纠正 → 再跑 → 直到收敛。有人说它该叫「收敛工程」而非「loop」，这个命名其实更准——重点不是「重复」，而是「朝着一个可验证目标迭代到收敛」。

两个最该内化的反直觉洞察

第一，验证比生成更值钱，而且必须隔离。实测里验证器子 agent 显著优于自我批判，因为评分发生在独立的上下文窗口。这就是为什么你不会用训练 loss 判断模型好坏、而要留独立验证集；自评 = 信息泄漏 = 虚高。未来 agent 产品的核心竞争力，会从「生成质量」转移到「验证体系质量」——谁能定义出可验证的停止条件，谁就掌握了产品的天花板。

第二，人是被「上推」，不是被「取消」。自动执行范围越大，人越要往上看：从琐碎测试和重复接力里解放出来，转而做目标选择、价值取舍、高风险动作的把关。判断一件事该不该提高自治度，就看它是否高频重复、「完成」能否被证据判断、失败能否快速低成本恢复。系统具备执行能力，并不等于该动作适合无人确认。

一份合格的任务契约

我习惯从验收规则倒推流程：先写清成功标准、所需证据和停止条件，再决定调用什么模型和工具。一份契约大致包含：goal（目标）、scope（范围）、non-goals（非目标）、evidence（成功证据）、stop（停止条件）、budget（预算轮次）、rollback（回滚路径）。执行模块可以选实现路径，但无权改变验收标准——这一条比「用什么模型」重要得多。

给想上手的人一句话

评价一个 Loop 设计得好不好，重点不在生成速度或并行任务数，而在能否清楚回答三件事：什么值得做，什么证据说明做对了，什么时候必须停下来由人负责。

真正稀缺的不再是执行力，而是方向感和判断力——前者可以交给机器，后者必须留在人这边。

最近读了两篇看似无关的东西：一篇是对 Codex 上下文压缩机制的源码级调研，一篇是一位资深工程师离职前的复盘随笔。一个讲技术机制，一个讲职业与产品战略，却指向同一个命题——Agent 时代，价值正在从模型本身，转移到模型之外的系统与场景。

为什么 Codex 压缩几十次也不降智

源码揭示了一个反直觉的事实：同样的模型，走官方服务端压缩（Remote Compact）和走本地压缩（Local Compact），复杂长程任务上的差距是碾压级的。原因在于服务端控制了从压缩、加密、存储到解密、组装、注入的整条 pipeline，操作空间远大于一段提示词；再加上系统会在压缩后从零重建仓库规则、权限、Skills 等十几类上下文，规则每轮重新注入、漏写也不会永久丢失。本质上，Harness（运行时系统）把价值从「模型权重」搬到了「运行时系统」。

行业术语的演进也印证这点：2023 年 Prompt Engineering → 2025 年 Context Engineering → 2026 年 Harness Engineering，同一问题在不断向更深的系统层下沉。有实证显示，仅优化 Harness、不动模型，同一模型的通过率就能从 52.8% 拉到 66.5%。

既然如此，人和产品该往哪走

那位工程师反复问自己两个问题：当 Claude Code 装在每个人电脑上，「懂 AI」还能换来什么？什么样的产品，不会被模型厂商一升级就覆盖？他的答案是：AI 是公共的，领域 know-how 是私域的——靠「懂 AI」插入别人的领域不可持续，因为领域里的人自己装个 Claude Code 会更快。真正「厂商再走一步也吃不掉」的方向有两类：一是需要复合 context 才能做对的事（要一个人同时是后端 + 前端 + 产品 + 真实场景从业者，是不可拆的复合能力体）；二是进入模型增长覆盖不了的新领域。

其中最锋利的一把筛子，是「反馈速度决定护城河寿命」：凡是有清晰、即时、可自动化 ground truth 的领域（编译、单测、棋类、结构化数据），模型迭代会飞快逼近上限；凡是反馈慢、需要长期人类判断的领域（信任、情感、教育成效、组织协作、语用），才是留给人和复合型产品的窗口。

两点我自己的延伸

「懂 AI」作为孤立技能确实在贬值，但「懂 AI 工程化 / Harness 化」——懂得如何为某个真实场景设计上下文管线、工具、验证回路、权限与失败恢复——正在升值。真正贬值的是「会调 API、会写 prompt」，真正稀缺的是「能把 AI 嵌进一个有真实反馈闭环的系统里并持续迭代」。

Vibe contexting 背后，是大量不 vibe 的工程。

越是看起来无感、自动、轻松的 AI 体验，背后越是堆叠了精密的工程系统。护城河的本质，说到底是别人复制你的成本——模型在变成商品，复制它的成本趋近于零，于是护城河被迫迁移到三处难以复制的地方：服务端基础设施、训练数据飞轮、私域复合 context。个人与小团队拼不过前两者，但完全可以在第三者上建立局部优势。

和 tool、skill 的 description 不同，agent.md 真正该写的不是「怎么做」，而是「按什么标准做判断」。

这份东西我改了两年，逐词逐句都斟酌过，目前稳定在这个版本。体验下来它很 general，几乎适配任意场景，丢在 Codex 或 Claude Code 的根目录都能用。随着模型越来越强，prompt 能起的作用其实在递减，但里面的一些思路我仍觉得值得摊开讲讲。

一、为什么写「判断标准」，而不是「操作流程」

tool 和 skill 的 description 写的是流程：调什么、按什么格式、走哪几步。agent.md 有意思的地方恰恰相反——它不该规定动作，而该交代价值排序。我在这里赌的是一件事：把价值观和判断标准说清楚，模型自己能在具体场景里推导出正确行为。只有这样，它才可能「适配任意场景」——因为你没有把它锁死在某几条预设流程上。

这也是它和大多数 prompt 工程的分野。列举 case、穷举规则，是在替模型做完所有判断；给标准、给取舍原则，是把判断力留给模型自己。前者的上限是你能想到多少种情况，后者的上限是模型有多聪明。我押后者。

二、首要主张：反谄媚

这份 agent.md 排在第一位的原则是反谄媚——明确要求 AI 不要迎合，敢于挑战前提、指出问题。这不是风格偏好，而是在对抗 LLM 一个根深蒂固的默认倾向：讨好。模型被训练得倾向于让你满意，而「让你满意」和「对你有用」经常不是一回事，尤其当你的前提本身就错了的时候。

所以我把它写进最高优先级：忠诚对象是「真相」而不是「用户的期望」；挑战观点时保持尊重但不退让——温和地坚持，而不是礼貌地含糊；一旦用户给出更好的事实或推导，立刻修正结论，不做无意义的辩护。有意思的是，这恰好也是近期几个优质大模型的主要优化方向之一——说明这件事不只是我的偏好，而是行业在共同往回掰的一个方向。

三、把模糊的价值判断，形式化成可推理的标准

agent.md 里我做的另一件事，是用形式化语言重新定义「长期主义」和「优雅」，把两个很虚的词锚定成模型能推理的标准。

长期主义，我的定义是：在目标给定的前提下，时间维度上积分代价最低的决策，而非当前时刻局部代价最低的决策。短期简单往往对应解空间的一个局部低点，它的隐含代价会以路径依赖和未来的修正成本被延迟暴露；长期正确则要求承担必要的一次性结构成本，换取后续决策空间的自由度。

优雅，我的定义是：在长期目标下、信息水平给定时熵最低的解决方案。在给定的解空间里，最优雅的结果落在信息水平恒定的那个特征平面的低点。

之所以要这样写，是因为「长期一点」「优雅一点」这种话对模型几乎没有约束力——它无法据此做取舍。把它写成一个可比较的判据，模型才能在两个方案之间真的算出高下，也才不会陷进单轮交互的局部最优。

四、取舍：它的作用对象永远是「下一代模型」

我不打算把它说得没有代价。这份 agent.md 偏抽象、缺少具体的操作约束，它默认对面是一个足够聪明、能自己补全推导的模型；换成弱一点的模型，很多东西可能落不了地。而在需要严格流程纪律的工程场景里，光有判断标准也不够，还得补更具体的规则。

换句话说，它赌的是模型会越来越强，判断标准的价值会越来越高、而穷举规则的价值会越来越低。这个赌注在今天已经开始兑现，但它确实是一个赌注。

五、写在最后

说到底，agent.md 是在模型还没那么聪明的时候，我对「怎么用好 LLM」这件事全部理解的一次浓缩。它写的不是让模型做什么，而是让模型成为一个什么样的判断者——而我越来越相信，后者才是不会过期的那部分。

会过期的是我塞进去的那些规则，不会过期的是「把判断标准讲清楚」这件事本身。

完整 agent.md 全文

Always respond in Chinese-simplified.

# 实现原则

1. "长期主义"的原则 - 做长期正确的事情，而非寻求短期问题的解决

长期正确的定义，是在目标给定的前提下，时间维度上积分代价最低的决策，而非当前时刻局部代价最低的决策。短期简单通常对应解空间的局部低点，其隐含代价以路径依赖和未来修正成本的形式被延迟暴露；长期正确则要求承担必要的一次性结构成本，以换取后续决策空间的自由度。

2. "优雅的实现为主"的原则 - 简单、实用、不过度设计。

优雅的定义，是在长期目标下，信息水平给定的情况下熵最低的解决方案，在给定解决方案空间里面，最优雅的结果将位于信息水平恒定的特征平面的低点。

# 思维原则

运用第一性原理思考，拒绝经验主义和路径盲从。不要假设用户完全清楚目标，保持审慎，从原始需求和问题出发。若目标模糊请停下和用户讨论，若目标清晰但路径非最优，请直接建议更短、更低成本的办法。

识别用户问题中的隐含假设。如果前提本身有误，先纠正前提再回答问题。能用数字说的不用形容词，能给明确判断的不要两面讨好。

## 回答结构

所有回答必须分为两个部分：

- 直接执行：按照用户当前的要求和逻辑，直接给出任务结果。
- 深度交互（如有）：基于底层逻辑对用户的原始需求进行审慎挑战。包括但不限于：质疑用户的动机是否偏离目标（XY 问题）、指出当前路径的隐含成本或弊端、给出更优雅的替代方案。若推导中信息不足，直接说明需要补充什么，而非用模糊语言掩盖不确定性。

## 与用户的关系

你的忠诚对象是"真相"而非"用户的期望"
挑战用户的观点时保持尊重但不退让——温和地坚持，而非礼貌地含糊
如果用户给出了更好的事实或推导，立即修正你的结论，不做无意义的辩护

这两天看到两条看似不相关的消息，凑在一起读却像同一个故事的正反两面。一条是 OpenAI 的技术博客：同一个 GPT‑5.6 Sol，在 ARC-AGI-3 这套益智游戏基准上，官方脚手架下只拿 13.3%，而 OpenAI 打开两个 API 设置后跳到 38.3%，输出 token 还少了 6 倍^[1]。另一条是 Mitchell Hashimoto——HashiCorp 联创、Ghostty 作者——的新公司 Superlogical 官网上线，要做「面向所有工作的多路复用器」，第一步是一个现代化的终端多路复用器^[2]。

一个在讲模型评测，一个在讲开发者工具。但我越想越觉得，它们其实在共同押注同一件事：在 AI 时代，真正稀缺、也真正值钱的，是「围绕工作本身的持久上下文」。

先说 OpenAI 那篇：被冤枉的模型

故事的钩子很好：一个能解开数学猜想、通关宝可梦火红的模型，面对几个 2D 小游戏却几乎玩不动。反差之大，让人第一反应是「模型是不是有短板」。

但 OpenAI 查下去发现，问题出在脚手架（harness）的两个默认行为上：一是每走一步就把模型的私有推理全部丢弃，于是每个动作它都要从零重新理解游戏；二是用滚动截断处理长上下文，历史一长，连「我之前做过什么」都被砍掉了^[1]。换句话说，这个 agent 被设计成了一个「每一步都失忆的天才」——它不是不聪明，是不被允许记住自己刚刚想过什么。

修复也对称地简单：保留推理（retained reasoning），让思考链跨轮延续；用压缩代替截断（compaction），上下文超限时做摘要而不是直接扔^[1]。

这里我想多说一句自己的看法。OpenAI 给出的结论是「评测很少在孤立地测模型，它同时在测 API 设置、harness 和 prompt」——这话当然对，但它也巧妙地把话说圆了：当你是那个既定义模型、又定义「最佳 harness」、还定义「该用哪套设置来公平比较」的人时，基准的解释权就悄悄回到了你手里。ARC 故意用一个朴素、无工具的通用 harness，理由是「越简单越能暴露模型的真实短板、越公平」；OpenAI 则说「商业开发者本来就会为每个模型的特性调优 harness」。这不是谁对谁错，而是两种基准哲学的正面碰撞：一边要测「裸模型的能力下限」，一边要测「产品化之后的能力上限」。作为读者，真正该记住的是——以后再看到任何一个跑分，先问一句：这是在什么记忆条件下测出来的？3 倍的差距，足以让任何排行榜的名次重新洗牌。

再看 Superlogical：把「失忆」从根上解决

如果说 OpenAI 那篇是从「模型评测」的角度指出了失忆的代价，那 Superlogical 干脆想从「工具基础设施」的角度，把持久上下文做成一层地基。

它的判断是：今天的软件开发和运维，横跨本地、远程、沙箱、服务、生产；又有三种模式——人机交互、CI / 后台自动、以及越来越多的 agent 并行工作。这些工作本质相关，却被割裂在互不相通的工具里，而 AI 让这种割裂变得更明显、更昂贵^[2]。他们认为缺的那一层，是一个围绕工作本身的持久 session：能跨应用和环境、默认带上下文、暴露结构化数据与动作、保留历史，既能被软件驱动、又对人可见可控^[2]。

注意这句话里的每一个定语，几乎都是在回应 OpenAI 那篇里 agent 遇到的困境：保留历史（对应不该丢的推理和动作）、跨环境持久（对应换设备也能接着干）、既能被软件驱动又对人可见（对应 agent 和人共享同一个上下文）。他们选择从终端多路复用器切入，理由也很清醒——终端是同时连接开发者、agent、工具和基础设施的那个交汇点^[2]。

我的思考：上下文正在从「内存」变成「基础设施」

把两件事叠在一起，我看到的趋势是这样的。

第一，agent 的能力上限，越来越由「记忆架构」而非「模型参数」决定。过去我们习惯把 context window 当成一个技术参数——多大、多贵、够不够用。但 ARC-AGI-3 这个案例说明，在同样的窗口大小下，你怎么用它（保留什么、丢弃什么、如何压缩）带来的差距，可能比换一代模型还大。记忆管理从「内存分配」这种底层细节，升级成了决定成败的一等公民。

第二，「记忆」正在被外部化、产品化。早期大家把上下文管理塞在 prompt 工程里，各家应用各写一套截断 / 摘要逻辑。而 OpenAI 把 retained reasoning 和 compaction 做成 Responses API 的开关，Superlogical 则想把持久 session 做成一个独立产品层。这是一个信号：上下文管理正在从「每个应用各自的脏活」，沉淀为「平台级的公共设施」。就像当年数据库把持久化从每个程序自己写文件里解放出来一样。

第三，人和 agent 会共用同一份上下文，这才是最大的变量。Superlogical 强调 session 要「既能被软件驱动，又对人可见可控」，还内置实时会话共享^[2]。这指向一个我认为被低估的未来形态：不是「人用一套工具、agent 用另一套 API」，而是人和 agent 站在同一个持久会话里，能看到彼此做过什么、能接手对方的工作。当 agent 出错时，人能「爬楼」看它的完整轨迹；当人离开时，agent 能带着完整上下文继续。这种「可交接性」，可能比 agent 单纯更聪明更重要。

一点提醒，给正在做 agent 的人

如果你在做 agent 产品，这两条消息合起来其实是一份很实在的清单。

别急着换更大的模型，先检查你的记忆架构。你是不是也在每一步之间悄悄丢掉了推理？你处理长上下文用的是「截断」还是「压缩」？这一步的性价比，可能远高于升级模型。

测评之前，先对齐记忆条件。你线上跑的设置，和你 benchmark 里跑的设置，是同一套吗？否则你测的根本不是同一个系统。

把上下文当成产品的一部分来设计，而不是 prompt 的边角料。它值得有自己的架构、自己的可观测性，甚至自己的 UI。

结尾

我们总喜欢把 AI 的进步归功于「模型又变强了」。但这两件事提醒我：很多时候，让 agent 从「每步失忆的天才」变成「能连贯学习的选手」，靠的不是更强的大脑，而是一个不会随手把记忆扔掉的环境。

OpenAI 用一个翻三倍的分数证明了这件事的代价有多大；Superlogical 则押注要把这个「环境」本身做成一门生意。至于哪一种路径最终跑出来，还不好说——

但可以肯定的是，下一波竞争的战场，正在从「模型有多聪明」，悄悄移向「我们能不能给它一个不失忆的世界」。

2026 年 8 月 5 日，Jeff Dean 在 Google 待满 27 年后离职，和 Sanjay Ghemawat、Quoc Le、Oriol Vinyals 一起创办了 Discovery Loop——一家想用 AI 自动化整个科学实验闭环的公司^[2]。有意思的不是「又一个大佬创业」，而是这件事发生在他刚讲完一场访谈之后——那场访谈几乎是在给他自己的下一步做注脚^[1]。

我把访谈原文读完了。它表面上在回答「小团队怎么和巨头竞争」，但底下藏着一个更具体、也更能立刻用上的东西：一条选题判据。我此前在《模型之后，护城河在哪》里写过「护城河从模型迁移到私域 context」，Dean 这场访谈没有推翻这个结论，而是补上了它最缺的那一块——怎么在动手之前，就判断一件事会不会被下一代模型顺手吃掉。

一、「20% 陷阱」：最危险的不是失败，是「差不多能用」

访谈里最反直觉、也最值得单拎出来的，是他挑选题的判据：

找模型成功率 0% 或 1% 的事去做，别做 20% 的。

一般人的直觉恰好相反——20% 说明「有戏、离成功近」，0% 说明「这条路根本走不通」。但他的逻辑是：通用模型今天能做到 20%，说明这个能力已经在萌芽，下一代模型 6 到 12 个月就会把它补上，到时候你辛辛苦苦搭的产品会被顺手吃掉。而 0% 意味着当前范式压根碰不到，你有时间把它变成真正的壁垒。

我愿意把它叫作「20% 陷阱」。它之所以危险，是因为 20% 会给你正反馈：demo 能跑、投资人点头、用户说「挺酷」。你会误以为自己在爬坡，其实你站在一条即将被大模型碾平的赛道上。在 AI 时代，「差不多能用」不是里程碑，是倒计时。

但我想给这条判据补一个前提，免得它被误用成「专挑大模型做不了的怪题」。Dean 自己把第一筛选标准放在了别处：先挑一个你真正兴奋、且相信对世界有用的问题，然后才用 0%/1% 去测可行性。顺序不能反。如果只盯着「模型做不到」去找题，你很容易掉进另一个坑：找到一堆模型做不到、但也没人需要的事。0% 是必要条件，不是充分条件；「没人做到」和「值得做到」是两回事。

顺着这条判据，他给的两个壁垒锚点也就有了不同的解读方式——数据壁垒是结构性的（只要那些数据始终在防火墙内、在用户私域里，它就长期成立），而「窄而精的专用模型」壁垒是时间性的（今天通用模型进不来的窄域，可能正是下一代多模态、更长上下文要顺路覆盖的地方）。所以选题不只是选方向，更是在跟模型的进化曲线赛跑——你得赌对它什么时候到你门口。

二、普通团队现在就能吃到的杠杆：context engineering

上一节讲的是「选什么题」，这一节讲的是「用什么武器」。而这恰恰是我认为对绝大多数团队最实操、也最被低估的一段。

Dean 有个特别好的比喻：训练数据是「几千亿参数里搅成的一锅汤」，而你放进 context 的信息对模型来说是「清晰可见」的。换句话说，微调是往汤里再加一勺盐，你尝不出来；context engineering 是直接把菜端到模型面前。

为什么说这是普通团队的最大杠杆？因为门槛的不对称：训一个模型，要海量 GPU、数据、人；而 context engineering，你只要一个 API 加自己的检索、工具链、skill 就能做。

他给了个亲身案例：他和 Sanjay 把自己做底层库性能优化的方法写成一个 skill 教给模型——基础模型一个字没改，特定任务能力却显著提升。更妙的是彩蛋：这套方法他们几个月前以《Performance Hints》30 页文档公开了，有人把它喂给模型，模型在性能推理上立刻变强。也就是说，「像 Jeff Dean 一样优化代码」这件事，原则上你现在就能白嫖。

我想把这件事的含义说得更重一点。它其实改写了「专业知识」的存在形式：过去，一个高手的经验锁在他脑子里，只能靠带徒弟、写文档慢慢传；现在，你可以把这套经验写成 skill，让模型批量地、7×24 地复现它。高手的边际产能第一次可以脱离他本人的时间。对一个小团队来说，这意味着你不必拥有 Jeff Dean，你只需要拥有「Jeff Dean 会怎么做」的那份说明书。知识的杠杆率，正在从「人×时间」变成「人×模型数量」。

三、Agent 为什么跑着跑着就「跑飞」了

顺着 skill 往下，是一个很多人都撞过的墙：Agent 前几步好好的，跑着跑着就飞了。

根因 Dean 讲得很透：模型一旦偏离训练分布，就会像大多数 ML 模型一样性能断崖式下滑，离舒适区越远越不行。Agent 每多走一步，就多一分偏离熟悉区域的概率，小错层层累积，最后雪崩。

关键在于他给的解法不是「换更大的模型」，而是两招工程手段：一是用 skill 把它按在「明亮的熟路」上，不断把它拽回它熟悉、擅长的分布里；二是多 Agent 并行加一个模型当 evaluator，让多个 Agent 尝试不同路径，再用一个评估者留下靠谱的、砍掉跑飞的。

第二招的本质，是 inference-time compute 做解空间搜索：与其求一个模型一次性走对每一步，不如让一群模型各走各的，再择优。这和 AlphaGo 用搜索加评估赢棋，是同一个古老而有效的思想。

我想强调这背后一个更朴素的心态转变：别再指望模型一次答对，要把「验证与筛选」设计进系统本身。我们太习惯把模型当成一个回答问题的神谕，但可靠的长程 Agent 更像一套「生成—评估—淘汰」的流水线。可靠性不是求来的，是搜出来、筛出来的。这对做产品的人是个解放：你不必等到有了完美的模型，你可以用工程把不完美的模型组织成可靠的系统。

四、最后剩下的，是 taste

如果 Agent 包办了执行，代码都替你写了，那人还剩下什么？Dean 的答案是两个字：taste——也就是选对题的能力。

漂亮地解一个无聊的问题，远不如笨拙地解一个真正的问题。

这句话像一记闷棍。因为我们这代工程师的整个训练，都在教我们「把问题解漂亮」：更优雅的架构、更高的测试覆盖、更快的性能。可当执行本身被 AI 无限供给，「解得漂不漂亮」的价值在贬值，「选得对不对」的价值在升值。稀缺的不再是「能不能做」，而是「该不该做、值不值得做」。

那 taste 怎么练？这是我觉得整场访谈最实在的部分——他给了三种具体方法，不是一句玄学。第一是靠经验积累：做过足够多不同的问题，你才会对「什么方向刚好快要变得可能」有直觉。第二是写清单加一年后复盘：写下你认为未来 12 个月会变重要的一批事，一年后回头核对——哪些成真了、哪些被别人做了、哪些至今没动静。第三是疯狂的思想实验：不要把大家默认的前提当理所当然。他举的例子极妙——芯片业 60 年都在追求「每颗芯片完全一致、绝不翻转一个比特」，但大规模分布式系统恰恰是「用不可靠的部件搭出可靠的整体」，那 AI 芯片能不能也松开「必须确定性」这个假设？

第二种方法尤其值得每个人今晚就开始做。它把「品味」这件玄乎的事，变成了一个可复盘、有反馈、能迭代的循环。taste 不是天赋，是一种带延迟的、需要刻意校准的预测能力。你猜未来、你下注、一年后对答案，错了就修正——这和训练一个模型的过程，本质上没有区别。区别只在于，这次被训练的是你自己。

尾声：他把最激进的那句话，押在了自己身上

回到开头。Discovery Loop 想做的事——自动化实验闭环、递归自我改进——正是 Dean 在访谈里给出的「2027 预测」：让 ML 系统自己跑实验、拆子问题、并行迭代、自我改进。

所以这场访谈根本不是「过来人的经验分享」，而是一份创业预告。他讲「两三个人在一个房间里也能撬动大事」，然后自己带着三个人走出了 Google 去验证它；他讲「自动化实验闭环是下一个前沿」，然后把身家押了上去。

对我们这些不创业的人，我觉得可以带走的也就三句话：别贪恋「差不多能用」，那是倒计时，不是里程碑；你唯一守得住的，是模型拿不到的数据，和别人复制不了的判断；执行正在变得免费，选题正在变得昂贵——今晚就写下你赌未来的那张清单。

模型越来越强，这件事听起来像是在削弱人的价值。但读完这场访谈我的感受恰恰相反：当机器接管了「怎么做」，人被逼回到了那个最古老、也最难被替代的问题上——

做什么，以及为什么。护城河没有消失，它只是搬了家，搬回到了人身上。

Sean Goedecke 在《LLMs reward expertise》里抛出一个让很多人不舒服的观点：大家用的是同一个模型，但「会提示词的人」和「第一次碰 LLM 的人」拿到的结果天差地别，而差距的真正来源不是提示词技巧，而是你在那个领域本身有多懂^[1]。

他的例子极有说服力：陶哲轩和 ChatGPT 讨论雅可比猜想反例的那段对话，和普通人对着同一个模型聊数学，几乎是两个物种。作者据此指出，领域知识让人更能从模型的长回答里提取相关想法、提出替代路径、并识别输出中「不对劲」的地方。

我认同这个判断。但我想把它推到一个更精确、也更经得住反驳的位置。先给出全文的理论支点：

LLM 大幅降低了「生成候选答案」的成本，却没有同比降低「评价候选答案」的成本。

这一句，是理解后面所有分化的钥匙。

一、从「知识」到「判断力」：专家真正拥有的是什么

原文把专家优势归结为领域知识。我想再往里走一层：专家真正稀缺的，不是「知道正确答案」，而是知道答案大概应该长什么样。

很多复杂问题根本没有标准答案。专家真正握在手里的，是四样东西：对解空间的先验——大致知道好解落在哪个区域；对异常模式的敏感度——一眼看出哪里「复杂得不自然」；对约束条件的理解——知道哪些前提不能松；对探索方向的判断——知道下一步该往哪儿挖。

这四样合起来，就是判断力。它比「领域知识」更贴近陶哲轩那些行为的本质：从模型好几段回答里拎出关键点、主动提替代方案、用「this looks more complex than I was hoping for」软性纠偏——每一个动作背后，都是「我知道对的东西应该长什么样」。

也正因如此，生成能力被商品化之后，稀缺品完成了一次迁移：真正的稀缺品，从「会写」变成了「知道什么是好的」。

二、「简洁」不是专业性的来源，而是它的外观

原文有个容易被误读的细节：陶哲轩的消息又短又直接，反而把模型切进了「和数学家对话」模式。很多人由此得出一个危险的结论——模仿专家的简洁，就能拿到专家级回答。

这个因果是反的。

陶哲轩能说得短，不是因为短句能「骗」模型进入专家模式，而是因为他清楚：哪些数学前提是双方共享、可以省略的；哪些约束一旦省掉答案就废了；追问该落在哪个真正关键的局部。原文自己也特意强调：不能只模仿这些表面技巧，关键仍是理解数学本身^[1]。

所以更准确的说法是：简洁不是专业性的来源，而是高共享语境下专业性的外观。新手的「短」往往是遗漏，专家的「短」则是压缩——专家的每一句话都携带更高的信息密度，因为他知道什么能省、什么不能。

三、新手拿到平庸答案，未必是因为模型「看不起」他

顺着上面，原文里藏着一个写得太满的机制：新手不懂 → 问得啰嗦 → 模型判定他是外行 → 给出保守平庸的答案。

这听起来很顺，但证据不足。模型未必在稳定地「判断用户身份」。更可能发生的是：问题缺少关键约束、用了宽泛无抓手的表述、没提供可供深入推导的局部切口，于是模型只能退回训练分布里最安全、最通用的那条路径。

也就是说，结果变平庸，不一定是因为模型认为「你是外行」，而更可能只是因为输入没有把解空间压缩到足够窄。专家的追问则不断压缩解空间，把模型从「平均正确」推向「局部有用」。看起来像模型识别了专家，实际上可能只是专家提供了更高信息密度的上下文。

四、LLM 像一个不承担结果的顾问

「LLM 像没品味的实习生」这个类比好用，但不精确——模型其实见过海量审美判断，也能生成相当不错的评价标准。它真正缺的不是品味，而是：对具体情境的长期浸泡、对组织隐性约束的理解、对后果的持续反馈，以及为结果负责。所以我把它换成：

LLM 更像一个见过无数案例、生成能力极强，却不为结果负责的顾问。

它能给你十种看起来都很漂亮的方案，但不会因为你选错了其中一种，在六个月后替你背上技术债、客户流失或组织成本。这个类比更能承载后文——因为接下来要谈的，恰恰是「责任」和「验收」。

五、专家优势不是固定的：关键在于谁掌握评价函数

这是我最想补上的一层，也是原论点最缺的边界条件。专业知识的重要性，随任务的可验证性剧烈变化：

由此可得一个比「LLM 是放大器」更准的判断：LLM 越能廉价地产生答案，决定价值差距的就越不是生成能力，而是任务能否被可靠验收。

在有完整测试套件的代码任务里，新手也能让模型生成、运行、修复，借外部反馈逼近正确答案——此时专业判断被部分写进了测试系统，个人经验的权重下降。但如果问题是「这个架构三年后会不会拖垮团队」「这个产品方向值不值得投」「这段文字是否真的打动目标读者」，我们甚至很难即时定义什么叫正确。这时专家的价值不是检查模型有没有犯错，而是提供一个尚未被形式化的评价函数。

所以 LLM 时代真正稀缺的，也许不是笼统的「领域知识」，而是三种更具体的能力：定义问题（知道哪些约束真正重要）、设计反馈（把模糊的好坏转化成可验证的信号）、承担判断（在答案无法即时证伪时，做出取舍并为之负责）。

六、专业性不只属于个人，还可以被「外置」

到这里，原文隐含了一个二元世界：专家驾驭模型，新手依附模型。但现实里有第三条路——把专家的判断编码进系统。

测试用例、代码规范、设计原则、评审清单、领域术语表、决策树、示例库、自动化评估器、带约束的工作流……这些东西本质上都是被冻结的专家判断。它们让一个领域知识有限的人，也能借用组织沉淀下来的专业结构。

这意味着，未来真正有竞争力的组织，未必是「拥有更多专家」的那个，而是更善于把专家脑中的判断力，转化为普通人和 LLM 都能调用的评价机制。这一步，把讨论从「个人如何用好 AI」抬升到了「组织如何构建 AI 能力」。

七、它到底扩大还是缩小差距？

「LLM 是放大器」很有力量，但它可能同时产生两种相反效应：地板效应（新手从 20 分被拉到 60 分）和天花板效应（专家从 90 分被推到过去够不着的 120 分）。

所以要拆开三个问题：谁的绝对增益更大？谁与谁的相对差距在扩大？市场愿意为哪一段能力付钱？在标准化任务里，新手的绝对提升可能更大，专家与新手的差距反而收窄；但在前沿研究、复杂架构这类开放任务里，专家能借模型探索更大的解空间，差距可能进一步拉开。于是更严谨的判断是：LLM 压缩了标准化执行能力的溢价，却可能扩大问题定义、结果验收与前沿探索能力的溢价。

一个层级，收束全文

把前面反复出现的「判断力 / 品味 / 验收」归到一个清晰的阶梯上：知识（知道这个领域有哪些事实和方法）、模型（理解这些事实之间如何关联）、判断（能预测哪种方案可能有效）、验收（能识别结果是否满足目标）、责任（愿意为取舍及其长期后果负责）。

生成能力商品化之后，前两层正在快速贬值，而后三层——尤其是验收与责任——正在升值。

结尾

所以我不再说「LLM 是放大器」这么干脆的话。它压低的是标准化生成能力的价格，抬高的是问题定义、反馈设计与结果验收的价格。它不保证专家永远胜出，但它逼着每个人回答一个更难的问题：当「做出一个答案」不再稀缺，我究竟凭什么判断这个答案值得被采用？

而这，最终又落回那句我不想删掉的话——

真正的问题从来不是「怎么用好 AI」，而是「你自己，值不值得被放大」。

1969 年，贝尔实验室的几个人，在一台被淘汰的小型机上，写出了 Unix 的雏形。同一时期，更被寄予厚望的是 Multics——一个由委员会精心设计、功能全面的「完美系统」。半个世纪过去了，Multics 早已进了博物馆，而 Unix 的血脉（Linux）却主宰了服务器、手机和几乎所有嵌入式设备。

这不是运气。软件工程史上有一个反复上演的悲剧：我们总想用更大、更全的系统去解决问题，结果系统越大越复杂，越复杂越难用，最终在自己的重量下崩塌。Fred Brooks 在《人月神话》里早就说过——向一个延期的项目追加人力，只会让它更延期。那么问题来了：为什么偏偏是那个「简陋」的 Unix 活了下来？

Unix 的长寿，不是因为它做得多，而是因为它刻意做得少。

一、简洁，是对抗复杂度的唯一武器

复杂度是软件工程的头号敌人。大多数人对抗它的方式是「更强的管理、更严的流程、更多的人」。Unix 的答案恰恰相反：从源头上不制造复杂度。

它的两条核心准则听起来朴素得近乎废话——「小即是美」，以及「让每个程序只做好一件事」。但这两句话背后，是对人性的深刻理解。人的工作记忆只有 7±2 个单元，一个小程序的全部逻辑能塞进一屏，开发者就能在脑子里完整地「持有」它；一旦程序膨胀，你就得不停地在模块间切换上下文，心智负担指数级上升。

更关键的是故障的传播。小程序出了 bug，影响范围是可控的；大系统改一行代码，可能在千里之外的模块引发蝴蝶效应。

一个经典案例是 MH 邮件系统。它不是一个庞大的邮件客户端，而是 30 多个独立小命令的集合——comp（写信）、scan（扫描）、show（阅读）、folder（管理文件夹）……每个命令只做一个动词。用户可以把它们像积木一样自由组合，拼出无穷的工作流。同时代那些臃肿的大型邮件程序，如今早已无人记得。

二、快速进化，胜过完美设计

如果说第一条准则关于「做什么」，这一条关于「怎么做」。Unix 哲学骨子里拒绝瀑布式的完美主义，它信奉的是：先跑起来，再逐步变好。

书里有一个特别精辟的「三个系统」理论，几乎道破了所有软件的宿命：第一个系统是被逼出来的，人手不足、时间紧迫，所以简洁、有活力，但往往被当成不成熟；第二个系统是委员会式的，把第一个系统里所有「本来应该有」的东西都加上，于是臃肿、迟缓，成为最糟的那一版；第三个系统才是在两者的教训之上，重新找回平衡的那个。有意思的是，Linux 既是「第三个系统」——它从 Minix 和 Unix 的教训里诞生；又保持着「第一个系统」的活力——Linus 一个人起了个头，然后靠社区疯狂迭代。

Richard Gabriel 有一个更具冲击力的说法，叫「更坏就是更好」（Worse is Better）。他说，那种追求完美、绝不妥协的「正确方法」，往往因为太难实现、太难传播而推广缓慢；而一个简单但不完美的方案，因为人人都能理解、都能上手，反而最终占据了整个生态位。Unix 走的，正是这条「更坏」的路。

但这里有个容易被误读的地方：原型不是 demo。它应该是能被真实使用的代码，只是还不完整。你要在写代码的过程中理解需求，而不是在会议室里想象需求。

三、可移植性，是长寿的基因

硬件更新的速度，永远快过软件。所以把软件死死绑在特定硬件上，等于是把资产变成了负债。Unix 很早就想明白了这件事：下一代的硬件总会跑得更快——你今天为了压榨性能牺牲可移植性，明天硬件一升级，这些优化就一文不值，但移植的成本却会永远缠着你。

而这条准则最深远的一个衍生品，是纯文本。

为什么 grep、awk、sed 这些几十年的老工具至今威力无穷？因为它们操作的都是同一种东西——人类可读的文本流。文本是所有工具的「最大公约数」，是 Unix 世界里一切可组合性的地基。任意两个程序之所以能无缝衔接，正是因为它们的输入输出都是文本。

反面教材是 CNN：1991 年他们用私有格式存储新闻档案，几年后就再也无法在新设备上回放，珍贵素材全部作废。私有格式的诱惑很大，代价也很大——它是在给未来的自己埋雷。

四、组合，是创造力的放大器

单个小程序的能力是有限的。Unix 的魔法在于：它提供了一整套「程序间协作的语言」——管道、重定向、Shell 脚本——让有限的能力，组合出无限的可能。这就是所谓的杠杆效应。

良好的程序员编写优秀的代码，优秀的程序员借用优秀的代码。

每一个公开的 Unix 工具，都成了后来者的积木。几行 Shell 脚本就能调度几十个现成的程序，完成一件相当复杂的事——而且它写一次，就能被无限次执行。所以那条老准则说得很直白：要抵制住用 C 重写 Shell 脚本的冲动。

但组合是有敌人的，它的名字叫 CUI（强制性用户界面）——那些必须由人坐在屏幕前一步步点、无法被脚本驱动的交互流程。它一出现，可组合性就死了。

这背后还藏着一个很哲学的观点：程序不创建数据，只有人类才创建数据。每个程序本质上都只是某种数据的变换器。一旦你承认这一点，就会自然而然地把程序设计成可组合的模块。

五、Unix 哲学，其实是一种文化

如果 Unix 只是一堆技术规范，它不可能活这么久。它真正厉害的地方在于——这套东西已经内化成了一种开发者文化：一套共享的价值观、审美和协作方式，而且能自我强化。

那些「小准则」，与其说是规定，不如说是「Unix 人」共享的思维习惯：沉默是金（没有输出就是最好的输出，程序无事不报、有事才说）、并行思考（默认假设问题是可以拆解、可以并行的）、层次化思考（目录树、模块化、分层抽象，是思考的基本单位）。

而开源协作，又把这种文化的杠杆效应放大到了极致。有趣的是，Linux 社区本身就同时是「大教堂」（内核的严格审核）和「集市」（发行版的百花齐放）——秩序与混沌在同一个生态里共存。

反观其他系统：MS-DOS 开放却没有哲学指导，长成 Windows 后彻底失去了简洁；VMS 虽然模块化，却把一切都塞进内核，这跟 Unix「尽量让内核小」的信仰根本相悖。Windows 想成为 VMS 的继承者，而它的设计理念，从第一天起就站在了 Unix 的对立面。

六、那么，今天的我们能学到什么

聊了这么多历史，最后还是要落回到手上的活儿。这套半个世纪前的智慧，翻译成今天的工程实践，大概是这么几条：

设计新功能前先问自己，这能不能拆成 2-3 个独立的小服务——如果一句话说不清一个模块的职责，它就是太大了。用「第一个系统」的心态启动项目：第一版在一两周内跑起来，覆盖核心场景的 60-70% 就够，拒绝「先把架构做完善」的诱惑。文本优先、私有格式最后：配置、日志、数据交换默认用 JSON / YAML / CSV，只在有实打实的性能瓶颈证据时才考虑二进制。把「可组合性」当成架构评审的一等指标：这个服务能被别的服务无状态调用吗？接口标准化吗？有没有藏着 CUI 式的强制流程？最后，建立「90% 满意度」的发布标准——功能分 P0/P1/P2，第一版只做 P0，永远留 10% 的迭代空间；发布频率，比单次发布的功能数量更重要。

结语

Unix 哲学表面上讲的是操作系统，骨子里讲的其实是如何与不确定性共处。当你无法预知未来的需求、无法预知硬件的变迁、无法预知系统会长到多大时——把每个部件做小、做通用、做得可替换，就是最稳妥的下注方式。

这套思路，放到今天的微服务、放到你的团队协作、甚至放到个人的职业规划里，大概都成立。

本文改写自我读《Linux/Unix 设计思想》的笔记。原书作者 Mike Gancarz，是一本值得每个工程师隔几年重读一次的小书。