从写代码到设计控制面：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 编程时代最致命的一种幻觉，就是把「生成能力」当成「生产能力」。看起来一次生成就能出代码，于是就以为生成即生产。实际上完全不是。
真正的生产能力来自两块的合成：
- 海量探索
- 低成本验证
两者都必须有。没有第二块，第一块会以惊人的速度放大你的错误。
你会发现，这个判断和软件工程里一直强调的那些东西——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 系统」的人。
今天就聊到这里。我们下次再见。