当程序员不再写代码——看完 Peter Steinberger 采访后的技术思考

“I always thought I loved programming. Turns out, what I really loved was creating.”

这个男人到底什么来头

前两天刷到了 Lex Fridman 播客第 491 期，嘉宾是 Peter Steinberger。说实话，如果你是做移动端开发的，PSPDFKit 这个名字你多少应该听过——十亿级别的装机量，做 PDF SDK 做到了行业天花板。这哥们花了 13 年时间把 PSPDFKit 做大，然后把公司卖了，退休了，消失了三年。

一般人到这儿故事就该结束了对吧？有钱有闲，环游世界，写写回忆录，完美收官。但 Peter 不是一般人。退休三年之后他说自己快无聊死了——“如果你每天早上醒来没有什么值得期待的事情，没有真正的挑战，那会非常非常无聊”。然后他搞了 OpenClaw，一个开源 AI Agent 项目，直接成了 GitHub 历史上增长最快的项目之一，目前251K Star(top1)，全世界都在讨论。

所以这期播客值得听，不只是因为 Peter 本身的传奇经历，更是因为他对 AI 时代软件开发的理解，真的跟大多数人不一样。他不是在纸上谈兵，他是真刀真枪地用 Agent 写生产代码，服务真实用户的人。

让 Agent 自己调试自己

整个采访里最让我上头的一个点，是 Peter 谈到他怎么调试 Agent 的 bug。

一般vibe时代前我们遇到 bug 是怎么做的？翻日志、打断点、读堆栈、加 print 语句，一层一层地排查。但vibe时代后的做法完全不一样，我们会直接问 Agent：“你看到了什么错误？去读源代码，找出问题在哪。” 但是更绝的是Peter会反问：“你能不能自己调用这个工具？”

这其实是一个非常反直觉的思路。我们习惯了把 Agent 当成一个执行指令的工具，但 Peter 是让 Agent 去理解自己的运行机制。他说了一句话让我印象很深：“I made the agent very aware — it knows what its source code is. It understands how it sits and runs in its own harness.” 他让 Agent 读自己的源码，理解自己是怎么被组装起来的，然后用这个认知去定位问题。

这东西说白了就是 Self-Modifying Software 的雏形。Peter 自己也说：”People talk about self-modifying software, I just built it.”

更深一层说，Peter 还提到了一个我觉得特别重要的理念：和 Agent 共情—换位思考。他说你得考虑 Agent 是怎么看你的代码库的——“它每次开始一个新会话，对你的项目一无所知，你得帮它建立上下文。” 这话听起来简单，但做到真的要转变思维方式。我们习惯了以自己的认知为中心来组织代码，但如果你的协作者是一个每次从零开始的 Agent，你就得重新思考代码结构、文档方式、甚至项目的文件命名。Peter 的原话是：”I’m not building the code base to be perfect for me — I want to build a code base that is very easy for an agent to navigate.” 这话要是放到两年前说出来，估计会被人骂疯了。但现在想想，确实有道理。

Agentic Engineering：不是 Vibe Coding

Peter 在采访中用了一个我很喜欢的说法来区分两种工作模式。他说：”I do agentic engineering, and then maybe after 3:00 AM, I switch to vibe coding, and then I have regrets on the next day.” 哈哈，凌晨三点以后做的决定谁没后悔过呢。

但玩笑归玩笑，Agentic Engineering 和 Vibe Coding 的区别是实质性的。Vibe Coding 是你大概给个方向，然后看着 Agent 去发挥，你凭感觉决定接不接受结果。而 Agentic Engineering 是你真正理解 Context Window 的限制、知道怎么给 Agent 搭建脚手架、怎么切分任务让多个 Agent 并行高效工作。

Peter 的实际工作流是这样的：他同时跑 4 到 10 个 Agent，用一个 3x3 的终端网格来管理它们，大部分 Agent 在同一个文件夹里工作。他很多指令是用语音输入的（用 Wispr Flow），甚至说他”至少 50% 的 prompt 都包含一张截图”。这就不是在 coding 了，这是在指挥。

他还提到了一个”复杂度曲线”的概念：最开始你用 AI 写代码，prompt 很简单——“帮我修一下这个 bug”。然后你开始搞复杂的编排，多 Agent 协作、工具调用、流程控制。但最终，当你真正掌握了这套东西之后，你会回到短 prompt——因为你已经把代码库、文档、工具链都调教到了 Agent 能一听就懂的程度。这个否定之否定的过程挺有意思的。

至于代码审查，Peter 的做法也和传统不一样。他不是自己逐行 review，而是先问 Agent：”你理解这个 PR 要做什么吗？” 确认 Agent 理解了意图之后，再问：”有没有更优的方案？” 然后让 Agent 自己回应 CI bot 的评论，通过了就自动合并。他还搞了 /automerge 和 /massageprs 这种自定义命令来批量管理 PR。这效率，说实话有点恐怖。

Skills 和 CLI 才是正道，MCP 靠边站

Peter 在采访中对 MCP 的态度可以说是毫不客气。他的原话是：“Almost all MCPs really should be CLIs. I say that as someone who wrote 5 MCPs myself.” 作为一个自己写过 MCP 的人来说这话，分量很重。

他总结了 MCP 的几个核心问题。第一是上下文污染——MCP 返回的数据会大块大块地塞进 Context Window。他举了个例子，光用 GitHub 的 MCP 就吃掉 23k tokens，最开始甚至接近 50k tokens。这对于寸土寸金的 Context Window 来说简直是灾难。第二是不支持组合调用——你没法像 Unix 管道那样把多个 MCP 的输出串联起来处理。第三是本质上是一套新语法——模型需要额外的训练才能理解怎么调用 MCP，而 CLI 命令？模型天生就懂。

相比之下，CLI + jq 管道的优势就太明显了。你可以精准地过滤数据，只让需要的结果进入上下文，不会造成任何污染。模型对 Unix 命令的理解是刻在骨子里的，不需要额外的 prompt 去解释。

Peter 说的 Skills 本质上就是一句话的功能描述，模型加载后直接就知道该调用什么 CLI 命令。简洁、高效、不浪费上下文。

当然他也承认 MCP 有一个不可替代的场景：需要维持状态的服务，比如 Playwright 做浏览器自动化，你需要一个持续运行的浏览器实例。但除了这类场景，Peter 的做法是：拿到一个 MCP，第一件事就是花一分钟把它转成 CLI。

说实话这个观点让我有一种”原来如此”的通透感。Unix 哲学里那句 “Do One Thing and Do It Well”，在 AI 时代不仅没有过时，反而焕发了新生。管道、过滤、组合——这些几十年前的老思想，恰恰是和 AI Agent 协作的最佳范式。

当编程变成织毛衣

这部分是整个采访最扎心的地方。

Peter 说了一个类比：编程这个技艺本身会一直存在，但会变成像织毛衣一样的东西——大家做这个是因为喜欢，不是因为什么实际用途。

你知道我第一次听到这话的时候是什么感受吗？说不上来，一种很复杂的东西。我们这些写代码的人，花了几千个小时沉浸在编辑器里，那种把一个复杂的算法写出来、所有测试通过的瞬间，那种凌晨三点终于把一个诡异的 bug 修好然后瘫在椅子上的成就感，那种在代码里找到心流状态、世界只剩下你和屏幕的感觉——这些东西，真的很难接受会被一个”没灵魂的玩意儿”取代。

Peter 注意到了很多开发者正在”mourning the loss of the flow state”——哀悼心流状态的失去。他把这比作工业革命时期工人砸蒸汽机的故事。当年的纺织工人觉得机器夺走了他们的手艺、他们的尊严、他们的身份认同。现在这个故事在技术圈重演了，只不过这次被威胁的不是体力劳动者，而是我们这些自诩为脑力劳动者的人。

但是 Peter 也说了一句很诚实的话——和 Agent 合作的时候，他也能进入类似的心流状态，”I never had so much fun than building this project”。只是那种感觉不一样了。以前的心流是在代码的细节里游泳，现在的心流是在更高的抽象层面做设计、做决策、做创造。

Peter 说他以前一直以为自己热爱的是编程，后来发现他真正热爱的是创造。这话听着简单吧？但真正对自己诚实地想想，我觉得大部分程序员其实都没有想清楚这个问题。我们究竟是喜欢”写代码”这个动作本身，还是喜欢”通过代码把脑子里的想法变成现实”这个过程？如果是后者，那 Agent 并不是在夺走你的东西，它只是换了一种方式帮你实现。

他还有一句话我记得很清楚：”不要把你的身份绑定在’程序员’这个标签上，你本质上是一个创造者。” 说实话，我知道这话是对的。但作为一个正在经历这场变革的开发者，真正做到这一点，比说出来难太多了。我的简历上写着”软件工程师”，我的技能树全部点在代码上，我的圈子里聊的都是框架和语言——这些东西突然被人说”不重要了”，你让我怎么轻描淡写地说一句”没关系我是创造者”？

但我也不得不承认，Peter 确实在身体力行。他真的从一个每天写 Objective-C 的 iOS 开发，变成了一个用语音指挥十个 Agent 同时干活的人。而且他做出来的东西比以前更疯狂、更有影响力。也许这就是答案——不是要放弃什么，而是要升级。

写在最后

两个多小时的播客看完，脑子里其实挺乱的。Peter 说的很多东西，我理性上都认同，但情感上还是需要时间消化。不过有一点我可以确定：这个行业的变化速度，已经快到了你如果不主动去理解新范式，下一次回头看的时候可能就已经被落下了。

至于编程会不会真的变成织毛衣？我不知道。但我觉得，不管怎样，那些凌晨三点修完 bug 的夜晚，那些和代码较劲的日子，都不会白费。它们构成了我们理解计算的底层直觉，而这个直觉，恰恰是在 Agent 时代做好 Agentic Engineering 的基础。

播客链接：Lex Fridman Podcast #491 - Peter Steinberger
Peter 的博客：steipete.me