从写代码到编排系统：我从 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 | 任务挡位： |
这个模板背后的逻辑，就是把前面七层讲的东西全都物化。第一节讲同步，所以模板先要边界；第二节讲 spec，所以模板有执行要求；第三节讲效率，所以模板要求一次性把验证标准讲清楚，减少返工；第四节讲身份，所以模板的核心是”让 agent 知道自己该做什么、不该做什么”；第五节讲管理，所以输出格式强调结论、变更、风险；第六节讲安全，所以执行要求里留了二次确认和 rollback 的位置；第七节讲归因，所以整个模板的目的是让失败有迹可循、有地方归因。
你看，它不是一个漂亮的表格，它是一套被压缩过的方法论。
结语：软件生产正在从手工艺变成系统编排
讲了这么多层，最后我想把它压成一句话。
软件生产正在从手工艺，变成系统编排。
在旧范式里，程序员的核心能力是亲手把代码写出来。在新范式里，越来越重要的能力是——定义问题、组织上下文、设置约束、分配执行、验证结果、控制风险、沉淀流程。
这是一次真正的身份迁移。它不只是一次工具升级，它改变了一个程序员要训练的肌肉。从手速肌肉，变成结构肌肉；从实现肌肉，变成验证肌肉；从独奏肌肉，变成指挥肌肉。
Peter Steinberger 的启发可以压缩成一句话：
未来最有价值的人，不是单纯写代码最快的人，而是最会把问题组织成可执行、可验证、可收敛系统的人。
这句话，值得你抄下来，贴在显示器边上。