AI Native 组织怎么干：一人端到端、视频当 PRD、数字同事
AI 写代码已经不稀奇；稀奇的是整家公司怎么围着 Agent 改组织结构。Manus 联合创始人在公众号长文《用 Manus 改造 Manus》里，记录了研发、产品、市场三支团队正在试的做法：一人端到端、本地秒级验证、人从「环里补刀」变成「环上拍板」、视频当需求、市场侧养「数字同事」。本文按该文整理成可对照的概论——以 Manus 为案例来源，不外推未写明的公司数据；文中自称的人均 AI 开销等数字照录并标明出处，本站未核实财务。
说明：以下实践与数字均转述自《用 Manus 改造 Manus，AI Native 组织改造的实践和思考》（潜云思绪 / Manus，微信公众号原文）。本站未参与其内部系统，未复现 Mono、数字同事或视频需求流程；凡组织效果与开销数字均视为文中自称。
问题从哪来：损耗在人与人之间
文中回顾「古法」产研：需求评审 → 前后端分工 → 联调 → 测试上线。最大损耗常在联调——两边各自理解需求、约定接口，理解不一致就反复改。作者的判断是：人和人对齐天然贵；既然 AI 能跨端改代码，岗位边界可以模糊，改成一个人把需求理解清楚，再推前端、后端、移动端。
卡点是代码散在多仓库时，即便人负责端到端，模型也看不到全局。于是他们做了统一入口 Manus-mono（下文称 Mono）：代码仍分散在各仓库，但给 AI 一本说明书——各仓库做什么、怎么配合、规范是什么；要改哪块就拉对应仓库。Git worktree 支持并行。演进顺序按文中所述大致是：看见全局 → 本地跑完整产品（验证从等测试环境 5–10 分钟降到数秒）→ 受控读线上日志与配置排查 → 补齐发布操作但审批仍在人 → 用测试账号在浏览器/模拟器走端到端。运维把发版流程写进 Mono 之后，别人也能让 AI 照做——一个人图省事，组织侧少打断。
文中称移动端约 7 人同时扛 2 个产品、共 4 个移动应用，进度与网页版基本同步。这是案例自述，不是行业基准。
人从「环里补完 AI 剩下的 20%」转向「环上定规则、审关键节点、为结果负责」。
产品侧：人人交过代码，视频当 PRD
工程师效率抬起来之后，文中描述的新瓶颈是：产品经理来不及产出足够多的高质量需求——资源紧张的方向反了。早期尝试让少数研发当 Builder，端到端从发现问题到上线；再推产品经理直接改代码，却仍卡在交接和缺少研发视角，一度只能改文案和交互。
Mono 之后，规范要求模型调用或成本相关改动必须先找负责人确认；自建审核机器人用强模型审代码，支付等模块另有规则；再用测试账号走注册、支付等流程并录屏，产品经理靠录屏指出问题。文中举语音转文字为例：产品经理让 Agent 测十多个模型再选型，按设计规范做 Demo、逐场景出图检查，再用视频编辑把 Demo 做成方案视频，随后把网页端和桌面端界面也写完。人的参与集中在：选模型、产品和设计评审 Demo、有权限的研发审代码。
作者把这概括为从 Human in the loop 到 Human on the loop：以前 AI 做七成八成、人补其余；现在人设计规则、监督多个 Agent、在关键节点判断，必要时介入并承担责任。Manus 2.0 的视频能力上去之后，部分需求不再是传统 PRD/设计稿，而是几分钟的产品需求视频（PRV）：场景、界面、点击后果、异常状态、实现逻辑一次说清。上下游看同一段演示，少反复解释。文中称约一半产品经理能独立完成需求并上线，所有产品经理都向 Manus 提交过代码；设计师也开始写代码；Studio 用户可见的大部分界面、Video Editor 等，文中写为由产品经理完成。
市场侧：数字同事进流程
内容合作、广告投放链条长，信息散落在邮件、合同、审批、表格和各平台后台，人在系统之间「搬运」状态。文中说改造从一个小痛点起步：合作内容/广告发布后，消息要经多层才传到负责人。于是先让 AI 写脚本发现何时发布，再看数据、复盘历史合作，再把合同签署、审批完成等信号接上，自动更新进度并催下一步。这些能力做成内部网站：对人是看板与日历，对 AI 是可调用工具——会用这些工具干活的 AI，被称作数字同事。
文中描述的行为包括：在一个「工作台」Session 接需求，再拆到其它 Session 并行，避免注意力被占满；Slack 消息先判断是否相关、是否要打断当前事；把新策略「学一下」写进知识后用于后续执行；无人 @ 时主动提醒项目阶段；跨团队问清功能适用条件再对外介绍；审脚本和价格时被拉来一起看历史——最终拍板仍是人。网站还开了反馈接口：数字同事用得不顺，可直接提需求并触发 Automations 开发任务，形成「用系统 → 嫌不够 → 提需求改系统」的闭环。以上均为文中叙述，本站未实测。
信息少「找人问」，打断变少
共识方向是：产品与开发的事务问题先问 AI（文中有跑在云电脑上的 Slack 机器人）；看进度则打开 Session——同项目成员默认可看彼此 Session，也可申请进入发言，产品和工程师可在同一会话里交替改样式与文案。作者强调，少掉的是「临时打断」的损耗；人与人该聊的还是要聊。更极端的用法：有人只维护一个总 Session，专门列出「现在需要我决定的事」和推荐方案；作者自己也把待办交给专门项目，能做的直接开做，不确定的先调研再交给对应产品经理。
开销与边界（文中自称）
| 主张（原文） | 怎么理解 |
|---|---|
| 9 月 AI 开销人均超过 1 万美元；少数人单人可达七八万美元 | 文中自称的财务观察，本站未核实；作者回应质疑时强调买的是时间与注意力，并用最强模型探边界 |
| 代码审核机器人启用后，近半年未听说因合入问题代码导致的线上故障 | 内部观感，非独立审计 |
| 审批权、发布权仍在人；支付等模块有专门检查 | Human on the loop 的硬边界 |
| Session 成为多人协作对象；跨设备与 Agent 主动发现解法是后续产品方向 | 文中对机会的展望，不是已交付承诺 |
作者对「人还做什么」的答案是：定义问题、判断质量、决定什么值得做、为结果负责，并与 AI 共同成长。公司氛围与信任仍靠人的磨合；他们也仍在招人。
常见坑（从案例反推，给你对照）
- 只发工具、不补知识入口。没有类似 Mono 的说明书和规范，一人端到端也会在多仓库里瞎找。
- 本地验证仍等远端环境。文中把「5–10 分钟等环境」当成早期瓶颈；秒级本地验证是闭环能转起来的前提之一。
- 人还在环里手补每一刀。若规则、审核、录屏验收没建好，所谓 on the loop 会退回成加班打补丁。
- 数字同事无拍板边界。文中反复写最终决策在人；把审批也交给模型，风险不在案例承诺范围内。
- 照抄人均开销数字当目标。那是文中自称的探索成本，不是你的预算模板。
完成标准
- 能用自己的话讲清：一人端到端要先解决「AI 看见全局 + 本地验证 + 人保留审批」。
- 能区分 in the loop 与 on the loop，并指出视频需求对齐了哪些信息。
- 若要试「数字同事」，先画清工具接口、工作台 Session、人的最终拍板点——而不是先堆自动化。
- 引用开销与故障数字时注明「文中自称 / 未核实」。
最后
AI Native 的重点不在多装几个 Agent，而在把知识、工具、审批和协作界面改到 Agent 能跑、人能判。Manus 的文章是一份进行中的内部笔记，当不了标准答案；可以从「统一给 AI 的说明书 + 本地验证 + 人只守关键闸门」三件最小集试起。关心公司级 Agent 的入口、身份与沙箱，可对照站内 公司级 Agent 五个底座。
