别再讨论 AI 会不会替代程序员了——该谈谈控制面（左耳朵耗子风格）

发表于 | 分类于

别再讨论 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 编程开始变严肃的地方，也是我们这代程序员现在真正该修炼的东西。

共勉。