从写代码到编排系统：我从 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 的工作至少包括六件事：
- 把一个模糊的愿望压成一个可被执行的系统；
- 为 agent 组织出它不会跑偏的上下文；
- 定义目标、边界和不可触碰的部分；
- 分配执行节奏和验证时机；
- 识别 agent 产出的语义风险；
- 把每次失败沉淀进一个越用越顺的流程。
这六件事里没有一件是靠”手速”解决的，全部都是靠”判断”。而判断这件事，是一种很难被模型短期替代的能力，因为它依赖的是长时间的经验内化和对具体情境的敏感。
所以真正让我松口气的，不是”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 | 任务挡位： |
这个模板最核心的思想只有六个字：先同步，再生成。不要把 agent 当成一个马上开写的实习生，要把它放进一个有目标、有边界、有验证、有回滚的执行系统里。
写在最后：从手艺人到编排者
我开头说这件事让我焦虑。走到这里，我发现焦虑已经被重构成了方向。
过去我定义自己是一个”会写代码的人”，这个定义在新范式里会越来越薄。新的定义对我更友好，也更有意思——我是一个能把问题组织成可被智能系统解决的人。
这个定义的好处是，它不依赖任何一个具体的模型、任何一个具体的工具、任何一个具体的流行语。它依赖的是我对问题的判断力、对边界的敏感度、对系统的设计感。
这些东西不会被下一代模型废掉。它们反而会因为模型更强而更显得稀缺。
Peter Steinberger 最重要的启发，对我来说不是他提供的某个工具，而是一个非常朴素的心智切换——
软件生产正在从手工艺变成系统编排。未来最有价值的人，不是写代码最快的人，而是最会把问题组织成可执行、可验证、可收敛系统的人。
这件事值得我重新练。