在大模型时代，AI 产品为什么更难复用？AI Agent产品应该如何开发？来自 Manus 的3个工程实践经验

最近，Manus 团队成员 Ivan Leo 在个人博客中发布了一篇题为 Three Lessons I’ve Learned at Manus 的文章，对自己在 Manus 工作期间的经历进行了系统回顾。

Manus 是一款面向真实生产环境的 AI Agent 产品。在极短时间内，这个团队完成了从早期产品形态到大规模商业化的跨越。根据作者在文中的描述，Manus 在 不到 8 个月的时间里实现了超过 1 亿美元的 ARR，这在当前 AI 应用层中属于极端少见的增长曲线。

Ivan Leo 本人并非外部观察者，而是一线工程成员。他加入 Manus 的时间 不足 5 个月，但在这段高度压缩的时间里，已经深度参与了多个关键功能的设计、实现与落地，包括用户触达功能、支付系统集成以及 API 与内部连接器相关的维护工作。

这篇文章并不讨论模型参数、训练方法或算法创新，而是从 工程执行、产品交付方式以及个人在高速系统中的角色变化 出发，总结了三条在现实环境中反复被验证的经验。正因为这些经验产生于一个「真实用户、真实收入、真实压力」的环境，它们才具备被单独拿出来分析的价值。

一、当 Agent 成为执行主体时，“代码正确”不再等于“系统可用”

在传统软件工程体系中，“代码正确 ≈ 系统可用”并不是一种天真的假设，而是建立在一套成熟、长期有效的方法论之上。

产品经理通过 PRD 明确定义用户是谁、如何使用系统、允许和不允许的行为边界；工程师围绕这些确定性假设实现功能，并通过接口契约、单元测试和集成测试来验证正确性。在 UI 和流程的强约束下，用户行为高度可预测，系统是否可用，往往可以在上线前被证明。

这套机制在过去二十多年里持续奏效，其核心价值在于：把不确定性尽可能压缩在设计和测试阶段。

但在 Agent 产品中，这个前提开始瓦解。

首先，Agent 的主要交互方式是自然语言。用户输入不再是被严格约束的字段，而是开放文本；prompt 本身成为系统行为的一部分。真实使用路径不再是有限集合，而是一个不断被用户探索和扩展的空间。PRD 无法穷举这些路径，只能给出非常粗粒度的预期。