动词
有一件事，我越想越觉得重要——软件工程里真正的主动词，正在被替换。
多数人没注意到这件事。这不奇怪。当一个词在某个领域里用了三十年，大家会开始把它和那个领域本身混为一谈。于是谈到软件工程，我们下意识想到的动词就是“写代码”。好像“工程师”就等于“把代码敲出来的人”。
但“写”只是软件工程在过去这段时间里最顺手的一种表达方式。它不是这门学科的本质。本质是解决问题。“写”只是那个时代里解决问题最便宜的方法。
现在这个方法不再是最便宜的了。
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 多强”，而是“一个人的工作流，可以被升级到什么程度”。
那个东西一旦被你看见，你就回不去了。