从写代码到编排系统：我从 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 | 任务挡位： |
这套模板背后的思想只有六个字：先同步，再生成。不要把 agent 当成一个马上开写的实习生，而要把它放进一个有目标、有边界、有验证、有回滚的执行系统里。
它不是一张漂亮的表格。它是新工匠的工作台。
十、结语：软件生产的三段论
把前面九节放在一起，我想给出一个简单的三段论。
第一段：软件的瓶颈，从”能不能写出来”到”能不能稳定地发出来”，再到”能不能把多个智能体的工作可控地同步起来”。
第二段：每一次瓶颈的转移，都会伴随身份的重新洗牌、文档的重新定价、效率的重新度量、安全的重新定位、管理学的重新回归。
第三段：在这三段历史的末端，最有价值的人，不是写代码最快的人，而是最会把问题组织成可执行、可验证、可收敛系统的人。
从 Peter Steinberger 身上，我学到的最重要的一课就是这件事。它不是某个工具，不是某个模型，不是某个 prompt，而是一次非常干净的历史观察——
软件生产正在从手工艺，变成系统编排。而每一个想在下一段历史里有位置的工程师，都需要重新认领自己在这条时间线上的位置。