Manus 用 Manus 改造自身：AI Native 组织的实践和思考

原创 hidecloud 2026-10-26 10:00 新加坡

AI Native 组织如何运转，未必有标准答案，也未必有终极形态。对 Manus 这样一家 AI Agent 公司来说，探索人与 AI 如何协同工作，是一个必然命题。我们会不断回答这个问题。

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

我给工程师提了几条需求和 Bug，过一会儿去问进展。我看到工程师的电脑上开着的一排 Codex 和 Manus 的 Session，随便点开一个，这些 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 更友好地协作的组织，应该怎么工作？

由于篇幅有限，这里只分享三个团队的情况，记录的是我们内部正在发生的实践和思考，它是一个探索的过程，不代表我们对 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 用测试账号走一遍真实流程，在浏览器和手机模拟器里检查结果。

〔同事用 Manus 制作的 Mono 概念和演进视频〕

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

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

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

 为什么这套方法能在 Manus 跑起来 

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

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

1. 探索 AI 的使用边界本来就是我们的追求。这让此类探索能得到鼓励，并且持续的有人去推进。

2.团队无法忍受低效。大家对于要重复做的事情，以及 AI 已经能高效判断处理的事，如果仍然是人工来做，接受度非常低。

3.组织足够扁平。这使得大部分决策，不管是自上而下，还是自下而上，都能快速覆盖到整个组织。

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

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

 以前：最怕的是优先级错位 

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

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

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

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

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

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

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

 现在：所有产品经理都提交过代码，视频是新的 PRD 

Mono 解决了这两个问题。

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

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

这里分享一个故事。

我们的一位产品经理在做语音转文字功能，先让 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 里的信息先做一轮调研，再把需求和调研结果一起交给对应的产品经理。产品经理拿到的，不再是一句话的待办，而是一份有完整背景的方案。对我来说，这不只是效率的变化。它让我每天少了很多"不知道从哪开始"的焦虑。

 人均 1 万美元的 AI 开销，值不值 

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

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

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

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

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

当然，所有的这一切，根源来自我前面说的团队对自己的要求和追求：“吃自己的狗粮” + 探索 AI 的使用边界。我们也相信，成本会持续下降。今天每月 1 万美元换来的工作方式，两年后可能只需要几百美元。而在这个过程中积累下来的全新工作方式，组织方式，则是更宝贵的资产。

 我们看到的机会 

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

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

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

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

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

 人最后做什么 

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

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

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

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

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

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

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

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

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

跳转微信打开