Manus的AI原生组织实践
文章记录了 Manus 团队在研发 Manus 2.0 期间，如何用自己的 Agent 产品改造内部工作方式。作者观察到，工程师收到 Slack 上的需求或 Bug 后，常常不再先手工分析，而是直接把原文交给 Codex、Manus 等 Agent；一个人并行处理十几个甚至二十个任务逐渐成为常态。变化不只发生在写代码环节，也扩展到产品、市场、运营、信息流动和团队协作。
作者把这视为一家 AI Agent 公司必须亲自探索的问题：如果工作默认由人和 AI 协作，一个更适合这种协作方式的组织应该怎样运转？文章分享的是仍在演进中的内部实践，并非一套已经定型、适用于所有公司的标准答案。文中主要讨论研发、产品和市场三个团队。
研发：从跨团队交接转向 AI 贯穿研发流程
传统研发流程中，需求通常由产品、前端、后端、测试等角色依次传递。最大的损耗往往出现在联调和交接：不同人对需求及接口的理解不一致，需要反复沟通修改。Manus 希望让一个人借助 AI 跨端推进需求，减少人为分工边界造成的协调成本；但代码分散在不同仓库，AI 看不到完整业务上下文，于是团队建立了 Manus-mono（Mono）。
Mono 并不是把各个代码仓库合并成一个，而是作为统一入口和面向 AI 的知识说明书，描述各仓库的职责、协作关系和研发规范，并让 AI 按任务拉取所需仓库。它逐步补上研发闭环中的能力：
- 提供全局知识和并行开发能力：补充独立仓库之外的业务背景，并借助 Git worktree 支持多个任务并行。
- 支持本地验证：完整 Manus 可在开发者电脑本地运行，减少过去推到测试环境等待 5 到 10 分钟的反馈时间。
- 帮助排查线上问题：在权限控制下读取线上日志、配置和异常信息。
- 覆盖发布流程：针对发布中的重复和易卡环节补充自动化，但发布审批仍由人掌握。
- 执行端到端检查：用测试账号在浏览器和手机模拟器中走真实流程，验证功能结果。
Mono 也逐渐成为共享知识库和流程入口。比如运维人员把常见发版步骤写入其中，之后其他同事和 AI 都能按统一流程执行。作者认为，一个人为解放自己所做的小改进，最终可能让整个组织都更快。Manus 移动团队目前约 7 人，同时维护两个产品、四个移动应用，并尽量与网页版保持同步；团队已形成一个需求由一人借助 AI 负责多端实现的工作方式。
产品：产品经理直接构建，视频成为新的需求表达
传统产品流程需要调研、原型、设计、评审、研发排期、开发和验收。每经过一次交接，信息都可能损失；不同角色的优先级也可能错位。随着 Claude Code、Codex 等工具提升研发效率，Manus 一度发现瓶颈反过来了：研发不再是唯一短板，高质量需求供给不足，产品经理来不及支持开发速度。
团队先让少数研发人员成为端到端 Builder，负责从发现问题到上线；随后开展内部计划，让产品经理也能直接改代码。Mono 帮助补足规范、知识和流程，但产品经理的代码仍需研发审核。涉及模型调用或成本的修改，要先与负责同事确认；团队还用代码审核机器人检查代码，对支付等关键模块设置专门规则，并通过测试账号检查注册、支付等真实流程。
文章举例，一位产品经理为语音转文字功能先让 Manus 测试十多个模型、选择接入方案，再用 Mono 获取前端代码，按既有设计规范制作 Demo，逐一生成和检查用户场景图；迭代满意后，还把 Demo 剪成视频，并继续完成网页端和桌面端界面。这个过程里，人的精力主要放在模型选择、产品和设计评审，以及有发布权限的研发审核上。
Manus 将这一变化描述为从 Human in the loop（人在每一步参与）走向 Human on the loop（人设计规则、监督多个 AI，并在关键节点判断和负责）。AI 能完成的环节越来越多，但仍由人把控关键判断和上线责任。Manus 内部约一半产品经理已能独立完成需求并上线，所有产品经理都提交过代码；设计师也开始写代码。团队还尝试用产品需求视频（PRV）替代部分传统 PRD 或设计稿：视频可以直接展示使用场景、界面、交互、异常状态和实现逻辑，让设计、研发、测试围绕同一结果对齐。
市场：把 AI 变成工作流中的数字同事
市场团队原本需要在邮件、合同平台、审批系统、项目表格和广告平台之间搬运信息。内容合作要经历联系、确认、脚本审核、价格审批、签约付款、发布跟踪和复盘；广告投放也要跨平台查看数据、建系列、填素材并持续分析。流程和协作占用了大量时间，挤压了创意工作。
改造从一个具体痛点开始：内容或广告发布后，团队经常不能及时获知。团队先让 AI 写脚本自动发现内容发布时间，随后增加表现数据和历史合作复盘，再把合同、审批等环节连接起来，让状态变化触发 AI 更新进度并推进下一步。Manus 把这些功能做成内部网站：对人是看板、数据和日历，对 AI 则是一组可调用工具。AI 因此能进入实际工作流，而不只是等待用户逐条提问的工具。
数字同事可以在一个工作台 Session 中接收多人请求，再把具体工作拆给多个 Session 并行处理；它会区分紧急事项与可稍后处理的任务，而不是对 Slack 每条消息都立即响应。负责人可以把新的策略或产品理解直接交给它学习，使后续执行使用更新后的知识。它还会记住项目状态，在无人询问时提醒团队依赖关系，并主动向产品同事了解新功能的适用范围，以便之后准确回答市场问题。
这类 Agent 能查看历史资料、协助审核脚本和报价，但最终决策仍由人做。为了让数字同事能改善所用系统，Manus 给内部网站增加反馈接口：Agent 遇到功能缺口时可直接提交需求，通知触发 Manus 2.0 Automations 开发任务，未来便能使用新增功能。系统从“人将意见转交开发者”转向 Agent 直接反馈并推动工具迭代。
减少打断，让信息和工作进度更容易获取
Manus 的内部协作出现了几种新模式：产品和开发的事务性问题先问 AI；同事可查看同一项目成员的 Session，必要时申请加入并发言；一个总 Session 负责汇总需要负责人决策的事项，附上背景和推荐方案。Session 因而逐渐不只是个人对话记录，而成为多人共同推进工作的对象。
作者特别说明，“少找人问”不等于减少人与人交流，目标是减少临时打断以及由此带来的注意力损耗。作者自己会把二十多项待办交给 Manus：系统把任务拆开，能直接处理的就开始执行；需要背景时再询问，并结合 Slack、Gmail 和 Notion 做初步调研，把完整背景和方案交给对应产品经理。对作者而言，这除了提高效率，也减轻了面对大量待办时“不知道从哪里开始”的焦虑。
高额 AI 成本与团队判断
作者透露，Manus 9 月 AI 开销的人均金额超过 1 万美元，少数员工个人达到七八万美元。团队对这笔支出的解释有三点：购买的是时间和注意力，减少团队规模扩大后的沟通成本；在代码审核等重要场景使用当前能力最强的模型，以了解模型能力边界并降低线上风险；随着更多开发工作在 Manus Studio 内完成，内部使用数据能帮助团队找出 Token 浪费并改进产品，进而降低未来成本。
作者也承认，这种投入需要建立在持续“吃自己的狗粮”和探索 AI 边界的目标上，并相信模型和产品改进会让成本逐渐下降。文章并没有给出普遍适用的投入标准；其论点是，评估 AI 开销不能只看账单，还要看它是否减少了协调和等待、提高了质量，以及内部产品迭代是否能够持续降低单位成本。
Manus 看到的后续产品机会
内部实践让团队看到三类机会：第一，把 Session 作为多人协作的工作对象，提供更清晰的状态流转和管理能力；第二，让 Agent 在本地电脑、云端和团队成员设备之间协作，使工作不必依赖某个人一直守在电脑前；第三，让 Agent 能进入企业系统和知识库，主动组合工具与信息，发现用户尚未想到的解决方案。
文章最后强调，AI Native 并不意味着人的价值变小。组织过去更多依靠分工、层级和人力调度传递信息；现在则需要为 AI 补足上下文、工具和规则，再由人定义问题、判断质量、确定值得做的事，并对结果负责。团队的信任、文化和共同经历仍来自人与人的长期协作。Manus 的阶段性体会是：人的角色变得更集中，而不是消失；这套组织方式仍在探索中，也没有适用于所有公司的统一答案。