系列解读 Manus 联创张涛「用 Manus 改造 Manus，AI Native 组织改造的实践和思考」
01 - 研发：AI 不只是助手，还能走完全流程
Manus-mono：给 AI 一张全栈地图
传统产研团队的痛点普遍是前后端联调里人对不齐，不是写代码本身。Mono 没有把多仓揉成一个大仓，而做统一入口 + 给 AI 看的说明书，让一个人带着同一个智能体上下文，把前端、后端、移动端一路做完；审批仍留在人手上。
以前卡在哪
需求评审 → 前后端分头写 → 联调 → 测试上线。损耗最大的是联调：两边各自理解需求、再约接口，理解一偏就反复改。Manus 想模糊分工（一人吃透需求再推各端）但代码散在多仓，AI 仍看不到全貌。
Mono 是什么
统一入口，说明书里写清：各仓职责、怎么配合、研发规范。要改哪块就拉对应仓。文中强调它是一步步长出来的，每步都在解上一步的瓶颈：
1. 看见全局：补业务知识，跨仓协作；Git worktree 支持并行。
2. 本地验证：完整 Manus 可跑在本机，验证从测环境等 5–10 分钟变成几秒。
3. 查线上：权限内读日志、配置、异常。
4. 走发布：补齐易卡环节的操作能力，审批权仍在人。
5. 端到端验证：测试账号走真实流程，浏览器和手机模拟器里看结果。
用的人越多，知识越多。运维嫌老被叫去发版，就把发版流程写进 Mono，一人图省事，全公司都快一点。共识变成：一个需求，一个人可以写完所有端。例子：移动端 7 人撑 2 个产品、4 个 App，进度和网页版基本同步。
Mono 效果对比：整个代码库共用一个智能体
不用 Mono：每个需求约 5 人 + 5 个智能体（产、设、前、后、移动各带独立上下文），产出再靠跨团队人工交接；流程是需求→设计→开发→集成→测试→运维发布，环节长。
使用 Mono：每个需求约 1 名构建者 + 1 个共享上下文的智能体。Mono 竖条列出仓库地图、开发规范、界面规范、发布流程、线上调试，并注明「由全团队编写和使用」。流程压成：提需求 → 全栈构建 → 本地验证 → 审批后上线。
为什么在 Manus 推得动
张涛归为三点：本来就在探 AI 边界；受不了重复活和 AI 已能办的事仍人工做；组织够扁，上下决策都能很快铺开。