夜雨聆风
最近做了一个公司内部的分享，我非常推荐大家不要再用IDE，而是使用terminal多开操作claude code。其中一个同学就问了我一个问题，如果我不一行行看他写的代码，那怎么能保证这些代码是可以上PROD的呢，这篇文章应该说最权威的回答了：
🃏 大佬名片：Peter Steinberger
Peter Steinberger，他一手打造了 PSPDFKit——这个顶级PDF渲染框架如今运行在全球超过 10 亿台设备上，当年甚至逼得谷歌、苹果、微软只能用他的基准测试来优化自家浏览器。
在把公司做到行业绝对头部后，他卖掉股份，带着财富自由身退江湖，消失了整整三年。直到今年，他因为极度沉迷大模型（Claude/Codex）重出江湖，并在短短几个月内靠一己之力打爆了Github社区，开发出极其火爆的AI个人助理项目 ClaudeBot，现在的 OpenClaw
“代码审查（Code Review）已经死了。现在的 PR 根本不该叫 Pull Request，而应该叫 Prompt Request。我交付代码，但我根本不读代码。” —— Peter Steinberger
为什么一个曾经连一个空格都要纠结的极致架构师，敢把“盲目合并代码”说得这么理直气壮？ 今天我们来看看他用 AI “降维打击”传统软件工程的真实逻辑。
1. 致命Bug：把绝大部分精力耗费在“水管工”代码上
“应用开发本质上就是在把JSON转来转去，为什么要人类亲自去读这些废话？”
很多程序员拒绝使用AI，理由是“AI生成的代码太乱，我必须一行行检查，这比我自己写还慢”。Peter 曾经也是个细节狂魔，甚至在过去花一两个月时间去重构PDF解析里的底层引用机制。
但他敏锐地指出：今天90%的应用软件开发，本质上就是“水管工”。数据从 API 进来是一种格式，存进数据库换一种格式，吐到前端再换一种格式（HTML/Tailwind）。这些枯燥的“转换逻辑”对系统架构本身毫无营养。
Peter 现在的工作模式，像是在玩高强度的《星际争霸》多线操作。
他同时跑着 5 到 10 个 Agent（智能体），把自己的大脑当作CPU的调度中心。在这个终端里分配系统重构任务，在那个终端里让AI去写个新的CLI工具。他只看大方向的“摩擦力”——如果Agent给出的输出耗时异常，或者偏离了架构预期，他才会介入。
“我现在的身份不是写代码的 Typist，而是 Builder 和 Architect。只要系统边界和接口定义对了，中间那些转换数据的烂代码，我连看都不想看。”
2. 高阶心法：“闭环（Closing the Loop）”才是AI编程的命门
“不要觉得AI写不出Bug-Free的代码，是你根本不懂怎么让它自己测试自己。”
之前有圈内大佬发文嘲笑AI，说往Claude里丢一段需求，生成的代码跑起来直接崩溃，由此得出“AI编程还是个玩具”的结论。Peter 看到后觉得十分可笑：“你难道指望人类程序员第一遍手敲的代码就能直接免测上线吗？”
用好AI的核心，不在于它第一遍生成的质量，而在于你有没有给它设计一个完美的“自我纠错闭环”。
Peter 分享了一个极其硬核的场景：他在写一个包含复杂重定向和API请求的模块时，甚至懒得自己去启动环境调试。
他的做法是：强迫 AI 写一个专用的 CLI 调试工具，并编写测试脚本。 接着告诉 AI：“用这个 CLI 去调用你的代码，读取运行 Log。如果崩溃了，你自己分析报错、修改代码、重新编译、再次运行，直到全部绿灯再来叫我。”
这就叫“验证闭环”。 一旦你的系统具备可测试性，你根本不需要去逐行Review代码，你只需要Review它的测试用例和闭环逻辑。这也是为什么他说“用AI写代码，反而逼着我做出了更高可用、更利于测试的系统架构”。
3. 重定义PR：Prompt Request，思维维度的降维打击
“看别人的源码太浪费时间了，我只看他是怎么向AI提问的。”
在传统开源社区，维护者最头疼的就是Review那些动辄大几千行的杂乱PR。你要切分支、跑CI、揣摩作者的思路，耗时耗力。
随着 OpenClaw 的爆火，Peter 每天要处理海量的社区 PR。他现在提出了一个颠覆性的标准：提交 PR 时，请务必附上你的 Prompt（提示词）。
对他而言，阅读 Prompt 比阅读源码的价值高十倍。因为 Prompt 直接暴露了开发者的“架构拆解能力”和“系统边界认知”。
现在拿到 PR 后，他甚至不直接 Merge 代码。他会把原作者的 Prompt 拿过来，加入自己更高维度的架构考量（比如“这会引发代码膨胀，请改用插件化架构”），丢给自己的 Codex，让 AI 重新 编织（Weave in） 出一份完美契合自身项目的代码。
从 Pull Request 到 Prompt Request，这标志着软件工程的评估标准，正在从“代码实现细节”向“问题定义能力”全面转移。
以前我们或许会说talk is cheap, show me the code. 现在我们可能需要去想想是不是应该说 code is cheap, show me the prompt.
4. 摒弃过度设计：为什么大佬连MCP和重型CI都嫌弃？
“他们把Agent编排得像大公司的官僚机构一样臃肿，这完全是逆势而为。”
目前业界极度推崇 MCP（模型上下文协议）和各种复杂的 Agent Orchestration（比如Agent A查完库，转成JSON发给Agent B建单）。但在实战派的 Peter 眼里，这纯属大厂病发作（Waterfall Model的AI版）。
Peter 坚决拥抱最古老的 CLI（命令行工具）。因为大模型天生就是操作 Bash 脚本的神。
在 MCP 里，你必须预设好所有 API 的格式，大模型拿到 500 个城市的天气数据后，很容易在庞大的上下文中迷失；但在 CLI 环境下，模型可以像黑客一样灵活使用 grep 或 jq 瞬间过滤出它只需要的一行信息。
同样，他彻底弱化了重型 CI/CD 流水线。当 Agent 可以在本地用极高的并发和秒级的速度完成全量“Full Gate”拦截测试时，把代码推上云端等 40 分钟 CI 构建，简直是在谋杀工程师的心流（Flow State）。
💡逃离“API调用员”的宿命
如果你现在依然把大部分精力花在纠结一个方法名怎么起、一段CRUD怎么写得更优雅，那你在这个AI时代将面临真正的生存危机。因为这些曾经让你引以为傲的“肌肉记忆”，在懂得“架构调度”和“闭环验证”的超体程序员面前，不堪一击。
不要抗拒，不要觉得自己“必须亲手敲下每一行代码才算正宗”。正如Peter所说：“用这些机器智能工作，就像是在弹奏一台全新的乐器。”一旦你跨过那道门槛，你一个人，就是一支军队。
👇 评论区硬核互动：
你目前的工作流中，有多少比例是“必须由你手写”的核心逻辑？又有多少是如果剥离出来，完全可以交由Agent自动闭环的“脏活累活”？ 欢迎在评论区开麦，我们一起探讨技术人的转型之路。
PS：文字能传达的压迫感不及原声的十分之一。强烈建议大家点击左下角 【阅读原文】，花时间去听一听这期完整的英文原版播客内容。听听这位曾主导十亿级设备架构的真大佬，是如何一边痛批传统开发模式，一边靠超强执行力颠覆软件工程范式的！
