本文来自于Clawdbot创始人Peter Steinberger对Agent编程的思考实践。在使用各种IDE做过项目后，深为同感，故直接放到这里。 原文： https://mp.weixin.qq.com/s/uOiPOJJcwtJa6RBYG_INcA
我非常不喜欢’Vibe Coding’这个词，“Peter说，“我更倾向于：Agentic Engineering。”
为什么？
因为"Vibe Coding"暗示的是一种随意、感性的编程方式，好像你只要"感觉对了"就能写出好代码。但实际上，Agent编程需要更系统的思考和规划。
Peter甚至痛斥了AI圈内非常常见的"编排、拆解"的做法：
“他们可能花几个小时设计spec，然后机器用一天把东西’造’出来。我不信这套能行。这本质上还是瀑布式软件开发，我们早就知道它行不通。”
这样只会带来一场"精致的混乱”。
Peter的观点很明确：传统的"规划好Spec文档，然后交给Agent去自动执行"的做法，行不通。
为什么？
因为这本质上仍然是瀑布式开发。你在前期花大量时间做规划，然后期待机器能完美执行。但软件开发从来不是这样的——你需要在开发过程中不断调整、优化、重构。
AI Agent也是一样。
你不能指望一个完美的spec就能让Agent做出完美的产品。你需要在过程中不断与Agent对话、调整方向、优化细节。
这不是"编排”，而是"协作”。
有人说，AI时代程序员变成了"架构师”——不再写代码，只负责设计架构。
Peter对这个说法也不太认同。
“这听起来有点像很多年前流行过的一种模式：有一个’大写A的架构师’，不再亲手写代码，负责蓝图，然后把方案往下传。后来大家都讨厌这种模式。”
Peter认为，真正的工作方式不是单向的"架构师→执行者”，而是双向的"协作规划”。
你不是在"指挥"Agent，而是在和它对话
Peter分享了一个关键洞察：为什么AI在写代码上表现很好，但在写作上常常平平？
答案是：代码可以被验证。
代码可以编译、跑测试、检查输出。这种即时反馈机制，让AI能够快速迭代、优化。
而写作则缺乏这种验证机制。你很难客观地判断一篇文章是"好"还是"不好”，这种主观性让AI难以优化。
这个洞察的价值在于什么？它指出了高效使用Agent的关键——构建验证闭环。
Peter在设计系统时，会让Agent可以自己编译、lint、执行、验证输出。
这样，Agent就能自己判断代码是否正确，而不需要人工介入。
更进一步，Peter选择本地CI而不是远程CI。
“我不想等额外10分钟让远程CI跑完，我的Agent可以在本地立即运行测试。”
这种设计哲学的核心是：让反馈循环尽可能短。
越短的反馈循环，越高的迭代效率。
Peter说，当你和Agent工作久了，你会慢慢"感知"这个模型。
“我能看到代码飞过去，能感知花了多长时间，能感觉Agent有没有在’顶你’，能看出来生成的东西是杂乱的还是有结构的。”
这是一种共生关系。
你学会了如何跟它说话，甚至可以说是一门语言。与此同时，模型也在变得更好。
“很多时候我一开始就能判断大概会花多久，如果明显更久，我就知道自己哪儿搞砸了。”
这种"感知"能力，是长期使用Agent后才能培养出来的。它不是技术，而是一种直觉。
Peter的另一个反直觉观点，可能会让很多人不服：大公司用不好AI。你信吗？
“除非它们来一次彻底的重构。”
为什么？
因为新世界需要的是那种有完整产品视角、什么都能干的人，而且数量要少得多，但必须具备极高的自主性和能力。
但公司的职务分工太细分了。工程师和产品经理的角色划分清晰，根本不存在这样的复合岗位。
这是组织结构问题，不是技术问题。
Peter观察到，大公司的组织结构是为"规模化"设计的——通过细分职责、标准化流程来提高效率。
但AI时代需要的是"灵活性”——快速决策、快速迭代、快速调整。
这两种模式是矛盾的。
一个70人的团队，可能不如一个用好AI的3人小团队高效。因为前者需要大量的沟通成本、决策成本、协调成本。
而后者，每个人都是全栈，每个人都能独立决策，每个人都能快速迭代。
这意味着什么？
个人开发者的黄金时代来了。
AI降低了创业门槛。一个人，可以对抗一个团队。Clawdbot就是最好的证明。
Peter一个人，一个月6600次提交，做出了一个现象级产品。
这在以前是不可想象的。
Peter的另一个工作方式是：同时跑多个Agent。
“在Clawdbot这个最新产品上，我通常会同时跑5到10个agent。”
这在心理上比单纯写代码更累。你需要不断切换上下文，管理多个任务，确保每个Agent都在正确的轨道上。
但这种并行工作方式，极大提升了效率。
举个例子，Peter在开发Clawdbot的某个功能时，会这样分配任务：
这5个Agent同时工作，互不干扰。Peter只需要在关键节点介入，确保方向正确。
这种工作方式，让他的开发效率提升了至少5倍。
想象一下：你有10个"自己"在同时工作，每个"自己"都在处理不同的任务。这种感觉，就像开了挂一样。
Peter强调，很多人没意识到一个关键点：
你并不是在"指挥"Agent，而是在和它对话。
“我会说，我们看看这个结构，有哪些选项？这个特性考虑过没有？因为每一轮session，模型一开始对你的产品是零认知的，你得给它一些指路标志，让它去探索不同方向。”
你并不需要什么plan mode，Peter就是一直聊天，直到他说"build”，Agent才会真的开始构建。
“有一些触发词，它们确实都挺’饥渴’的，但只要我说’我们讨论一下’或者’给我一些选项’，它们就不会动手。”
这是一种对话式的、探索式的工作方式。
那么，如何写好prompt？
Peter的答案可能会让你意外：Prompt不是提前精心预备好的，而是跟Agent之间的协作规划出来的。
“我通常从一个想法开始，甚至会刻意’欠提示’Agent，让它做点出乎意料的事，给我新想法。”
这种"欠提示"策略，听起来反直觉，但实际上很有效。
因为你不可能一开始就想清楚所有细节。与其花大量时间写一个"完美"的prompt，不如先给一个大概的方向，然后在对话中不断细化。
这更像是一种"共同创作”。
Peter还分享了一个有趣的观察：AI时代，代码的PR本身价值在缩水。
“当我看到一个PR时，我更感兴趣的其实是prompt，而不是代码本身。”
为什么？
因为prompt才是更高信号量的东西。它告诉你：这个人是怎么思考的，他想解决什么问题，他是如何引导Agent的。
而代码，只是这个思考过程的输出。
所以Peter要求团队提交代码时，必须附带prompt。
PR变成了"Prompt Request”。
这是一个范式转变。
Peter还有一个观点：大部分应用代码，其实就是"massaging data in different forms”（用不同形式处理数据）。
这些代码，不值得投入过多精力。
你应该把精力放在系统设计上——如何组织模块、如何设计接口、如何保证可扩展性。
这些才是真正需要人类智慧的地方。
Peter说，在开发打磨Clawdbot这件事情上，他已经不太关注如何写代码。
“我更在意结果和产品体验。”
这是一种思维方式的转变：从"如何实现"到"实现什么”。
以前，你需要关注每一行代码，因为你要亲手写。现在，你可以把这些交给Agent，自己专注于更高层次的思考。
这不是说代码不重要，而是说你的注意力应该放在更有价值的地方。
Peter观察到一个有趣的现象：
喜欢解算法题的工程师，往往难以适应AI-native的工作方式。而喜欢shipping产品的人，则如鱼得水。
为什么？
因为前者关注的是implementation（如何实现），后者关注的是outcomes（实现什么）。
AI时代，implementation可以交给Agent。但outcomes，仍然需要人类来定义。
这是一种思维方式的差异。
Peter给AI原生世代新人的建议，只有一条：
保持无限的好奇心。
“这是在AI时代最重要的品质。”
为什么？
因为AI降低了试错成本。以前，你需要谨慎选择副项目，因为每个项目都需要投入大量时间。现在，你可以大胆尝试各种想法，快速验证，快速迭代。
好奇心，让你不断探索新的可能性。
而AI，让这种探索变得更容易。
Peter说，以前你得非常谨慎地选副项目，因为软件真的很难。
现在当然还是难，但那种摩擦感不一样了。
你可以尝试你以前不敢尝试的东西。你可以学习你以前不敢学习的技术。你可以做你以前不敢做的项目。
因为AI降低了门槛。
不要害怕尝试。
回到最开始的问题：Clawdbot为什么能爆火？
因为Peter找到了Agent编程的终极答案：
不是"Vibe Coding”，而是"Agentic Engineering”。 不是单向指挥，而是协作规划。 不是关注细节，而是关注结果。 不是瀑布式开发，而是验证闭环。 不是大公司的优势，而是个人开发者的机会。