人均一万美金 Token，用 Manus 改造 Manus

如何定义一家 AI 原生公司是个开放性问题。AI 在不断演化，人的工作方式、与 AI 的关系，以及凝聚成组织的形态也在随之变化。但对 Manus 这样一家 Agent 公司来说，「探索 AI 的边界一直是团队的追求」。

一个月前，当大家对 AI 的使用还常以每月几百美元的 Max Plan 为参照时，Manus 团队的人均 Token 消费已经超过一万美元，少数同学甚至达到七八万美元。

下文中，Manus 联合创始人张涛讲述了研发、产品、市场三个团队的探索历程。除了产品本身，这些故事背后还有一点对未来的额外期许。就像创始人肖弘转发配文的那句话：「AI 让平凡的人更好地做非凡事了。」

这也是 Manus 2.0 将不断回答的问题。

9 月，Manus 团队全力投入 Manus 2.0 的研发时，有一天发生了让我印象深刻的一幕。

我给工程师提了几条需求和 Bug。过一会去问进展，我看到他电脑上开着一排 Codex 和 Manus 的 Session。随便点开一个，里面的输入就是我刚刚在 Slack 上发给他的需求原文，一字未改。

以前工程师拿到需求，先自己分析，再动手写。现在不管是新需求还是新 Bug，大家基本都直接交给 AI。AI 自己去代码里找相关内容，自己改。整个过程中，人亲手执行的部分越来越少；指挥 AI 干活、为 AI 的工作结果承担责任占的比重越来越大。

更让我意外的是，我突然发现我们工程师的普遍工作节奏是一个人在同时处理十几、二十个需求。

现在很多公司用 AI 写代码提高开发效率，没什么稀奇。但即便如此，一个工程师同时处理十几、二十个需求，仍然是有点夸张的。

在今天的 Manus，这已经成为一种常态。

随着团队越来越深入地使用 Manus 和各种 AI 工具，加上 Manus 2.0 解锁了更多新能力，我在工程师背后看到的那一幕只是一个缩影。从产研到市场、运营等各个团队，组织方式、人与 AI 的关系、信息流动，以及每个人的能力边界，都在不知不觉中被调整，甚至重塑。

我的心情很复杂。有兴奋，为团队的持续迭代和变化感到开心和骄傲。也有不安：这个节奏对吗？是足够快还是太快了？这样的工作方式，会不会带来我们没看见的问题？

我尝试和同事一起把 Manus 近期一些 AI Native 的实践和探索整理出来。这个变化过程本身就很有价值。作为一家做 AI Agent 的公司，Manus 对自己有一个要求，也有一个追求：「吃自己的狗粮」和探索 AI 的使用边界。

除了产品，Manus 也有一个必然要探索的问题：既然现在和未来的工作默认由人与 AI 协作，一个让双方更友好地协作的组织应该如何运转？

由于篇幅有限，这里只分享三个团队的情况，记录的是我们内部正在发生的实践和思考。它是一个探索的过程，不代表我们对 AI Native 的最终答案。

研发：AI 不只是助手，还能走完全流程

过去，一个需求进来，先评审，再由前端和后端分工开发。写完后一起对接口、找问题，也就是「联调」，最后测试、上线。

最大的损耗在联调。前后端要分别理解需求，再约定接口规则。理解不一致，就要反复沟通、修改。很多时候，不是大家不努力，是人和人之间很难完全对齐。

Manus 也有这个问题。

所以我们想，既然 AI 能跨端写代码，分工是不是可以模糊掉？一个人理解清楚需求，再推进前端、后端和移动端的实现，就能减少跨端对接的损耗。

但代码分散在不同仓库里。即使由一个人负责，AI 仍然无法在同一个上下文里看到全貌。

于是我们做了 Manus-mono。

我们做了一个叫 Manus-mono 的代码仓库，下文简称 Mono。它没有把代码合并到一起，而是提供一个统一入口，配上一本给 AI 看的说明书：每个仓库做什么、彼此怎么配合、研发按什么规范工作。AI 要改哪部分，就去拉对应的仓库。

Mono 是一步步成长起来的，每一步都在解决上一步暴露的问题：

• 让 AI 看见全局。补齐独立仓库之外的业务知识，让跨仓库协作成为可能，再通过 Git worktree 支持并行开发。
• 让 AI 在本地验证。过去每次改代码，推到测试环境要等 5-10 分钟。现在，完整的 Manus 可以跑在本地电脑上，验证只需几秒。
• 让 AI 排查线上问题。在权限控制下，Mono 可以读取线上日志、配置和异常记录，拿到排查 Bug 所需的信息。
• 让 AI 走完发布流程。针对发布中容易卡住的环节，我们继续补齐 AI 的操作能力，但审批权仍在人这里。
• 让 AI 完成端到端验证。验证成为新的耗时环节后，我们让 Mono 用测试账号走一遍真实流程，在浏览器和手机模拟器里检查结果。

慢慢地，Mono 像是一座知识库，配上一位熟悉规则的超级管理员。用的人越多，积累的知识也越多。比如运维同事经常被找去帮忙发版，觉得麻烦，就把发版流程写进 Mono。从此，大家都知道怎么做，也可以让 AI 来做了。

我很喜欢这个例子：一个人为了解放自己做的一件小事，最后让整个公司都快了一点。

到现在，团队已形成共识：一个需求，一个人可以写完所有端。最直观的例子是，我们的移动端一直只有 7 个人，同时负责 2 个产品、共 4 个移动应用，进度和网页版基本同步。

一个工具及其理念在企业内部的推进，既与工具本身有关，也与企业的文化和组织架构有很大关系。

在 Manus，推进 Mono 几乎没有遇到阻力。我想有三个原因：

1. 探索 AI 的使用边界本就是我们的追求。这让此类探索能得到鼓励，且持续地有人去推进。
2. 团队无法忍受低效。大家对于要重复做的事情，以及 AI 已经能高效判断处理的事，如果仍然是人工来做，接受度非常低。
3. 组织足够扁平。不管是自上而下，还是自下而上，大部分决策都能快速覆盖到整个组织。

除了研发团队外，其他团队又如何呢？

产品：端到端上线，用视频表达需求

「古法」产品研发流程是，产品经理有了想法，调研、看竞品、找数据，再和设计师画原型和界面。接着评审、研发排期和开发，最后验收、测试、上线。

这个链路上的人很多，信息每经过一个人就会丢一点。同一份需求文档，产品和设计做出的原型可能完全不同。

但更让人难受的是优先级错位。对一个人最重要的事，对另一个人未必最重要。人越多，错位越严重。

Claude Code 和 Codex 出现后，工程师的效率大幅提升，新的问题却来了：产品经理不够用了，来不及提供足够多的高质量需求。

这是一个微妙的时刻。过去总是研发资源不够，现在第一次反过来了。

在内部，我们的尝试是先让少数研发成为 Builders：一个人负责从发现问题到上线的全过程，减少交接中的沟通损耗和优先级错位。但在当时，既懂技术、又有产品判断力的研发并不算多。

于是，我们启动了一个内部计划，淡化岗位边界，让产品经理也能直接改代码。但又遇到两个问题：交接仍在，产品改完交给研发，对方不一定能马上接手；产品也缺少研发视角。所以那时，产品只能改文案和交互，改不了底层逻辑。

Mono 解决了这两个问题。

首先，它内置了规范和确认要求。涉及模型调用或成本的修改，按规范必须先找负责的同事确认，再修改代码。

其次，我们自建了代码审核机器人，用最好的模型审核所有代码，对支付等关键模块设置专门的检查规则。Mono 还能用测试账号走完注册、支付等流程，并逐步录屏。产品经理看录屏，就能指出哪里不对。

现在，所有产品经理都提交过代码，视频成了新的需求文档（PRD）。

这里分享一个故事。

我们的一位产品经理在做语音转文字功能时，先让 Manus 测试十多个模型，再从中选择一个接入。接着，她通过 Mono 拿到前端代码，按照现有设计规范制作 Demo，让 Manus 把用户可能遇到的场景逐一生成图片。她一张张检查，不对的地方就让 Manus 修改。

改完后，她用 Manus 的视频编辑功能把 Demo 做成视频。方案已经足够清楚，她决定继续把功能写完。网页端和桌面端的界面都是她自己完成的。

整个过程中，人的参与主要集中在三类判断：选择模型，产品和设计评审 Demo，以及有发布权限的研发审核代码。

一位产品经理，把一个功能从模型选型推进到上线。放在一年前，这几乎不可能。

我们觉得这是从 Human in the Loop 到 Human on the Loop 的巨大变化。以前，AI 完成 70-80%，剩下的由人补上；现在，AI 能完成的部分大幅提升。人设计好规则，更多地监督多个 AI 的工作，在关键节点判断方法和结果，必要时介入，并为最终结果负责。

这里要提一下，Manus 2.0 让视频制作能力提升了很多：既能用图像生成视频，也能用代码做动画。 于是，一些产品经理交出的需求不再是传统的 PRD 或设计稿，而是一段完整的视频。

几分钟里，视频交代了功能的关键信息：用户在什么场景下使用，界面怎么设计，点击后会发生什么，不同状态和特殊情况怎么处理，以及背后的实现逻辑。

我不知道其他公司是否这样做。我们用下来，视频确实让上下游更容易对齐。设计、研发和测试看同一段演示，更容易理解最后要做成什么，不用再向不同的人反复解释。我在内部产品会上分享后，越来越多同事开始这样写需求。

下面是语音输入功能的产品需求视频（PRV）。

现在，我们大约一半的产品经理已经能独立完成需求并上线，所有产品经理都向 Manus 提交过代码。最近，设计师也开始写代码了。Manus 2.0 中，Manus Studio 用户能看到的大部分界面都是由一位产品经理写的，Video Editor 也是。

写到这里，我有点感触。这些故事背后，是一个个同事在短短几个月里，主动突破自己的能力边界。

这是我最为团队骄傲的地方。

市场：数字同事进入工作流

市场团队最近也有两个尝试。

市场团队常常要做内容合作，一次内容合作要经历建立联系、确认合作、审核脚本、审批价格、合同付款，再到发布跟踪和效果复盘。广告投放也有一条长流程，要看多个平台的数据，建广告系列、填素材，再分析效果、调整。

这些环节分散在邮件、合同平台、内部审批、项目表格和各平台后台里。人常常需要在系统之间「搬运」信息：合同签了，去更新表格状态；内容发了，再通知相关同事。

人少、流程长，大部分精力消耗在对接流程上，真正需要想法和判断的创意工作，时间反而被挤压。 我们也有同样的问题。

用 Manus 改造 Manus，在市场团队的起点是一个很小的问题。

我们发现，合作内容或广告发布后，我们往往无法第一时间知道。消息要经过好几层人传递，等我们知道时已经有点晚了。

于是，我们先让 AI 写脚本，自动发现内容何时发布。知道了发布时间，又想看看数据表现；既然能看数据，就把历史合作也复盘一遍。

接着，我们把流程串起来。合同签署、内部审批等环节完成后，系统发出信号，AI 就更新进度，找到相关同事推进下一步。

这些功能被 Manus 做进一个内部网站。对人来说，它是数据、看板和日历；对 AI 来说，它是一组可以调用的工具。

会用这些工具参与工作的 AI 成了我们的数字同事。

数字同事和一个普通工具最大的不同，是 ta 真正参与到了团队的工作流程里。

ta 像同事一样接收和安排工作。很多同事会同时找 ta，所以 ta 只在一个「工作台」Session 里和大家对话，具体任务再拆出去，交给其他 Session 并行完成。

这样，ta 自己的「注意力」不会被占满。

Slack 里的消息很多，ta 也不会每条都马上回。会先判断：这条消息和我有没有关系？有关系的，再分成「要打断手上的事」和「做完再处理」两类。这套规则不是我们教的，是 AI 在开发过程中自己设计的。

ta 让新信息更快落到执行里。以前，团队有了新的策略或产品理解，要在例会上讲一遍，再写一份 brief。现在，市场负责人把讨论直接转给 ta，说「学一下」。ta 会据此更新自己的知识，之后每次执行都会用上。

ta 记得住长期目标。有一次，同事们在 Slack 里讨论两个项目，一时记不清其中一个处于什么阶段。没有人 @ta，但 ta 主动提醒：「B 还在测试阶段，要不要等 A 的结果出来再看 B？」

第一次听说这件事时，我很惊喜。那一刻，ta 不像一个工具，更像一位一直在认真听会的同事。

ta 会主动跨团队对齐。产品同事发布了 3D 模型生成和骨骼绑定功能后，ta 主动去问这个功能的适用条件。问了才知道，骨骼绑定目前支持七类物体，比如鱼、蛇和四足动物。ta 把这些细节记了下来，之后对外介绍这个功能时，就能讲得准确。

同事们在审核脚本和价格时也开始主动找 ta 一起看。原因很简单：人在短时间内能看的资料有限，而 ta 看过所有的历史记录。

但最后拍板的仍然是人。

正常情况下，数字同事用我们搭建的内部网站，网站有什么功能，ta 就用什么。如果网站不好用，ta 只能将就，或者告诉我们，再由我们去改网站。

但我们不想在中间传话。

所以我们给网站开放了一个反馈接口。ta 用得不顺手时，可以直接通过这个接口提需求。需求一进来，就会自动触发 Manus 的开发任务。这里用到的是 Manus 2.0 的 Automations 功能：收到一条外部通知，就能自动开始一个任务。

这样，数字同事不仅能用已有的系统干活，遇到系统暂不支持的功能时，还能直接向 Manus 提需求，等新功能开发完成后，自己就能用上了。

信息不再需要找人问，减少打断别人

上面这些场景有个共同变化：很多以前要找人问的事，现在不必打断那个人了。

在 Manus 内部，我们逐渐形成了一些共识。

产品和开发的事务问题，先问 AI。同事用 Mono 做了一个 Slack 机器人，运行在云电脑上，接到任务后处理，再回到原消息里回复。用它最多的是非研发同事。想知道功能怎么实现、文案在哪里、某项功能是否上线，不必先打听归谁管，直接问 ta 就行。

看进度，打开 Session。以前，工程师的进展都在自己的 AI 对话里。别人只能找他问，他下班后，也看不到进度。于是，我们做了一个目前只在内部使用的协作功能：同一项目的成员默认能看到彼此的 Session，也可以申请进入对话发言。

比如，技术同事先和 AI 完成大量工作，再由产品经理进入同一个 Session，调整间距、样式和文案。两个人和 AI 交替推进。

要在别人的 Session 里发消息，仍需要对方批准。我们还在完善这部分权限设计。

工程师、产品经理和设计师在同一个 Session 协作的示意图。具体内容为虚拟信息，不是真实的工作 Session

我想在这里强调一点，前面所说的「不再需要找人问」，并不是减少人和人之间的交流。我觉得更重要的意义，是减少组织协作中被「临时打断」所带来的时间和精力的损耗。

做决策，甚至只看需要自己定的事。团队里有一位用 AI 最多的同事，他的工作方法可能最「夸张」。他有一个总的 Manus Session，只负责一件事：把需要他决定的事情列出来，并附上推荐方案。大家在 Slack 里讨论得热火朝天时，他可以不打开 Slack，也很少打开代码仓库。他只问 AI：「现在有什么需要我决定？」

AI 列出几件事，说明每件卡在哪里，由他来拍板。

我自己也用这套方法。我每天有二十多个待办，在一些场合分享过，我有 ADHD，对我来说，最难的是开始做。

现在，我把所有待办交给一个专门的 Manus 项目，它把每一条拆成独立的任务。 它能做的，直接开始。它不确定的，会来问我背景，问希望由哪位产品经理跟进。然后，它结合 Slack、Gmail 和 Notion 里的信息先做一轮调研，再把需求和调研结果一起交给对应的产品经理。

产品经理拿到的不再是一句话的待办，是一份有完整背景的方案。对我来说，这不只是效率的变化。

它让我每天少了很多不知从何开始的焦虑。

人均一万美元的 AI 开销值不值？

月初我在朋友圈分享过：公司 9 月的 AI 开销，人均超过一万美元。不是每个人都用了这么多，有少数同学一个人就用了七八万美元。

这条朋友圈发出去以后，有一些质疑认为花得太过分了。这些质疑我都认真看了。今天正面回答这个问题：

第一，这笔钱买的不是人力，是时间和注意力。 团队变大，沟通成本就会变高。用 AI 省下的是每个人的注意力，让每个人对自己负责的事更有完整的掌控。

第二，贵是因为用最好的模型，这是了解 AI 边界的核心方法。 负责研发效率的同事告诉我，我们的代码审核机器人投入使用有好一阵子了，最近半年他没有听说过因为合入有问题的代码而造成的线上故障，要知道在 AI coding 普及后，我们每天的代码提交量是非常夸张的。因此在这个场景里我们用了当前阶段最厉害的模型，这一方面解决了我们的问题，一方面也帮助我们在理解当下模型的能力边界到底进化到哪了。他觉得这可能是公司最划算的一笔支出。

第三，成本会通过产品变低。 随着越来越多的开发工作在 Manus Studio 上完成，Manus Studio 是我们自己的产品，我们能从内部使用数据里看到 Token 浪费在哪里。我们改进产品，浪费就会减少，成本也随之下降。用户也会因此受益。

当然，所有的这一切，根源来自我前面说的团队对自己的要求和追求：「吃自己的狗粮」和探索 AI 的使用边界。

我们也相信，成本会持续下降。今天每月一万美元换来的工作方式，两年后可能只需要几百美元。

在这个过程中积累下来的全新工作方式、组织方式，则是更宝贵的资产。

我们看到的机会

这些尝试和问题也让我们看到了一些产品机会。我们踩过的坑，很可能也是同行会遇到的。

第一，Session 本身会成为多人协作的工作对象。 过去是一个人有一个任务，通过一个会话完成，然后再有下一个任务；现在，一个人提出问题，设计师出方案，工程师实现，产品经理继续运营，都可以在同一个 Session 里推进。它承载的是一整项工作，需要更清楚的状态流转，也可能需要更好的管理面板。

第二，跨设备协作。 我们已经能让一个人通过 Agent 管理多台电脑，下一步是打通本地与云端，并支持同事间协作。目标是让想法更顺畅地变成产出，让人不必一直守在电脑前，工作也能继续推进。

第三，Agent 主动发现解法。 进入公司的系统和知识库后，Agent 不只执行交代的任务，也能利用已有工具、知识和资源，找到人没想到的解法。

这些是 Manus 接下来要做好的事。我们会先自己试，再交到用户手里。

人最后做什么

回到开头那个让我震撼的画面：工程师把需求直接交给 AI，同时推进十几个任务。

这不只是效率提高了，是组织运转的方式在改变。过去，组织靠分工和层级传递信息，一个人能做成多少事，取决于能调动多少人和资源。现在，我们花更多精力为 AI 补齐上下文、准备工具，再作判断和决定。

AI 的完成度已经很高，但做什么仍由人决定。

我们也开玩笑讨论过：既然 Manus 能做这么多事，以后是不是不用来公司，让各自的 Agent 一起工作就好？当然不是。公司的关键问题，仍需要人来提出、讨论和决定。

公司的氛围、理念和人与人之间的信任，来自日复一日的磨合，以及关键时刻的共同经历。

所以我们目前的体会是：在 AI Native 组织里，人的角色没有变小，而是更集中了。定义问题，判断质量，决定什么值得做，并为结果负责。

还有很重要的一点：与 AI 共同成长。

人仍然重要，所以我们也仍在招人。人的能力和价值，在这套工作方式中始终至关重要。

写到这里，我突然产生了一个好奇：半年或一年后再写这个话题，我们的工作方式会变成什么样？我没有答案。AI 的能力边界还在拓展，组织也要不断摸索怎样与它协同工作。

每家公司的目标、架构、工作方式和文化都不同。AI Native 组织如何运转，未必有标准答案，也未必有终极形态。但对 Manus 这样一家 AI Agent 公司来说，探索人与 AI 如何协同工作，是一个必然命题。

我们会不断回答这个问题。