发表于 | 分类于

从写代码到编排系统：我从 Peter Steinberger 身上学到的 AI Coding 方法论

——万维钢风格：知识转译，精英日课

一个被很多人看错了的转变

2026 年 2 月，Peter Steinberger 宣布加入 OpenAI，他一手做起来的 OpenClaw 转入基金会，继续保持开放和独立。Reuters 的报道里用的词是「从一个开源 bot 变成了广受关注的个人 agent 项目」。

大多数人关注的是这条新闻本身——谁去了哪家公司，哪个项目归了谁。但我想告诉你，这些都不是这件事最有价值的部分。

真正值得学习的，是 Peter 给出的一个判断。他说：AI coding 改变的不是程序员写代码的速度，而是整个软件生产系统的结构。

这句话听起来平平无奇。但如果你慢慢咀嚼，会发现里面藏着三层含义。而这三层含义合起来，足以让我们重新思考一件事：当 AI 可以写代码了，一个程序员到底还应该训练什么。

我把我在这件事上的学习和思考，系统整理成这篇文章。不是给你一个 prompt 模板，不是给你一个工具推荐，而是给你一个框架——当软件生产从手工艺过渡到系统编排，什么能力正在升值，什么能力正在贬值。

第一层：瓶颈从”构建”变成了”同步”

先说一个容易被忽略的事实。

Peter 在 TED 2026 的表达里有一句关键话：软件里大量无聊、重复、费力的部分，AI 已经可以承担；真正的瓶颈开始从”构建”转向”同步”。他还把 OpenClaw 描述为一种个人 AI 的操作系统，而不是一个单独的应用。

大多数人对这句话的第一反应是：哦，AI 写代码更快了。

这是一个很粗糙的理解。它的真正含义是——构建这件事的单位成本在快速下降，而同步这件事的单位成本正在快速上升。

什么叫同步？你可以这么想。一个任务从被提出，到真正上线，中间要经历若干种”对齐”。需求要和实现对齐，实现要和测试对齐，测试要和设计对齐，设计要和风险对齐，风险要和上线动作对齐。如果只有一个人、一个模型、一个任务，这些对齐都是隐性的，你脑子里自动完成。但当多个 agent、多个上下文、多个分支同时工作，任何两个地方一旦不同步，整个系统就开始返工。

经济学里有一个词叫科斯的交易成本。我们可以借用一下。AI 让”构建”这部分的交易成本掉到了接近零，这就意味着瓶颈必然转移到新的地方——那个地方就是”同步”。这是一个规律，不是巧合。

所以，如果你发现你的 AI workflow 总是返工，多半不是模型不够强，而是同步机制太差。 这是我从 Peter 这句话里学到的第一层东西。

第二层：spec 不是说明书，而是控制面板

同步的起点是什么？是 spec。

在手工时代，我们对文档有一种矛盾的态度。写少了怕漏，写多了怕没人看，到最后大家心照不宣——文档主要是写给人看的说明书。

Peter 的实践让我意识到，在 AI coding 时代，requirements、design、implementation doc 的角色变了。它们不再是说明书，而是 agent 的控制面板。

这是一个很大的心智切换。你可以这么想：过去文档是被动的，agent 时代文档是主动的。过去文档的使命是”解释清楚”，agent 时代文档的使命是”约束得准”。

什么叫约束得准？就是告诉 agent 哪里可以发挥，哪里必须保守；哪里可以重构，哪里只能局部修复；哪些测试必须先写，哪些行为必须保持兼容；哪些风险必须在动手前说清楚。

这里有一个反常识的点。很多人以为 AI 写代码的主要问题是”写不出来”，其实恰恰相反，AI 最常见的问题是”长太多”。 你让它改一个函数，它顺手把整个模块重写了；你让它修一个 bug，它顺便把你的架构升级了。人类 review 的价值之一，是做减法——把 AI 长出来的多余部分砍回去。

而真正好的 spec，本质上是在 agent 动手之前就帮它做这件减法。spec 不是”写得多”，而是”约束得准”。 它的价值不在于覆盖每个细节，而在于界定可变区和禁区。

第三层：真正的效率是”收敛速度”，不是”响应速度”

讲完 spec，我们讲效率。

Peter 在《Shipping at Inference-Speed》里比较过 Codex 和 Opus。他的结论很有意思——有些模型会先花很久读代码，表面上更慢，但更可能修对；有些模型更快、更积极，但在大改动时可能漏上下文，导致后续不断”修修补补”。

这句话值得被反复读。

因为它背后藏着一个指标的切换。我们习惯用”响应时间”来衡量 AI 的效率——它多久给出第一版回答。但 Peter 告诉我们，这个指标在 agent 时代是有误导性的。

真正决定工程效率的，不是第一轮有多快，而是从任务被提出到可以放心 merge，一共走了多少轮。

我把它叫做收敛时间。收敛时间由几个指标共同决定：首次通过率、返工轮数、误改范围、为了兜底花掉的人工脑力。如果一个 agent 第一轮写得飞快，但引入了一堆隐性问题，它其实并不高效。如果另一个 agent 先慢慢读代码、先问问题、先写 plan，最后一次性通过更多测试，它反而可能更快。

这里有一个很容易被忽略的副作用：你对”快”的感受是错的。 人在体验上会把”第一回合的响应快”误认为”整件事完成得快”，就像你在餐厅总觉得上菜快的那家比较好，但最后算下来，吃完付账的时间未必更短。

所以，在评估 AI coding workflow 的时候，不要看它几秒钟给出回答，要看它几轮之内到达可 merge 状态。

第四层：你不是 programmer，你是 orchestrator

讲完了 spec 和效率，我们讲身份。

Peter 的另一个判断，我觉得更值得细品。他说 OpenClaw 的使用者并不只是工程师，还包括创业者和没有正式编程背景的人。他把这些人统称为 builders，并强调真正的变化不只是技术本身，而是 access——更多人第一次拥有了把想法推进成现实的能力。

我们得把这句话翻译一下。

表面上，它在说 AI 降低了编程门槛。但它真正的含义是：“会不会写代码”正在变成一个低层问题；更高层的问题是你能不能把一个模糊愿望压成一个可被执行的系统。

你可以这么想。过去程序员的核心能力有三件套：理解需求、设计结构、写出代码。其中”写出代码”是最显眼的一件，也是最花时间的一件。现在 AI 把这一件的边际成本压到了接近零。结果不是前两件也跟着贬值，而是前两件变得相对更值钱了。

更准确地说，前两件之外还多出了两件：组织上下文和验证结果。

  • 组织上下文：把目标、边界、约束、已有代码、接口形状、测试预期，一起打包成一份让 agent 不会跑偏的输入。
  • 验证结果：当 agent 产出一坨东西后，判断它是否真的满足 contract，是否破坏了现有行为，是否覆盖了关键路径。

把这些合起来，你的身份就变了。你不再是 programmer（程序员），你是 orchestrator（编排者）。programmer 的价值曲线会越来越平，orchestrator 的价值曲线会越来越陡。

Peter 在 TechCrunch 的采访里特别强调，他一开始也没有完整计划，很多东西是在探索中长出来的。他建议 builder 更 playful，允许自己通过一次次失败慢慢变强。这是一个很重要的提示——orchestrator 不是天生的，是练出来的。 它更像一门乐器，不是一句咒语。

第五层：带 agent 本质上是一门管理学

orchestrator 这个身份带来一个隐藏的变化。你从一个执行者，变成了一个管理者。

这件事对程序员心理冲击很大。因为大部分程序员选择这份工作，本来就是因为喜欢自己动手、不喜欢被别人打扰、讨厌开会。但 agent 时代让你没法逃了——你带的不是人，是 agent，但原理一模一样。

带 agent 的第一个心智升级，是放弃”必须按我的方式写”。

你看一个人类同事的代码，哪怕风格和你不一样，只要结果是对的、可维护的、能通过测试的，你就应该接受。你不能要求每一行都长得像你自己。这个道理在 agent 时代更加适用——因为一个 agent 每天能产出的代码量远超任何人类同事。如果你坚持让它”写得像你”，你会把大把时间浪费在审美上，而不是花在真正有风险的工程决策上。

更合理的标准是：这段代码是否满足 contract？有没有破坏现有行为？测试是否覆盖了关键路径？上线后是否可观测？出问题能不能快速回滚？

如果这些问题都过关，它不一定要长得像你亲手写的代码。这不是降低标准，这是改变标准。 手工时代的标准是”代码是否符合我的手感”，agent 时代的标准是”系统是否可控地收敛”。

你看，到了这一层，AI coding 已经不只是一个技术问题，它是一个管理学问题了。

第六层：安全是产品的一部分，不是补丁

讲到管理，就不得不讲边界。

Peter 加入 OpenAI 的那篇博客里有一句话值得记住：他下一步想做的是让普通人也能使用的 agent，但这需要更多关于安全的思考，以及接触最新模型和研究。

这句话表面看是套话，其实不是。它在说明一件事——当 agent 真的能替人做事，安全就不再是附属问题，而是产品本身的一部分。

Reuters 在报道 OpenClaw 流行的时候也同步提到，错误配置可能导致网络攻击和数据泄露风险。这不是危言耸听。agent 和 chatbot 最大的区别就是——chatbot 只是说话，agent 会动手。当它动手的时候，它代表的是你的账号、你的权限、你的系统。

这意味着，以后凡是让 agent 改代码、动配置、连生产、调外部 API，都必须默认加一层安全原语。

具体是哪些？最小权限、dry-run、二次确认、敏感信息隔离、diff trace、rollback、kill switch。这些不应该是”高级选项”，它们应该是默认设施。

反过来讲，真正能长期落地的 agent，不是能力最强的 agent，而是行为可审计、权限可限制、错误可止血、影响范围可控制的 agent。 这是工程意义上的常识，但在 AI 狂热期很容易被忽略。

第七层：失败归因给系统，而不是归因给人格

讲完了外部安全，讲一讲内部心态。

如果你真的按 Peter 的方式开始做 AI coding，你会撞上一件让人泄气的事——它会失败，而且频繁失败。模型跑偏、上下文没读全、方案过度设计、测试没覆盖、改动范围失控，每一条都会让你短暂地怀疑自己。

这里有一个归因的陷阱。失败发生的时候，最快的反应是把它解释成”我不行”或者”模型不行”。这两种解释都便宜，但都不准确。

更工程化的解释是：我的 harness 还不够好，任务边界不够清楚，验证机制不够强，同步流程还有洞。

这种归因方式有两个好处。第一，它把问题从情绪层面拉回了系统层面。你不再是被自我怀疑拖住，而是被一个明确的改进方向牵引。第二，它把每一次失败转化成了系统的提升。下一次任务，你的 kickoff 模板会更准，你的测试会更早介入，你的 rollback 会更显式。

这其实就是 Peter 的那句 playful 背后的东西。play 的意思不是随便玩，而是允许失败，但让每次失败都转化成系统的增量。

这是一个非常 professional 的心态。

第八层：把你学到的东西压成一套 kickoff 模板

前面讲了七层。你可能会问，这些东西具体怎么用？

我给自己整理了一套 kickoff 模板，核心思想只有六个字——先同步，再生成。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
任务挡位：
- 探索 / 设计 / 实现 / 修复 / 上线

任务目标：
- 这次必须完成什么
- 成功之后，用户或系统会看到什么变化

明确边界：
- 这次不做什么
- 哪些文件、接口、表结构、状态机禁止擅自扩展
- 哪些行为必须保持兼容

执行要求：
- 先读哪些上下文
- 是否必须先出 plan
- 是否必须先写测试
- 哪些动作需要二次确认后再执行

验证标准：
- 必须通过哪些测试、lint、build、smoke
- 必须提供哪些 diff、日志、风险说明
- 是否需要 rollback plan 或 feature flag

输出格式：
- 先给结论
- 再给变更点
- 再给风险点
- 最后给验证证据

这个模板背后的逻辑，就是把前面七层讲的东西全都物化。第一节讲同步，所以模板先要边界；第二节讲 spec，所以模板有执行要求；第三节讲效率，所以模板要求一次性把验证标准讲清楚，减少返工；第四节讲身份，所以模板的核心是”让 agent 知道自己该做什么、不该做什么”；第五节讲管理，所以输出格式强调结论、变更、风险；第六节讲安全，所以执行要求里留了二次确认和 rollback 的位置；第七节讲归因，所以整个模板的目的是让失败有迹可循、有地方归因。

你看，它不是一个漂亮的表格，它是一套被压缩过的方法论。

结语：软件生产正在从手工艺变成系统编排

讲了这么多层，最后我想把它压成一句话。

软件生产正在从手工艺，变成系统编排。

在旧范式里，程序员的核心能力是亲手把代码写出来。在新范式里，越来越重要的能力是——定义问题、组织上下文、设置约束、分配执行、验证结果、控制风险、沉淀流程。

这是一次真正的身份迁移。它不只是一次工具升级，它改变了一个程序员要训练的肌肉。从手速肌肉，变成结构肌肉；从实现肌肉，变成验证肌肉；从独奏肌肉，变成指挥肌肉。

Peter Steinberger 的启发可以压缩成一句话：

未来最有价值的人，不是单纯写代码最快的人，而是最会把问题组织成可执行、可验证、可收敛系统的人。

这句话，值得你抄下来，贴在显示器边上。

发表于 | 分类于

从写代码到编排系统：我从 Peter Steinberger 身上学到的 AI Coding 方法论

——刘未鹏风格：深度思考，暗时间

一个一开始让我焦虑、后来让我着迷的问题

最近几个月我一直在反复想一个问题：当 AI 已经可以写代码了，程序员到底还剩什么？

这个问题一开始让我焦虑。因为我心里有一个很朴素的自我定义——我是一个会写代码的人。这个身份过去十几年里为我提供了稳定感。它是我的手艺，是我靠它养活自己的方式，也是我在面对世界时的一种底气。当这个东西的边际成本被模型一口气压到接近零，我下意识地有一种”空”的感觉。

后来我开始反向想这件事。如果只是焦虑，那就只是情绪；而情绪对我来说是信息，它指向某个我还没想清楚的问题。如果这件事真的让我不安，说明我对”程序员”的定义里，混入了一些在新范式下正在贬值的东西；而这恰好是一次把它们拆开、看清楚、再重新组装的机会。

真正帮我从情绪里捞出来的，是 Peter Steinberger 的一句话——瓶颈正在从 building 转向 syncing。我花了好几天时间反复咀嚼它，才慢慢意识到，这句话的价值不是给了我一个答案，而是重新定义了问题本身。

这篇文章就是我把这个定义重写一遍的过程。

一次重要的拆解：building 与 syncing 不是一件事

我发现，很多时候我们对一件事的焦虑，来自于我们把两件不同的事当成了一件。程序员的工作就是一个典型。

我过去习惯把”写软件”当成一个整体：从脑子里有一个想法，到代码上线运行。但 Peter 的那句话迫使我把它拆开。拆开之后你会看到两件本质非常不同的事。

一件是 building。 这是从”我知道要做什么”到”代码存在”的转化过程。写函数、写接口、补测试、连数据库，都属于这一层。这一层的特点是它是重复性的、机械的、可模式化的。也正因为可模式化，它是最容易被模型替代的。

另一件是 syncing。 这是让多个”版本的真实”保持一致的过程：需求和实现是否同步，测试和设计是否同步，实现和风险是否同步，多个 agent 的修改之间是否同步，当前代码和历史假设是否同步。这一层的特点是它不是重复性的，而是持续性的；它不产出代码，但它决定了代码有没有意义。

把这两层区分开之后，一个关键的观察冒了出来——过去我以为自己是在 building，其实我很多时间在 syncing，只是我没有意识到。 我读代码、我在脑子里对齐各种不一致、我修补文档里没写但实际存在的约束，这些都是 syncing。

这就是为什么当 building 的成本被压低之后，我反而更忙了。因为原来被埋在 building 里的 syncing 成本，现在暴露了出来，而且它没法被模型替代——至少不是线性替代。

所以我真正的问题不是”AI 抢走了我的工作”，而是”我过去对自己做的事的理解太粗糙”。一旦把工作拆成 building 和 syncing 两层，焦虑就变成了方向：我要训练的是 syncing 层的能力。

文档作为”外化的认知”：spec 是控制面板

想清楚这件事之后，我对”文档”这件事的理解也变了。

过去我把 requirements、design doc、implementation plan 当成”给人看的说明书”。这种理解有一个隐藏的假设——读这份文档的是一个有背景知识、有常识、会察言观色的人。于是我写文档的时候是偷懒的，我可以省略很多东西，因为”反正读的人自己会脑补”。

但在 agent 时代，这个假设不成立了。agent 没有我的背景知识，没有我脑子里那些没写出来的默认约束，没有”我在心里反复告诉自己不要碰的那块代码”。它只有我写下来的东西。

这逼我重新理解 spec。spec 不是说明书，spec 是我自己认知的外化。 它是我把脑子里那些隐性的默契，变成可以被一个外部系统遵守的显式约束。

这个切换一旦发生，你写 spec 的方式就变了。

过去写 spec，我关注的是”我有没有把事情讲清楚”；现在写 spec，我关注的是”我有没有把边界画清楚”。好的 spec 不是在描述事实，而是在划定可变区和禁区。

它要告诉 agent：

  • 哪些地方欢迎你长出新东西，哪些地方必须保持原样；
  • 哪些行为必须保持兼容，哪些接口可以动但必须迁移；
  • 哪些测试必须先写，哪些 API 不能被重命名；
  • 哪些风险必须在动手前说清楚，哪些动作必须等到人类确认。

一旦你开始这样写 spec，你会突然意识到一件事——写 spec 不是在服务 agent，是在服务自己。 它强迫你把脑子里那些”只可意会不可言传”的工程直觉，一项一项显式地翻出来。这个过程本身就是一种极好的思维训练。

你甚至会在写 spec 的时候发现，自己一直以为自己想清楚的事情，其实从来没有想清楚。这和刚开始学 TDD 的时候一样——测试不是写给别人看的，测试是在逼你直面自己知识里的空白区。

一个反直觉的观察：你以为的”快”，很多时候是在制造未来的”慢”

接下来我想谈的一件事，是关于效率的认知错觉。

Peter 在比较 Codex 和 Opus 的时候讲过一件很有意思的事：有些模型会先花很久读代码，表面上更慢；有些模型更快更积极，但在大改动时常常漏上下文，后面得不断”修修补补”。

这个观察之所以重要，是因为它揭示了一个很普遍的认知偏差——我们会把”第一次响应快”误认为”整件事做完得快”。

这是一种非常典型的”系统一”的偏差，它来自我们对”快”的直觉更新得太快。你在餐厅会因为上菜快而觉得这家店高效，即使总结账时间并没有缩短；你在沟通时会因为对方回复得快而觉得他效率高，即使他因此给你留下了更多返工。

在 AI coding 里，这个偏差会带来一个很具体的后果：你会系统性地偏爱那些第一轮就开始写代码的 agent，哪怕它们最终并没有更快地到达可 merge 状态。

所以我必须切换一个度量单位。我不再看”它多久给出第一版”，我改成看几个更冷的指标：

  • 首次通过率：第一次交付能通过多少测试、lint、build、smoke；
  • 返工轮数：从 kickoff 到可 merge，人和 agent 一共来回多少次；
  • 误改范围：它有没有动了不该动的地方；
  • 收敛时间：从任务被提出到可以放心合并，全局花了多少时间；
  • 兜底脑力：我为了让它”不出事”，私下花了多少精神力。

这一组指标合起来，我称之为收敛时间。它才是 AI coding 真正的效率单位。响应时间只是它的一个很小的子集。

一旦你开始看收敛时间而不是响应时间，你对很多事情的判断都会反转。那些”慢吞吞先读代码、先问问题、先出 plan”的模型或流程，看起来像是在浪费时间，实际上是在用前期的同步成本换取后期的返工减免。这是一个非常经典的投资式思维——前期多付出一点理解成本，后期省下十倍的修补成本。

从这个角度讲，AI coding 的效率，不是一种速度问题，是一种利率问题。你愿意用多少前期时间，换取多少后期的稳定。

身份的重新定义：从 programmer 到 orchestrator

讲到这里，我不得不面对那个一开始让我焦虑的问题——如果最容易被 AI 取代的是 building，那”程序员”这个身份还剩什么？

Peter 给了我一个词：builders。他说 OpenClaw 的使用者并不只是工程师，还包括创业者和没有正式编程背景的人。真正的变化不只是技术本身，而是 access——更多人第一次拥有了把想法推进成现实的能力。

这句话有两层含义。浅的那层是：”不会写代码也能做软件了”。深的那层是——“会写代码”正在从一个门槛变成一个底层技能，它本身不再是核心竞争力。

换句话说，程序员曾经享有的那道护城河正在快速塌方。但这不意味着程序员的价值在消失，而是价值的分布发生了变化。过去价值集中在”我能写”，现在价值集中在”我能让系统稳定地写”。

我对自己的定义也因此要重写。我不再是 programmer（程序员），我是 orchestrator（编排者）。orchestrator 的工作至少包括六件事：

  1. 把一个模糊的愿望压成一个可被执行的系统；
  2. 为 agent 组织出它不会跑偏的上下文；
  3. 定义目标、边界和不可触碰的部分；
  4. 分配执行节奏和验证时机；
  5. 识别 agent 产出的语义风险；
  6. 把每次失败沉淀进一个越用越顺的流程。

这六件事里没有一件是靠”手速”解决的，全部都是靠”判断”。而判断这件事，是一种很难被模型短期替代的能力，因为它依赖的是长时间的经验内化和对具体情境的敏感。

所以真正让我松口气的，不是”AI 还取代不了我”，而是**”我要训练的东西从外化变成了内化”**。外化的东西（代码本身）被商品化了，内化的东西（判断、组织、边界感）反而升值了。

带 agent，本质上是带一个从不疲倦的团队

做 orchestrator，还有一个隐性的心理转变——你从一个执行者，变成了一个管理者。

很多程序员最初会抗拒这个转变，我一开始也是。因为我们选择这份工作，本来就是因为喜欢自己动手、讨厌开会、不喜欢在代码里嗅到别人留下的味道。但在 agent 时代你跑不掉——你带的不是人，是 agent，但原理几乎一样。

带 agent 的第一课，和带人一样，是放弃”必须按我的方式写”。

一个人类同事的代码，如果风格和你不一样但结果是对的、可维护的、能通过测试的，你通常会接受。但同样的代码如果是 agent 写的，人很容易就掉进一种”我为什么不自己写”的情绪里。这种情绪是有腐蚀性的——它会让你把大量时间浪费在审美上，而把真正需要判断的地方（契约、行为兼容、关键路径、回滚、可观测性）反而忽略掉。

所以我强迫自己切换标准。我不再用”像不像我写的”评价代码，而用”契约有没有被满足”评价代码。

具体是几个问题：

  • 这段代码是否满足它声明的 contract？
  • 有没有破坏现有行为？
  • 测试是否覆盖了关键路径？
  • 上线后是否可观测？
  • 出问题能不能快速回滚？

如果这些问题都过关，它不必长得像我写的。这不是在降低标准，而是在切换标准——从”手感标准”切换到”收敛标准”。

一旦你真正做出这个切换，你会发现你的产出结构也变了。你不再是一个独奏者，你是一个指挥者。 独奏者关心每一个音符的细节，指挥者关心整首曲子的结构。这是两个完全不同的能力维度。

安全不是补丁，是 agent 的产品形态本身

管理学讲完了，还有一个我必须正视的问题：安全。

Peter 加入 OpenAI 的那篇博客里说过，他下一步想做的是让普通人也能使用的 agent，但这需要更多关于安全的思考，以及接触最新模型和研究。Reuters 在报道 OpenClaw 的流行时，也特别提到错误配置可能导致网络攻击和数据泄露风险。

这两件事指向同一个结论——agent 和 chatbot 最本质的区别是，chatbot 只是说话，agent 会动手。当它动手的时候，它代表的是你的账号、你的权限、你的生产环境。

这意味着在 AI coding 的语境下，安全不能再被理解成”事后补一层”。它必须被写进 agent 的产品形态。凡是让 agent 改代码、动配置、连生产、调外部 API，都必须默认加一层安全原语。

具体就是——最小权限、dry-run、二次确认、敏感信息隔离、diff trace、rollback、kill switch。这些不应该是”高级选项”，它们应该是默认设施。

我更倾向于把这件事反过来表述——一个 agent 真正值得长期托付的标准，不是它能力多强，而是它行为可审计、权限可限制、错误可止血、影响范围可控制。能力强的 agent 在兴奋期最受追捧，但能长期活下去的，一定是被写进了安全边界的那一类。

把失败归因给系统，而不是归因给人格

最后我想谈一个最容易被忽略、但对长期成长最重要的事：归因。

你真的开始用 AI coding，你会撞到一堆让人挫败的瞬间——模型跑偏、上下文没读全、方案过度设计、测试没覆盖、改动范围失控。每一次都会让你心里升起一种”我是不是不行”的质疑。

这种质疑是很正常的，但如果不处理，它会慢慢把你推到一种防御性姿态里——要么怪自己，要么怪模型。

这两种解释都便宜，但都不准确。

更工程化的解释是：我的 harness 还不够好，任务边界还不够清楚，验证机制还不够强，同步流程还有洞。

这个归因方式之所以重要，是因为它的对象是系统，不是人格。当你把问题归到系统上，你下一步就知道要改什么——改 kickoff 模板，改测试优先级，改 rollback 机制，改上下文收集的顺序。失败就不再是一个让你自我怀疑的事件，而是一个让你系统持续升级的输入。

这才是真正的 playful 心态。不是随便玩，是允许失败、但让每一次失败都转化成系统的一次小增量。

我把这些压成一套 kickoff 模板

讲了这么多，我最后把它压成一套我每次任务都会用的 kickoff 模板。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
任务挡位：
- 探索 / 设计 / 实现 / 修复 / 上线

任务目标：
- 这次必须完成什么
- 成功之后，用户或系统会看到什么变化

明确边界：
- 这次不做什么
- 哪些文件、接口、表结构、状态机禁止擅自扩展
- 哪些行为必须保持兼容

执行要求：
- 先读哪些上下文
- 是否必须先出 plan
- 是否必须先写测试
- 哪些动作需要二次确认后再执行

验证标准：
- 必须通过哪些测试、lint、build、smoke
- 必须提供哪些 diff、日志、风险说明
- 是否需要 rollback plan 或 feature flag

输出格式：
- 先给结论
- 再给变更点
- 再给风险点
- 最后给验证证据

这个模板最核心的思想只有六个字：先同步，再生成。不要把 agent 当成一个马上开写的实习生，要把它放进一个有目标、有边界、有验证、有回滚的执行系统里。

写在最后：从手艺人到编排者

我开头说这件事让我焦虑。走到这里，我发现焦虑已经被重构成了方向。

过去我定义自己是一个”会写代码的人”，这个定义在新范式里会越来越薄。新的定义对我更友好，也更有意思——我是一个能把问题组织成可被智能系统解决的人。

这个定义的好处是，它不依赖任何一个具体的模型、任何一个具体的工具、任何一个具体的流行语。它依赖的是我对问题的判断力、对边界的敏感度、对系统的设计感。

这些东西不会被下一代模型废掉。它们反而会因为模型更强而更显得稀缺。

Peter Steinberger 最重要的启发，对我来说不是他提供的某个工具，而是一个非常朴素的心智切换——

软件生产正在从手工艺变成系统编排。未来最有价值的人，不是写代码最快的人，而是最会把问题组织成可执行、可验证、可收敛系统的人。

这件事值得我重新练。

发表于 | 分类于

从写代码到编排系统：我从 Peter Steinberger 身上学到的 AI Coding 方法论

——Paul Graham 风格：短句、直白、翻转

大多数人搞错了

大多数人以为 AI 让程序员变快了。

这是错的。

Peter Steinberger 说得很清楚：瓶颈从构建变成了同步。

这是两件事。构建便宜了，同步就贵了。贵的那头，才是你该去的地方。

我花了一段时间才真的理解这句话。一旦理解了，很多事情开始变得显而易见。这篇文章就是这些”显而易见的事”。

构建便宜了

写代码曾经很贵。

不是因为键盘贵，是因为把一个想法翻译成能跑的代码，消耗脑力。现在一个好的 agent 可以十分钟替你做完。

这件事的意义不是”省了十分钟”。意义是——这十分钟里的知识，不再是你的护城河。

你可能已经感觉到了。那种”我会用这个框架”的骄傲，正在变薄。那种”我能一口气写出一个 CRUD”的自信，也开始不太值钱。这不是因为你退步了。是因为这件事本身贬值了。

承认这件事并不丢人。丢人的是不承认。

同步变贵了

把构建想象成发电厂。

过去你自己发电，自己用。现在有了便宜到可以随便开的电，你突然发现真正的问题是电网——电怎么送到对的地方，怎么不过载，怎么不着火。

这就是同步。

需求和实现要同步。实现和测试要同步。测试和设计要同步。几个 agent 的分支之间要同步。生产环境和假设要同步。

一旦有一个地方不同步，整件事开始返工。

过去这些同步成本被藏在你自己的脑袋里。现在你的脑袋不参与写代码了，它们就暴露了出来。很多人把这种暴露误认为”AI 不好用”。其实不是 AI 不好用，是同步成本一直在那里，只是你以前没看见。

如果你的 AI workflow 总是返工，多半不是模型不够强，是同步机制太差。

Spec 是控制面板

我们对 spec 一直有一种奇怪的态度。

我们觉得 spec 是写给别人看的说明书。能省就省。能糊弄就糊弄。真正重要的东西存在写代码的人脑子里。

在手工时代这种态度是有效的，因为确实有一个人的脑子装着这些东西。

在 agent 时代，这种态度是灾难性的。

因为 agent 的脑袋里什么都没有。它只有你写下来的东西。

所以 spec 不再是说明书。它是 agent 的控制面板。

好的 spec 不是写得多，是约束得准。它要告诉 agent：

哪里可以动，哪里不能动。
哪里可以重写，哪里只能修补。
哪些测试必须先写，哪些行为必须兼容。
哪些风险必须在动手前说清楚。

spec 的真正作用，是让 agent 不要乱长。

你会惊讶地发现，一个 agent 最大的危险不是它做不到，而是它做得太多。你让它改一个函数，它重写了一个模块。你让它修一个 bug，它升级了你的架构。这件事不是 agent 的错，是你没给它画好边界。

Spec 就是边界。

速度是陷阱

我们都想要快。所以我们喜欢那些上来就开始写代码的 agent。

这是一个陷阱。

Peter 比较过 Codex 和 Opus。他说有些模型会先花很久读代码，看起来慢；有些模型一上来就写，看起来快。但后者在大改动时经常漏上下文，最后不得不一直打补丁。

表面上的快，是未来的慢。

你真正要看的，不是第一轮有多快。是从任务被提出，到能放心 merge，一共走了多少轮。

我给它起了个名字：收敛时间。

收敛时间由几个东西决定——首次通过率、返工轮数、误改范围、你兜底花掉的脑力。

一个 agent 第一轮写得飞快，但引入了一堆问题，它并不快。一个 agent 慢慢读代码、先出 plan、先写测试，但一次通过，它反而是真的快。

响应时间是幻觉。收敛时间才是真的。

你要优化的单位，从 response time 换成 convergence time。

这件事一换，很多选择就反过来了。

你已经不是 programmer 了

Peter 用了一个词：builders。

他说 OpenClaw 的用户不只是工程师，也包括没有编程背景的创业者。真正的变化不是技术本身，是 access——更多人第一次有了把想法推进成现实的能力。

翻译一下：

“会不会写代码”正在变成一个低层问题。高层问题是：你有没有一个真的问题，你能不能定义目标，你能不能判断结果。

这意味着你要重新定义自己。

你不是 programmer。你是 orchestrator。

programmer 的价值曲线会越来越平。orchestrator 的价值曲线会越来越陡。

programmer 花时间把代码写出来。orchestrator 花时间让一整个系统稳定地产出结果。前者的护城河在变薄，后者的护城河在变厚。

如果你把自己定义成”会写 Java 的工程师”，你的价值会被 AI 慢慢压低。

如果你把自己定义成”能把问题组织成可被智能系统解决的人”，你的价值会被 AI 放大。

两个定义，结局完全不同。这不是抽象的哲学问题，这是一个非常具体的职业选择。

带 agent 像带团队

从 programmer 到 orchestrator，最难的部分是心理的。

你从一个执行者变成了一个管理者。

大多数程序员选择这份工作，本来就是因为讨厌当管理者。但在 agent 时代你没法逃——你带的不是人，是 agent，但道理一样。

第一件要放下的事：“它必须按我的方式写代码”。

一个人类同事的代码，如果风格和你不一样但跑得起来、通过了测试、可维护，你会接受。agent 的代码也应该用同样的标准。

不然你会把所有时间花在审美上，而不是花在风险上。

更合理的评判标准是这些问题：

  • 这段代码是否满足 contract？
  • 有没有破坏现有行为？
  • 测试是否覆盖了关键路径？
  • 上线后是否可观测？
  • 出问题能不能快速回滚？

如果这些问题都过关，它不必长得像你写的。这不是降低标准，这是切换标准。

手工时代的标准是”代码是否符合我的手感”。

agent 时代的标准是”系统是否可控地收敛”。

这是两个完全不同的事。

安全是产品，不是补丁

有一件事很多人不愿意想，所以我直接说。

agent 和 chatbot 的区别是，chatbot 只是说话，agent 会动手。它动手的时候，代表的是你的账号、你的权限、你的生产环境。

这意味着，安全不再是附属问题。安全就是产品。

Peter 在加入 OpenAI 的博客里说，让普通人用 agent 需要更多关于安全的思考。Reuters 报道过 OpenClaw 带来的安全担忧——错误配置可能导致网络攻击和数据泄露。

以后凡是让 agent 改代码、动配置、连生产、调外部 API，都必须默认加一层安全原语。

最小权限。
Dry-run。
二次确认。
敏感信息隔离。
Diff trace。
Rollback。
Kill switch。

这些不是高级选项。这些是默认设施。

真正能落地的 agent，不是能力最强的 agent，而是可审计、可限制、可止血、可控制影响范围的 agent。

能力最强的 agent 在兴奋期最受欢迎。但长期活下去的，只有安全边界最完整的那一类。

失败归因给系统

你真的开始用 AI coding，你会失败。

很多次。

模型跑偏。上下文没读全。方案过度设计。测试没覆盖。改动范围失控。

每一次都让你想：是不是我不行。

停。

不是你不行。也不是模型不行。

是你的系统不行。

具体来说：

harness 不够好。
任务边界不够清楚。
验证机制不够强。
同步流程有洞。

这种归因方式的价值在于，它是工程化的。它给你下一步该改什么，而不是给你一通情绪。

每一次失败都应该变成系统的一次升级。kickoff 模板更准了。测试介入更早了。rollback 更显式了。上下文收集的顺序更合理了。

Peter 说建议 builder 更 playful，允许自己慢慢变强。play 不是随便玩。play 是允许失败，但让每次失败都换来系统的一个增量。

这个心态本身，就是一种工程技能。

一个模板

把上面这些东西压成一个你今天就能用的 kickoff 模板：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
任务挡位：
- 探索 / 设计 / 实现 / 修复 / 上线

任务目标：
- 这次必须完成什么
- 成功之后，用户或系统会看到什么变化

明确边界：
- 这次不做什么
- 哪些文件、接口、表结构、状态机禁止擅自扩展
- 哪些行为必须保持兼容

执行要求：
- 先读哪些上下文
- 是否必须先出 plan
- 是否必须先写测试
- 哪些动作需要二次确认后再执行

验证标准：
- 必须通过哪些测试、lint、build、smoke
- 必须提供哪些 diff、日志、风险说明
- 是否需要 rollback plan 或 feature flag

输出格式：
- 先给结论
- 再给变更点
- 再给风险点
- 最后给验证证据

这个模板的核心思想只有六个字。

先同步，再生成。

不要把 agent 当一个马上开写的实习生。把它放进一个有目标、有边界、有验证、有回滚的系统里。

编排

很多年以后，人们会回头看 2026 年，说那是软件生产的一次底层翻转。

翻转的那一刻看起来很安静。没有爆炸，没有裁员公告，没有戏剧性的新闻。只是有一群人突然意识到，自己训练的肌肉不再是以前那组了。

在旧范式里，程序员的价值来自亲手把代码写出来。

在新范式里，程序员的价值来自于定义问题、组织上下文、设置约束、分配执行、验证结果、控制风险、沉淀流程。

前者叫手艺。

后者叫编排。

手艺依然有价值。但编排的价值曲线更陡。如果你想做一件长期回报递增的事，选编排。

Peter Steinberger 的启发，压缩成一句话就是——

未来最有价值的人，不是写代码最快的人，而是最会把问题组织成可执行、可验证、可收敛系统的人。

这句话值得你今天就开始相信。

因为未来的竞争不在谁打字快。

在谁能让一整个智能系统围着他的问题稳定转起来。

发表于 | 分类于

从写代码到编排系统：我从 Peter Steinberger 身上学到的 AI Coding 方法论

——纳瓦尔风格：箴言压缩体

起点

Peter Steinberger 加入了 OpenAI。OpenClaw 转入基金会。

这不是新闻。这是信号。

信号是——软件的瓶颈已经换了位置，而大多数人还在旧瓶颈上卷。

下面是我从这件事里抽出来的所有箴言。每一条都可以单独读，也可以合起来读。

第一条：瓶颈换了位置

AI coding 的瓶颈不是生成，是同步。

过去，你的时间花在”把想法变成代码”。
现在，模型替你花掉这段时间。
结果是，你的时间必须花在”让多个版本的真实保持一致”。

同步的对象包括：需求和实现、实现和测试、测试和设计、多个 agent 的分支、生产环境和假设。

构建便宜了，同步就贵了。
贵的地方，才是你该去的地方。

第二条：返工不是模型的问题

你发现 AI 总在返工。你怪模型。

错了。

如果你的 workflow 总在返工，多半不是模型不够强，是同步机制太差。

返工是成本溢出的信号。成本溢出的那一层，就是你该修的那一层。

第三条：你不是 programmer，你是 orchestrator

会写代码，曾经是一张长期饭票。

现在不是了。

“会不会写代码”正在变成一个底层问题。
“能不能把问题组织成可被智能系统解决的”，才是高层问题。

低层问题会被模型越做越便宜。
高层问题会因为模型变强而越来越贵。

把自己定义在哪一层，决定了你十年后的价格。

第四条：Builder 这个词

Peter 用了一个词：builders。

Builder 不是程序员。
Builder 是那些有问题要解决、并且能动手让结果落地的人。

这个世界缺的从来不是写代码的人，缺的是能把一个模糊愿望压成可执行系统的人。

Builder 不一定会写代码，但 builder 一定懂得如何组织问题。
会写代码的人如果不会组织问题，就会被便宜的替代品追上。

第五条：Spec 是控制面板，不是说明书

文档过去是写给人看的。

现在不是了。

Spec 是 agent 的控制面板。
好的 spec 不是写得多，是约束得准。

它告诉 agent 哪里可以发挥、哪里必须保守；哪里可以重构、哪里只能局部修复；哪些测试必须先写、哪些行为必须保持兼容。

spec 的真正价值是——让 agent 不要乱长。

一个 agent 最大的危险不是它做不到，而是它做得太多。
你不约束它，它就给你长出一个你不需要的系统。

第六条：响应时间是幻觉

你喜欢那些”上来就写”的 agent。

你被骗了。

响应时间是幻觉。收敛时间才是真的。

收敛时间 = 从任务被提出，到可以放心 merge，一共走了多少轮。

它的内部参数包括：首次通过率、返工轮数、误改范围、你兜底花掉的脑力。

一个 agent 第一轮飞快但引入一堆问题——它不快。
一个 agent 先读代码、先问问题、先出 plan，最后一次通过——它才真快。

你要优化的单位，从 response time 换成 convergence time。

这件事一换，很多选择会反过来。

第七条：前期慢一点是一种投资

慢慢读代码、先写 plan、先写测试——
这些不是拖延。

这是用前期的同步成本，换取后期的返工减免。

效率这件事，本质是一种利率问题。
你愿意用多少前期时间，换取多少后期的稳定。

愿意前付、眼界拉长的人，永远赢愿意即时满足的人。

第八条：带 agent 和带团队是一回事

从 programmer 到 orchestrator，心态变了。

你从执行者变成了管理者。

带 agent 的第一课和带人一样——放弃”它必须按我的方式写”。

契约满足、行为兼容、关键路径有测试覆盖、可观测、可回滚——
如果这些都过关，它不必长得像你亲手写的。

手工时代的标准是”代码是否符合我的手感”。
agent 时代的标准是”系统是否可控地收敛”。

这不是降低标准，是切换标准。

第九条：审美有价值，但不是首要价值

你会忍不住要求 agent”写得像你”。

这种冲动很自然。
但它是一种陷阱。

如果你把时间花在审美上，你就没时间花在风险上。

审美无限优化，边际收益递减。
风险一旦失控，会直接清零。

在 agent 时代，时间要先分配给可能让你清零的地方，再分配给让你舒服的地方。

第十条：安全是产品，不是补丁

chatbot 只是说话。
agent 会动手。

动手的时候，它代表的是你的账号、权限、生产环境。

这意味着——安全不再是附属问题。安全就是产品。

凡是让 agent 改代码、动配置、连生产、调外部 API，都必须默认加一层安全原语：
最小权限、dry-run、二次确认、敏感信息隔离、diff trace、rollback、kill switch。

这些不是”高级选项”。
它们是默认设施。

第十一条：强不如稳

兴奋期里，大家追”能力最强的 agent”。

周期长了，你会发现——

真正长期被托付的 agent，不是能力最强的，而是行为可审计、权限可限制、错误可止血、影响范围可控制的。

强在短期赢注意力，稳在长期赢信任。
信任才是复利。

第十二条：失败归因给系统，不归因给人格

你会失败，很多次。

模型跑偏。
上下文没读全。
方案过度设计。
测试没覆盖。
改动范围失控。

每一次都让你想：我是不是不行。

停。

不是你不行，也不是模型不行。是你的系统不行。

harness 不够好。
任务边界不够清楚。
验证机制不够强。
同步流程有洞。

这种归因方式的价值在于——它给你下一步该改什么。
自我怀疑给不了这个。

第十三条：每次失败都要换来系统的一次小增量

Peter 说 builder 要更 playful。

playful 不是”随便玩”。

playful 是允许失败，但要求每次失败都能被系统吸收成增量。

kickoff 模板更准了。
测试介入更早了。
rollback 更显式了。
上下文收集更合理了。

复利就是这么来的。
不做这件事的人，每一次失败都是一次纯损失。
做这件事的人，每一次失败都是一次未来的利息。

第十四条：能力是在探索里长出来的

Peter 在 TechCrunch 的采访里说，他一开始也没有完整计划，很多东西是在探索中长出来的。

所以：

不要期待自己第一天就是专家。
AI coding 是一门乐器，不是一句咒语。

咒语靠记忆。
乐器靠练习。
你要练的是手感、节奏、判断力，不是某一句 prompt。

第十五条：先同步，再生成

这是全部箴言里最重要的一条。

先同步，再生成。

不要把 agent 当成一个马上开写的实习生。
把它放进一个有目标、有边界、有验证、有回滚的系统里。

把这六个字刻进流程，你就已经拉开了和大多数 AI coding 使用者的差距。

第十六条：Kickoff 模板

把前面十五条压成一张表：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
任务挡位：
- 探索 / 设计 / 实现 / 修复 / 上线

任务目标：
- 这次必须完成什么
- 成功之后，用户或系统会看到什么变化

明确边界：
- 这次不做什么
- 哪些文件、接口、表结构、状态机禁止擅自扩展
- 哪些行为必须保持兼容

执行要求：
- 先读哪些上下文
- 是否必须先出 plan
- 是否必须先写测试
- 哪些动作需要二次确认后再执行

验证标准：
- 必须通过哪些测试、lint、build、smoke
- 必须提供哪些 diff、日志、风险说明
- 是否需要 rollback plan 或 feature flag

输出格式：
- 先给结论
- 再给变更点
- 再给风险点
- 最后给验证证据

这不是表格。
这是一套被压缩过的方法论。

第十七条：两种价值曲线

两种自我定义，两条未来曲线。

“我是一个会写代码的工程师”——这条曲线的斜率会越来越平。
“我是一个能把问题组织成可被智能系统解决的人”——这条曲线的斜率会越来越陡。

选哪一条，决定了你五年后的定价。

第十八条：新价值公式

用一个公式收尾：

价值 = 问题定义力 × 上下文组织力 × 边界设置力 × 验证严格度 × 风险控制力 × 流程沉淀力

这六个变量全部是乘法关系。
任何一项趋近零，整体趋近零。

过去，公式里可能只有一项是”写代码速度”。
现在，写代码速度已经不再是独立变量了——它被模型吸收进了环境常数。
你要训练的是其他六项。

过去训练的是手速。现在训练的是结构感。

第十九条：新范式的一句话

把这篇文章能压缩成一句话，就是这一句——

软件生产正在从手工艺，变成系统编排。

旧范式里，程序员的价值来自亲手写代码。
新范式里，价值来自定义问题、组织上下文、设置约束、分配执行、验证结果、控制风险、沉淀流程。

前者的护城河在塌方。
后者的护城河在隆起。

第二十条：结束语

Peter Steinberger 给我的全部启发，能抄到笔记本上的，只有两行。

未来最有价值的人，不是写代码最快的人，
而是最会把问题组织成可执行、可验证、可收敛系统的人。

这两行不是结论，是起点。

从今天开始，每一次任务——先想边界，再想步骤；先想验证，再想实现；先想回滚，再想上线；先想”如何让智能系统稳定产出”，再想”我要自己动手做什么”。

你就已经在训练一条在未来十年复利最高的肌肉了。

剩下的，交给时间。

发表于 | 分类于

动词

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

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

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

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

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 多强”，而是“一个人的工作流，可以被升级到什么程度”。

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

发表于 | 分类于

从写代码到编排系统：我从 Peter Steinberger 身上学到的 AI Coding 方法论

——吴军风格：历史视角，范式叙事

一、一次小型的范式迁移

2026 年 2 月，Peter Steinberger 宣布加入 OpenAI。他做的 OpenClaw 转入基金会，继续保持开放和独立。Reuters 报道这件事的时候，用的一句话是——OpenClaw 已经从一个开源 bot 变成了广受关注的个人 agent 项目。

如果只是从人事新闻的角度去看，这件事并不特别。在技术圈里，个人项目被大公司收编、作者加入平台公司的例子每年都有。但如果把它放在一个更长的时间尺度上去看，它其实是一次小型的范式迁移的缩影。

过去三十年的软件史，大致可以分成三个阶段。

第一个阶段是手工作坊阶段。一个人、一台电脑、一份源代码。软件的价值几乎全部来自个体手艺。第二个阶段是工业化流水线阶段。版本管理、持续集成、自动化测试、云服务，把手艺人的劳动标准化、分工化、规模化。而现在我们正在进入第三个阶段——智能编排阶段。在这一阶段，代码不再主要由人写，而是由多个智能体在人的指挥下产出，人的角色从”生产者”变成”调度者”和”裁判”。

Peter Steinberger 加入 OpenAI 之所以值得记录，不是因为它改变了一个人的职业轨迹，而是因为它恰好落在这次范式迁移的节点上。他在 TED 2026 的表达里说过一句很关键的话——软件里大量无聊、重复、费力的部分，AI 已经可以承担；真正的瓶颈开始从”构建”转向”同步”。他还把 OpenClaw 描述为一种个人 AI 的操作系统，而不是一个单独的应用。

这句话如果放在 1995 年会很超前，放在 2015 年会很激进，放在 2026 年，只是一个工程师对时代的冷静陈述。

这篇文章要做的事情，就是把 Peter 的这个判断，放回到它所属的历史脉络里，然后拆成几个可操作的层面，供我们自己在日常工作中使用。

二、从”构建”到”同步”——瓶颈的转移

任何一个长周期产业的发展，总是在不断经历瓶颈的转移。

汽车工业刚起步的时候，瓶颈是怎么造出一辆可靠的车，那一代的英雄是福特。等到造车这件事本身被流水线解决之后，瓶颈转移到了怎么把车高效地送到消费者手里，于是出现了现代意义上的经销商网络和市场体系。再到后来，瓶颈又转移到了怎么让车持续产生数据、服务、金融价值，于是有了今天的智能汽车。

软件产业的演化路径和这个非常像。

在手工作坊阶段，软件的瓶颈是”能不能写出来”。会写代码本身就是一种稀缺能力。那一代的英雄，是那些一个人做出令人惊叹产品的独立开发者。

在工业化流水线阶段，瓶颈变成”能不能稳定地发出来”。这催生了 CI/CD、SRE、平台工程这一整套工程文化。那一代的英雄，是那些让一千个工程师的协同变得有秩序的人。

而到了智能编排阶段，Peter 告诉我们，瓶颈再一次转移了，这次是从”构建”转到了”同步”。

要理解这件事，我们得先做一个区分。”构建”是把一个想法翻译成能跑的代码的过程；”同步”是让多方面的真实保持一致的过程——需求和实现要一致，测试和设计要一致，多个 agent 的修改要一致，生产环境和假设要一致。

在手工阶段，这两件事的成本都压在一个人的脑子里。在工业化阶段，构建被流程化了一部分，但同步主要靠文档和会议。而到了智能编排阶段，构建的成本被模型迅速压低，同步的成本反而第一次以清晰的形式暴露出来。

这就是为什么很多人在使用 AI coding 时，会感到一种奇怪的疲惫——不是写代码更累了，而是对齐这件事在他们身上变得更重了。这不是 AI 的问题，这是瓶颈迁移之后，重力场的位置变了。

识别瓶颈所在，并把自己的注意力搬到新瓶颈上，是任何一次范式迁移里最关键的事。

三、身份的重新洗牌——从 programmer 到 builder

历史上，每次生产方式的变革，都会伴随一次身份的重新洗牌。

工业革命的时候，手工匠人的一部分技能贬值了，但一种新的角色诞生了——工程师。会计变成了财务，账房先生变成了 CFO。计算机革命的时候，打字员贬值了，程序员兴起了。而每一次这样的身份重组，总有一批人因为及时重写自我定义而受益，也总有一批人因为没能及时重写而被动地被甩下。

Peter 在他的工作里用了一个很值得留意的词——builders。他说 OpenClaw 的用户并不只是工程师，还包括创业者和没有正式编程背景的人。真正的变化不只是技术本身，而是 access——更多人第一次拥有了把想法推进成现实的能力。

这句话如果换成历史语言，大致是这个意思——“写代码”这项技能的门槛，正在从一个职业门槛，下降到一个底层工具门槛。就像 Excel 在 90 年代曾经是会计师的专业技能，后来变成所有白领的通用技能一样。

对传统程序员来说，这个趋势既是威胁也是机会。

威胁在于，”会写代码”不再是一张长期有效的饭票。护城河在变薄。

机会在于，需要被解决的问题，比以前多得多。因为 access 的扩散意味着更多人开始有能力把自己的想法产品化，而这些想法的落地都需要真正懂得如何把问题结构化的人。

所以合理的自我重写，不是把自己定义成”会写某种语言的工程师”，而是把自己定义成”能把一个模糊问题组织成可被智能系统解决的方案的人”。

用更古典的语言讲，这是从匠人到工程总监的身份跃迁。匠人的价值来自手艺，工程总监的价值来自结构。前者的价值曲线会越来越平，后者的价值曲线会越来越陡。

四、文档的重新定价——spec 是控制面板

每一次范式迁移，也会让一些原本被低估的事物，重新被定价。

在手工作坊阶段，文档是一件经常被省略的事。原因很简单，关键信息全部装在写代码的人脑子里，文档是锦上添花。到了工业化流水线阶段，文档的重要性上升了，因为协作的范围变大了，但它依然是”给人看的说明书”——是协作的附属物。

到了智能编排阶段，Peter 的实践让我们看到一件更深的事——文档的性质变了，它不再是附属物，而是控制面板。

这件事怎么理解呢？我们可以类比一下工业时代。一家工厂的图纸、工艺标准、QA 流程，在外人看来只是”说明文件”，但实际上它们是工厂这台机器的控制系统。工人依据它动作，机器依据它运转，质检依据它判断。没有这套图纸，工厂寸步难行。

agent 时代的 spec 大致是同一个角色。它不是给阅读者的消遣，而是给执行者的指令。

这意味着我们在写 requirements、design、implementation plan 的时候，标准要升级。

过去标准是”写清楚”，现在标准是”约束得准”。
过去重点是覆盖细节，现在重点是划定可变区与禁区。
过去目的是帮人理解项目，现在目的是防止 agent 乱长。

更具体地说，好的 spec 要能告诉 agent：哪里可以发挥，哪里必须保守；哪里可以重构，哪里只能局部修复；哪些测试必须先写，哪些行为必须兼容；哪些风险必须在动手前说清楚。

你会发现，这样写出来的 spec 不再是一份”项目备忘录”，它更像是一张施工图。而施工图的价值，和备忘录的价值，根本不是同一个量级。

五、效率的新度量——收敛时间

瓶颈变了，身份变了，文档变了，度量效率的方式自然也要变。

在工业时代，衡量工厂效率的指标从最早的”单件工时”演化到”整条产线的节拍”，再演化到”从订单到交付的总周期”。每一次度量单位的升级，都是一次工厂经营者认知的升级。

软件行业也在经历类似的事。

过去我们习惯用”响应时间”衡量 AI 的效率——模型多久给出第一版回答。Peter 在《Shipping at Inference-Speed》里做过一个对我很有启发的比较——有些模型先花很久读代码，表面上更慢，但更可能修对；有些模型更快、更积极，但在大改动时常漏上下文，之后不断修修补补。

这句话里藏着一个指标切换。

真正决定工程效率的，不是第一轮有多快，而是从任务被提出，到可以放心合并，一共走了几轮。

这个”几轮”才是新度量。我把它叫做收敛时间。它由几个子指标共同决定：首次通过率、返工轮数、误改范围、从 kickoff 到可 merge 的总时间、人为兜底花掉的脑力。

一旦度量单位从响应时间换成收敛时间，整个评估体系就会翻转。那些”上来就写”的 agent，在响应时间上赢；但在收敛时间上经常输。那些”先读代码、先出 plan、先写测试”的流程，看起来慢，却常常是真正快的。

这就像工业时代那个经典教训——局部最优未必是全局最优，第一工序提速反而可能拖慢整条产线。

所以经营一个 AI coding workflow，和经营一条产线在原理上没什么不同。你得盯着总吞吐，而不是盯着某一台机器的快慢。

六、管理学的回归——带 agent 像带团队

智能编排阶段还有一个耐人寻味的现象——工程师重新被管理学需要了。

过去几十年，很多程序员选择这份工作，正是因为讨厌管理、讨厌会议、希望专注于自己动手。但 agent 时代让这种逃避变得不可能。

原因很简单：你不再只是执行者。你手下（严格说是你身边）站着一批可以自主行动的智能体。你要决定它们做什么、不做什么、以什么顺序做、在哪里停下来让你看一眼。这件事和管理一个小团队在结构上没有本质区别。

带 agent 的第一课，和带人一样——放弃”它必须按我的方式写”。

过去我们 review 一个人类同事的代码，只要行为正确、契约满足、测试覆盖、可维护、可回滚，就会接受哪怕风格不那么顺眼的写法。同样的宽容度，需要被迁移到 agent 上。

如果你总是要求 agent 写得”像你亲手写的”，你的时间会被消耗在审美和习惯上，而不是消耗在真正有风险的工程决策上。这是一种不经济的工作方式。

更合理的 review 清单是这些问题：

  • 是否满足 contract？
  • 有没有破坏现有行为？
  • 测试是否覆盖了关键路径？
  • 上线后是否可观测？
  • 出问题能不能快速回滚？

如果这些问题都过关，它不必长得像你写的。这不是降低标准，而是迁移标准。从”手感标准”迁移到”收敛标准”。

这种迁移其实很符合管理学的常识。一个好的团队领导，从来不会要求每个下属写出一模一样的代码，他要求的是一个可以持续产生正确结果的团队。

七、安全不再是附属——agent 时代的工程伦理

每一次生产力的跃迁，都会伴随新的风险类别的出现。

工业革命带来了职业安全问题，于是有了现代劳动法；汽车工业带来了交通事故，于是有了交通规则；互联网带来了数据泄露，于是有了隐私保护。而智能编排阶段带来的，是一种新的风险类别——能动手的智能体带来的风险。

Peter 在加入 OpenAI 的博客里说得很克制——他下一步想做的是让普通人也能使用的 agent，但这需要更多关于安全的思考，以及接触最新模型和研究。Reuters 在报道 OpenClaw 流行时也提到，错误配置可能导致网络攻击和数据泄露风险。

这两段话合起来，其实在讲同一件事——agent 和 chatbot 最本质的区别是，chatbot 只是说话，agent 会动手。当它动手的时候，它代表的是使用者的账号、权限、生产环境。

这意味着在 AI coding 的语境下，安全不能再被理解成”事后补一层”。它必须被写进 agent 的产品形态本身。

工程上，这意味着若干条默认设施：

  • 最小权限；
  • Dry-run；
  • 二次确认；
  • 敏感信息隔离；
  • Diff trace；
  • Rollback；
  • Kill switch。

这些在 AI 狂热期很容易被当成”高级选项”而被跳过。但从更长的时间尺度上看，一个 agent 真正值得托付的标准，不是它能力多强，而是它是否可审计、可限制、可止血、可控制影响范围。

能力最强的那一类 agent 常常在兴奋期最受追捧。但能穿越周期、长期留在产业里的，一定是那些把安全当成产品内置部件的。

八、归因的工程化——失败要归给系统

最后还有一件事，是每一次范式迁移里，个体最难做好的功课——如何解释失败。

智能编排阶段的 AI coding，会有大量的失败。模型跑偏、上下文没读全、方案过度设计、测试没覆盖、改动范围失控，这些都会发生，而且不会完全消失。

在这种情况下，一个工程师对失败的解释方式，决定了他能不能在新范式里持续变强。

两个最便宜的解释都不好。一个是”我不行”，一个是”模型不行”。前者把问题归到人格，后者把问题归到工具。两者的共同缺陷是——它们都不能指向下一步该改什么。

更工程化的解释是：我的 harness 还不够好，任务边界还不够清楚，验证机制还不够强，同步流程还有洞。

这种归因的好处在于，每一次失败都会变成系统的一次小升级。kickoff 模板更准一点，测试介入更早一点，rollback 更显式一点，上下文收集更合理一点。久而久之，你的整个工作系统会开始呈现出复利效应。

Peter 建议 builder 更 playful，允许自己通过探索慢慢变强。playful 这个词不是”随便玩”，它的工程学含义是——允许失败，但要求每次失败都能被系统吸收。这是一种非常专业的心态。

九、新工匠的工作台——一套 kickoff 模板

讲了这么多历史脉络，最后我想把它凝结成一个可以马上使用的工具——一份 kickoff 模板。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
任务挡位：
- 探索 / 设计 / 实现 / 修复 / 上线

任务目标：
- 这次必须完成什么
- 成功之后，用户或系统会看到什么变化

明确边界：
- 这次不做什么
- 哪些文件、接口、表结构、状态机禁止擅自扩展
- 哪些行为必须保持兼容

执行要求：
- 先读哪些上下文
- 是否必须先出 plan
- 是否必须先写测试
- 哪些动作需要二次确认后再执行

验证标准：
- 必须通过哪些测试、lint、build、smoke
- 必须提供哪些 diff、日志、风险说明
- 是否需要 rollback plan 或 feature flag

输出格式：
- 先给结论
- 再给变更点
- 再给风险点
- 最后给验证证据

这套模板背后的思想只有六个字：先同步，再生成。不要把 agent 当成一个马上开写的实习生，而要把它放进一个有目标、有边界、有验证、有回滚的执行系统里。

它不是一张漂亮的表格。它是新工匠的工作台。

十、结语：软件生产的三段论

把前面九节放在一起，我想给出一个简单的三段论。

第一段：软件的瓶颈，从”能不能写出来”到”能不能稳定地发出来”，再到”能不能把多个智能体的工作可控地同步起来”。

第二段：每一次瓶颈的转移，都会伴随身份的重新洗牌、文档的重新定价、效率的重新度量、安全的重新定位、管理学的重新回归。

第三段：在这三段历史的末端，最有价值的人，不是写代码最快的人，而是最会把问题组织成可执行、可验证、可收敛系统的人。

从 Peter Steinberger 身上，我学到的最重要的一课就是这件事。它不是某个工具，不是某个模型，不是某个 prompt，而是一次非常干净的历史观察——

软件生产正在从手工艺，变成系统编排。而每一个想在下一段历史里有位置的工程师，都需要重新认领自己在这条时间线上的位置。

发表于 | 分类于

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

共勉。

发表于 | 分类于

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