简介

从头到尾过了一遍OpenClaw作者的访谈(https://www.youtube.com/watch?v=8lF7HmQ_RgY)，其实有很多点感觉都还挺有意思的，用个AI工具能把大纲都总结出来，我就不重复工作了。实际上我觉得前面一段讲述个人经历，以及体现出的一些对人生和社会的理解，也蛮值得品味品味的，不过还是把重点放在「生产力」上，谈谈我对Peter如果使用AI实现爆炸性生产力提升（一天能提600个commits）的理解，篇幅应该不会太长，可能会有从「道」到 「术」的理解递进。当然这个访谈里也有很多Peter其他观点以及这个项目本身的愿景，这些我们持保留意见，暂时不做讨论。

人的主观能力性

其实我觉得这个才是最重要的

  • 愿意思考
  • 保持好奇心和热情
  • 持续学习
  • 不怕犯错
  • …

有这些属性的人才有可能对真正提升生产力有追求，不然我们再怎么追求「工具」、「方法论」、「最佳实践」都是没有用的。

因为世界在不断变化，我们面临的问题也在不断变化，这个世界唯一不变的就是变化，只追求表面上的东西很可能演化成巨大的流程或技术债务，让大量生产力浪费在没有意义的事情上。

聚集有共同理想的人，并创造利于培养/保持这些品格的人的环境，其实可能在组织/公司上，可能才是最重要的。

道：开发模式的转变

最重要的，Peter认为开发模式应该有一个转变，从传统手写，到Agentic Engineering，我理解为基于Agent的整套工作流，而不只是编码本身。

如果只说编码，实际上我们平时做的大量工作是「缝合代码」，用他的话来说，是「Plumbing Code」，这部分工作其实大量是纯粹的苦活，完全可以由AI来搞定。

但目前的LLM，最大的问题就是它们是概率模型，对输出的结果的「正确性」无法保证，那么我们怎么提升Agent的协作与生成效果，减少频繁的返工和堆屎山呢？他说他最大的技巧在Close the Loop，即「闭环原则」上。

代码场景之所以现在比较火，是因为这个场景更容易构建compile-lint-execute-verify这一整套闭环，让AI自己在实现一些功能后，自我验证、发现错误、迭代修改，不断循环，直到事情完成。

普通小白当然感受不到这个，但他们其实可以通过现在的AI工具了解这些东西，取决于人是否愿意思考、愿意学习，门槛真的没有那么高，可惜自媒体们忙于夸大事实和割韭菜，并不会说这个。

在这个基础上，他建议我们改变一些思维方式，从一个代码的编写者，转变成为架构和系统的思考者（但用他的话来说，他更愿意用Builder这个词而不是Architect）。

所谓的不review代码，并不是真的一点都不看，而是不一行行看代码的具体实现逻辑，把正确性的保障尽可能交给「闭环」。

而我们作为Builder，应该更认真去思考架构，如何设计测试，如何指导AI让他们生成合理的测试，如何对工具层下指令等等等等。

这些是真正的Skill Issue，在以前人主力编码的时代也是存在的，只是Manager和所谓的架构师们根本不care，出问题了就让干活的人背锅。

现在生成式AI的大发展给当前的生产关系带来了冲击，这些问题会被摆到明面上，以更深刻的代价来冲击组织架构、交付方式等等。我们需要让自己能够「放手」，让方向/架构本身不出现问题，而不是纠结于一些细枝末节。

而问「对的问题」的能力，是需要人的主观能动性的。

不断学习，实际上和LLM/Agent不断对话的过程，也是一个学习的过程。我们会在学习过程中不断修正自己对系统的理解，大模型也是一样的。

这也是他认为所谓的spec driven可能行不通的原因，它就像是人类软件工程以前的「瀑布模型」。用他的话来说：

“How can you even know what you want to build before you built it? You learn so much in the proess of building it that will go back into your thinking of how the system actually will end up being.

因此他也不喜欢「vibe coding」这个词，因为有大模型的帮助，依然需要人对手上的这个系统有非常清晰的认知，这个过程现在可以借助与大模型的对话和讨论不断完善，因此他更推崇under-prompting。

因为有大模型的帮助，试错代价降低了很多，我们可以尝试各种各样的想法。哪怕和大模型讨论的过程当中，80%的idea都是没用的，只要那20%有用，哪怕只是给你一些灵感，都可以打开无限的可能性。 即通过「对话」而非单纯"Prompt"来引导AI

术：具体的使用方式

这些只是Peter的访谈中偶尔体现出来的，但我觉得这些其实不如上面说的那些重要，随着模型能力的提升，对Agent工程理解的加深，很多具体手段可能会不断革新，所以仅做一些简单的列举翻录，以作为我们提升使用AI agent的生产力的一些参考

  • 并行使用5到10个代理，一直切换，让agent在talk 和 cook 间交替

  • Codex(GPT5.2)那种想的更久，一把做对的方式，比Claude Code这种一会儿break一下，需要频繁交互的要好，特别是在复杂工程当中

  • 我们可以一直和模型讨论，一步步得到自己想到的架构或者实现方式，再让模型去实现，并不需要什么plan mode.

  • 使用相关AI越多，越能有一种感觉，即掌握特定模型的「机器语言」，大概知道提什么样的问题、怎么样的讨论是有效的

  • 闭环中的让AI能够自我测试和调试，通过CLI快速运行测试以验证AI输出的正确性

  • MCP协议过于冗余，更倾向CLI作为AI调用工具的媒介

  • Pull Request -> Prompt Request（持保留意见），然后Rewrite PR，Weaving进项目里

  • CI的重要性降低，我们需要本地快速反馈，而非冗长的云端CI等待（这点我基本同意）

  • 公司结构要重组，高能动性的小型团队（可能是当前30%的人力）将完成目前数百人的工作

  • 这一点他没说，但我觉得：版本控制流程也可以放进agentic engineering里，通过prompt来自动化

  • …