动词

有一件事，我越想越觉得重要——软件工程里真正的主动词，正在被替换。

多数人没注意到这件事。这不奇怪。当一个词在某个领域里用了三十年，大家会开始把它和那个领域本身混为一谈。于是谈到软件工程，我们下意识想到的动词就是“写代码”。好像“工程师”就等于“把代码敲出来的人”。

但“写”只是软件工程在过去这段时间里最顺手的一种表达方式。它不是这门学科的本质。本质是解决问题。“写”只是那个时代里解决问题最便宜的方法。

现在这个方法不再是最便宜的了。

Andrej Karpathy 前阵子说了一句话，引起了不少讨论，很多人把它理解错了。他说：“code’s not even the right verb anymore。”

反对他的人把这句话读成“代码不重要了”。这是典型的因为讨厌结论而曲解前提。Karpathy 显然不是这个意思。他的意思更接近我上面说的——那个动词用旧了。

他给了一个很具体的时间点。从 2025 年底开始，他自己亲手写代码的比例断崖式下降。大多数工作变成了向 agent 描述要做什么、布置任务、检查结果、反复调整。

如果你在 2024 年听到有人这么说，你会以为他在吹牛，或者他已经被 demo 骗了。但在 2026 年听到这句话，最诚实的反应应该是——他只是更早几个月到达了一个我们大家都会到的地方。

而这个地方的关键不是“生成更快了”，是动词换了。

我在想，为什么多数人会抗拒这种替换。

一个原因是工具和自我认同的绑定。你花十年练会一种动作，这个动作就会变成“你是谁”的一部分。有人花十年把敲代码练成本能，再突然告诉他“以后不这样干了”，他不是觉得效率问题，他觉得这是对他本身的冒犯。

历史上每次抽象层级往上爬，这种反应都会出现一次。汇编的人看不上 C。C 的人看不上带垃圾回收的语言。SRE 成熟之前，所有人都觉得运维不该有一个抽象层。每一次都是同样的剧情：先是“这不算真功夫”，然后是“好吧它在某些场景有用”，最后是“你们怎么还在手动做这个”。

这一波应该也是一样。

有意思的地方是，这种抽象往上爬的过程，其实都是同一件事在反复发生——人的工作从执行层往上移。每一次往上移，需要的技能就更偏向“定义问题”而不是“解决问题”。前者不容易，后者容易被自动化。

我认为 Karpathy 真正想表达的，是人要从 worker 变成 scheduler。

他有一段话很直白。他说自己现在看到订阅额度没用完，会焦虑。因为这意味着他的 token throughput 没吃满。他把这种感觉类比成读博时代“GPU 不能闲着”的紧迫感。

这话听起来像玩笑，但其实是一个很硬的工程判断。一个调度者如果让下游 worker 饥饿，他就是在浪费产能。过去我们不会用“产能”这个词形容一个程序员，因为一个程序员就是 worker 本身，产能就是他打字的速度。现在不一样了。现在一个人可以调度的下游执行力，是完全不同的数量级。

于是瓶颈被迫迁移了。不再是“一小时能敲多少字”，而是“一小时能让多少条并行任务跑完并且结果被我采纳”。

这种转变有一个不太容易察觉的副作用——注意力本身变成最稀缺的资源。过去你以为“有时间就行”，现在你会发现“有注意力”和“有时间”是两件事。一个被 agent 环绕的人，真正的限制不是时间，是他愿意做裁决的带宽。

一旦你接受这个视角，你就会开始重新设计你一天的时间。不是按小时，而是按“我今天能做多少次有效裁决”。

有人会说：那不就是多写 prompt 吗？

不是。这是我想专门说清楚的一个地方。

prompt 是一次性的指令。它有点像喊一声。但真正有杠杆的东西，不是喊声，是声学系统——你以什么方式喊、在什么空间里喊、传到哪里、谁会接、接到之后怎么反馈。

Karpathy 没有直接用“控制面”这个词，但他用的那一串词——instructions、instruction optimization、harness、program.md——放在一起就是这个意思。他甚至把一整套研究组织方式抽象成一份叫 program.md 的文档：先把系统该怎么运转讲清楚，再比较不同版本的 program.md，最后甚至让模型根据经验写出更好的 program.md。

这不是 prompt。这是规范（spec）。

一个文档如果能决定下游成千上万次执行的行为模式，它就不是文档，它是配置。配置比指令值钱的地方在于，它反复复用。你花在写一份好 spec 上的时间会按调用次数收益。你花在写一次 prompt 上的时间只会按一次收益。

这就是为什么我会说，未来最值钱的文档，可能根本不是代码，而是那些规定“系统应该如何运转”的元文档。需求模板、review 清单、上线检查表、回滚原则。这些东西在过去被归到“工程管理”，有种被贬低的意味。以后它们会重新被照亮——因为它们才是真正的控制面。

接下来我想讲一个看起来和前面没关系的点，但其实是一回事。

Karpathy 谈 AutoResearch 的时候，有一个结构我反复品。他把系统抽象成两类 worker：一类是 untrusted 的，数量多、便宜、负责生成大量候选；另一类是 trusted 的，数量少、贵、专门负责验证。

乍一看这像是对 AI 做研究的一种具体架构。但其实它就是一条非常古老的工程原则：探索侧放开，验证侧收紧。

这个模式在软件工程里的每一层都存在。编译器里的 parser 和 type-checker。搜索里的召回和精排。CI 里的构建、单测、集成测、合规扫描。Git 里的 feature branch 和 code review。每一处你都能看到同样的结构——让一侧变便宜，让另一侧变硬。

这个结构真正厉害的地方在于，它解决了一个看起来无解的矛盾：我们希望又快又对。如果你把两侧都放在同一条线上，你只能二选一。但如果你把它们拆成两侧，让它们异步运作，“又快又对”就不再是悖论，而是一种分工设计。

把这条原则搬到 AI 编程里，你会得到一个反直觉的推论——

AI 越强，测试越重要。

这和大多数人直觉相反。很多人以为 AI 强了就可以少写测试了。实际上恰好反过来。AI 强，意味着生成侧产能越大；生成侧产能越大，就越需要验证侧有能力收口。否则你只是在以更高的速度往项目里灌入不稳定性。

这一条我希望每一个认为“有了 AI 就不用 TDD 了”的人读三遍。

Karpathy 4 月初的另一波输出，是关于知识库的。他公开了一份叫 llm-wiki.md 的文档。很多人读完第一反应是：“哦，又一个知识库项目。”

但他第一句话就把话讲白了——这不是一个项目，是一份 idea file。也就是说，他给的不是答案，是模式。

而这个模式的起点是他对今天 RAG 工作流的一次彻底不满。他指出了一个很多人其实都感觉到了、但没说清楚的病：传统 RAG 每次提问都是从零组织知识。你上传一百份文件，检索一百次，系统不会因此更“理解”任何事情。它只是在反复做同一件拼接动作。知识没有积累，综合判断不会长出来。

他的提议是，在 raw sources 和最终问答之间，插入一层会持续演化的 markdown wiki。LLM 不只是把新资料索引起来，还要更新概念页、更新实体页、修正旧结论、标记矛盾。他把这一层叫做 “persistent, compounding artifact”——持久的、会复利的产物。

我觉得 compounding 这个词用得非常准。因为这不是“存得多”，是“每次新增都改变未来提问时的起点”。复利的本质从来不是数量，是每一期的基数都不一样。普通聊天记录没有这种性质。聊天是线性消耗，不改变未来。Wiki 是非线性积累，改变未来。

这个区别一旦被你看清楚，你就会开始对“用完就散”的工作方式极度不满。你会突然意识到——你过去几年的绝大多数 AI 对话，全部浪费了。

这种不满，是一个重要的信号。

然后是那个三层结构。Karpathy 把整个 wiki 系统拆成：raw sources、wiki、schema。

• raw sources 是不可修改的原始资料。
• wiki 是 LLM 持续维护的派生层。
• schema 是定义行为边界的治理层。

这三层看起来朴素，但它解决的是一个之前从没被认真处理过的问题——在一个 AI 可以持续改写内容的系统里，哪些东西必须保持原样，哪些东西允许被改写，改写要遵循什么规则。

这问题之前没人认真处理，是因为之前没人认真面对一个 AI 会持续改写你东西的世界。现在这个世界来了，你必须有一套治理结构，否则你就会在某个礼拜发现你的知识库被模型悄悄改得面目全非，还没人知道。

这就是为什么他把 schema 放在那么重要的位置上。schema 不是“配置文件”，它是让 LLM 从一个聊天机器人变成一个有纪律的维护者的关键。

我甚至觉得这是整份 llm-wiki.md 里最值钱的一句话：the schema turns the LLM from a general chatbot into a disciplined wiki maintainer。

discipline（纪律）这个词用在一个模型身上，乍一听很奇怪。但你仔细一想，这其实就是我们对任何一个合格工程师的基本要求。不是聪明，是有纪律。让一个聪明但没纪律的东西稳定产出，是工程学永恒的问题。

AI 时代不过是这个老问题的新版本。

把 Karpathy 这两波内容放在一起看，我会得出一个结论。

软件工程正在从代码中心走向规范中心。

在代码中心的世界里，主语是程序员，动词是写。规范是辅助，是文档里的尾注，是新人入职时随便扫一眼的东西。

在规范中心的世界里，主语是系统，动词是 specify / delegate / verify。代码仍然存在，但它更多是执行产物，而不是人类主要的操作对象。规范从尾注变成了生产资料。

这两个世界的差别，比“代码生成效率”之类的指标要深得多。它是分工结构的变化。

而一旦分工结构变了，胜出者也会变。

在代码中心的世界里，最值钱的人是那个写得最好的人。

在规范中心的世界里，最值钱的人，不是最会用模型的人，也不是最会写 prompt 的人。而是最会设计一整套「人 + agent」协同系统的人——知道什么该让 agent 并行探索、什么该人类串行裁决、什么结果该被回写成资产、什么失败该被转化成规则。

这种人今天还很少。原因是过去几十年没有必要长出这种人。现在开始有必要了。

如果你读到这里，希望带走一点什么，我会给你这样一句话：

不要把 AI 当工具用，把 AI 纳入系统里用。

当你还在用“AI 是不是能替我写这段代码”来度量它的价值时，你得到的是一次性的效率提升。

当你开始问“我怎么设计一套规范、验证、沉淀、回写的系统，让 AI 在里面长期稳定工作”时，你得到的是一种会复利的产能。

这两者中间，差的不是模型，而是一层系统设计的意识。

这也是 Karpathy 最近这波内容最值得反复琢磨的地方。他展示的不是“AI 多强”，而是“一个人的工作流，可以被升级到什么程度”。

那个东西一旦被你看见，你就回不去了。

从写代码到设计控制面：AI 编程真正开始变严肃的地方

咱们今天要讨论一件容易被误解的事：最近半年，关于 AI 编程的讨论热闹得像菜市场，人人都在喊「效率翻倍」「十倍工程师」。但在我看来，热闹是浅的，真正深的那一层变化，被 Andrej Karpathy 最近连续放出的两波信号点破了。

一波是 2026 年 3 月 20 日 Karpathy 在 No Priors 播客里的长访谈；另一波是 4 月初的 LLM Wiki 设想。表面上，一个在讲 code agents，一个在讲知识库。其实讲的是同一件事。

我打算用一句话给这件事起个名字——从写代码，到设计控制面。

这篇文章，我们就把这条主线拆成几块，慢慢讲。

第一，先讲一个关键判断：代码不再是正确的动词

Karpathy 在访谈里有一句非常扎眼的话：「code’s not even the right verb anymore」。代码不再是那个正确的动词。

注意，他没说代码不重要。他说的是——主语变了。

以前软件工程的主语是「写代码的人」。你一天八小时，手上敲字母、脑子拼逻辑，产出就是你打出来的那些字符。这套逻辑在键盘时代是成立的。

但 Karpathy 给自己统计了一下，从 2025 年 12 月左右开始，他的工作状态就已经大幅偏离这条曲线了：越来越少亲手写代码，越来越多地向 agent 表达意图、布置任务、检查结果、反复调整。他用了一个很有意思的词——「delegate」，委派。

我给这个转变打个比方。这很像一个厨师当了很多年厨师之后，忽然被推去当厨师长。过去他的价值在炒得多好，现在他的价值在菜单设计、流程安排和品控。你要是以为他「不炒菜了就是不重要了」，就看错了：他的价值被整体上移了。

这里有一个关键推论：

未来工程师最稀缺的能力，不一定是把实现细节写得多漂亮，而是能不能把一项复杂工作拆成 agent 能执行的宏动作，并用合适的约束让它们稳定推进。

这句话很重要，请你划下来，之后几节都会反复用到。

第二，新的瓶颈，已经不是打字速度

承认了主语变化，下一个问题就来了：新世界里，到底什么才是瓶颈？

Karpathy 给了一个很生动的说法——他现在对「订阅额度还没用完」这件事会焦虑。因为没用完意味着——他没把 token throughput 吃满。

这个感觉他自己类比成读博时代「GPU 不能闲着」的心态。以前焦虑 FLOPs 没吃满，现在焦虑 token 没吃满。

咱们提炼一下这个观点背后的规律：

• 键盘时代，一个人的产出瓶颈是一小时能敲多少字。
• Copilot 时代，是一小时能生成多少代码。
• Agent 时代，是一小时能调度多少并行产能，并且这些产能里有多少最终被你采纳。

单位变了，问题自然跟着变。以前问「这段代码写得好不好？」，以后就要问——

• 这个任务能不能并行？
• 哪几步必须人来裁决？
• 哪些步骤可以大批量铺量试错、低成本筛选？
• 我的系统里是不是哪里有 agent 在白白闲着？

用另一种说法：人的注意力是稀缺资本，agent 的执行力是可扩展产能，工程学的任务就是让前者尽量不被锁死在线性循环里。

这和 copilot 心态完全不是一回事了。copilot 心态问的是「帮我打得快一点」，agent 心态问的是「别让我卡在 loop 里」。

第三，高杠杆的东西不是 prompt，而是控制面

很多人听到这里会说：好，我知道了，以后要多写 prompt。

这是半对半错。prompt 当然重要，但它不是最值钱的那层。

Karpathy 在访谈里反复强调几个词：instructions、instruction optimization、harness、schema、program.md。你把这些词放在一起看，就会发现他说的不是单次 prompt，而是整个系统。

他在聊 AutoResearch 的时候甚至把研究组织方式直接抽象成了一份 program.md——先把系统该怎么工作讲清楚，再去比较不同 program.md 的效果，最后甚至可以把这些经验回流给模型，让模型自己写出更好的 program.md。

这才是真正值钱的东西。

我给它起个名字——控制面。

你可以这样理解：

• Prompt，是一次临时指令。
• 控制面，是一整套让 agent 可以反复在上面稳定工作的规则。

所以，未来工程系统里真正最值钱的文档，会越来越不是代码本身，而是那些规定「这个系统应该怎么运转」的元文档：需求模板、设计模板、实现说明、测试规范、review 清单、上线检查表、回滚原则。

以前我们把它们叫「工程管理」。以后你会发现——

它们就是工程生产力本身。

第四，AutoResearch 真正给的启示：探索可以便宜，验证必须坚硬

Karpathy 讲 AutoResearch 的时候，大多数听众被「自动做研究」这件事吸引了。但我觉得更值得学的，是他对「验证」的结构性设计。

他把整个系统抽象成两类 worker：

• 一类是「不可信 worker 池」：数量多，成本低，负责大量尝试、大量生成、大量探索。
• 一类是「可信 worker 池」：专门负责验证和筛选。

这个结构非常有启发。

因为 AI 编程时代最致命的一种幻觉，就是把「生成能力」当成「生产能力」。看起来一次生成就能出代码，于是就以为生成即生产。实际上完全不是。

真正的生产能力来自两块的合成：

1. 海量探索
2. 低成本验证

两者都必须有。没有第二块，第一块会以惊人的速度放大你的错误。

你会发现，这个判断和软件工程里一直强调的那些东西——TDD、单元测试、集成测试、E2E、静态检查、code review、灰度、监控、回滚——本质上是同一个方向：

先承认 agent 会写错，然后用系统设计把这种不确定性驯服下来。

所以请记住这一条：

AI 时代越往后，自动化测试不会变得更不重要，反而会更重要。

因为这些东西，才是「可信 worker 池」在软件工程里的现实对应物。

第五，Dobby 的真正意义：agent 是自然语言控制层

Karpathy 在访谈里顺嘴讲了他家里那个叫 Dobby 的 agent。通过 WhatsApp 接收自然语言指令，帮他统一调度家里的各种自动化系统——快递、家务、维护。他特别提到一点：以前要切换好几个 app，现在只要一句自然语言。

这段听起来像花絮，但我觉得它其实是一个关键的提示。

因为它说明——在 Karpathy 的脑子里，agent 从来不是「给程序员用的工具」，而是一种更普遍的执行层。只要底层能力够强，很多原本要靠 GUI、菜单、多 app 切换才能完成的事情，都会被提升到自然语言控制面上。

这就得出一个判断：

代码 agent，只是更大范式里的一个先行子集。

真正被重写的不只是编程，而是「人如何控制复杂系统」这件事本身。

• 以前控制复杂系统，靠的是按钮、表单、脚本、菜单和手动切换。
• 以后越来越多会变成：人用自然语言给出高层意图 → agent 翻译成底层动作 → 验证与反馈回路兜底。

这已经很接近控制论了。

第六，LLM Wiki 讲的是另一件事：知识不是用来检索的，是用来编译的

如果说 No Priors 访谈讲的是「执行层」，那 4 月初的 LLM Wiki gist 就是在讲「知识层」。

Karpathy 一上来就把话讲清楚了：这不是一个成品 app，而是一份 idea file。目的不是给你一段代码，而是给你一套架构模式——你可以把它扔给自己的 agent，让它在你的环境里把实现补出来。

而他批评得最狠的，是今天主流的那种 RAG 工作流：

上传一堆文件 → 提问时临时检索相关片段 → 拼成答案。

这套东西当然能工作。但它有一个致命问题——每一次都是在重新发现知识，系统没有积累。

好了，这里就出现了这篇文章里最值得你收藏的一个概念——

知识编译。

请你把它和「知识检索」做一个对照：

• 检索，是在问答时临时找。
• 编译，是在平时不断整理、归纳、链接、修正。
• 检索更像运行时。
• 编译更像构建时。

两者都需要，但不是一个层面的事。

Karpathy 的做法是，让 LLM 在「原始资料」和「最终问答」之间维护一个持续演化的 markdown wiki。新资料进来时，LLM 不是把它简单索引，而是更新概念页、实体页、汇总页，标记矛盾，修正旧结论。他给这个中间层起了一个名字——

persistent, compounding artifact

中文意思是：持久的、会复利的产物。

这个词非常准确。知识之所以能复利，不是因为你存得多，而是因为每次新增内容都能改变你下次提问时系统的起点。

第七，三层结构：这才是 LLM Wiki 的精华

LLM Wiki 里最值得反复琢磨的，是它把系统明确拆成三层。

第一层：raw sources。
原始资料。不可修改。LLM 只能读，不能改。它是 source of truth。

第二层：wiki。
由 LLM 持续维护。包括摘要页、实体页、概念页、对比页、综合页。人来读，LLM 来写。

第三层：schema。
比如 CLAUDE.md、AGENTS.md 这类文档。规定 wiki 的组织方式、命名约定、摄取流程、回答流程、维护流程。Karpathy 说得非常明白——这是关键配置文件，是它把 LLM 从一个通用聊天机器人，变成了一个有纪律的 wiki 维护者。

为什么这三层重要？因为它第一次把很多人说不清楚的东西显式化了：

• 哪些内容必须原始、不可动；
• 哪些内容允许由 LLM 持续重写重组；
• 哪些规则负责约束 LLM 的行为边界。

这已经不是「记笔记」，而是系统设计。

再说一遍这三个关键字，我建议你背下来：raw sources、wiki、schema。

第八，index、log 与回写：知识为什么会复利

Wiki 里还有几个很容易被忽略的细节，我单独拎出来讲，因为它们是整套系统真正起作用的地方。

index.md——内容目录。记录 wiki 里有哪些页面、每页讲什么、怎么归类。Karpathy 有一个很反直觉的观察：在大约百个 sources、几百页 wiki 的规模下，靠 index 导航就已经「surprisingly well」，不一定马上需要 embedding-based RAG。这一点我觉得特别重要，很多人一谈知识库就上向量数据库，其实在你还没到规模时，纯结构化目录已经能打。

log.md——按时间追加的日志。摄取、查询、lint 都记进去。人和 LLM 都能靠它理解 wiki 的演化史。

回写——这是复利的核心。Karpathy 的态度很明确：好的回答不应该死在聊天记录里，应该回流进 wiki，成为新的一页。一段新的比较、一个新的综合、一次新的联想，都不该蒸发。

lint——定期自检。检查过时结论、孤儿页、矛盾链接、信息空洞。

把这四件事放一起，你就能看出这不是在「存信息」，而是在维护一个可再利用的结构。

• 聊天是消耗品。
• 结构化、可回写、可 lint 的 wiki，才是资产。

第九，容易误读 Karpathy 的三个地方

说到这里，我得专门提醒三个最常见的误读，不说清楚，前面的内容很容易被带偏。

误读一：人类退出。

听见「我已经不怎么亲手写代码了」，很多人直接理解成「Karpathy 在说人不重要了」。错。

无论在访谈里还是在 LLM Wiki 里，他都反复强调一件事——人负责 sourcing、exploration 和 asking the right questions。

所以真实的变化不是人退出，而是人上移。从执行层迁移到控制层和判断层。

这反而对工程师提出更高要求：你不能只会实现，还得会定义、会裁决、会验证。

误读二：反 RAG。

Karpathy 没说 RAG 没用。他说的是——不要只停留在检索。

检索适合取材，wiki 适合沉淀，schema 适合治理。三者是互补的，不是互相替代的。

误读三：多开 agent 就赢了。

很多人看完会以为「我同时开十个 agent 窗口就很厉害」。完全不是。

Karpathy 对 instructions、schema、verification 的强调，恰好说明问题从来不在 agent 数量，而在系统设计。没有规范，agent 越多只会越快产生更多噪音。

真正该学的是：

• 什么任务适合并行；
• 什么任务必须串行收口；
• 什么任务能低成本验证；
• 什么结果应该回写成资产。

第十，我给你总结四个「转移」

如果把 Karpathy 这两波内容压缩进工程实践里，我认为可以归纳成四个关键转移。这是这篇文章最想让你带走的东西。

转移一：从「写代码」到「设计任务单元」。

未来高杠杆的工作，不是把函数写得多快，而是能不能把需求拆成适合 agent 接手的任务单元。一个成熟的任务单元应该包括——边界条件、异常路径、数据契约、依赖关系、验证方法、上线风险、回滚策略。

你给 agent 的，不应该只是「活」，而应该是「带护栏的活」。

转移二：从「prompt」到「control plane」。

最值钱的文档，会越来越是那些规定「系统如何运转」的元文档：规范、模板、命名约定、测试门槛、上线规则、事故预案。

agent 不是靠情商稳定工作的，它靠控制面。

转移三：从「生成正确」到「验证收敛」。

不要指望模型一次写对。真正可持续的做法是——让生成便宜，让验证坚硬。探索可以放量，但收口必须靠测试、检查、日志、评审、回滚。

所以再说一遍：AI 时代越往后，TDD、E2E、lint、静态检查、合约测试、监控与灰度，只会更重要。

转移四：从「聊天记录」到「复利资产」。

今天绝大多数人和 AI 的交互仍然停留在消费品层面：问一次、答一次、用完就散。

Karpathy 这波最值得学的是——把问答、分析、比较、综合，一点一点回写成长期可复用的结构化资产。

未来人和人之间的差距，可能不在「谁会不会用 AI 」，而在「谁有没有把自己的工作流、判断标准和知识沉淀成 agent 能继续利用的系统」。

结语：模型会商品化，驯化能力不会

最后，我想给这篇文章一个收尾的判断，也是我最深的一个感受。

Karpathy 最近在示范的，不是「怎么用 AI 提高一点点效率」，而是怎么把一个人的工作流，升级成一个会自我增益的系统。

在这个系统里：

• agent 负责大量执行；
• schema 负责约束执行；
• tests 和 review 负责验证执行；
• wiki 和 log 负责沉淀执行；
• 人类负责定义方向、调整结构、做最终裁决。

工作不再是一次次完成任务，而是在不断改造「完成任务的机器」本身。

未来模型会越来越强，工具会越来越趋同，价格也会继续往下走。这些都会被商品化。

但有一项能力，短期内不会被商品化——

把不稳定智能，驯化成稳定产出的能力。

把它作为一种系统设计能力来训练，才是 AI 编程真正开始变得严肃的地方。

到这里你会发现，前面讲的那些零碎的东西——prompt、spec、AGENTS.md、TDD、E2E、review、knowledge base、daily notes、playbook、复盘文档——突然连成一条线了。

它们不是散装技巧，而是在共同组成一个控制系统。

如果你能从这篇文章里带走一句，那就这句：

未来最值钱的人，不一定是最会用模型的人，而是最会设计「人 + agent 系统」的人。

今天就聊到这里。我们下次再见。

从写代码到设计控制面：Karpathy 最近两波观点的学习笔记

本文是一份学习笔记，整理 Andrej Karpathy 最近两次公开表达里对 AI 编程最有启发的部分。

背景

2026 年 3 月 20 日，Karpathy 在 No Priors 播客做了一期长访谈，主要讨论 code agents、delegation、AutoResearch 等话题。

2026 年 4 月 2 日，他在推特上提出 LLM Knowledge Bases 的构想。两天后，4 月 4 日，他在 GitHub Gist 上公开了一份 llm-wiki.md，把这个构想具体化为一份“架构说明”。

这两次输出，表面上一个在讲 agents，一个在讲知识库。实际上讨论的是同一件事：在 AI 能力越过某个门槛之后，人类的工作应该如何重新组织。

本文把相关观点整理成十个小节，便于日后查阅。

一、代码不再是正确的动词

Karpathy 在访谈里说了一句：“code’s not even the right verb anymore。”

这句话容易被误解成“代码不重要了”。它真正的意思是：工程师日常工作的主体动作，不再是写代码本身。

他自述的时间点是 2025 年 12 月左右。从那时起，他亲手写代码的比例大幅下降，主要工作变成向 agent 表达意图、布置任务、调参、验收。

这是一个分工上的变化，不是一个效率上的变化。

二、新的瓶颈：token throughput

访谈里有一个值得记住的说法：他现在会对“订阅额度没用完”这件事感到焦虑。原因是——没用完意味着他没把 token throughput 吃满。

他把这种感觉类比成读博时代对 GPU 的焦虑。以前怕 FLOPs 没吃满，现在怕 token 没吃满。

把这句话翻译成普通话：

• 键盘时代，个人产出的瓶颈是打字速度。
• Copilot 时代，是单线代码生成速度。
• Agent 时代，是能同时调度多少条可并行的产能。

人不再是执行者，而是调度者。

三、杠杆不在 prompt，在控制面

Karpathy 在访谈里反复使用几个词：instructions、instruction optimization、harness、program.md。

把这些词放在一起看，他要表达的是：高杠杆的不是单次 prompt，而是整个围绕 agent 构建的系统。

在 AutoResearch 那段，他甚至把研究组织方式抽象成一份 program.md：

1. 用这份文档描述系统该怎么工作；
2. 比较不同 program.md 的效果；
3. 最后让模型根据经验自己写出更好的 program.md。

这意味着未来工程体系里，最值钱的文档可能不再是代码，而是规定“系统如何运转”的元文档：

• 需求模板
• 设计模板
• 实现说明
• 测试规范
• review 清单
• 上线检查表
• 回滚原则

过去我们把这些东西归在“工程管理”；以后它们会越来越像工程生产力本身。

四、AutoResearch 真正的启示：探索与验证的分离

Karpathy 提到 AutoResearch 时，用了一个很清晰的结构：

• Untrusted workers：数量多，成本低，负责大量探索与生成。
• Trusted workers：数量少，专门负责验证与筛选。

探索可以分布式、廉价、海量；验证必须收口、可信、可检查。

这个结构对 AI 编程有直接意义。

AI 编程最常见的幻觉，就是把“生成能力”当成“生产能力”。两者并不相同。真正的生产能力，由两部分合成：

1. 海量探索
2. 低成本验证

少了第二部分，第一部分只会更快放大错误。

因此，在 agent 时代：

• TDD 不会退场
• 集成测试不会退场
• E2E 不会退场
• 静态检查、合约测试、监控、灰度、回滚都不会退场

相反，它们会变得更重要，因为它们是“可信 worker 池”在软件工程中的现实对应物。

五、Dobby：agent 是更普遍的执行层

访谈里还有一段关于家庭 agent “Dobby” 的内容。Karpathy 用 WhatsApp 给它发自然语言指令，它再统一调度家里的各个自动化系统——提醒快递、执行家务维护等等。

这段话信息量不小。

它说明在 Karpathy 那里，agent 不是“编程专用工具”，而是一种更普遍的自然语言控制层：

• 以前控制复杂系统，靠按钮、表单、脚本、菜单和多 app 切换。
• 以后越来越多会变成：“用自然语言表达意图 → agent 翻译为底层动作 → 验证与反馈回路兜底”。

代码 agent，只是这个更大范式的一个先行子集。

六、LLM Wiki：知识不是只拿来检索的

4 月 4 日的 llm-wiki.md 一上来就讲清楚了三件事：

1. 它不是一个成品 app。
2. 它是一份 idea file，目的是把高层想法交给自己的 agent 去补全实现。
3. 它要解决的，是当前 RAG 工作流的一个根本问题——没有积累。

所谓“没有积累”是指：传统 RAG 在每次提问时临时检索文档片段，用完就散。知识没有被整理、归纳、链接、修正。每一次提问都是在重新发现。

LLM Wiki 的思路是：在原始资料和最终问答之间，加一层可持续演化的 markdown wiki。

新资料进入后，LLM 不只是索引它，而是：

• 更新概念页
• 更新实体页
• 更新汇总页
• 标记矛盾
• 修正旧结论

Karpathy 给这一层起了一个名字：persistent, compounding artifact——持久的、会复利的产物。

七、三层结构：raw sources、wiki、schema

LLM Wiki 的关键，是把系统明确拆成三层。

第一层：raw sources。

原始资料，不可修改，是 source of truth。LLM 只读，不改写。

第二层：wiki。

由 LLM 维护。包括：

• 摘要页
• 实体页
• 概念页
• 对比页
• 综合页

人来阅读，LLM 来写。

第三层：schema。

比如 CLAUDE.md 或 AGENTS.md。用来规定：

• wiki 的组织方式
• 命名约定
• 摄取流程（新资料进入时怎么处理）
• 回答流程（查询时怎么产出答案）
• 维护流程（什么时候 lint、检查）

Karpathy 明确指出，schema 才是关键配置文件。它把 LLM 从一个通用聊天机器人，变成了一个有纪律的 wiki 维护者。

这三层的意义在于把过去含糊的“知识管理”显式化了：

• 哪些内容必须保持原始、不可改；
• 哪些内容允许由 LLM 持续重写；
• 哪些规则负责约束 LLM 的行为边界。

八、index、log 与回写

Wiki 里还有几个容易忽略但很关键的细节。

index.md

内容目录。记录：

• wiki 中有哪些页面
• 每页讲什么
• 按什么分类组织

Karpathy 给了一个经验性的规模判断：在约百级 sources、几百页 wiki 的规模下，仅靠 index.md 就能帮助 LLM 导航，“surprisingly well”，不一定立刻需要 embedding-based RAG。

log.md

按时间顺序追加的日志，记录：

• 摄取
• 查询
• lint

作用是让人和 LLM 都能理解 wiki 的演化史。

回写

Karpathy 明确指出：好的回答不该只留在聊天记录里，应该被回写进 wiki，成为新页面。

一段新的比较、一次新的分析、一条新的联想，都不应该蒸发。

lint

定期自检。检查：

• 过时结论
• 缺失页面
• 孤儿页
• 矛盾链接
• 信息空洞

这四件事合在一起，说明 LLM Wiki 不是在“保存信息”，而是在维护一个可再利用的结构。

知识的复利效应，来自每次新增内容都会改变下次提问时系统的起点。这和普通聊天记录的区别，就在这里。

九、三个容易出现的误读

误读一：人类退出。

“我已经不怎么亲手写代码了”不等于“人类不重要了”。

无论在访谈里，还是在 LLM Wiki 的描述里，Karpathy 都反复强调一件事——人负责 sourcing、exploration 和 asking the right questions。

真正的变化是：人的工作从执行层迁移到控制层和判断层。这对工程师提出了更高要求：不仅要会实现，还要会定义、会裁决、会验证。

误读二：LLM Wiki 是反 RAG。

不是。Karpathy 没有否定检索，他只是指出：单次检索式工作流缺少积累。

• 检索适合取材
• wiki 适合沉淀
• schema 适合治理

三者互补。

误读三：多开 agent 就赢了。

也不是。Karpathy 对 instructions、schema、verification 的强调说明：问题不在 agent 数量，而在系统设计。

没有规范，多开 agent 只是更快产生更多噪音。

十、四个转移

把上面的观点压缩到工程实践里，可以归纳成四个转移。

转移一：从“写代码”到“设计任务单元”

高杠杆的工作，不再是把函数写得多快，而是能否把需求拆成适合 agent 接手的任务单元。

一个合格的任务单元至少应该包括：

• 边界条件
• 异常路径
• 数据契约
• 依赖关系
• 验证方法
• 上线风险
• 回滚策略

简而言之：不要只给 agent 派活，要给 agent 派“带护栏的活”。

转移二：从 prompt 到 control plane

最值钱的文档，会从代码本身转向那些规定“系统如何运转”的元文档：

• 规范
• 模板
• 命名约定
• 测试门槛
• 上线规则
• 事故预案

agent 不是靠情商稳定工作的，它靠控制面。

转移三：从“生成正确”到“验证收敛”

不要指望模型一次写对。可持续的做法是：

• 让生成便宜
• 让验证坚硬

探索可以放量，但收口必须靠测试、检查、日志、评审和回滚。

转移四：从“聊天记录”到“复利资产”

今天多数人与 AI 的交互还停留在消耗品层面：问一次、答一次、用完就散。

Karpathy 这波最值得学的是——把问答、总结、分析、比较、联想，逐步回写成长期可用的结构资产。

小结

如果只留一句话，我会选这句：

Karpathy 最近在示范的，不是“如何用 AI 提高一点点效率”，而是“如何把一个人的工作流，升级成一个会自我增益的系统”。

在这个系统里：

• agent 负责大量执行
• schema 负责约束执行
• tests 和 review 负责验证执行
• wiki 和 log 负责沉淀执行
• 人类负责定义方向、调整结构、做最终裁决

工作不再是一次次完成任务，而是不断改造“完成任务的机器”。

模型会越来越强，工具会越来越趋同，价格也会继续往下走，这些都会被商品化。

但把不稳定智能驯化成稳定产出的能力，短期内不会被商品化。这正是 AI 编程真正开始变得严肃的地方。

参考

• Andrej Karpathy, No Priors 访谈，2026-03-20。
• Andrej Karpathy, Twitter/X 关于 LLM Knowledge Bases 的推文，2026-04-02。
• Andrej Karpathy, llm-wiki.md，GitHub Gist，2026-04-04。

别再讨论 AI 会不会替代程序员了——该谈谈控制面

先把我的结论摆在前面：

这一波 AI 编程真正值得严肃对待的地方，不是 agent 能写多漂亮的代码，而是它把整个软件工程从“代码中心”往“规范中心”又推了一大步。

看不到这一层的人，基本还停留在“我是不是要失业了”的讨论里；看到的人，已经在重构自己的工程体系。

Andrej Karpathy 最近两波公开输出，一个是 2026 年 3 月 20 日的 No Priors 长访谈，一个是 4 月初的 LLM Wiki 设想。这俩看上去完全不搭界——一个讲 code agents，一个讲知识库。但你要是写过几年系统的，一眼就能看出它们讲的是同一件事：分层、契约、验证、沉淀。

这就是程序员的修炼要讲的那套东西，只不过对象从人换成了 agent。

下面我按自己的理解讲八段。

一、“code’s not even the right verb anymore” 是什么意思

Karpathy 原话：“code’s not even the right verb anymore。”

很多人第一次听会觉得这是一句口号。其实不是，这是一个很精确的工程判断。

软件工程这门学科里，“verb”（动词）对应的是人在这个系统里的主要动作。

• 单体时代，程序员的动词是 write。
• DevOps 时代，动词里多了 deploy、monitor、rollback。
• 云原生时代，动词里又多了 orchestrate、scale、observe。
• Agent 时代，动词真正要换掉了——主导动作变成了 specify / delegate / verify。

说白了就是：不是我亲自干，而是我告诉系统该怎么干，然后校验它干得对不对。

Karpathy 自述从 2025 年底开始，自己亲手写代码的比例大幅下滑，日常工作变成向 agent 表达意图、布置任务、校对结果。

这件事我见过太多老工程师抵触。因为一个人几十年练出来的手感，突然在新范式里失效了。可惜，工程学不看人情，它看抽象层级。

历史上每一次我们把一层原本由人承担的动作下沉给机器，都会有人说“这还能叫工程吗”。汇编的人这么说过 C，C 的人这么说过 Java，Java 的人这么说过运行时。每一次抵触都没能阻止抽象继续往上爬。

这一次也不会。

二、新的瓶颈不是敲键盘，是“池子够不够满”

Karpathy 讲了一件很有意思的事。他说自己现在对“订阅额度没用完”会感到焦虑。原因是没用完意味着他的 token throughput 没有吃满。

熟悉系统工程的人看到这句话，脑子里应该立刻想到的是——吞吐瓶颈。

这和以前我们在分布式系统里分析“CPU 利用率没上去”“队列深度异常”“worker 饥饿”是一回事。

重点在于，人在这个系统里的位置变了：

• 过去人是worker。瓶颈是键盘速度。
• 现在人是调度器。瓶颈是能不能让下游 worker 不饥饿。

你调度不过来，agent 就会闲着。你一旦卡在人肉 review，整条 pipeline 就降频。

所以 Karpathy 讲的那句“尽量不让人类卡在 loop 里”，对应到工程学里就是一条很古老的原则——

避免关键路径上的单点阻塞。

只不过这次单点阻塞的角色是“人”。

三、杠杆在哪：不在 prompt，在 harness

现在谈 AI 编程，大家都在谈 prompt。

我先说一句得罪人的话：prompt 层不够高，不值得在这一层投入太多。

高杠杆的东西是 Karpathy 反复在讲的那几个词：

• instructions
• instruction optimization
• harness
• program.md

这些放在一起，其实就是一个东西——控制面（control plane）。

你要理解，program.md 不是一份 prompt，它是一份系统规约。Karpathy 在 AutoResearch 那段里说得很直白：

1. 用 program.md 描述系统该怎么工作；
2. 去比较不同 program.md 的效果；
3. 最终甚至让模型根据经验自己写出更好的 program.md。

熟悉这一套的老工程师应该一眼就认出来了——这是元编程 + 架构文档 + 配置即代码的合体。

再往前追一点，这其实就是 Unix 哲学的一个现代变体：

“Rule of Representation: Fold knowledge into data, so program logic can be stupid and robust。”

——《The Art of Unix Programming》

把知识折叠进数据。Karpathy 现在做的事情是——把知识折叠进规范。

所以控制面里真正有价值的东西，是那些以前被贬低为“工程管理”的文档：

• 需求模板
• 设计文档
• 实现说明
• 测试规范
• Review checklist
• 上线检查表
• 回滚预案

过去这些东西在很多公司被当成合规负担。以后你会发现——

它们不是合规，它们是生产资料。

一个团队的战斗力，会越来越取决于这套元文档的质量。

四、AutoResearch 那段：这是教科书级别的验证架构

Karpathy 讲 AutoResearch 的时候，很多人被“AI 做研究”这件事吸引了。但我看的重点是另一个：

Untrusted workers + Trusted verification。

这是经典的**“生成/判别分离”架构**：

• 大量廉价的 untrusted worker 负责生成候选。
• 少量昂贵的 trusted worker 负责验证、筛选、收口。

这个结构在软件工程里根本不新鲜。你做过大规模系统都见过：

• 搜索里的召回 + 精排。
• 编译器里的 lexer + parser + type-checker。
• CI/CD 里的构建 + 单测 + 集成测 + 合规扫描。
• 推荐系统里的 cold path + hot path。
• 甚至 Git workflow 里的 feature branch + code review + main。

全都是同一个模式：探索侧放开，验证侧收紧。

所以 Karpathy 这句话在工程上完全是符合常识的，你把它搬到 AI 编程里就是一条硬性原则——

AI 时代，TDD、单测、集成测、E2E、contract test、静态检查、lint、灰度、监控、回滚，一个都不能少，而且只会更多。

为什么？因为：

• 以前你只需要验证一个“慢且稳”的开发者。
• 现在你要验证一个“快且不稳”的 agent。

需要验证的力度反而更大。

那些以为“有了 AI 就不用写测试了”的人，走的是一条最危险的工程路径：

把所有火力都押在生成侧，让验证侧裸奔。

这在工程学里有个专门的名字，叫自杀。

五、LLM Wiki：知识工程化

4 月初的 llm-wiki.md 值得展开单独讲。

Karpathy 一上来就明确：这不是产品，是一份 idea file。它解决的是当下 RAG 工作流里的一个病——没有积累。

传统 RAG 长这样：

1
2
3
4

user 提问
  → 向量检索原始文档
  → 拼接上下文
  → LLM 回答

这套东西可以工作。但它有一个硬伤——每次提问，系统都在从零开始组织知识。

你问十遍同一个问题，系统不会变聪明。你往库里加一百份资料，系统也不会自动产生新的综合判断。知识是碎的，没有结构，也没有版本。

Karpathy 的做法是在 raw sources 和最终问答之间，插一层 markdown wiki。

这一层由 LLM 持续维护，用来：

• 把多源信息综合成概念页、实体页、对比页
• 标记矛盾
• 修正旧结论
• 记录综合判断

他给这层起的名字很准——persistent, compounding artifact，持久的、会复利的产物。

我把它翻译成工程师听得懂的话：

• RAG 的思路是运行时检索。
• LLM Wiki 的思路是构建时编译。

两者不是互相替代，是不同层的工作。

你可以做一个类比：

• raw sources 相当于源码。
• wiki 相当于中间表示（IR）或构建产物。
• 最终问答相当于运行时调用。

一个做过编译器或者构建系统的人会立刻明白这种分层的意义：一旦把“构建”和“运行”分开，系统就具备了做增量优化和持续演化的条件。

这是 LLM Wiki 最重要的工程学贡献。

六、三层架构：raw sources / wiki / schema

LLM Wiki 把系统明确拆成三层。这一节，我用工程学的语言给它映射一遍。

第一层：raw sources。

不可变原始资料。只读。相当于 immutable log 或者 source of truth。

第二层：wiki。

由 LLM 维护的可变层。包括摘要、实体、概念、对比、综合页。相当于派生视图（derived view）。

第三层：schema。

CLAUDE.md、AGENTS.md 这类文档。相当于治理层（governance layer）：规定组织方式、命名规范、摄取流程、回答流程、维护流程。

如果你做过 DDD，这个结构应该很熟悉：

• raw sources = raw events
• wiki = read model / projection
• schema = domain rule + invariant

如果你做过 data engineering：

• raw sources = bronze layer
• wiki = silver / gold layer
• schema = governance + metadata catalog

这套东西在数据工程和 DDD 里已经被反复验证过，现在 Karpathy 把它搬到了 LLM 时代的个人知识系统里。

重点是：哪些内容不可改、哪些内容允许 LLM 改、哪些规则约束 LLM 的行为，必须在 schema 里显式写出来。

这已经不是“记笔记”了，这是系统设计。

七、index、log、回写与 lint：为什么这套东西会复利

还有几个容易被忽略但非常关键的细节。

index.md

LLM 用来导航的目录。Karpathy 有一个反常识的观察：在大约百个 sources、几百页 wiki 的规模下，纯结构化的 index 就已经“surprisingly well”，不一定立刻需要 embedding-based RAG。

我个人非常认同这一条。**在你的问题规模还没超过结构化方法的上限之前，不要急着上向量数据库。**这是典型的“用大炮打蚊子”，在工程上是反模式。

log.md

时间序日志。摄取、查询、lint 都追加在这里。这一层对 LLM 来说是“可追溯性”，对人来说是“审计”。

回写

好答案不该死在对话窗口里，要回流进 wiki。每次问答都可以变成一次 schema 驱动的小型 ETL。

lint

定期自检。过时结论、孤儿页、矛盾链接、信息空洞。相当于静态分析。

把这四件事放一起看，你会发现 LLM Wiki 就是一个针对“个人知识”的小型 CI/CD 系统：

• index 是目录和路由。
• log 是事件流。
• 回写是 ETL。
• lint 是静态检查。
• schema 是配置。

知识之所以能复利，不是因为你存得多，而是因为每次新增内容都改变了下一次提问时系统的起点——也就是 derived view 越来越好。

普通聊天记录做不到这一点，因为它没有派生视图。

八、四个工程上的转移

我把 Karpathy 这两波输出在工程实践里压缩成四个转移，这是我自己会拿来检查一个团队“在不在路上”的标尺。

转移一：从“写代码”到“设计任务单元”

一个合格的任务单元，不是 JIRA 上一条“实现 XX 接口”，而应该是一份带护栏的规约：

• 边界条件
• 异常路径
• 数据契约
• 依赖关系
• 验证方法
• 上线风险
• 回滚策略

以前这叫“设计文档”。以后它就是你喂给 agent 的最小工作单元。

转移二：从 prompt 到 control plane

团队里最值钱的文档，会从代码慢慢迁移到：

• 规范
• 模板
• 命名约定
• 测试门槛
• 上线规则
• 事故预案

这些就是 agent 的“控制面”。没有控制面，agent 越多越乱。

转移三：从“生成正确”到“验证收敛”

不要再幻想“一次生成就对”。工程上可持续的做法是——

• 让生成便宜
• 让验证坚硬

探索可以放量，收口必须靠测试、合约、静态检查、灰度、监控、回滚。

这条跟 SRE 的那套哲学是完全对应的。

转移四：从“聊天记录”到“复利资产”

聊天是消耗品。wiki 才是资产。

未来拉开差距的不是“谁会不会用 AI”，而是“谁把自己的工作流、判断标准、知识沉淀成了一个 agent 能继续使用的系统”。

三个容易掉进去的坑

最后必须说一下三个常见误读，别掉进去。

坑一：以为“人不重要了”。

Karpathy 说自己几乎不亲手写代码，但他同时在反复强调：人负责 sourcing、exploration、asking the right questions。

人没退出，人上移了。对工程师的要求变高了——你得能定义问题、设计约束、设计验证、做最终裁决。

坑二：以为 LLM Wiki 要干掉 RAG。

不是。检索、编译、治理是三层不同的事。检索适合取材，wiki 适合沉淀，schema 适合治理。三者互补。

坑三：以为多开 agent 就赢。

没有 schema 和 verification，多开 agent 只是把噪音产生得更快。这在工程上等价于“把 CI 关了然后开 20 个 feature branch 并行推主干”，稍微懂系统的人都知道结果是什么。

结语：模型会商品化，驯化不会

写到这里，我想把话说死一点。

模型会越来越强，工具会越来越趋同，价格会持续走低，这些都会被商品化。

但“把不稳定智能驯化成稳定产出”的系统设计能力，不会那么快商品化。

这个能力，和过去老工程师练出来的那些硬功夫是一脉相承的——分层、契约、验证、沉淀，换了个对象而已。

Karpathy 这两波内容真正提醒我们的就是这一件事：

未来的软件工程，不只是“如何让机器替你做事”；而是“如何把机器纳入一个你能长期控制、长期优化、长期复利的系统”。

谁把这件事做扎实了，谁就不会被替代。

谁只是一窝蜂去追新模型、新工具、新 prompt 技巧，谁才是真的有危险。

这就是 AI 编程开始变严肃的地方，也是我们这代程序员现在真正该修炼的东西。

共勉。

On the Loop：在加速的时代，重新认领自己的摩擦

这是一份双声部的学习笔记，整理自 2026 年 4 月 19 日的一次周谈。
两位说话人以 L 和 W 指代，其余背景信息按隐私考量省略。
话题从 Cursor 3.0、Codex、Claude Opus 4.7、Harness Coding 这些当下的工程工具，一路延伸到 AI 摩擦论、功利主义、电车难题、河村勇辉、比尔·盖茨自传，最后落到分手、噩梦与请假这些最具体的生活面。
本文不是逐字稿的浓缩，而是把对话拆成五个板块。每个板块保留两人的差异与张力，再在末尾给出一条可作为思考刻度的小结。

板块一：编程范式的转移

1. Cursor 3.0 与一种“界面无力感”

L 一开始就抛出一种状态：以前 AI 工具一更新，她总有跃跃欲试的冲动；这次 Cursor 3.0 和 Claude Opus 4.7 接连发布，她却第一次产生了“无力感”。不是不想学，而是不知道该怎么学。

最直接的表现是界面。Cursor 3.0 上线后，新版 UI 总在引导她跳到一个类似 Codex 的“对话优先”的页面，左边是项目列表（本机、实验室服务器、自己的云服务器），看起来像一个多 agent 工作面板。但她固执地留在旧布局：左边文件树，中间代码，右边对话列表。

L 的反对意见：
一是跨电脑、跨服务器的对话上下文没有打通。白天在一台电脑上聊到一半，换到另一台机器时哪怕做了 markdown 记录，“上下语境”也没有强连续性，要花时间让它“想起来我们刚才在做什么”。
二是宣传过的“跨服务器执行”功能她试过，似乎跨不过去——也可能只是她还没研究透。
三是新的界面“看不见代码”会让她没有安全感。

这其实是一个普遍的心理触点：当工具开始替你管理上下文，你会本能地不信任它。 因为你以前的“安全感”是建立在“我能看到一切”之上的。

2. Codex 让你看不见代码：从 In the Loop 到 On the Loop

W 给出了一个更激进的视角：这不是 Cursor 改坏了，是编程范式正在转移。

他把当下的 coding 工具粗略分成两代：

• 第一代（旧 Cursor、Copilot）：编辑器是中心，代码是中心，AI 是辅助。鼓励你在编辑器里直接改 AI 写的代码。
• 第二代（Codex、新 Cursor 3.0）：连编辑器都不提供。鼓励你不要看代码，只通过指令、规范文件和最终评估来驱动它。

W 自己的转变很典型：刚用 Codex 时极不习惯，两三周后完全适应。两个月里“一次回滚都没有过”。哪怕 AI 改得不满意，他也只是说“你改的我不满意，继续改吧”，从来没有“把东西改崩”的情况。

为什么趋势会朝“不看代码”这个方向走？W 用了一句很 PG 的判断：

代码生成的速度已经越来越快了。问题不是它会不会失控，而是：怎么样才能不让人类的旧习惯拖慢它的速度？

人类阅读代码的速度，早就赶不上 LLM 写代码的速度。继续坚持“逐行 review”，等于强行让跑得最快的那一环陪着最慢的那一环走。所以新范式不是放任 AI 乱跑，而是把“质量保证”从行内挪到了边界上：

• 边界约束：每次只改需求范围内的部分，不动别的。
• 效果约束：给一个明确的 benchmark——多少测试用例、平均耗时多少、内存占用降到多少。达不到就换方案。
• 并行扩张：一个需求拆 10 个思路，10 个线程并行实现，最后汇总报告，挑 1–2 个继续优化。

W 用一句话总结这一代工具想要你做的事：不要在循环里（in the loop），要在循环之上（on the loop）。

他举了一个非常贴切的类比：
你做的番茄炒蛋我觉得太咸了。
旧范式的解法是：我自己加点水、加点蛋、加点番茄，把这盘菜救回来——这是 in the loop。
新范式的解法是：我告诉你“以后做番茄炒蛋之前先尝一口再端上来”，给你加一条规则。下次你重新做一盘——这是 on the loop。

In the loop 是修补结果，on the loop 是修补规则。

L 在听完后没有立刻被说服，但她承认这至少给了她一个新的支点：自己之前的“看不见代码就不安全”的反应，本身就是一种范式残留。

3. Opus 4.7：当 AI 不再“猜”你

谈到 Claude Opus 4.7，两人都用了几天，结论却不太一样。

L 引述了一个 AI 博主的判断：模型的代码能力越来越强，但“不会说人话”了，跟人交互的能力反而在弱化。她自己没有强烈感受，因为她使用 AI 的场景偏机械——“分析这个结果”，她只关心准确性和专业性，不太在乎口吻。

W 的感受不一样，但他也不同意“不会说人话”这个表述。他的体感更精准：

不是 4.7 不会说人话了，是它没有以前那么愿意“猜”你的需求了。

4.6 及之前的版本会“擅作主张”——你没说清的部分，它替你脑补一个合理动作直接做了。4.7 更倾向于反复回头确认：“接下来你想要 A 还是 B？”

这是一种在 RLHF 调教中常见的偏移。过去模型乐于“主动猜测”，惊喜多但翻车也多；新版本更“遵从字面意思”，安全但失去了主动性。

W 没有给出“哪种更好”的结论，只是冷静地标记了变化。对一个工具的真正了解，往往不是“我喜不喜欢它”，而是能不能精确说出它最近变了什么。

4. Harness Coding：给麻将定方向

W 在对话快结束的时候提了一个新关键词——他听到的发音介于 honest coding 和 harness coding 之间，本意是后者：“给马具上缰绳”的 coding。

L 的第一反应：是不是 skill 的集合？W 否认——skill 是“做某件事”，harness 更像一套规则（rules）的集合：它不是教模型做什么，而是圈出模型不能越过的边界，再给一个评判标准。

W 把这种工作方式类比成“管理一个团队”：

• 你不可能要求每个人写代码都符合你的品味。
• 但你必须让团队建立标准化的东西、沉淀隐性知识。
• 还要做兜底机制：发现重大问题时，能用一个配置开关回滚，而不必重新发布。

他自己已经在朝这个方向尝试：先聊需求 → 出设计文档 → 出实现文档 → 自动跑测试用例。这其实就已经是一种轻量的 harness。

最有意思的是 W 对自己旧习惯的反思：

以前我会逐行去看 AI 写的代码，看到不符合品味的就要求重构。后来我意识到，这是一种“没有必要的修饰工作”。

命名长一点短一点，三段逻辑是写在一个方法里还是拆三个 private 方法——这都是风格。风格上的洁癖是 in the loop 的另一种形式，会拖慢整个团队的速度。

L 在这里没有反驳，她还在适应“看不见代码”的不安全感——这本来也是 W 几个月前的状态。

小结
第一代工具让你“写代码更快”，第二代工具让你“不写代码”。
你需要切换的不是 IDE，是身份。
从程序员，切换到一个 AI 团队的 tech lead。
安全感不再来自“我看到了什么”，而来自“我设了哪些边界”。

板块二：AI 压缩了摩擦，还是搬运了摩擦？

1. 一句被广泛传播的判断

L 提到一个最近听到的论点，来自李继刚（注：原话被她一开始误记为卡兹克所提，事后纠正）：

AI 压缩了你和世界之间的一切摩擦。

逻辑大致是：人有 system 1 和 system 2 两套思维系统，AI 的出现在两套系统之外又生成了一个 system 0——它让你根本不需要思考，键盘最终会退化成 yes / no / yes / no。

L 自己对这句话半信半疑。她有一个朴素的反驳：人前进是要靠摩擦力的，那摩擦真的被压缩之后，人怎么进步？

2. 摩擦不会消失，只会换一种形式

W 几乎是立刻反对了这句话，措辞罕见地直接：

这是一个“滑坡谬误”，是“刻舟求剑”。

他的论证是这样展开的：

第一，AI 现在压缩了某一类摩擦，不等于会压缩所有摩擦。
第二，每一次旧摩擦的消失，都会同时长出新摩擦。

举一个最具体的例子——编程：

• 旧摩擦：CRUD 模板代码很烦人。要么招个应届生写、付一两万月薪、还要沟通；要么自己耗时间。
• AI 解掉的部分：模板代码现在不成问题。指令给得好，几分钟搞定。
• 新摩擦：代码生成速度起飞了，怎么保证它正确？

旧的 code review、人工点页面、写测试用例——这些质量保证的机制，跟不上代码生成的速度。所谓“摩擦”，本质上就是“problem”；新摩擦就是新的 question。

AI 没有压缩摩擦，它只是把摩擦从一个地方搬到了另一个地方。

旧摩擦在写代码上，新摩擦在“如何在不看代码的前提下保证代码质量”上。
旧摩擦在挑商品上，新摩擦在“被算法投喂时如何保留判断”上。
旧摩擦在记知识上，新摩擦在“如何不让自己只会问 AI”上。

这个判断很重要，因为它直接反过来定义了这一代人的核心命题不是“享受被压缩的摩擦”，而是“识别新摩擦，并解掉它”。新摩擦没人替你解，AI 也不会立刻给你答案。

3. 散文病：当言辞代替思想

L 顺势提到了第二个分享者——罗振宇。

她形容自己最近的一种阅读体验：在看这些“思想嘉宾”的发言时，感觉像在看散文。每一句都很优美、都想摘抄，但摘完之后才发现“真正有意思的句子并没有那么多”。她把它形容为小时候老师让划好词好句的那种感觉——“天蓝蓝的，地绿绿的”。

W 说他没看到罗振宇的名字时，已经从字句的“taste”里嗅出来了：

罗振宇所有的句子都是 taste。从十几年前他做《罗辑思维》开始，就是这个味道。

这里他给出了一个很犀利的判断标准：

当一个搞 AI 的自媒体开始唱红歌、开始用人文社科守旧老师的腔调说话时，他的观点就已经失去价值了。

这跟政治时事博主一旦“变得很红”就开始失去棱角是同一件事。

L 在这里也补了一句很真诚的自嘲：她现在画下来的每一句“金句”，本质上和小时候摘抄“好词好句”没区别。优美和深刻不是一回事。

4. 警惕“思想的脂肪”

把这两段并起来看，会得到一种有用的判断框架：

• 真正的思想自带摩擦——它会让你不舒服、会让你停下来。
• **“思想的脂肪”**是滑顺的——它顺着你已有的认知滑下去，让你以为自己理解了什么，但其实只在原地。

李继刚那句“AI 压缩了你和世界之间的一切摩擦”恰恰是一颗思想脂肪：它太滑了，滑到你忘了去问“是哪些摩擦？被压缩到哪里去了？”

小结
在一个所有人都试图替你“解释 AI”的时代，最有用的本能不是赞同，而是先问一句：
“它说的对在哪里？错在哪里？我能不能给出反例？”
如果一个观点既经不起反例、又顺得让你想截图发朋友圈，它大概率是脂肪。

板块三：功利主义的边界

1. 一个反复被提起的问题

L 列出的第四个思考是：功利主义的背景下，如何让快乐不依赖于成功？

她对自己的这个问题不太满意——感觉自己以前也问过，也讨论过，最后还是回到这个评价体系里。原因是：她处于一个“既得利益者”位置，没法说这套规则坏，但也不能说它好。

她给出了一个非常有质感的细节——那一周她非常开心，因为同时发生了三件事：

1. 一篇合作论文得到了较好的评分，可能成为她的第一篇一作。
2. 一次赛事申诉成功了。她作为队长，跟另一方打了一周的文字仗——“累死了，理科生跟一群文科生说话”。
3. 学生账号上意外多了一笔小钱。

她说：第一种开心和“吃到好吃的、看到好看的”那种开心是不一样的——它有“质感”，有质量。但与此同时，她意识到这种开心是依赖于成功的。

如果只有成功才能快乐，那不成功的时候是不是就不能快乐？
而成功本来就是少数时刻。
这是不是一个伪命题？

2. W 的三段式答案

W 没有正面给出“不依赖于成功的快乐配方”，他给出的是一个三层结构：

第一层：知足。
要先满足于一些基本需求。比如赚钱这件事——他说他现在的收入水平已经够了，不会再去追求更多的钱，而是更关注“是不是用我喜欢的方式工作”“有没有足够的自由”“能不能做一些新尝试”。

第二层：在你想要挑战的地方，立更高的目标。
看似和第一层矛盾，其实是一个取舍。在欲望上要降；在投入上要专。“有点像谈恋爱——为了爱情而去付出、去奉献。”

第三层：学会接受结果。
做了很多事情之后，要知道你最后不一定会成功。很可能会失败。

痛苦有两种：得不到自己想要的，和得到了自己想要的。

W 在这里顺势举了两个体育人物。

3. 韩国电竞选手与日本的河村勇辉

第一个故事是韩国的英雄联盟选手 Faker（原话中 W 未直接点名，此处按语境补注）。这位选手拿了无数冠军，被问及“你是否觉得骄傲、满足”时，他的回答大致是：

冠军不是终点。它只是我一直在艰苦向上攀登这条路上，伴随出现的偶然收获。

第二个故事是 NBA 球员河村勇辉——一个 1.72 米的日本控卫，在日本联赛已经拿过 MVP，但在 NBA 只能拿双向合同，相当于“临时工”。

W 说他特意问 ChatGPT：他为什么不回日本做“鸡头”？回日本能赢球、薪水高、被人捧着。退而求其次去欧洲也行。

ChatGPT 给出的答案，被 W 进一步消化为一个“普通人”和“顶级运动员”的心态差异：

普通人会把困难视为困难，想绕过去、躲开它。失败概率高就放弃。
顶级运动员会把困难视为挑战，会跃跃欲试、会兴奋。 河村勇辉认为日本联赛太无聊了，他要去 NBA 挑战自己——哪怕几年之后他依然是临时工。

W 顺势把话题扩到了“国民性”上——他承认这是一种粗略的归纳，但很有意思：

中国舆论看待留洋球员：你打不好就回来，不要丢人现眼。成功是唯一的判断标准。
日本舆论看待河村勇辉：我们篮球水平本来就不行，黄种人体能不占优，我们知道这件事困难，但我们要去做——这种姿态会被尊敬。
日本热血漫画、甲子园、棒球教练训话里那种“中二”的台词——他承认看了之后“中年人的血都热起来了”。

这个故事和“功利主义”那个问题之间的连接是这样的：

如果一个人真的把“成功”作为快乐的唯一来源，那他就永远走不到河村勇辉那种姿态——因为站在 NBA 边缘做几年临时工，从功利的标准看就是“失败”。

4. 电车难题与器官移植：直觉的两次崩塌

W 把对话推向了功利主义最经典的反例。他先问 L 一个简化版的电车难题：5 个小孩 vs 1 个小孩，没人会知道是你扳的，你扳不扳？

L 的反应很真实——她说自己“会选择不管这件事情”。理由不是冷漠，而是：

在渡人之前要先渡己。 我不能确定我搬不搬得动那条轨道。
如果一定要二选一，我会“为有选择而苦恼”。

W 接着抛出第二个变体——这是哲学课经典的“器官移植难题”：

现在有 50 个等待器官的病人，刚好有一个健康的人和这 50 个人都匹配。你愿不愿意杀掉这个健康的人，把器官移植给那 50 个人？

按“5 大于 1”的功利主义算术，两个问题的答案本该一致。但 L 立刻退缩了——“不知道，我觉得这是过于介入他人的因果。”

W 总结得很冷静：

你在火车那个题目上还能进入“5 条命和 1 条命”的比较，但在器官那个题目上，直觉告诉你“这不对、太残忍了”。

这就说明，除了“50 条人命大于 1 条人命”之外，我们还有一些其他的、朴素的道德直觉在影响我们。
而功利主义最大的问题，正是它假定价值取向是单一的、可计算的。

由此他给出了对功利主义的二级批评：

功利主义会用一两条标准把人简化、矮化。
在相亲时只看“年薪百万”，就会忽略掉这个人是否尊重你、是否对家庭有责任感、是否对伴侣忠诚。
你以为自己在最优化，其实是在偷懒。
而且更糟糕的是——你没有办法真的把自己简化成一台功利的机器。 工作几年之后你就会发现：你那些被压抑的需求还在那里。

5. 把“功利”和“自我”放在同一张桌上

L 在这里追问了一个更接近真问题的版本：

追求功利的过程中，缺少自我的那一部分。

W 反将一军：那什么是自我？

L 给出的“自我”定义其实很朴素：不喜欢听这个课就可以不听，不用为了表演坐在第一排虚假地认真。 是对每件事最真实的感受。

W 没有否定这一点，反而绕回他自己的方法论：

• 不依赖成功的快乐，靠的是定义你的人生意义。
• 你怎么定义意义，就怎么定义成功。
• 当你能让你的成功定义在自己的价值观系统里更容易自洽，你的快乐就渐渐不依赖于“世俗成功”了。
• 他自己也在做这件事：给自己定读书目标，给自己感兴趣的事（AI 编程）投入更多时间。“我是渐渐迫使自己，让自己的快乐不依赖于成功。”

小结
功利主义不是一个需要被推翻的体系，而是一个需要被框定边界的体系。
它适合用来设“下限”——保证你的方向不至于太离谱。
它不适合用来设“上限”——上限要交给兴趣、热情、自洽的意义系统。
一个把自己人生交给单一指标的人，得到的生活大概率是没有尊严的。

板块四：未来与方向

1. 可解释性还重要吗？

L 把第五个问题抛出来时，是带着一种焦虑的：

我现在的专业偏统计方向，想往计算机走。但计算机方向太多了，发展太快了。
我有点看不清未来，最怕的是等我学会的时候，那个东西已经不需要让我学了。
而且现在很多以“实验结果”为导向的成就，已经变得不值一提——AI 跑 1000 次实验、把 1000 种方案都试一遍、得到比之前最好的还要好的结果。那我还要做什么？

她想做的事情，是用自己本科训练出来的统计直觉去赋能那些不可解释的机器学习黑盒——让它变得可解释一些。她的判断是：

AI 走到最后，可能还是回到管理学、基础学科的集合。最不被焦虑裹挟的方式，就是回到基础。

这个判断是有骨头的。换一种说法是：当一个领域急速扩张的时候，靠近“边界”的部分变化最快、最容易被颠覆；靠近“内核”的部分变化最慢、最值钱。 可解释性恰好处在 ML 的方法论内核。

2. 看不清的未来：苏茨克维与永远还有 50 年的核聚变

W 没有正面回答“该选什么方向”，他先承认了一个让人安慰的事实：

未来的方向是看不清的。 那些坐拥海量资金和技术人才的大公司看不清，世纪名校里的超级大教授也看不清。

NLP 的旧路线是一个最典型的例子——大语言模型直接把它整片整片地推平了。

他还举了核聚变这个经典反例：

1951 年说“50 年后能用”，2026 年还是说“50 年后能用”。
可控核聚变永远还有 50 年。

然后他提到 Hinton 和苏茨克维（Ilya Sutskever）：

当年他们选这个专业的时候，也看不清方向。
Hinton 在第几次“AI 寒冬”里坐了多少年冷板凳？无人问津。
但他们留下来了。

由此他给出一个反直觉但很合理的方向选择策略：

去研究“相对冷门、但比较有前景”的东西，比研究“已经被公认的热门”要好。

因为如果一个方向你能确定它会大热，别人也能确定，竞争会非常拥挤。
真正的 alpha 永远在“有人在做但还没有人讲清楚”的地方。

3. 选导师就像相亲：功利的下限与兴趣的上限

紧接着 W 给出了一个让 L 印象很深的类比——选导师/方向 = 相亲。

你找一个老公，不可能说“年薪必须 500 万、1000 万”——这是过度条件。
也不可能说“我就喜欢他，哪怕他没有正经工作”——这是不把自己的未来当回事。

合理的做法是设置一个功利的下限：比如月入 8000、年入 10 万。
在这个下限之上，再去看性格、相处、价值观。

把它平移到选研究方向、选导师上：

• 功利下限：学校的层级、导师的职称、文章数量、项目经费、研究方向的前景。
• 兴趣上限：你对这个方向有没有兴趣？有没有热情？这个导师把你当合作者还是干杂活的人？

W 引用了他之前分享过的一个 MIT 教授的话，那位教授的学生问他“怎么发 Nature / Science”，他不喜欢这个问题，但他还是回答了：

第一是兴趣——你要觉得这个题目有意思、想把它解出来。
第二是热情——你要能持续地做下去。
如果只有功利，做不到。

W 在这里索性把话挑明——他追问 L：“你为什么觉得功利不好？钱多很好啊，颜值高也很好啊。”

L 给出了一个很坦诚的回答：

功利对普通人来说是一条最直接的路径——它告诉你要干什么，你朝那个方向走就是了。
但是在朝着目标走的过程中，你其实不知道自己想要什么。
总会感觉，在追求功利的过程里，缺少了“自我”那一部分。

W 没有立刻反驳，他承认这一点——并且把这种“自我缺席”和上一节的功利主义批评连起来了：功利主义把人简化成了一台机器，但人不是一台机器。你那些被压抑的“自我需求”，最终会以另一种形式找上门来。

4. 比尔·盖茨与 13 岁的产品开发者

L 这周在读比尔·盖茨的自传《源代码》。她形容那种感觉是“恍若隔世”——盖茨那一代人最早接触电脑的时候，要靠打字机一样地刻字。她由此联想到：

我们现在抢 token 用，有点像他们当年抢“机时”。
但我真的非常佩服他们当时的想象力和创造力。
他们能在我这个年龄就孵化出未来这么大的商业版图。

她追问的是一个很硬的问题：这是教育环境的不同，是个人的天赋，是时代的机遇，还是中美体系的差异？

她也提到 AI 时代的另一个例子：那次大会上一个 13 岁的小女孩分享，10 岁起妈妈就要求她每天和 AI 玩四个小时，三年下来产品经验非常丰富，被互联网大厂认可。但 L 看了她做的产品（“青蛙背单词”“心情储蓄罐”）觉得“也比较普通”——她没 get 到这个小朋友被高度认可的点。

这里两个例子放在一起，其实指向了同一个判断：

整个计算机时代，从盖茨那时候开始，注定可以以 10 倍、100 倍的速度向前发展。
13 岁可以独立做产品，18–20 岁可以孕育商业蓝图。
在一个“无限可能”的时代里，最大的痛苦不是没有可能，而是知道有这么多可能、自己却被评价体系卡住。

L 自己说：“我现在每一年都是以之前 10 年的速度在增长。”

这是她这一段最有重量的话。

小结
看不清的未来里，可执行的策略只有三条：
一，回到内核——基础学科、可解释性、第一性的训练。
二，去冷门但有前景的地方——避开拥挤交易。
三，给功利设下限，把上限交给兴趣——这是抗脆弱的人生结构。

板块五：身体、情绪与休息

1. 分手与“大女主”时刻

L 在成长板块第一个谈的是分手。她自己用了一个非常坦白的形容：

我这次异常的冷静，甚至有一种**“大女主”的感觉**——我要找回主体性，要做更多更有用的事情，那种突然觉醒的英雄主义感。
出乎我自己意料。

但她也清楚地观察到了情绪的“代偿”：

那天之后的几天我都非常平静。但与此同时，回到宿舍之后，我很难再有更多情绪去和舍友讲话。
他们表现得很开心、很热闹，我不太想去接受他们的情绪，或者消化他们的情绪。
是一种淡淡的、顺顺的“冷漠”——但我并不觉得这是一个很丧的状态。

她给出的另一个观察很有质感：

我第一次深刻了解到什么叫**“缘分太浅”**——之前看起来多么深厚的一段感情，结局只不过是删掉了联系方式，仅此而已。
我不知道这该是一种“很潇洒的离开”，还是说“感慨人与人之间原来就这么浅薄”。
也有可能——还好没有太多的羁绊。异地是优点也是缺点。

2. 接不住情绪的人：W 的反向自白

L 提到了一个让她不太确定的问题：自己情绪不稳定的时候，对方是否会受到影响？

她的判断是：他接不住，所以一遇到他认为接不住、不想解决的问题，就用“分手”作为逃避方式。

她不太确定这是他的承受能力问题，还是自己的情绪太肆意。

W 在这里给出了这次对话里最坦诚的一段自白——他说他可以回答这个问题，并且从他自己的经历出发：

因为我是回过头去看自己好几次谈恋爱的时候，对方也发脾气。
事后看，他们的脾气都是“有理由的”，也并不严重。
但我当时就是会进入到一种“瘫痪”的状态。
我知道自己肯定有问题，我清楚意识到这个时候应该去道歉、应该做点什么——
但我整个人是瘫痪的，做不了任何思考、也做不了任何行动。

由此他给出一个比“对方脾气问题”更深一层的判断：

接不住情绪是一种身心的问题，不是一种品德问题。
我以前以为自己“不会经营亲密关系”“花心”“薄情”——后来才意识到，这是我身体的一个问题。
需要更多时间适应自己的精神状态，需要在以后跟伴侣很好地沟通——告诉对方我在什么状态下需要更多磨合、更积极的沟通。

他还举了一种反向的尝试——找完全不发脾气的对象：

完全不发脾气的人在我面前总是一副“受气包”的样子。
反而让我觉得自己是不是个大暴君、是不是在 PUA 别人——
这种时候我又想逃避了，“我不要做坏人”，分手算了。

3. 救人先救己：一段亲缘关系里的那条边界

W 顺势讲了一个延伸案例，是他身边一位很亲近的家人——单纯的亲缘关系。

她长期被一种剧烈的情绪起伏困住——情绪高涨时会失控地消费，情绪低谷时会有很重的自伤想法。

她引发了我第一次明显严重的焦虑发作。那一次之后，我自己也没有再出现过那么严重的发作。

他选择的处理方式是：

我让她不要再联系我了，我也不再联系她。
因为我们两个都管不住自己的情绪。
她管不住自己，我也有自己的边界——
我自己情绪不好的时候，会主动减少跟别人的接触。

这一段最有重量的判断是：

我有一段时间会觉得自己是不是太无情了——抛弃了一个在挣扎中的、脆弱的人。
后来我发现，并不是。救人先救己。

就像飞机上那句话——在你给别人戴上氧气面罩之前，你要给自己先戴上。

他对 L 的处境给了一个收束式的安慰：

我也不好说你们分手是对是错。
像我说的，有可能一个礼拜之后他回过来又找你，你们又甜甜蜜蜜，把这段时间忘掉。
顺其自然吧，他不是坏人。如果他是 PUA 的渣男，我肯定让你跟他分手，把腿打断也要让你跟他分手。
但他明显不是。那你们两个互相折磨吧——爱情的苦本来就是要吃的。
它不仅是苦，它也有甜。你回想一下，你们之间肯定有很多甜蜜、很温暖的时刻——这些都不是假的。

4. 把多梦当成身体的信号

第二个具体的话题是睡眠。L 不失眠，但多梦——而且很多是让她紧张害怕的噩梦。她不确定影响因素是什么，但很多天早上起来心情都不好。

W 给了她一个生活级的常规建议：固定饮食、好好吃睡、多运动、跑步。然后他自然地接到了自己的状态：

我最近也有点状态不好。
工作压力、天气变化加在一起，有点 emo。
我自己感觉抑郁和焦虑有点复发的前期征兆——
我已经跟公司说了，请两天假休息一下，看恢复情况。

他这一段最珍贵的不是请假这个动作，而是请假背后的那种“成熟的悲观”：

我做好了最坏的打算——大不了就离职。
我觉得我做事情还是 OK 的，互相磨合嘛，磨合不了就撤。
我不会把它当作一种失败。

以前我把自己逼得太狠了。 觉得压力是要自己管理、自己协调的。
前些年有一次，被调到一个新项目，我不情不愿地去做那个事情，但又不许自己做不到很高的标准——非常拧巴，最后把自己搞垮了。

现在我把身体的信号真的当成信号——
多梦、早醒、emo——这些不是矫情，是身体在提醒你不要再逼迫自己了。

他把状态调整放在了人生策略的位置上：

状态不好就请假调整。
调整不好就跟领导聊。
聊不通就离职。
反正有钱吃饭，找下一份工作我也有信心。

这是一种把“身体优先”内化成默认设置的生活方式。它和板块二里“功利主义不能简化人”的判断，其实是同一件事：你不是一台 365 天保持高产的机器。

5. 浪费时间的伦理学

最后一个话题，由 W 抛出来：如何浪费时间？

他特意解释为什么不用“如何休息”这个说法：

“如何更好地休息”——这个表达本身就有问题。
它暗含了**“为了更好的工作”**。这就又回到了“不要浪费时间”，又把休息变成了一种压力。

L 的回答非常具体：

这个学期课多。但单双周里有一天下午一二节没课，那时候我就直接睡到下午。
上周我梦到自己起床迟到了——下午五六节没课、七八节有课，4 点要上课。我梦到睡到五六点，天都黑了，我一直问朋友“老师有没有点名”——把我吓醒了。结果醒来的时候刚好 3:40。

下午睡觉是我最不受打扰的时候。早晨睡得晚的话宿舍会陆陆续续起床有声音，晚上早睡大家也有声音。

五一不出去旅游，下意识第一反应是“太好了，抓紧时间干活学习”——
转念一想，怎么天天这么 PUA 自己。
然后她想去徒步一天，去附近的山水间走一走。

W 给出他自己的版本：

我自己是状态好的时候，每天都在学习、每天都在干活。
状态不好的时候——
看一下网络小说，昨天还拿抖音回来刷——发现抖音没有以前那么好玩了，为什么？不知道为什么。
刷了一会就不刷了。
喝了一次糖水，减肥也不减了。

低谷的时候怎么过？他给了一个时间维度上的对照：

更早几年里也会周期性地低谷，那时候是抑郁情绪，没到抑郁的症状。
现在我会把身体的这些信号真正当成信号——不要再折腾自己了。

待会开完会也去锻炼一下身体。我觉得还蛮乐观。

小结
“浪费时间”和“休息”这两个词，背后是两种不同的人生姿态。
叫它“休息”，意味着它是为下一段工作做准备——它仍是工作的附庸。
叫它“浪费时间”，意味着它自己就是目的——刷一会抖音、喝一杯糖水、睡一个不被打扰的下午、徒步一天山水，这些事情本身就是它们自己。

一个能心安理得“浪费时间”的人，比一个会“高效休息”的人更接近自由。

结语：在循环之上

把这五个板块并到一起看，这场对话的内核其实只有一个判断：

在 AI 加速的时代，人最重要的能力不是跑得更快，而是站到循环之上。

• 在编程这件事上，On the loop 意味着你不再纠结某一行代码，而是去定规则、定边界、定 benchmark。
• 在思想这件事上，On the loop 意味着你不被“AI 压缩了一切摩擦”这种顺滑句子滑走，而是回头去问“哪些摩擦消失了，哪些新摩擦长出来了”。
• 在功利主义这件事上，On the loop 意味着你不被任何单一指标矮化成机器，而是允许自己有“不可计算”的需求。
• 在选方向这件事上，On the loop 意味着你不挤在公认热门里，而是给功利设下限、给兴趣留上限。
• 在身体和情绪这件事上，On the loop 意味着你不再扮演 365 天高产的机器，而是把身体的信号当作真正的信号——该请假就请假，该浪费时间就浪费时间。

这场两个人的对话里，留下了许多没有解决的问题——L 不确定可解释性是不是值得做一辈子的方向；W 不确定 Cursor 3.0 和 Codex 谁才是终局；他们都不确定自己处理情绪的方式是否足够好。

这些不确定性本身就是新摩擦。 AI 没有把它们压缩掉，只是把它们换了一种位置长出来——长在每一个想认真生活的人面前。

我们能做的，不是消灭它们，而是认领它们。

我发现 AI 编程时代真正稀缺的不是代码，是判断力的轨道

你肯定听说过一句话——“AI 来了，程序员要失业了”。这句话火了三年，讲的人不少，信的人也不少。但真正在工程一线的人都知道，这件事比这句话复杂得多。

今天我想跟你讲一个非常有意思的故事，以及一个你听完之后可能会重新理解“工程能力”这四个字的概念。这个概念叫 Harness Engineering——姑且翻译成“驾驭工程”。它来自 OpenAI 今年二月发的一篇技术博客，但这件事的意义远不止一家公司的内部实践。我认为，它揭示了 AI 时代软件工程整个学科的重心迁移。

一、先讲个有意思的故事

先说故事本身。OpenAI 有一个团队，用了大约五个月的时间，搭建了一个几乎完全由 Codex——就是他们内部的代码生成 agent——写出来的仓库。从应用代码到测试，从 CI 配置到文档，从可观测性到部署脚本，整套东西基本上都是 agent 产出的。人呢？人不直接写代码，人负责“指挥”。

这个团队估算，同样的功能量，他们大约只用了“人手写代码”时代十分之一的工作量。换句话说，他们用一成的人力就搞定了。

他们在文章里甚至写了一句特别提气的话——“Humans steer. Agents execute.”——人来掌舵，agent 来执行。

你第一反应可能是：哇，这是不是说 AI 真的可以取代程序员了？别急，故事的关键不在这里。

故事的关键在于：他们一开始搞得很烂。 真的很烂。早期 agent 的产出乱七八糟，Bug 频出，代码风格各异，到处都是“模式复制”——agent 把一段看起来还行但其实有问题的代码疯狂复制到几十个地方。团队每周五要花 20% 的时间专门清理 agent 生成的“AI slop”——就是那种看着不错、细看有问题的垃圾代码。

然后他们开始反思：为什么 agent 表现这么不稳定？

这里有一个非常关键的转折。他们没有把锅甩给“模型不够强”，也没有说“这活儿 agent 干不了”。他们问的问题是——我们到底缺了什么能力，才让 agent 干不好？

这个问法一换，一切都不一样了。

这里有一个非常有意思的认知切换。以前人看到 AI 代码写不好，第一反应是“模型不行”，觉得要换模型、要等下一代模型更强。这种思路把所有希望寄托在模型身上，工程师只是“等待升级”的旁观者。OpenAI 这群人换了个问法——不是问模型行不行，是问我们给模型的环境行不行。这一问，主动权就回到了自己手上。

这是我在这篇文章里看到的最聪明的地方。它不是技术细节的聪明，是思考方式的聪明。

二、核心发现：瓶颈已经变了

OpenAI 通过这个项目得出一个非常有洞察力的结论。我再给你提炼一层——

过去我们做软件工程，瓶颈主要在“写代码”。团队能多快交付、能做多大系统，基本取决于工程师能写多少行有效代码。所以我们发明了各种加速写代码的工具：更好的 IDE、更好的语言、更好的框架、更好的库。一切都围绕“让代码被更快地写出来”。

现在 agent 把“写代码”这件事的成本降到了接近零。那瓶颈跑到哪里去了？

跑到判断力那里去了。

想一想传统软件工程里，人的“判断力”承担了多少工作。一个资深工程师 review 代码的时候，他真正在判断的不是语法错误——那种事 linter 就能做——他在判断的是：这段代码有没有违反团队的隐性约定？会不会把某种坏模式扩散出去？踩没踩到那种“平时看不出问题但特定场景会炸”的坑？从长期看会不会变成技术债？

这些判断过去是够用的，因为代码产能本身就是瓶颈，判断力虽然稀缺但供给勉强跟得上。agent 把代码产能翻了十倍之后，判断力立刻变成了最紧的那根线。

OpenAI 在文章里用了一个词：他们最想最大化的稀缺资源，是人的时间和注意力。

这个表述特别精准。不是“人的能力”，是“人的注意力”。能力已经被 agent 放大了，放大之后剩下需要小心分配的，是那一点点珍贵的注意力。

这就引出了 Harness Engineering 这个新概念。

顺着这个逻辑你会想到一个有意思的问题——如果判断力变成了新的瓶颈，那一个工程师、一个团队最该优化的，就不是“我们今天写了多少代码”，而是“我们把多少判断力固化下来、不再依赖于某个人的脑子”。前者是工作量，后者是资产。这两者的差别就像“打工”和“建厂”的差别。打工赚的是当天的钱，建厂赚的是之后每一天的钱。

三、Harness Engineering 到底是什么

Harness 这个词来自“马具”——就是缰绳、挽具、轭、车辕这些东西。单独一匹马是有力量的，但那股力量是发散的、甚至危险的。给它装上 harness，马才变成了可用的生产力——力量被约束、方向被确定、状态被监控。

软件工程里的 harness 是同样的逻辑。agent 本身是一股很大的力量，但这股力量天生缺方向、缺记忆、缺自纠偏。你需要一套系统来把它的力量转化成可用、可复用、可持续的产出。这套系统就是 harness，设计这套系统的工程叫 Harness Engineering。

那 Harness Engineering 具体在设计什么？我来给你提炼最关键的四件事：

第一件事：约束。 告诉 agent 什么不能做。但是——这里是最容易搞错的地方——文档不是约束，能阻止违反的才是约束。 你写一份“不要直接调数据库”的规范贴在 Confluence 上，那叫建议。你配一条“调数据库就 CI 挂掉”的规则，那才叫约束。前者依赖注意力，后者依赖系统。注意力会分心会疲劳，系统不会。

OpenAI 自己就吃过这个亏。他们一开始写了一份巨长的AGENTS.md，想把所有规则塞进一份说明书。结果呢？上下文被挤爆、内容迅速腐化、校验不了谁还有效。后来他们改成AGENTS.md只做目录，规则拆到结构化文档里，真正起作用的是 linter、CI 和 structural test。这才跑通了。

第二件事：验证。 告诉 agent 它做得对不对。关键是要让 agent 自己能走完验证路径。怎么做？把原本给人看的 UI、日志、指标、trace 接到 agent 能直接消费的地方。让 Codex 自己能复现 bug、自己验证修复、自己对比性能目标。你只要有一个只能靠人眼判断的环节，那就是瓶颈；而瓶颈一定会被 agent 的吞吐反向压垮。

第三件事：反馈。 让偏差尽早暴露。这不只是“跑测试”这么简单。OpenAI 搞了一个特别聪明的动作——他们设置了后台 Codex 任务，定期扫描代码库偏差，更新质量评分，自动发起针对性的重构 PR。收垃圾从“资深工程师英雄主义”变成了“系统能力”。

这件事为什么重要？因为全 agent 代码库一定会复制模式，好的模式会被复制，坏的模式也会被复制。熵一定增加。如果你不把“降熵”做成系统，就只能靠人拼命救火，迟早累死。

第四件事：沉淀。 把一次经验变成资产。这是四件事里杠杆最大的一件。你想想看，一个 bug 修完之后，你做了什么？大部分人就修完了事。但一个会做 Harness Engineering 的人会问一句——这件事属于约束没做好、验证没做好、反馈没做好，还是沉淀没做好？ 然后他会强迫自己至少补一项资产：一个 CI 规则、一条 linter rule、一个 structural test、一份 golden principle。

哪怕很小。只要它能让同一个坑下次不用再踩，就值得做。

我要特别说一句——这四件事的顺序不是随机的，是有递进关系的。约束告诉系统“不该做什么”，是第一层护栏；验证告诉系统“做对了没有”，是第二层护栏；反馈让偏差能被自动捕捉并修正，是第三层护栏；沉淀把这次的经验变成下次的先验，是第四层护栏。前三层在“这一次”工作，第四层在“下一次”工作。只有四层都做到位，你的系统才算真正“会自我成长”。大多数团队只做了第一层甚至半层——写个规范贴在 wiki 上，然后就没有然后了。这是典型的“半截 Harness”，上去就翻车。

四、类比一下你就明白了

到这里你可能还觉得这些东西有点抽象。我给你打个类比——

你可以把过去的程序员想成一个工匠。工匠的价值在于他的手艺——他能雕多好、多细、多快。一个工匠一生能做多少东西，取决于他自己的双手。

现在 agent 相当于给这个工匠配了无限多的学徒。学徒手艺惊人，但没经验、没规矩、不认识这家作坊的老规矩。工匠面前有两个选择——

选择 A：工匠继续当工匠。自己做得飞快，一个人顶过去五个人，但因为学徒帮不上忙，瓶颈还是他自己的双手。

选择 B：工匠升级成总工程师。他不再亲自雕，而是设计一套“学徒使用手册+质检流水线+错题本”，让无限多个学徒都能按这套系统干活。他自己动手的时间少了，但系统输出的东西多了十倍、百倍。

Harness Engineering 就是选择 B。它要求工程师从“做代码”升级到“做系统的系统”——做一个让 agent 能持续产出正确代码的系统。

这个升级不是一朝一夕的事，它要求工程师改变自己的工作重心，改变自己的能力结构，甚至改变自己的成就感来源。你不能再靠“我今天写了多少行代码”获得满足感，你得靠“我今天沉淀了多少可复用资产、堵住了多少潜在偏差”获得满足感。

这一点对资深工程师尤其不容易。他们过去的竞争力很大一部分就来自于那些“只在脑子里”的隐性判断——显性化了之后，等于把自己的护城河主动填平。心理上是很难过这道坎的。

但是——时代会逼着所有人过这道坎，早过比晚过好。

五、为什么这件事特别反直觉

讲到这里我想插一段，因为 Harness Engineering 这件事有一个非常反直觉的地方，很多人卡在这里就过不去了。

反直觉在哪里？在于——做 Harness Engineering，短期看上去是在“浪费时间”。

你想啊，工程师 A 天天在敲代码、交功能，老板看得见、同事看得见、产品经理看得见，朋友圈也方便发。工程师 B 呢？他每天在写 CI 规则、调整项目结构、重构 agent 的工作流、沉淀质量检查清单。他这一周可能一行业务代码都没写，但他把团队下一个月的返工量降了一半。

短期看，A 的工作可见性高、显性产出多；B 的工作可见性低、当下好像没干啥。如果团队的评价体系还停留在“看谁交付了多少 feature”，B 就会被严重低估。

但长期看，时间一拉长，B 创造的价值是指数级的。因为 A 做的是“一次性劳动”——他这周写的代码，下周可能还得让别人 review、改、维护；而 B 做的是“结构性劳动”——他沉淀下来的规则、流程、自动化，会在之后每一次类似场景里都发挥作用。

这个事情的难点不在技术，在组织认知。很多团队讲起来都支持 Harness Engineering，但评价体系还是按旧的逻辑在运转——周报里看交付量、OKR 里看 feature 数。这种组织就算有人想做 Harness Engineering，也会被逼回去做一次性劳动。

所以我给团队负责人的建议是——如果你想让 Harness Engineering 在你的团队里真的发生，你必须亲自把“沉淀资产”写进评价指标。 不然没人愿意去做那些“当下看不见回报”的事。这是组织层面的闭环，不能只靠工程师的自觉。

有意思的是，一旦这个闭环建立起来，你会发现团队里最擅长 Harness Engineering 的那批人，往往不是代码敲得最快的人。他们是那些思考深、有耐心、愿意把一件事琢磨透然后系统化的人——而这种人过去在“交付 KPI”的压榨下，反而一直是被边缘化的。

Harness Engineering 的兴起，可能会让这类人重新成为团队里最有价值的人。

六、给你几条可操作的建议

讲到这里，你可能会想：“这个道理我懂了，那我具体该怎么做？”

我提炼三条可直接上手的建议——

第一条：每次出问题之后，问自己那个四选一的问题。 约束、验证、反馈、沉淀，这次出问题到底是哪一层没做好？然后哪怕只补最小的一片——一条规则、一个测试、一份 checklist——也去补。积少成多。三个月下来，你会发现你的系统变成了一个会自己变强的东西。

第二条：开始前先写非目标，而不是只写目标。 大部分人做需求、做设计，只写“我们要做什么”；更有经验的做法是同时写“我们明确不做什么，以及哪些写法虽然能跑但不希望以后被复制”。前者指方向，后者划边界。边界对 agent 时代格外重要，因为 agent 不会自动识别边界——它只知道哪里有例子就去那里学。你不划，它就自由发挥。

第三条：把 repo 当成你们团队的知识的唯一来源。 那些只在 Slack、Google Docs、会议口头共识里的知识——对人勉强够用，对 agent 全是空白。agent 看不见的知识，就等于不存在。所以你有多少隐性知识没进到 repo 里，你的 agent 表现上限就被卡在哪里。把知识 repo-local 化、versioned 化、discoverable 化，这是 AI 时代的组织基本功。

我再追加一条更进阶的建议——

第四条：审视自己的技术设计文档是给人看的还是给 agent 看的。 大部分工程师写的设计文档都还是“essay 风格”：长段落、叙事、讲权衡、讲故事。这种风格给人读还行，给 agent 读就是灾难——agent 不会抓中心思想，它只会按你写下来的内容去执行。agent 时代的技术设计文档应该更像“操作手册”：目标和非目标要分清，模块边界要明确，依赖方向要画出来，不变量要列清单，数据边界要划出来，验证路径要指明，观测点要标注，回滚策略要写出来，最后还要加上那句最关键的——哪些写法虽然能跑但不希望以后被复制。

这种文档写起来比散文累得多，但每一条都是能被 agent 直接消费的“指令”，不是“建议”。文档的形态也必须跟着工程范式一起变。

七、最后一层：能力的分化

我想在最后留一个思考给你。

如果 Harness Engineering 真的成为未来工程能力的核心，那会发生什么？

会发生一件事——工程师群体会出现一次快速的能力分化。

一部分人还会停留在“我用 Cursor 写代码很快”这个层面。他们的生产力确实会比不用 AI 的时候高，可能高到三倍五倍。但他们还是在做“一次性劳动”——写代码、修 bug、review PR。这些劳动的单位价值会随着 agent 能力提升而持续下降。

另一部分人会转向“设计让 agent 工作得好的系统”。他们的产出单位价值会越来越高，因为他们做的每一件事——每一条 CI 规则、每一个 structural test、每一份约束文档——都能被复用无数次。一件事写一次，帮你拦一万次偏差，这叫资产。一次性做完的事叫耗品。

这两种人的长期杠杆率差异会是指数级的。不是 2 倍、5 倍，是 10 倍、100 倍。

这就是 AI 时代工程能力的真正分水岭。它不是“用不用 AI”的分水岭——那个问题已经过时了——它是“有没有能力设计 agent 的工作系统”的分水岭。

结语

如果让我用一句话总结这整篇文章，我会这么说——在 AI 时代，“做了什么事”越来越不值钱，“把这件事变成系统以后就不用再做了”才值钱。

一次性劳动是耗品。可复用判断力是资产。过去这两种东西的价值差没那么大，因为人的时间是主要瓶颈，大家不得不做大量一次性劳动。agent 打破了这个限制之后，这两种东西的价值差一下就拉开了。

Harness Engineering 最深的含义，就是教会一个工程师如何把自己的判断力从“一次性”变成“可复用”。懂这件事的人，未来十年会越走越轻；不懂这件事的人，会发现自己越做越累、却越做越不值钱。

这不是一篇吓唬人的文章，这是一篇提醒你“时间窗口还开着”的文章。这个窗口不会永远开着。但你现在开始想清楚、开始动手，还来得及。

当你愿意花一点时间把那些“原本只能靠自己盯着”的判断搬出脑子、搬到系统里，你就已经站在了正确的那一侧。

软件工程的重心正在悄悄迁移

一个有意思的现象

我最近注意到一件有意思的事。过去三十年，软件工程这个学科一直有一个隐含的假设：工程能力的上限，大致等于工程师写代码的速度和质量。我们讨论编程语言、讨论设计模式、讨论架构、讨论 review 制度，几乎所有的讨论都围绕着同一个核心：如何让人写出更多、更好、更可靠的代码。

这个假设正在松动。

过去一年，我身边最好的团队开始花越来越多的时间做一件看起来不像“工程”的事：他们不再主要写代码，而是在搭建一种让 agent 能稳定产出代码的环境。他们写测试、写 linter、写 CI 规则、写结构化文档、写可观测性管道。他们做的每一件事，都不是在直接产出功能，而是在定义一个系统——在这个系统里，agent 能够被引导、被约束、被验证、被纠偏。

这件事一开始看起来很奇怪。如果 agent 已经能写代码，为什么还要花这么多时间去准备它的工作环境？为什么不直接让它写？

但如果你观察得久一点，你会发现这些团队的产出比那些只是“让 agent 写得更多”的团队高得多。它们不是更快，而是可持续地更快。

这个观察很重要。它指向一个我花了很长时间才想明白的结论：软件工程的重心，正在从“写代码”迁移到“设计让代码被正确地写出来的系统”。

我知道这句话听上去像一句话术，像某种被反复说过的“范式转移”口号。但它不是。它是一个有具体后果的判断，一个会改变你接下来每天做什么、关心什么、积累什么的判断。真正被迁移的不是某种技术栈，也不是某套工作流，而是“工程能力”本身在什么样的活动里被培养、被体现、被兑现。

这种迁移在历史上发生过几次。一次是从汇编到高级语言——那次迁移让工程能力的重心从“熟悉机器指令”变成了“熟悉抽象结构”。一次是从本地部署到云和分布式系统——那次迁移让工程能力的重心从“一台机器的优化”变成了“一整套服务的编排”。每一次迁移都让上一代最擅长的那批人突然发现，自己的竞争力不再完全适用，必须重新学一次。

我有理由相信，我们现在正处在类似的节点。

为什么过去的直觉失效了

过去我们对生产力的直觉大致是这样的：一个工程师一天能写多少行代码，就决定了他一天能创造多少价值。这个直觉不完全对，但它大致成立——因为代码产能确实是大多数软件项目的主要瓶颈。

然后 agent 来了，这个直觉突然失效了。

一个使用 agent 的工程师，代码产能可以是原来的十倍、二十倍。但很少有团队真的跑出了十倍的产出。大部分团队跑出的是三倍、两倍，甚至更糟——一开始快，过几个月反而慢了下来。有些团队的 bug 率、技术债、重复工作量反而在上升。

为什么？

因为产能从来不是真正的瓶颈，我们只是以为它是。真正的瓶颈，是判断力。

想一想传统软件工程里“判断力”承担了多少工作。一个资深工程师在 review 一段代码的时候，他不是在“检查有没有语法错误”——那种事 linter 就能做。他真正在做的，是判断这段代码有没有违反团队的隐性约定、会不会把某种坏模式传播下去、有没有踩到某个只有在某种特定场景才会出问题的坑、长期看会不会变成技术债。

这种判断力是极其稀缺的，而且它只存在于少数人的脑子里。过去之所以没成为瓶颈，是因为代码产能更稀缺——判断力虽然也稀缺，但供给勉强够用。agent 把代码产能拉高了一个数量级，判断力立刻变成了最紧的那根线。

这是一个非常经典的瓶颈迁移。它提醒了一件很重要的事：你一旦解除了某个瓶颈，系统的真正瓶颈就会显形，而那个新的瓶颈通常藏在一个你原本没怎么认真对待的地方。

这也是为什么“AI 时代是不是要失业”这个问题问得不太对。它问的方向不对。真正该问的问题是：当代码产出变得便宜，什么东西变贵了？答案是判断力。判断力变贵之后，怎么分配和规模化这种稀缺资源？这才是更有意义的问题。

顺着这条线想下去，你就会意识到软件工程学科接下来很多年的真正议题，大概率会围绕“判断力的规模化”展开。怎么把一个人的判断力固化成代码？怎么把一个团队的共识固化成自动化的检查？怎么让 agent 在做决策时能访问到组织积累下来的那些“这种情况下应该这样做”的先例？这些问题从 2020 年的角度看会显得奇怪——那时代码产能还是瓶颈，没人会专门花精力“规模化判断力”——但从 2026 年的角度看，它们就是这个学科最中心的问题。

一个新词：harness

OpenAI 最近写了一篇文章，给这种新的工程实践起了个名字，叫 harness engineering。我觉得这个词起得很好。

harness 这个词的本义是马具——那些把一匹马的力量转化成有方向、可控、可持续劳动的装置。缰绳、挽具、车辕、轭。如果只有一匹马，没有这些东西，马的力量是发散的，甚至是危险的。加上 harness，马才变成了一个可用的生产力单位。

agent 在某种程度上很像一匹马。它有力量，有速度，但没有方向，没有自控，也没有记忆。你要让它真正为你干活，就必须给它一套 harness——那套能把它的原始能力转换成可用产出的系统。

harness engineering 就是在设计这套系统。它包括什么？OpenAI 自己把它拆成了几层：约束、工具、反馈、记忆。我觉得可以用更抽象一点的语言概括：你要告诉 agent“不该做什么”，要给它“能做什么”的手段，要让它“做了之后能知道做对没有”的信号，还要让它“这次做错了下次能改进”的机制。

这听起来像常识。但有趣的地方在于，这件事过去根本不需要做。过去的工程师自带 harness——他们的经验、他们的品味、他们上次被骂过的记忆，构成了一套隐性 harness。这套 harness 装在他们脑子里，你看不见，但它一直在工作。

agent 没有这套 harness。你想让它工作，必须把 harness 外化成系统——变成代码、变成规则、变成测试、变成文档、变成流水线。

这就是 harness engineering 最本质的那件事：把原本存在于人脑中的隐性 harness，外化成系统可执行的显性 harness。

这个动作听起来平淡，但它触及了一个非常深的问题：大多数工程师的竞争力是从哪里来的？仔细想一下，你会发现它不是来自他们“知道”什么——知识在互联网时代早已免费了——而是来自他们“会判断”什么。他们知道什么时候该规范化、什么时候该 hack、什么时候应该重构、什么时候不要动。这种判断往往讲不清楚，也没法完整地写下来。它存在于一种只有经验能锻炼出来的直觉里。

harness engineering 要求你做一件过去几乎没人认真做过的事：把直觉写下来。 不是写成“设计原则”这种不会被执行的纸面规则，而是写成能拦住错误、能推动纠偏、能被系统反复执行的形态。这件事的难度，远大于大多数工程师的预期。也正因为它难，它才成为新的能力分水岭。

它在改变什么

这种迁移一旦发生，会连带改变很多东西。我挑几个最重要的讲。

首先，它改变了“好代码库”的定义。

过去我们说一个代码库好，通常是说它“对人友好”——结构清晰、命名合理、注释得当、新人看得懂。现在开始有一种新的标准在出现：一个好的代码库首先是 agent 能独立理解并推理的代码库。

这个标准听起来和“对人友好”差不多，但实际上要求更严格。人可以靠口头沟通、靠私下问、靠经验脑补来弥补文档缺失；agent 不行，它只能看见仓库里写着的东西。所以那些“只存在于某个资深工程师脑子里”的知识、“只在 Slack 里讨论过”的约定、“只在某次设计评审上口头说过”的边界——这些对人来说勉强够用的知识，对 agent 都是空白。

推论是很明确的：知识是否是 repo-local 的、versioned 的、discoverable 的，决定了 agent 的表现天花板。

其次，它改变了工程的主产物。

过去工程师的主产物是代码。现在 agent 可以写代码了，你的主产物开始往另一个方向迁移——往上游迁移，迁到约束上。

这个变化不是说代码不重要了。代码当然还重要。但代码变成了某种“下游产物”，是系统的输出，而不是系统本身。真正的系统是你搭起来的那个 harness——它决定了下游产出什么样的代码。

一个工程师的杠杆率，越来越取决于他能不能让自己的工作“被写一次就能被使用无数次”。一条好的 CI 规则能拦住一万次错误。一个好的 structural test 能阻止某种坏模式的扩散。一份好的架构文档能让 agent 在下一次需要做类似决策时不用重新推理。这些都是可复用资产。

相反，亲自修一个 bug、亲自 review 一个 PR，这些是一次性劳动。它们在 agent 时代的性价比正在快速下降。

第三，它改变了思考的单位。

如果你还在思考“怎么把这个 prompt 写得更好”，你就还在“一次性生成”的心智模型里。agent 的本质不是一次性生成器，它是一个循环——它推理、调用工具、观察结果、再推理。真正产生效果的单位不是一条 prompt，是一个 loop。

这个区别很大。一条 prompt 是静态的，一个 loop 是动态的。你在设计 loop 的时候，你不是在告诉 agent“做这件事”，你是在设计“它做错了会怎么被发现、怎么被纠正、怎么被提醒下次别再这样”。这种思维方式接近于 control theory，而不是 prompt engineering。

第四，它改变了流程的逻辑。

以前的工程流程是为“修正很贵”的世界设计的。因为一旦一段代码合进了主干、出了问题，回滚成本、影响面、排查成本都很高，所以我们有了两人 review、阻塞式 merge gate、完整的回归测试门禁。这些流程的存在是合理的——它们对应着一个特定的成本结构。

agent 时代的成本结构变了。修正变得很便宜——agent 可以连夜跑，可以批量重构，可以自动修复 flaky test。相比之下，“等待”变贵了——每一次阻塞式 review 都在消耗 agent 的带宽，消耗整个系统的吞吐。

所以你会看到一些先行的团队开始做看起来“违反直觉”的事：更短命的 PR，更少的阻塞式门禁，更多的“先合再修”。如果你还停留在前一个成本结构里，你会觉得这是在放弃质量。但如果你理解了新的成本结构，你会意识到这不是放弃质量，而是把质量的维持工作从“入口处的一次检查”转移到了“持续的后台纠偏”。这是两种不同的质量观，它们服务于不同的世界。

一个有用的推论

这里有一个推论，我觉得非常重要，虽然 OpenAI 那篇文章没有直接说：未来最稀缺的工程师，可能不是那个手写代码最快的人，而是那个最会设计 harness 的人。

这两种人在过去的评价体系里看起来差不多，因为过去大部分工程师都不得不自己写代码。但在未来，当 agent 承担了主要的代码产出之后，这两种能力会分化得非常厉害。一个能把判断力固化成系统的工程师，和一个只会把判断力用在一次性劳动上的工程师，长期的杠杆率差距会是指数级的。

举个类比。古代的商人，最值钱的能力是会不会讨价还价、会不会砍价、会不会挑货；工业时代的商人，最值钱的能力是会不会设计供应链、会不会管库存、会不会做分销体系。同样是“商人”，但这两种人面对的问题完全不一样。

软件工程正在经历类似的分化。我们这个时代的“会讨价还价”是“会写代码”；我们这个时代的“会设计供应链”是“会设计 harness”。这两种能力不是互斥的——你还是要会写代码，就像商人还是要懂货——但真正决定你长期价值的，是后者。

这件事的难度

我想诚实地说一句：harness engineering 是很难的，比大多数人以为的难。

它难，不是因为技术复杂，而是因为它要求你把那些你自己都没意识到的隐性判断，一条一条翻出来写成规则。这件事情对资深工程师来说尤其反直觉——他们的竞争力之一恰恰是这些隐性判断，现在你要他们把竞争力显性化、组织化、变成组织能力。心理上很难接受。

它还难在另一个地方：它不是一次性的工作。agent 和业务都在演化，你的 harness 必须跟着一起演化。一条今天写下来的 CI 规则，三个月后可能就过期了。所以 harness engineering 不是“搭完就完事”，而是“持续搭建并持续维护”。

但正是因为它难，才值得做。简单的事情护城河浅，难的事情护城河深。一个团队如果能认真做 harness engineering，它会获得一种几乎不可被快速复制的能力——不是因为别的团队学不会，而是因为别的团队意识不到这件事的重要性。等他们意识到的时候，你已经领先了太多。

如果只带走一件事

如果让我用一句话总结我对这件事的理解，我会说：我们正在见证软件工程的重心，从“把代码写出来”迁移到“把让代码被正确写出来的系统搭起来”。

这不是一个温和的升级，而是一次心智模型的换轨。过去我们关心的是“你能不能写代码”；未来我们关心的会是“你能不能设计一个让别人（和 agent）写出正确代码的环境”。前者是工匠的能力，后者是建筑师的能力。

一个工匠一生能盖多少房子，取决于他的手艺。一个建筑师一生能盖多少房子，取决于他能把多少人的手艺组织起来。这两种人的规模上限，差了不止一个数量级。

软件工程未来最有价值的人，会是那些想清楚了这件事、并且愿意把时间投到看起来“不像写代码”的地方的人。他们不会在朋友圈秀每天敲了多少行代码，他们会在安静地搭建那些让整个团队、整个仓库、整个 agent 舰队都能跑得更稳的轨道。

这些轨道不性感，但它们决定了所有跑在上面的东西能跑多远。

一点提醒

最后我想加一个提醒，因为这类文章太容易被误读。

我说“工程重心正在迁移”，不是在说“写代码不重要了”。恰恰相反——要设计好 harness，你必须对代码有非常深的理解。你必须知道什么模式会演变成什么问题、知道什么抽象是真抽象什么是假抽象、知道什么边界值得守什么边界其实无关紧要。一个从未认真写过代码的人设计不出好的 harness，就像一个从未真正懂马的人设计不出好的马具。

我说的“迁移”，是指时间和注意力的重新分配。未来一个好工程师花在“自己写代码”上的时间会变少，花在“设计让 agent 写出好代码的系统”上的时间会变多。这种变化是缓慢的、不均匀的，而且会先在前沿团队里发生，再逐步扩散。如果你在一个传统团队，你可能会在很长一段时间里还是主要写代码。但越早开始把一部分注意力转向 harness，你的长期杠杆率就越高。

这件事不需要你辞职创业，不需要你推翻整个流程，不需要你背叛过去的经验。它需要的只是一个轻微但持续的倾斜：每当你做完一件事，花一点时间问自己一个问题——这件事，有没有可能被写成一条规则、一个测试、一份文档、一个脚本，让下次不需要我再做一遍？

如果有，就动手把它写下来。一次一次地写，写的东西越多，你就越接近那个未来最稀缺的工程师形象。

很多重要的变化看上去都像这样：不是哪一天突然翻天覆地，而是从某一个角度看，一切都已经不一样了。

别再纠结怎么写 Prompt 了，真正要造的是那条轨道

先说句扎心的话

最近 OpenAI 发了一篇叫《Harness Engineering》的文章，讲他们怎么用 Codex 搭了一个几乎全自动生成的仓库。我看完第一反应是：终于有人把这件事说透了。

说透的是什么？是大多数团队现在用 AI 写代码的姿势，根本就是错的。

你观察一下身边，大部分团队用 Cursor、用 Codex、用 Claude Code，忙的事情是什么？是研究“怎么把 Prompt 写得更漂亮”，是收集“最佳 Prompt 模板”，是在群里转发“一句话让 Claude 写出满分代码”。我不是说这些没用，但你要明白一件事：这是在折腾工具的表面，不是在造系统。

OpenAI 那篇文章里有句话说得很实在：他们最早踩坑，不是因为 Codex 不够强，而是因为环境定义得不够清楚。后来每次失败，他们问的不是“怎么再试一次”，而是“到底缺了什么能力，怎么把它做成 agent 能理解、能被强制执行的东西”。

差距就在这里。一个把 AI 当打字员的团队，和一个把 AI 当工人的团队，用的根本不是同一套心智模型。

我见过一个特别典型的失败案例。某个中等规模的团队，上了 Cursor 半年，产出的代码量翻了三倍。老板很开心，工程师也很开心。然后线上事故开始密集爆发，每周一次、每周两次、每周三次。复盘的时候发现，大部分事故的根因都不是 agent 生成了错的代码——代码本身单独看都挺工整的——而是 agent 把某个旧的、本来就有问题的模式复制扩散到了整个代码库。以前这个模式只在两三处出现，老司机知道绕着走；现在 agent“学”会了这个模式，把它复制到了几十个地方，连带几十个地方一起出问题。

这个团队的问题不在于 agent 不够强，也不在于工程师不够资深，而在于他们没有把“这种模式不能再用了”这件事，固化成 agent 能感知、能被强制纠偏的机制。换句话说，他们没有 harness。

搞清楚你到底在做什么

我看很多人聊 AI 编程，聊的都是下游的细节：哪个模型强、哪个 IDE 好用、哪个上下文工程技巧最新。这些都是战术问题。战术问题解决不了战略问题。

战略问题是什么？是当 agent 成为主要执行者之后，工程师的工作性质已经变了。

以前你的主产出是代码。一天能敲多少行有效代码，大致决定了你的价值。现在不是了。现在的主产出是约束、是反馈、是让下一次执行更正确的那套环境。OpenAI 干脆把这个叫做“Harness Engineering”——驾驭工程。

Harness 这个词翻译得有点拗口，但意思不复杂。你可以把它理解成马的缰绳、理解成货运的轨道、理解成流水线的夹具。它强调的不是那匹马有多快，而是那匹马必须跑在你设定的方向上、不能把你摔下来、跑完之后还能让下一匹马继续跑。

说白了，harness engineering 就这一件事：把原本只存在于你脑子里的经验、边界、品味和验收标准，变成 agent 能看见、能执行、能被验证、能被沉淀的系统能力。

你品品这句话。过去我们说“老司机带新人”，靠的是口口相传、靠的是 review 里被骂几次就记住了、靠的是在 Slack 里翻一翻。这些套路在 agent 面前全部失效。为什么？因为 agent 没有记忆，没有面子，没有“上次被你骂过所以这次小心点”。它每一次都是新人。你想让它稳定产出，就必须把所有隐性规矩显性化。

这事儿以前也该做，只是过去你偷懒也能蒙混过关，因为人脑会帮你兜底。现在兜不住了。

再打个比方。你以前是老师傅，带三五个徒弟。徒弟犯错你骂一顿，骂完徒弟记住了，下次少犯。这种模式下，你的经验是靠“骂”在传递的，慢，但有效，因为徒弟会学。现在不是这样了，现在你面对的是无限多个刚上班的新人，每一个都不认识你、每一个都没被你骂过、每一个都得从头来。靠骂是传递不了经验的。你只能把经验做成“这里有道墙，撞上来自动弹回去”的东西。撞一百次还是弹回去，不需要你在场。这就是 harness engineering 和“写代码”的根本区别。

几件你必须做的脏活

我按 OpenAI 的实践，加上我自己的理解，把 harness engineering 拆成四件脏活。之所以叫脏活，是因为它们都不光鲜，不性感，不能发朋友圈秀，但没有这四样，你那些 Prompt 再漂亮都白搭。

第一件脏活：把约束做成可执行的东西，而不是一份文档。

OpenAI 一开始也犯了个很常见的错误——写一份巨长的AGENTS.md，把所有规则都塞进去。结果呢？上下文被挤爆、内容迅速腐化、也没人能校验这份文档是不是还有效。后来他们改了路子：AGENTS.md只做目录，规则拆到docs/的结构化文档里，真正生效的是 linter、CI 和结构性测试。

这个转变非常重要。你要搞明白：文档不是约束，能阻止违反的才是约束。

一条“不要直接调数据库”的注释，和一个“调数据库就 CI 挂掉”的规则，不是一回事。前者是建议，后者才是约束。前者是给人看的，后者是 agent 一碰就知道痛的。

我见过太多团队搞 AI 编程搞不起来，根子就是这里。他们写了一堆“规范”，贴在 Confluence 上，agent 当然视而不见——因为那根本不是系统能读懂的东西。

你要问自己一个问题：这条规则，如果违反了，谁会最先发现？ 如果答案是“靠 review 的人去看”，那它就不是约束；如果答案是“CI 会挂、测试会红、linter 会报”，那它才是约束。这两者的差别在于，前者依赖于注意力，后者依赖于系统。注意力会分心、会疲劳、会离职，系统不会。

更进一步说，一条活的约束至少要满足三件事：agent 在生成代码之前能读到它、agent 在生成代码之后能被它拦住、人看到失败信号之后能知道这条规则是什么意思。缺任何一条，这条约束都不算数。

第二件脏活：把验证路径设计得让 agent 自己能走完。

OpenAI 这篇文章里另一个关键点是：他们把原本主要给人看的 UI、日志、指标、trace，全都接到了 agent 能直接消费的地方。Codex 能自己复现 bug、自己验证修复、自己检查性能目标。

这其实就是工业化。过去很多团队的反工业化状态是什么？是所有验证都要人来做。agent 生成一段代码，扔给你，你跑一下、看一下、点几个链接、打开几个面板，然后判断行不行。这个流程的瓶颈永远是你。

真正的工业化，是把“行不行”这件事也交给系统去答。测试能跑、指标能读、日志能解析、性能能自动对比——所有这些，都是让 agent 在没有人盯着的时候也能自我验证。

你要学的一件事是：凡是只能靠人眼判断的环节，都是瓶颈；凡是瓶颈，都会被 agent 的吞吐反向压垮。

这条经验我个人踩过两次。一次是性能回归——以前性能好坏都是凭我跑一跑感觉一下，agent 大规模上线之后，改动频率从一天几次变成一小时几十次，我再也跑不过来了。第二次是接口契约——以前我 review 时候能看出来“这里 return 的字段名不对”，现在根本看不过来，必须把接口 schema 做成 CI 强制校验。每一次瓶颈被暴露，都逼着我把一段判断力从脑子里搬进系统里。搬完之后才发现，原来这些判断力一直都值得被显性化，只是过去人肉凑合就过去了而已。

第三件脏活：把反馈回路建在重复问题爆发之前。

很多人对“反馈”的理解太浅了，以为就是给 agent 看错误日志。不对。反馈的本质是：偏差能被尽早发现，发现之后能被压回正确的轨道。

这里面分两层。第一层是实时反馈——测试挂了、静态分析挂了、structural check 挂了，agent 立刻知道。第二层是趋势反馈——某类问题是不是在反复出现？某个模块的技术债是不是在积累？某种写法是不是正在被错误地复制？

OpenAI 的做法是搞“后台 Codex 任务”，定期扫描偏差、更新质量评分、直接发起针对性的重构 PR。这就是典型的趋势反馈。它承认了一件事：全 agent 代码库一定会复制模式——好模式会被复制，坏模式也会被复制，熵一定会增加。

你如果指望靠每周五“大扫除”清理 AI slop，那是靠资深工程师的英雄主义。这个办法一定不可持续。团队一扩大、项目一增多、资深工程师一休假，你就完蛋。

收垃圾必须是系统能力，不是人肉能力。记住这句话。

第四件脏活：把每一次经验沉淀成下次不用再交学费的资产。

这是最容易被忽视的一层，但可能是杠杆最高的一层。

你想想看，一个成熟工程师值钱在哪里？值钱在他踩过的坑。这些坑在他脑子里，离职了就带走了，招个新人要重新再踩一遍。agent 时代放大了这个问题——因为 agent 比新人更“新”，它每次都是零经验上岗。

所以沉淀是个必答题。具体怎么做？一次问题解决之后，别只修这一次的 bug，你要追问一句：这属于约束没做好、验证没做好、反馈没做好，还是沉淀没做好？然后强迫自己至少补一项资产——一份模板、一条 CI 规则、一个脚本、一个 structural test、一个 golden principle。

哪怕很小，只要它能让同一个坑下次不用再踩，就值得做。

沉淀还有一个被严重低估的价值——它能决定你的知识是属于个人还是属于组织。个人的知识，你一走就没了；组织的知识，存进系统里，下一个人来了立马能用。以前我们说“把自己做成不可替代的人”，其实是一种反组织效率的策略；在 agent 时代，更稀缺的是“能把知识沉淀成可复用资产的人”。这种人走到哪里，团队的整体能力都会涨一截。这种人，才是真正值钱的。

一个特别反直觉的观察

OpenAI 那篇文章里有句话特别扎眼：他们的仓库首先是为 Codex 的可理解性而优化的。

注意这个表述。不是“可读”，不是“可维护”，是“Codex 可理解”。

这背后的逻辑非常狠：以前我们写代码是给人看的，顺便机器也能跑；以后我们写代码是给 agent 读的，顺便人也能看懂。

你要反应过来这件事的含义。今天大部分团队的知识，都散落在 Google Docs 里、Slack 对话里、会议纪要里、某个资深工程师的脑子里。这些地方 agent 看不见。

结果是什么？结果是 agent 的表现上限，直接被你“知识外泄”的程度卡住了。你有多少隐性知识没进到 repo 里，agent 就差多少理解力。

我给你一个判断标准：知识是否是 repo-local 的、versioned 的、discoverable 的，决定了 agent 的表现天花板。

以后招工程师，你该问的问题不只是“你会写什么”，还要问“你会把什么固化进系统里”。前者是个人能力，后者是组织能力——后者才是 AI 时代真正稀缺的。

顺着这个逻辑往下想，你会发现连技术设计文档都得重写。以前的设计文档写得再华丽都没关系，反正是写给人看的，看不懂还可以找作者问。现在不行了，设计文档是 agent 读的，它不会找你问，它只会根据文档生成代码。所以那种纯解释性的长段落、那种“这里为了保持灵活性我们做了一些权衡”的模糊话术，agent 消化不了。

agent 需要的是什么？是目标和非目标、是模块边界、是依赖方向、是不变量、是数据边界、是验证路径、是观测点、是回滚策略，以及那句最关键的——哪些写法虽然能跑但不希望以后被复制。这是 operational document，不是 essay。文档的形态也必须跟着工程范式一起改。

判断力才是真正的稀缺资源

我再展开说一件事，OpenAI 那篇文章里有个观察非常尖锐：他们发现瓶颈已经不是“有没有人能把代码写出来”，而是“有没有足够的人类注意力做 QA、裁决和判断”。

这句话值得反复咀嚼。

过去的工程瓶颈在什么地方？在代码产能。一个团队能养活多大的系统，大致取决于这个团队一天能产出多少有效代码。所以我们做架构、做分工、做流程，核心目标都是“让更多的代码能被更快地写出来并且还不出事”。

现在代码产能这个瓶颈被 agent 打破了。你想要多少代码就有多少代码。新的瓶颈变成了什么？变成了判断力。谁来判断这段代码要不要合、这个设计对不对、这个改动会不会踩线、这个权衡在当前业务环境下是不是合理？

判断力是稀缺资源。稀缺资源必须被精细配置。

这就解释了为什么 harness engineering 会成为核心——因为它本质上是在做“判断力的预置和规模化”。你把一次判断做好了、固化成约束、固化成验证、固化成反馈，那下次一万次类似的场景都不需要你再判断一次。你的判断力被复用了一万倍。这就是杠杆。

反过来，如果你不做这件事，你的判断力就是一次性的。agent 吞吐翻十倍，你的判断力就会被稀释十倍。稀释的结果就是你要么熬死自己，要么放弃把关——哪种结果都不好看。

所以我经常跟团队说一句话：在 AI 时代，“做了什么事”越来越不值钱，“把这件事变成系统以后就不用再做了”才值钱。 一次性劳动是耗品，可复用判断力是资产。你得想清楚自己在积累哪一种。

工程流程也得重写

这件事还有一个衍生结论——而且这个结论可能会让一些老派的人不舒服——吞吐量变化会反过来改写工程流程。

OpenAI 那篇文章提到：他们的仓库采用更少的阻塞式 merge gate、更短命的 PR、用后续 agent run 修复 flaky test。这些做法放在十年前，任何一个资深架构师都会拍桌子——这不是乱来吗？

但你仔细想想就明白了。过去流程之所以严格，是因为“修正很贵”——回滚成本高、重构成本高、找人复盘成本高。所以你要在 PR 阶段把一切堵住。

现在呢？修正变得很便宜。agent 可以连夜跑、可以自动重构、可以批量改。贵的变成了“等待”——你堵在那里等 review 的每一分钟，都是在浪费 agent 的带宽。

流程不是神圣不可变的，流程应该服务于新的成本结构。

我不是说所有团队都该照搬这一套。OpenAI 自己也强调，这依赖于他们特定的仓库结构、投入和纪律。但这个原则值得刻在脑子里：当下游的成本结构变了，上游的流程必须跟着变。

那些死守“每个 PR 都必须两人 review、必须跑完所有测试才能合”的团队，不是在守质量，是在守习惯。守习惯的成本，未来会变成看不见的竞争差距。

最后的警告

说两句掏心窝子的话。

第一句：harness engineering 不是 coding 的边角料，是在重新定义什么叫工程能力。

未来更稀缺的工程师，未必是手写代码最多的那个，而是最会设计“约束、验证、反馈、沉淀”这套系统的那个。他知道什么必须前置写清，他知道怎样让正确性可证明，他知道怎样让偏差尽早被发现，他知道怎样把一次经验固化成长期资产。

这种能力不是写 Prompt 能练出来的，是你一个项目一个项目踩过来、一次闭环一次闭环补出来的。

第二句：别再指望靠人肉兜底了。

agent 吞吐上升以后，任何“靠资深工程师最后把关”的流程都会崩。你必须承认：纪律这件事，未来体现在 scaffolding、tooling、abstractions 和 feedback loops 里，而不是体现在某个具体的人有多靠谱。

你能不能活下来，取决于你能不能把自己从系统的关键路径上挪开，变成系统的设计者而不是瓶颈。

这事儿没有捷径。想明白了就开始做，做出一个闭环是一个闭环。别再在 Prompt 花招上浪费时间了，那条路走不通。

临了再啰嗦一句给那些团队负责人听。你们现在最该关心的不是“我们团队的 AI 编程渗透率是多少”，也不是“我们引入了哪些大模型”，而是“我们把多少判断力沉淀到了系统里”。前两个指标可以一夜暴涨，也可以一夜归零；最后那个指标是慢变量，是长期护城河，是未来决定组织效率的关键。

盯住慢变量，别被快变量骗了。这是我混了这么多年工程圈最大的体会。

从让 AI 写代码到为 AI 设计系统：Harness Engineering 的第一性原理

大多数人在问：“AI 什么时候能替代程序员？”

这是一个错误的问题。

真正的变化不是 AI 取代了谁，而是工程的重心从“写代码”转移到了“设计 AI 工作的系统”。

你不会问一匹马：“汽车什么时候能替代你？”你会问：“道路该怎么修？”

一、真正的转变

过去二十年，软件工程师的核心能力是把想法变成代码。

现在，AI 可以写代码了。而且写得越来越快，越来越便宜。

但这不意味着工程师消失了。恰恰相反——工程师的价值正在从“生产代码”跃迁到“定义代码生产的边界”。

想想看：工厂出现后，铁匠没有消失，他们变成了工程师。他们不再亲手锤打每一块金属，而是设计模具、定义工艺流程、把控质量标准。

软件行业正在经历同样的跃迁。

你不再是铁匠。你是设计锻造系统的人。

这个过程有一个名字：Harness Engineering。

它不是一个新框架，不是一个工具，不是一个可以 npm install 的东西。它是一种根本性的思维方式转变——从“我如何写好这段代码”到“我如何让 AI 在正确的约束下持续产出好代码”。

大多数团队还没意识到这个转变已经发生了。他们还在用旧的思维框架理解新的现实。

二、隐性知识的显性化

每个资深工程师脑子里都有一套没写下来的规则。

“这个模块不能直接调那个服务。”“日志要这样打，不能那样打。”“这里用事件驱动，不要用轮询。”“这段遗留代码别碰，碰了会塌。”

这些规则从来没有文档化。它们活在老员工的大脑里，通过 code review 口口相传，在午餐时间偶然提起，在新人踩坑后才被发现。

AI 不吃午饭，也不做 code review。它只认识被写下来的东西。

所以，Harness Engineering 的第一个动作是：把隐性知识变成显性规则。

这听起来很简单，但它是整个范式转变的核心。因为——

你的经验如果不能被编码为约束条件，它在 AI 时代就等于不存在。

想想这有多深刻。你十年积累的技术直觉，你对系统架构的精微理解，你知道哪些“看起来优雅但实际上是坑”的设计模式——如果这些东西没有被转化为 AI 可以理解和遵守的规则，它们的价值就是零。

不是接近零。是零。

因为 AI 会绕过你所有的隐性知识，直接按照它训练数据里的“最佳实践”来干。而训练数据里的最佳实践，往往是脱离上下文的通用方案。

Harness Engineering 就是把经验变成环境。不是教 AI 你知道什么，而是构建一个系统，让 AI 只能在你定义的边界内行动。

就像河流不需要“知道”应该流向哪里。河床决定了一切。

你不是在训练 AI。你是在塑造河床。

三、从手艺到工厂

软件工程一直被视为一种“手艺”。

每个程序员都是工匠，代码是他们的作品。我们甚至用“craft”这个词——software craftsmanship。我们谈论“优雅的代码”“漂亮的架构”，好像在谈论一件艺术品。

这个时代结束了。

软件正在从“手艺模式”进入“工厂模式”。这不是降级，这是升维。

手艺模式里，价值在于你能亲手做出什么。工厂模式里，价值在于你能设计什么样的生产系统。

一个木匠可以做出精美的椅子。但设计宜家平板包装系统的人，改变了全世界的人坐什么椅子。

哪个创造了更大的杠杆？

人在上移，不是在出局。 从执行层上移到设计层，从操作层上移到架构层，从写代码上移到定义代码的生成规则。

这里有一个关键区别：上移不是变得更“抽象”。不是画更多的架构图，开更多的会议，写更多的 PRD。

上移意味着你的工作变成了：

• 定义系统的边界条件
• 设计验证循环
• 构建 AI 可以在其中安全工作的“赛道”
• 当 AI 产出偏离时，调整赛道而不是修改产出

你不是在管理 AI。你是在工程化 AI 的工作环境。

这就是 Harness 这个词的含义——驾驭，束缚，利用。不是控制每一步，而是设计让正确行为自然涌现的结构。

四、AI 的过度设计倾向

给 AI 一个简单的任务，它会给你一个复杂的方案。

这不是 bug，这是特性。或者说，这是它的本性。

AI 被训练来展示能力，不是来展示克制。

你让它写一个用户登录功能，它会给你加上 OAuth2.0、JWT 刷新机制、多因素认证、设备指纹、风控引擎的接口预留、国际化支持、无障碍访问优化。

你只需要一个简单的邮箱密码登录。

这就是 AI 在设计阶段的核心问题：过度设计。

为什么？因为在 AI 的训练数据里，“更完善”的方案得到了更多的正面反馈。Stack Overflow 上获赞最多的回答，往往是最全面的那个，不是最简洁的。技术博客里被转发最多的架构设计，往往是最精巧的那个，不是最朴素的。

AI 学会了一个错误的等式：复杂 = 专业。

但真正的工程智慧恰恰相反。

最好的架构不是你再也无法添加什么的架构，而是你再也无法删除什么的架构。

AI 不懂得删除。它只懂得添加。

它不会说“这里不需要”。它会说“这里可以加上”。每一次“可以加上”，都是技术债务的种子。

一百个种子长成一片杂草丛，你的系统就窒息了。

这就是为什么在设计阶段，AI 的输出必须被视为“初始提案”而非“最终方案”。它是原材料，不是成品。

需要有人做减法。

五、人类审查的核心价值：做减法

大多数人以为 code review 的价值是找 bug。

错了。

在 AI 时代，code review 的核心价值是做减法。

Bug 可以通过测试找到。逻辑错误可以通过形式化验证发现。安全漏洞可以通过扫描工具检测。

但“这个东西根本不应该存在”——这个判断，只有人能做。

AI 擅长回答“怎么做”。人擅长回答“该不该做”。

当你 review 一个 AI 生成的 PR 时，你最重要的工作不是检查代码是否正确。而是检查——

这段代码是否多余？

这个抽象是否必要？

这层封装解决了真实问题还是想象中的问题？

这个配置项真的会被改变吗？

这个接口预留是基于真实需求还是基于“万一以后要用呢”？

每一行你删掉的代码，都比你写的代码更有价值。

因为删除的代码永远不会有 bug，永远不需要维护，永远不会成为技术债务。

这就是为什么在 Harness Engineering 的框架下，人类审查不是瓶颈。它是系统中最关键的过滤器。

不是 AI 写得不够好。是 AI 不知道什么时候该停下来。

一个好的工程师，不是写了什么惊天动地的代码。而是挡住了一百个不应该存在的功能，删掉了一千行不需要的代码，说了一万次“不”。

这种能力——知道什么不该做的能力——是 AI 最难学会的东西。

因为“不做”在训练数据里没有正面样本。没有人会因为“什么都没做”而获得 GitHub star。

但最好的系统，恰恰是被无数个“不做”雕刻出来的。

六、系统原语：AI 放大的基础

现在我们来谈一个核心概念：系统原语（System Primitives）。

系统原语是你架构中不可再分的基本构件。它们是 AI 构建一切的地基。

日志系统是原语。错误处理模式是原语。数据访问层的接口契约是原语。消息队列的使用规范是原语。配置管理的层级结构是原语。

原语不是你“选择”的。它们是你“定义”的。区别很大。

选择意味着从现有选项中挑一个。定义意味着你决定了这个东西在你的系统里是什么样子，有什么行为，有什么边界。

AI 是一个放大器。它放大你的原语。好的原语被放大成好的系统。坏的原语被放大成灾难。

这就像复利。

如果你的利率是正的，时间是你的朋友。如果你的利率是负的，时间是你的敌人。

原语就是你的利率。

一个设计良好的错误处理原语，会让 AI 在每个模块里都产出一致的、可追踪的、容易调试的错误处理代码。一千个模块，一千次正确。

一个设计糟糕的错误处理原语——比如“catch 所有异常然后打个日志”——会让 AI 在每个模块里都吞掉异常。一千个模块，一千个定时炸弹。

你不需要审查 AI 写的每一行代码。你需要确保你的原语是对的。

因为原语对了，AI 的输出大概率是对的。原语错了，无论 AI 多强大，输出都会系统性地偏离。

这就像物理学。如果牛顿定律是对的，你可以推导出整个经典力学。如果牛顿定律是错的，你推导得越多，错得越远。

原语是你的定律。

投资时间在原语上。这是整个 Harness Engineering 中杠杆最大的一个动作。

七、真原语与伪抽象

但这里有一个陷阱。

不是所有看起来像原语的东西都是原语。很多时候，我们创造的是伪抽象——看起来像基础设施，实际上是不必要的复杂性。

真原语简化系统。伪抽象复杂化系统。

怎么区分？

真原语有三个特征：

第一，它解决了一个你真实遇到过的问题，不是一个你想象中可能遇到的问题。

第二，它减少了使用者（包括 AI）需要做的决策数量。好的原语让你不用想。坏的抽象让你想得更多。

第三，它在不同上下文中的行为是可预测的。你不需要查文档就知道它在这个场景下会怎么表现。

伪抽象恰恰相反：

它解决的是假设性问题。“万一以后我们需要换数据库呢？”于是你建了一个数据库抽象层。三年后你没换数据库，但每个新功能都要跟这个抽象层搏斗。

它增加了决策数量。“我应该用 AbstractBaseRepository 还是 ConcreteRepositoryAdapter？它们有什么区别？为什么有两个？”

它的行为因上下文而异。“在这个场景下用 configV2，在那个场景下用 legacyConfig，但如果是测试环境要用 mockConfig，除非是集成测试。”

AI 特别擅长制造伪抽象。因为伪抽象在代码层面看起来很“专业”。

它有清晰的接口定义，有完整的类型标注，有详细的文档注释。一切看起来都很好。除了一个事实——这些东西根本不需要存在。

所以当你为 AI 定义系统原语时，坚守一个原则：

如果你不能用一句话解释为什么这个原语必须存在，它就不应该存在。

不是“它很有用”。不是“它很优雅”。是“如果没有它，系统会在某个具体场景下出问题，而这个场景我们真实遇到过”。

从真实的痛苦中提炼原语，而非从想象中的完美中推导原语。

这是第一性原理思维的核心。

八、验证循环比更强的模型重要

行业里有一种迷信：模型越强，问题越少。

这就像说“司机技术越好，就越不需要交通规则”。

不是这样的。

GPT-7 不会让你不需要验证。Claude 5 不会让你不需要测试。未来的模型不管多强，在你的特定业务上下文中，它仍然会犯错。

因为它不了解你的业务上下文。它不可能了解。你的上下文是独特的、动态的、充满历史遗留决策的。

真正决定 AI 工程质量的，不是模型的能力上限，而是验证循环的严密程度。

什么是验证循环？

AI 生成代码 → 自动化测试 → 静态分析 → 规则校验 → 人工审查 → 反馈修正 → AI 再次生成。

这个循环的每一个环节都在做同一件事：缩小 AI 的可能输出空间，直到它只能产出正确的答案。

想象一个漏斗。

AI 的原始输出是漏斗的顶端——巨大，充满可能性，也充满错误。每一层验证都收窄一点。最终流出来的，是经过多层过滤的、高度可靠的代码。

漏斗设计得越精密，你对模型本身的依赖就越小。

这意味着：一个普通模型配上精密的验证循环，胜过一个顶级模型配上松散的流程。

这是一个违反直觉但极其重要的洞察。

大多数团队把 80% 的时间花在选择和调优模型上，把 20% 的时间花在设计验证流程上。

应该反过来。

验证循环是可以被你完全控制和持续改进的。模型是别人的产品，你无法控制。

把精力花在你能控制的事情上。这是 Harness Engineering 的基本纪律。

一个好的验证循环应该具备什么特征？

快。快到 AI 每次生成后都能在秒级得到反馈。如果验证需要半小时，AI 就会在错误的方向上走半小时。

全面。覆盖功能正确性、代码规范、架构约束、安全规则、性能边界。每一层都是一道防线。

可解释。当验证失败时，失败信息必须清晰到 AI 可以理解并自我修正。“测试失败”是没用的。“在处理空列表时，期望返回空数组但实际返回了 null”——这才有用。

可演进。每发现一个新的问题模式，就新增一条验证规则。系统像免疫系统一样，遇到的病原体越多，就越强壮。

验证循环是活的。它不是你搭建一次就忘记的基础设施。它是你最重要的工程资产，需要持续投入和迭代。

九、每个 Bug 都是一条未被书写的规范

当 AI 产出了一个 bug，大多数人的反应是修复 bug。

这是正确的。但不够。

每个 bug 都是一条未被书写的规范。

这句话值得反复读。

AI 为什么会在这里犯错？不是因为它“笨”。是因为在你的系统规范中，有一个空白地带——一条你以为是“常识”但从未明确写出来的规则。

用户 ID 不能为负数——你觉得这是常识。但你写在规范里了吗？

金额计算不能用浮点数——你觉得这是常识。但你的原语里有这条约束吗？

删除操作必须软删除——你觉得这是常识。但 AI 不知道。

在 AI 的世界里，没有“常识”这个概念。只有“已定义”和“未定义”。

未定义的空间，就是 bug 的温床。

所以，当你修复一个 AI 产出的 bug 时，不要只修复代码。要回溯：

这个 bug 对应的规则是什么？

这条规则为什么没有被写下来？

把这条规则写下来之后，它应该在验证循环的哪一层被检查？

如果这条规则更早被写下来，AI 一开始就不会犯这个错误吗？

每修复一个 bug，就多一条规范。规范越完善，AI 犯错的空间就越小。这是一个正向飞轮。

最好的团队不是 bug 最少的团队。是规范增长最快的团队。

因为规范的增长速度决定了 AI 可靠性的提升速度。

这也回到了前面说的——经验的显性化。每个 bug 都是一次显性化的机会。不抓住这个机会，同样的 bug 就会以不同的面貌反复出现。

你消灭的不是 bug 本身，而是产生这类 bug 的条件。

这才是真正的根因分析。不是“为什么这段代码有 bug”，而是“为什么我的系统允许这种 bug 存在”。

前者修复一个点，后者封堵一个面。

十、从“写代码的人”到“定义边界的人”

让我们把这一切串起来。

工程师的角色正在经历一次根本性的重新定义。

过去，你的工作是写代码。你的价值由你写的代码的质量和数量决定。

现在，代码由 AI 写。你的工作变成了——

定义 AI 工作的边界。

什么是边界？

边界是规则。“在这个系统中，所有 API 响应必须遵循这个格式。”

边界是约束。“任何数据库操作必须通过这个原语层，不允许直接 SQL。”

边界是验证。“每次提交必须通过这组检查，不通过不允许合并。”

边界是接口。“这个模块对外暴露这三个方法，其余全部私有。”

边界是“不”。“不，我们不在这一层做缓存。”“不，这个功能不需要配置化。”“不，这个抽象不必要。”

你的价值不再是“我能写什么”，而是“我能定义什么样的边界，让 AI 在其中产出正确的东西”。

这是一种完全不同的能力。

写代码需要的是技巧——语言特性、算法知识、框架用法。

定义边界需要的是判断力——什么是必要的，什么是多余的，系统的真正约束在哪里，灵活性应该开放在哪里。

技巧可以被训练。判断力只能通过经验和反思获得。

这就是为什么资深工程师在 AI 时代不会贬值。恰恰相反——他们的判断力，是整个系统中最稀缺的资源。

一个初级工程师可以学会使用 AI 写代码。任何人都可以。

但只有经历过系统崩溃的人，才知道哪些边界是不可逾越的。

只有维护过遗留系统的人，才知道哪些“优雅的设计”最终会变成噩梦。

只有上线过大规模服务的人，才知道哪些假设在真实流量下会崩塌。

这种经验无法通过训练获得。这就是 Naval 所说的“specific knowledge”——独属于你的、无法被标准化传授的知识。

AI 时代，specific knowledge 的载体从“手指上的代码能力”变成了“脑子里的系统判断力”。

载体变了，本质没变。

十一、如何面对那些贩卖焦虑的口号

“程序员将在两年内被取代！”

“AI 已经可以独立完成项目了！”

“不学 AI 你就完了！”

深呼吸。

口号的目的是制造情绪，不是传递信息。

每一次技术变革都伴随着同样的叙事结构：新技术出现 → “旧技能将消亡” → 恐慌 → 卖课 → 现实逐渐展开 → 变化确实发生了但远没有口号说的那么极端。

还记得“no-code will replace developers”吗？

还记得“blockchain will replace databases”吗？

还记得“agile will eliminate project failure”吗？

变化是真实的。口号描述的方式是失真的。

判断一个变化是否真实，看它是否改变了底层的激励结构。判断一个口号是否失真，看它是否过度简化了这个改变。

AI 确实改变了底层激励结构。写代码的边际成本趋近于零——这是真实的。这意味着能写代码不再是竞争优势——这也是真实的。

但“程序员消失”？这就是过度简化了。

代码生产的自动化不等于软件工程的自动化。代码只是软件的一部分——甚至不是最难的部分。

最难的部分是什么？

理解业务需求中的矛盾和模糊。

在不确定性中做出不可逆的技术决策。

管理一个系统在多年演进中的复杂性。

协调多个团队对“什么是正确的”的不同理解。

在紧急故障中快速判断根因。

这些能力，AI 在可预见的未来都无法替代。不是因为 AI 不够强。是因为这些问题本身没有确定的答案，需要在特定上下文中做出权衡。

AI 能解决有确定答案的问题。人解决需要权衡的问题。

所以，面对口号，保持两种能力：

第一，区分信号和噪音。AI 改变工程方式——这是信号。“程序员两年消失”——这是噪音。

第二，把焦虑转化为行动。与其恐惧被取代，不如问自己：我的哪些能力是 AI 放大器的一部分？我的哪些能力只是在做 AI 已经可以做的事情？

聪明的人不恐惧变化，也不无视变化。他们重新定位自己在变化中的位置。

十二、普通团队的实操系统

理论说够了。谈谈一个普通团队，明天早上该怎么做。

好的系统不需要英雄。它需要流程。

以下是一个 Harness Engineering 的实操工作系统，你可以从明天开始使用。

第一步：盘点你的系统原语

花一天时间，和团队一起列出你们系统中的所有原语。

不要想象。去看代码。

你们的错误处理是怎么做的？有统一模式吗？还是每个模块各自为政？

你们的日志是怎么打的？有规范吗？还是每个人凭感觉？

你们的 API 设计遵循什么约定？URL 命名？参数校验？响应格式？错误码？

数据库访问有统一的抽象吗？事务怎么管理？连接池怎么配置？

列出来，分成三类：已有且好的、已有但差的、缺失的。

第二步：补齐和修正原语

先修正“已有但差的”。这些是你系统中正在被 AI 放大的负面模式。

再补齐“缺失的”。每个缺失的原语都是一个 AI 可能犯错的灰色地带。

每个原语都应该有三样东西：一个清晰的接口定义，一组使用示例，一组反面示例（“不要这样用”）。

反面示例特别重要。AI 很容易从正面示例中“过度泛化”。告诉它“不要”比告诉它“要”更有效。

第三步：建立验证循环

从最简单的开始：

一套覆盖核心路径的自动化测试。不需要 100% 覆盖率。先覆盖最重要的 20% 路径。

一组架构规则检查。“不允许直接导入内部模块。”“不允许在 Controller 层调用数据库。”“不允许在工具函数中使用全局状态。”这些可以用简单的 lint 规则实现。

一个 PR review 检查清单。不是代码层面的，而是架构层面的：“这个 PR 是否引入了新的依赖？”“是否修改了公共接口？”“是否新增了抽象层？”如果答案是“是”，就需要更严格的人工审查。

第四步：建立“Bug→规范”的转化流程

每次修复 AI 产出的 bug 时，多做一步：

这个 bug 对应什么规范？规范是否已经存在？如果不存在，创建它。创建后，添加到验证循环中。

这个流程不需要复杂的工具。一个共享文档加上纪律就够了。

关键不是工具，是纪律。

第五步：渐进式信任

不要一开始就让 AI 做所有事情。

从低风险的任务开始：写测试、写文档、做简单的 CRUD。验证 AI 在你的原语系统中是否表现良好。

逐步扩大范围：更复杂的业务逻辑、跨模块的功能、性能敏感的代码。每扩大一步，都确认验证循环能捕获问题。

信任是 earned，不是 granted。对 AI 也是一样。

第六步：持续迭代

每周回顾：

本周 AI 产出了多少需要大幅修改的代码？

哪些修改是因为原语不清晰导致的？

哪些修改是因为验证循环有漏洞导致的？

哪些修改是因为模型本身的局限导致的？

前两类是你能控制的。第三类不是。

把精力花在前两类上，持续缩小 AI 犯错的空间。

这不需要专门的“AI 工程师”。这是每个工程师的日常工作的一部分。就像测试不需要专门的 QA 团队（虽然有也好），原语维护和验证循环也是每个工程师的责任。

十三、真正的竞争优势

最后，让我们谈谈竞争。

AI 模型是公共资源。GPT、Claude、Gemini——所有人都能用同样的模型。

模型不是竞争优势。从来不是。

真正的竞争优势是：谁能最快地把组织经验转化为 AI 可执行的系统。

想想这意味着什么。

公司 A 有十年的行业经验，但这些经验全在老员工的脑子里。AI 对公司 A 来说就是一个通用工具——能写代码，但写出来的代码跟任何其他公司的 AI 写出来的没有本质区别。

公司 B 同样有十年的行业经验，但他们把这些经验编码成了系统原语、验证规则、架构约束、反面模式库。AI 在公司 B 的系统中工作，就像一个浸泡了十年的资深员工——它自动遵循公司 B 独有的实践，产出的代码体现了公司 B 独有的工程哲学。

公司 A 的 AI 是通用 AI。公司 B 的 AI 是定制 AI。两者之间的差距，就是 Harness Engineering 的差距。

这不是关于谁用了更贵的模型。这是关于谁把自己的独特知识变成了系统。

再说直白一点：

模型是发动机。你的 Harness 是底盘、悬挂、轮胎、导航系统。同一台发动机装在不同的车身上，表现天差地别。

大多数公司在拼发动机。聪明的公司在造车身。

而造车身的能力——把组织经验系统化的能力——是不可复制的。因为每个组织的经验是独特的。这就是你的护城河。

不是 AI 的能力。是你驾驭 AI 的能力。

不是模型有多聪明。是你的系统有多聪明。

结语：回到第一性原理

把所有的噪音去掉，AI 对软件工程的影响可以用一句话概括：

代码生产的边际成本趋近于零。

从这一个事实出发，所有的推论都是必然的：

既然代码便宜了，那么决定代码质量的因素——原语、约束、验证——就变得更重要了。

既然 AI 能写代码了，那么人的价值就从“写代码”转移到“定义什么样的代码应该被写”。

既然产出变多了，那么过滤和审查——做减法——就成了最稀缺的能力。

既然模型是公共资源，那么竞争优势就在于你的 Harness——你的系统、原语、验证循环、组织知识的编码化。

这就是 Harness Engineering。不是一套工具。是一种思维方式。

它的核心信念是：

AI 不需要被“管理”。它需要被“约束”在正确的结构中。

人的价值不在于做 AI 做不了的事。而在于定义 AI 应该做什么。

系统的质量不取决于最强的那个组件。取决于组件之间的边界定义得有多清晰。

不要追逐更强的模型。构建更好的系统。

模型会过时。系统会积累。

这是属于你的复利。

写代码的时代正在结束。设计系统的时代正在开始。你准备好了吗？

从让 AI 写代码到为 AI 设计系统：Harness Engineering 的心理学

一、织布机前的卢德分子

1811 年的英格兰诺丁汉，一群愤怒的纺织工人在夜色中砸毁了工厂里的织布机。他们自称“卢德分子”，以一个据说名叫内德·卢德的人物为精神领袖。历史课本通常把这个故事讲成一则关于“反对技术进步”的寓言——愚蠢的工人试图阻挡不可阻挡的工业革命。

但如果你仔细阅读那段历史，会发现一个被忽略的细节：那些砸机器的工人，并不是最差的纺织工。恰恰相反，他们是最好的。

他们是手工织布的大师，花了十年甚至二十年时间掌握了一门精湛的手艺。他们愤怒的真正原因不是“机器比我快”，而是“我花了一辈子积累的判断力、手感和经验，突然之间似乎不再被需要了”。

两百年后，我在一间科技公司的会议室里听到了几乎一模一样的话。一位有着十五年经验的高级工程师，看着屏幕上 AI 生成的代码，说了一句让我至今难忘的话：“它写的代码能跑，但它不知道为什么要这样写。”

这句话里藏着一个关于我们这个时代最重要的洞察——关于 AI、关于工程、关于人类经验的价值。

二、从“写代码”到“设计笼子”

2024 年到 2026 年之间，软件工程领域发生了一件微妙但深刻的事情。表面上看，大家都在讨论 AI 能不能替代程序员。但真正发生的变化，比这个问题本身有趣得多。

让我用一个类比来说明。

假设你经营一家餐厅。以前，你最重要的资产是一位天才厨师——他知道每道菜的火候、调料的比例、食材的搭配。现在，你拥有了一台无比强大的烹饪机器人。它可以同时处理一百道菜，速度是人类的十倍，而且永远不会累。

问题来了：你还需要那位天才厨师吗？

答案是：你比以前更需要他。但不是让他继续炒菜，而是让他设计菜谱、制定标准、定义什么叫“好吃”。

如果没有厨师的经验和判断，机器人会严格按照某个菜谱执行——哪怕那个菜谱有问题。它会在所有一百道菜里同时犯同一个错误。更可怕的是，它犯错的速度和规模，远超任何人类厨师。

这就是软件工程领域正在发生的事情。工程师的核心工作，正在从“写代码”转向“为 AI 设计系统”。不是被 AI 取代，而是角色发生了根本性的转变——从手艺人变成了系统设计师。

有人给这种新的工程范式起了一个名字：Harness Engineering——驾驭工程。

这个词本身就很有意味。Harness，既是名词“缰绳”，也是动词“驾驭”。它暗示着一种关系：AI 是一匹力量惊人的马，但方向、边界和目的地，需要人来定义。

三、经验的诅咒与祝福

我有一位朋友是急诊室的医生。有一次我问他：“你觉得你工作中最重要的技能是什么？”

他想了很久，然后说：“知道什么时候不需要担心。”

他解释说，急诊室每天会涌进各种各样的病人，表现出各种各样的症状。一个年轻的住院医生可能会对每一个异常指标都紧张万分，开出一堆检查和治疗。但一个经验丰富的急诊医生，会在几秒钟内判断出哪些情况是真正危险的，哪些只是虚惊一场。

这种判断力没有写在任何教科书里。它是上万个病例在脑海中留下的模式识别能力——一种隐性知识。

软件工程中充满了这样的隐性知识。为什么这个模块要用这种设计模式而不是另一种？为什么这个接口要暴露这三个参数而不是五个？为什么那段看起来可以优化的代码偏偏不能动？

答案往往不在代码注释里，不在设计文档里，甚至不在任何人的脑子里以清晰的语言存在。它存在于整个团队的集体记忆中，存在于无数次代码审查的讨论中，存在于上线后被三个凌晨的故障电话教训出来的本能反应中。

Harness Engineering 的核心，就是把这种隐性知识变成显性知识。把经验变成环境。

这听起来简单，做起来极难。因为隐性知识之所以是隐性的，恰恰是因为拥有它的人往往不知道自己拥有它。就像你很难向别人解释你是怎么骑自行车的——不是因为你不会骑，而是因为你会骑得太好了，以至于那些关键的平衡调整已经变成了无意识的本能。

但这正是工程师新角色的关键所在。你需要把“我就是知道这里不能这样做”翻译成 AI 能理解和遵守的明确规则、约束和边界。

每一次你对 AI 说“不，不要这样做”，每一次你在代码审查中否决了 AI 的建议，本质上你都在执行一次从隐性到显性的翻译。而真正的 Harness Engineering，是把这些零散的翻译系统化、结构化，变成一个 AI 可以在其中正确工作的“环境”。

四、手艺与工厂

1908 年，亨利·福特推出了 T 型车的流水线生产模式。在此之前，每一辆汽车都是由一组技艺精湛的工匠从头到尾手工打造的。一个优秀的汽车工匠需要掌握金属加工、发动机调试、底盘组装等十几种技能，培养一个这样的工匠需要五到十年。

流水线改变了一切。把复杂的整车制造分解成简单、标准化、可重复的步骤，每个工人只需要掌握其中一个环节。生产效率提高了几十倍，汽车价格从富人的奢侈品变成了中产阶级的日常交通工具。

但这里有一个被忽略的重要事实：流水线并没有让工匠消失。它让工匠升级了。

那些最优秀的汽车工匠没有去流水线上拧螺丝。他们变成了流水线的设计者——定义每个工位的标准、设计质量检测流程、优化整体生产节拍。他们的手艺经验没有消失，而是被编码进了整个生产系统中。

软件工程正在经历一模一样的转变。

过去二十年，写代码被视为一种“手艺”。我们推崇“代码工匠精神”，赞美优雅的算法、精妙的设计模式、简洁的代码风格。一个优秀的程序员，就像一个优秀的手工匠人，以作品的品质为荣。

AI 正在把这种“手艺模式”推向“工厂模式”。代码的生成——就像福特时代的零部件制造——正在被自动化。但代码生成只是软件工程的一部分，就像拧螺丝只是造汽车的一部分。

真正的工程师正在“上移”，而不是“出局”。

他们从“写代码的人”变成了“定义代码应该怎么写的人”。从“在流水线上操作的工人”变成了“设计流水线的工程师”。这不是降级，而是升级。但它确实要求一种完全不同的技能组合——更多的系统思维，更多的抽象能力，更多的将隐性知识显性化的能力。

这种转变让很多人感到不安，这是完全可以理解的。就像诺丁汉的那些织布大师一样，当你花了十年磨练一种技艺，突然被告知这种技艺的执行部分可以被机器完成时，你很难不感到一种存在层面的威胁。

但历史一次又一次地告诉我们：真正有价值的不是某种具体的手艺动作，而是那些驱动手艺动作的判断力、经验和品味。这些东西不会因为执行方式的改变而贬值——恰恰相反，当执行变得越来越廉价、越来越快速时，判断力和品味的相对价值反而会飙升。

五、加法的诱惑

查理·芒格讲过一个关于建筑的故事。

有人问一位著名的建筑师：“设计一座伟大建筑的秘诀是什么？”建筑师回答：“知道什么东西不该放进去。”

这个回答揭示了一个深刻的道理，而这个道理在 AI 时代变得前所未有的重要。

AI 在生成代码时有一个系统性的偏差：它倾向于过度设计。 给它一个简单的需求，它会返回一个带有三层抽象、两个设计模式和一个框架的解决方案。这不是因为 AI“想”炫技，而是因为它的训练数据中充满了复杂的代码——那些被写进教科书、发布到开源社区、在技术博客上被讨论的代码，往往都是复杂度较高的代码。

简单的代码很少被人写文章讨论，就像没有人会为“今天又是平静的一天”写新闻报道一样。

结果是，AI 有一种内在的“加法倾向”。遇到问题，它的本能反应是添加——添加一个新的抽象层、添加一个新的中间件、添加一个新的配置选项。它很少说“不，这里什么都不需要加”。

我见过一个真实的案例：一个团队让 AI 重构一个只有两百行的工具函数。AI 返回了一个完整的“框架”——带有插件系统、配置文件解析器、中间件管道和一个命令行界面。从技术角度看，每一个组件都写得很好。但整体来看，它把一个简单的问题变成了一个复杂的问题。

原来两百行就能解决的事情，现在需要一千五百行和一个使用手册。

这就是为什么人类审查在 AI 时代的核心价值不是“加法”而是“减法”。

你的工作不是在 AI 的输出上继续添加东西，而是删掉不需要的东西。不是问“还缺什么？”，而是问“什么是多余的？”不是把代码变得更复杂，而是确保它保持简单。

这需要巨大的勇气和判断力。因为删除总是比添加更难——删除意味着你需要真正理解什么是本质的、什么是装饰性的。添加只需要“看起来有用”就行，删除则需要“确定不需要”。

安托万·德·圣-埃克苏佩里说过：“完美不是没有东西可以添加，而是没有东西可以删除。”在 AI 时代，这句话应该挂在每个工程师的显示器上方。

六、地基的隐喻

1986 年 1 月 28 日，“挑战者号”航天飞机在发射后 73 秒爆炸，七名宇航员全部遇难。后来的调查发现，事故的原因是一个小小的橡胶 O 型圈——在低温下失去了弹性，导致固体燃料助推器的密封失效。

一个价值几美分的零件，摧毁了一个价值十二亿美元的航天器。

这个悲剧揭示了一个关于复杂系统的基本真理：系统的可靠性取决于它最基础的组件。 再先进的航天技术、再精密的飞行控制系统，都无法弥补一个基础密封件的失败。

在软件工程中，这些最基础的组件被称为“系统原语”（System Primitives）——你在其上构建一切的基石。它们可能是你的错误处理模式、你的数据验证逻辑、你的认证框架、你的 API 设计规范。

这里有一个关键洞察：AI 会放大你的系统原语——无论好坏。

如果你的基础原语是干净的、一致的、经过深思熟虑的，AI 会在这个坚实的地基上高效地构建。它会复用你的模式，遵循你的规范，生成与现有代码和谐一致的新代码。

但如果你的基础原语是混乱的、不一致的、充满历史遗留问题的，AI 同样会忠实地放大这些问题。它会在一个摇摇欲坠的地基上快速堆砌更多的砖块，让整个建筑更快地走向崩溃。

而且——这是最可怕的部分——AI 放大问题的速度，远远快于人类工程师发现和修复问题的速度。

想象一下：一个有问题的基础模块被 AI 在一天之内复用到了五十个新功能中。等你发现那个基础模块有问题时，你面对的不是一个 bug，而是五十个 bug——而且它们散布在整个代码库的各个角落。

这就是为什么在 AI 时代，系统原语的质量变得如此关键。在过去，一个有点问题的基础组件可能只会导致缓慢的技术债务积累。在 AI 时代，同样的问题会导致指数级的债务爆发。

好的原语就像好的地基：你不会注意到它们，直到地基出了问题，你才会意识到上面的一切都建在它之上。

七、真正的抽象与假装的抽象

在数学中，有一个概念叫“抽象泄漏”——一个抽象层本应隐藏的复杂性，在某些情况下“泄漏”出来，迫使使用者不得不理解它试图隐藏的东西。

好的系统原语和糟糕的系统原语之间的区别，往往就在于此。

让我讲一个故事。我认识一位工程师，他在一家电商公司工作。他们的系统里有一个叫做 BaseService 的类，每一个业务服务都继承自它。这个类有一百多个方法，涵盖了日志记录、数据库连接、缓存管理、错误处理等等功能。

听起来很合理，对吧？把所有公共功能放到一个基类里，所有服务都能复用。

问题是，这个“抽象”实际上是一个伪装成抽象的垃圾桶。每当有人不知道某个功能该放哪里时，就把它塞进 BaseService。几年下来，这个类变成了一个什么都做、什么都不精的庞然大物。更糟糕的是，因为所有服务都依赖它，任何对它的修改都可能影响整个系统。

这就是“假装的抽象”——它看起来像在简化事情，实际上在制造更多的问题。

当这个团队开始使用 AI 来生成新的服务代码时，灾难发生了。AI 忠实地继承了 BaseService，在每个新服务中调用了那一百多个方法中的各种组合。很快，新代码和旧代码一样混乱——而且数量增长得更快。

与此形成对比的是另一家公司。他们的基础原语非常简洁：一个统一的错误类型、一个标准的请求-响应接口、一组明确的数据验证规则。每一个原语都只做一件事，而且做得很好。

当这个团队使用 AI 时，AI 生成的代码自然而然地遵循了这些简洁的模式。新代码和旧代码一样清晰、一样可预测。

真正的抽象简化了思考。假装的抽象只是把复杂性换了个地方藏起来。

如何判断一个原语是真正的抽象还是假装的？有一个简单的测试：如果你需要了解一个抽象的内部实现才能正确使用它，那它就不是一个好的抽象。 好的抽象就像一扇门——你只需要知道推还是拉，不需要了解门铰链的力学原理。

在 AI 时代，这个标准变得更加严格。因为 AI 不像人类工程师那样拥有上下文和直觉来“绕过”一个有缺陷的抽象。人类可以看到 BaseService 的一百个方法，凭经验知道“这几个方法可以用，那几个方法千万别碰”。AI 不会。它会公平地使用所有一百个方法，包括那些“千万别碰”的。

所以，清理你的系统原语，在 AI 时代不再是一个“等有空再做”的改善项目。它是你能否成功使用 AI 的前提条件。

八、验证的胜利

2009 年，美国航空公司 1549 号航班从纽约拉瓜迪亚机场起飞后不久，两个引擎同时被鸟群击中失去动力。机长切斯利·萨伦伯格在短短 208 秒内做出了一系列决策，最终将飞机安全迫降在哈德逊河上，机上 155 人全部生还。

这个故事被称为“哈德逊河上的奇迹”，萨伦伯格机长被誉为英雄。但如果你仔细研究这个事件，会发现一个有趣的细节：萨伦伯格之所以能做出正确的决策，不是因为他比其他飞行员更聪明或反应更快，而是因为航空业有一套极其严格的验证回路。

每一个飞行操作都有对应的检查清单。每一个异常情况都有标准的应对程序。机长和副驾驶之间有交叉验证的机制——一个人操作，另一个人确认。即使在那 208 秒的极端压力下，萨伦伯格和副驾驶斯基尔斯仍然在执行他们训练了无数次的验证流程。

奇迹不是即兴发挥的结果，而是系统化验证的产物。

在 AI 辅助编程中，我们面临一个类似的问题。很多人和公司把赌注押在“更强大的 AI 模型”上——他们相信，只要 AI 足够聪明，就能生成完美的代码。这就像相信只要飞行员足够优秀，就不需要检查清单一样。

事实是：验证回路比更强的模型更重要。

一个中等能力的 AI 模型配合严格的验证回路，会比一个顶级 AI 模型在没有验证的情况下工作得更好。原因很简单：再强大的模型也会犯错，而且犯错的方式往往是不可预测的。你无法通过让模型“更聪明”来消除所有错误——但你可以通过系统化的验证来捕获大部分错误。

什么是好的验证回路？至少包含三个层次：

第一层是自动化测试——让机器验证机器。这是最基础的，包括单元测试、集成测试、类型检查、静态分析。AI 生成的每一段代码都应该在提交前通过这些自动化检查。

第二层是模式匹配——让规则验证结构。检查 AI 生成的代码是否遵循了既定的架构模式、命名规范、依赖规则。这不是检查“代码能不能跑”，而是检查“代码是不是在正确的轨道上”。

第三层是人类审查——让经验验证判断。这是最高层次的验证，关注的是那些无法被自动化工具捕获的问题：设计决策是否合理？抽象层次是否恰当？这段代码是否在解决正确的问题？

这三个层次缺一不可。只有自动化测试，你会错过设计层面的问题。只有人类审查，你会因为速度太慢而跟不上 AI 的产出。只有模式匹配，你会捕获形式上的偏差，但错过实质上的错误。

最好的工程团队不是那些使用最强 AI 模型的团队，而是那些建立了最严格验证回路的团队。

这里面有一个深刻的反直觉：在一个大家都在追求“更强模型”的时代，真正的竞争优势可能不在于你用了什么模型，而在于你用什么机制来验证模型的输出。就像在航空业，竞争优势不在于飞行员的天赋，而在于检查清单和训练系统的严谨程度。

九、Bug 是未写下的规格说明

1962 年 7 月 22 日，美国发射了“水手 1 号”探测器，目标是飞越金星。火箭升空后不久就严重偏离航线，地面控制中心被迫在发射后 293 秒启动自毁程序。

后来的调查发现，原因是制导程序中的一个极其微小的错误：一个上划线符号被遗漏了。在 Fortran 语言中，这个符号表示一个平滑函数。没有了它，程序把雷达数据中的正常噪声当成了真实的速度变化来处理，导致了错误的航向修正。

一个符号，价值一千八百万美元（在 1962 年）。

但这个故事更深层的教训不是“要小心打字错误”。它是：这个 bug 揭示了一条从未被明确写下来的规则——“制导程序中的平滑函数必须使用上划线符号标记”。

在 bug 发生之前，这条规则存在于程序员的脑子里，存在于团队的口头约定中，存在于“大家都知道”的假设中。但它从未被写成一份明确的规格说明。

每一个 bug，本质上都是一条未被写下的规格说明。

这个洞察在 AI 时代有着特殊的意义。当 AI 为你生成代码时，它依赖的是你给它的规格说明——无论是明确的提示词、代码注释、类型定义，还是隐含在现有代码模式中的约定。AI 不知道那些你“大家都知道”但从未写下来的规则。

所以，每当 AI 生成的代码出现 bug，你不应该只是修复 bug 本身。你应该问自己一个更深层的问题：“这个 bug 揭示了什么我认为理所当然但从未明确表达的知识？”

然后，把这个知识写下来——变成一条测试、一个类型约束、一段文档、一个代码检查规则。让它从隐性变成显性，从“大家都知道”变成“系统能验证”。

这是一个持续的过程。你永远不可能一次性把所有隐性知识都写下来，就像你永远不可能一次性发现所有 bug 一样。但每一次 bug 修复都是一次知识显性化的机会。

一位我非常敬佩的工程经理有一个习惯：每当团队修复了一个 bug，她不仅要求修复代码，还要求回答两个问题——“这个 bug 教会了我们什么？”以及“我们如何让这类 bug 不可能再发生？”

第一个问题让团队学习。第二个问题让系统学习。

在 AI 时代，第二个问题尤其重要。因为 AI 不会从 bug 中学习——至少不会在你的上下文中学习。它明天可能会犯和今天一模一样的错误。唯一能“记住”教训的，是你构建的系统——你的测试、你的规则、你的约束、你的原语。

修 bug 不是终点，写下那条缺失的规格说明才是。

十、边界的定义者

有一个关于米开朗基罗的著名故事（可能是虚构的，但它传达的道理是真实的）。

有人问米开朗基罗：“你是怎么雕出大卫像的？”

他回答：“大卫一直在那块大理石里面。我只是去掉了不属于他的部分。”

无论这个故事是真是假，它完美地描述了 Harness Engineering 时代工程师的新角色。

你不再是代码的“作者”。你是系统的“边界定义者”。

你的工作不是生成代码——AI 可以做到这一点，而且速度和数量远超人类。你的工作是定义代码生成的边界：什么可以做，什么不能做，什么必须做，什么不值得做。

这种角色转变是深刻的，它改变了工程师日常工作的几乎每一个方面。

过去，你花 80% 的时间写代码，20% 的时间思考设计。现在，这个比例可能需要反过来——甚至更极端。你可能花 90% 的时间在思考、定义、验证上，只花 10% 的时间在直接的代码操作上。

这让很多工程师感到不适。写代码有一种立即的满足感——你打出一行行字符，看到它们变成可运行的程序，就像画家在画布上看到色彩逐渐呈现。而“定义边界”是一种更抽象、更间接的工作，它的成果不那么直观，反馈循环也更长。

但这正是更高层次的工程实践。就像一个城市规划师和一个砌砖工人之间的区别——不是谁更有价值的问题，而是视野和影响范围不同。

一个优秀的“边界定义者”需要回答这些问题：

“这个系统的不变量是什么？” ——无论 AI 怎么生成代码，什么条件必须始终为真？用户数据必须加密？API 响应必须在 200 毫秒内返回？每个操作必须有审计日志？这些是不可协商的边界。

“这个领域的陷阱在哪里？” ——基于你的经验，你知道哪些看似合理但实际上会导致问题的做法？浮点数精度问题？时区处理的边缘情况？并发环境下的竞态条件？这些陷阱需要被编码成明确的规则和检查。

“什么是足够好的？” ——这可能是最重要也最难回答的问题。AI 可以无限制地优化、重构、添加功能。知道什么时候说“够了，这已经足够好了”，需要对业务目标、技术约束和用户需求的深刻理解。

米开朗基罗看到了大理石里的大卫，因为他知道大卫应该是什么样子。同样，一个优秀的工程师能定义系统的边界，因为他知道系统应该是什么样子——以及，同样重要的，不应该是什么样子。

十一、关于那些恐慌的标语

每隔几个月，社交媒体上就会出现一轮新的恐慌。“AI 将在 X 年内取代所有程序员！”“学编程已经没有意义了！”“软件工程已死！”

让我分享一个历史视角。

1995 年，互联网开始商业化时，有人预言：“五年内，所有实体店都会关门。”三十年过去了，亚马逊确实改变了零售业，但实体店并没有消失——它们进化了。

2012 年，深度学习取得突破时，有人预言：“放射科医生将在五年内被 AI 取代。”十四年过去了，放射科医生不仅没有被取代，他们在 AI 辅助下的诊断准确率比以前更高了。

每一次技术革命，都会伴随着两种声音：一种说“一切都会改变”，另一种说“什么都不会改变”。真相，一如既往，在两者之间——而且往往比任何一种极端预言都更有趣。

AI 不会取代工程师，就像自动驾驶不会取代交通规划师。 它会改变工程师做的事情，但不会消除对工程师的需求。恰恰相反，当代码生成变得廉价时，那些决定“生成什么代码”和“如何验证生成的代码”的人会变得更加重要。

面对这些恐慌性的标语，保持冷静的方法其实很简单：看做法，不要看说法。

那些喊着“AI 将取代一切”的人，他们自己在做什么？他们在雇佣工程师来构建和维护 AI 系统。那些声称“编程已死”的公司，他们的招聘页面上挂着多少个工程职位？

行动永远比言论更能说明真相。

而且，值得注意的是，那些对新技术最恐慌的人，往往是那些最不了解技术实际运作方式的人。真正在用 AI 写代码的工程师，对 AI 的能力和局限性有着清醒得多的认识。他们知道 AI 能做什么（生成大量样板代码、处理常见模式、快速原型开发），也知道 AI 不能做什么（理解业务上下文、做出架构决策、处理真正新颖的问题）。

最好的态度不是恐慌也不是忽视，而是好奇心驱动的务实主义。

十二、普通团队的操作系统

到目前为止，我们讨论的很多概念可能听起来有些抽象。那么，对于一个普通的工程团队——没有谷歌的资源、没有 OpenAI 的人才密度——来说，这一切意味着什么？

让我描述一个我见过的最有效的实践框架。我称之为“三层操作系统”。

第一层：原语治理。 每个季度花一天时间，团队一起审视自己的系统原语。这不是一个宏大的架构重构项目，而是一个简单的健康检查。问三个问题：我们的基础模式还一致吗？有没有新的“假抽象”偷偷溜进来了？AI 在使用这些原语时表现如何？

这就像定期体检——不是等到病了才去医院，而是定期确认一切正常。

我见过一个团队把这个做成了一个简单的看板。每个系统原语一张卡片，上面标注着“健康/需要关注/需要重构”三种状态。每次季度审查，大家一起更新这些状态。简单、直观、有效。

第二层：知识显性化。 建立一个持续的机制，把团队的隐性知识转化为 AI 能理解的显性规则。

具体来说：每次代码审查中，如果有人说了“这里不应该这样做”或“我们通常是那样处理的”，就把这条知识记录下来。每周花三十分钟，把这些零散的记录整理成明确的规则——可以是代码检查工具的新规则，可以是架构决策记录，可以是 AI 提示词模板中的新约束。

关键是把这个做成一个习惯，而不是一个项目。不需要一次性把所有知识都整理完，只需要每周比上周多一条明确的规则。

一位团队负责人告诉我他的做法：他在代码审查工具里加了一个标签叫“隐性知识”。每当审查者发现自己在解释一个“大家都应该知道”的规则时，就打上这个标签。每周五下午，他花半小时把这些标签汇总，选出最重要的一两条，转化成正式的团队规范。

六个月后，他们的 AI 代码审查通过率从 47% 提高到了 82%。不是因为他们换了更好的 AI 模型，而是因为 AI 终于“知道了”那些以前只存在于人脑中的规则。

第三层：验证闭环。 为 AI 的每一种使用场景建立对应的验证机制。

这听起来复杂，但实际上可以从很小的地方开始。比如：AI 生成的每段代码都必须通过现有的测试套件？好，这是最基础的验证。AI 生成的每个新 API 端点都必须有对应的集成测试？很好，这是第二层验证。AI 生成的每个架构变更都必须经过一位高级工程师的审查？完美，这是第三层验证。

关键不是一步到位建立一个完美的验证体系，而是为每一种 AI 的使用方式都建立至少一个对应的验证步骤。然后逐步加强。

一个实用的技巧是“红灯/绿灯”清单。对于 AI 生成的每一段代码，有一份简短的清单列出“绿灯条件”（必须满足才能合并）和“红灯条件”（出现任何一个就需要人工审查）。这份清单不需要很长——五到十条就够了——但它能捕获大部分常见问题。

这三层操作系统没有什么神奇之处。它不需要昂贵的工具、特殊的培训或天才的团队成员。它需要的只是纪律性和持续性——每天做一点，每周改进一点，每月回顾一次。

最好的系统不是最聪明的系统，而是最持久的系统。

十三、真正的竞争优势

让我以一个我最近在读的历史故事来结束这篇文章。

19 世纪末，美国铁路行业经历了一段疯狂的扩张期。几乎每一家铁路公司都在拼命铺设更多的铁轨——更长的线路、更多的车站、更远的目的地。他们相信，谁拥有最多的铁轨，谁就赢了。

但最终胜出的不是拥有最多铁轨的公司。而是那些建立了最好的调度系统、最可靠的时刻表和最高效的货物转运网络的公司。铁轨是基础设施，但调度系统才是让铁轨产生价值的东西。

类比到今天：AI 模型是铁轨，而你的工程系统——你的原语、你的验证回路、你的知识体系——是调度系统。

每家公司都可以使用同样的 AI 模型。GPT、Claude、Gemini，这些模型对所有人开放。真正的竞争优势不在于你使用什么模型，而在于你如何把组织的经验和知识转化为 AI 可以执行的系统。

让我把这个说得更具体一些。

公司 A 和公司 B 使用同一个 AI 模型来辅助开发。公司 A 的工程师只是简单地把需求描述扔给 AI，然后手动检查输出。公司 B 花了几个月时间，把团队十年积累的工程经验——架构原则、常见陷阱、设计模式、质量标准——编码成了一套完整的约束系统和验证流程。

六个月后，公司 A 的工程师仍然在每段 AI 生成的代码上花大量时间做人工检查和修改。公司 B 的工程师已经能够信任 AI 生成的 80% 的代码，把精力集中在那些真正需要人类判断的 20% 上。

这不是技术差距，而是系统差距。是经验被编码的程度差距。

这也解释了为什么那些经验最丰富的团队，在 AI 时代的潜在优势最大。不是因为他们的个人技能更强——在代码生成速度上，没有人能和 AI 竞争。而是因为他们拥有最多的隐性知识可以被显性化、被编码、被系统化。

一个有十年经验的团队，脑子里装着数以万计的“这样做行得通/这样做行不通”的教训。如果他们能把这些教训转化成 AI 可以理解和遵循的规则——测试、类型约束、架构模板、验证检查——他们就拥有了一个其他团队无法轻易复制的竞争优势。

因为经验不是可以购买的。你可以购买最新的 AI 模型，但你不能购买十年的工程教训。你能做的，是把这些教训变成系统——让它们不仅仅存在于人的脑海中，而是融入到 AI 工作的每一个环节里。

尾声：回到那些织布工

让我回到文章开头的那些诺丁汉织布工。

历史最终证明，他们的恐惧是有道理的——但也是错位的。他们确实失去了“手工织布”这份具体的工作。但纺织业并没有消亡，反而经历了空前的繁荣。而那些适应了新现实的人——那些学会了操作机器、设计织物图案、管理生产流程的人——过上了比手工织布时代更好的生活。

同样的故事正在软件工程领域上演。“手写代码”这个具体的动作正在被部分自动化。但软件工程——设计系统、定义边界、验证质量、将人类经验编码为可执行规则——这个更宏大的事业，才刚刚迎来它最激动人心的篇章。

AI 不是来取代工程师的判断力的。它是来放大工程师的判断力的。

前提是，你得先有判断力可以被放大。而这种判断力——来自经验、来自教训、来自无数次失败和成功的积累——恰恰是 AI 最无法替代的东西。

亨利·福特说过一句被广泛引用的话：“如果我问人们想要什么，他们会说更快的马。”

在 AI 时代，很多人想要的是“更快的代码生成器”。但真正需要的，是更好的系统来驾驭代码生成的力量——更清晰的原语、更严格的验证、更深刻的边界定义。

不是更快的马，而是更好的道路。

这就是 Harness Engineering 的本质。不是关于 AI 有多强大，而是关于我们如何驾驭这种力量。不是关于谁能生成最多的代码，而是关于谁能把最多的智慧编码进系统中。

而这种智慧，永远需要人来提供。