从写代码到编排系统：我从 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 | 任务挡位： |
这个模板的核心思想只有六个字。
先同步，再生成。
不要把 agent 当一个马上开写的实习生。把它放进一个有目标、有边界、有验证、有回滚的系统里。
编排
很多年以后，人们会回头看 2026 年，说那是软件生产的一次底层翻转。
翻转的那一刻看起来很安静。没有爆炸，没有裁员公告，没有戏剧性的新闻。只是有一群人突然意识到，自己训练的肌肉不再是以前那组了。
在旧范式里，程序员的价值来自亲手把代码写出来。
在新范式里，程序员的价值来自于定义问题、组织上下文、设置约束、分配执行、验证结果、控制风险、沉淀流程。
前者叫手艺。
后者叫编排。
手艺依然有价值。但编排的价值曲线更陡。如果你想做一件长期回报递增的事，选编排。
Peter Steinberger 的启发，压缩成一句话就是——
未来最有价值的人，不是写代码最快的人，而是最会把问题组织成可执行、可验证、可收敛系统的人。
这句话值得你今天就开始相信。
因为未来的竞争不在谁打字快。
在谁能让一整个智能系统围着他的问题稳定转起来。