从写代码到设计控制面：Karpathy 最近两波观点的学习笔记（阮一峰风格）

发表于 | 分类于

从写代码到设计控制面：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。