Skip to content
View original post on X: meng shao
Published
60/100

Manus co-founder describes how AI-native teams run work with agents

AIManus co-founder Zhang Tao describes how the company uses its own agent product to reorganize engineering, product, and marketing work. The article says engineers send Slack requests directly to agent sessions, with one person handling more than ten requests in parallel.
meng shaoVerified on X
@shao__meng
View on X

来自 @ManusAI 联合创始人张涛 @hidecloud 发布在公众号的一篇文章「用 Manus 改造 Manus,AI Native 组织改造的实践和思考」,Agent 工程实践价值非常高,强烈推荐给各位 AI 开发者们。 https://x.com/i/article/2114673070539776000

用 Manus 改造 Manus:AI Native 组织怎么边 dog fooding 边改进工作方式

来自 Manus 联合创始人张涛 @hidecloud 发布在公众号的一篇文章,Agent 工程价值非常高,强烈推荐给各位 AI 开发者们。

公众号:https://mp.weixin.qq.com/s/I_hNNAf7LFBf5nJ0rEJHig?scene=1

Manus 把「做 Agent 产品」和「用 Agent 改组织」绑在一起:工程师常把 Slack 需求原文直接丢给一排 Codex/Manus Session,一人并行十几个需求;损耗从「人与人对齐」转向「给人补上下文、工具与审批节点」。文中用 Manus-mono、产品经理写代码与视频 PRD、市场「数字同事」、人均约 1 万美元 AI 开销 四条线说明:人从 Human in the loop 更偏 Human on the loop,定规则、盯关键节点、对结果负责。

开场那一幕

9 月冲 2.0 时,张涛给工程师提需求/Bug,再去看进展:屏幕上是一排 Session,输入几乎是 Slack 原文一字未改。过去是人先分析再写;现在找相关代码、改动多由 AI 做,人更多在指挥与担责。一人同时压十几、二十个需求已成常态,张涛既兴奋又不安:够快还是太快?有没有看不见的坑?

立意:Agent 公司必然「吃自己的狗粮」+ 探索使用边界;默认人机协作后,组织该怎么工作。下文只写三个团队的切片。

研发:最大损耗曾在联调 → Manus-mono

旧链路:评审 → 前后端分仓开发 → 联调 → 测上线。联调最贵,接口与理解难对齐。想法是:AI 能跨端写码,模糊分工,一人吃透需求推前端/后端/移动,减少对接。但代码散在多仓,单人负责仍缺统一上下文。

Manus-mono(Mono):不是把代码物理合成一仓,是统一入口 + 给 AI 看的说明书(各仓职责、协作方式、规范);要改哪就拉哪。演进大致是:

- 看见全局(业务知识 + Git worktree 并行)

- 本地验证(整套 Manus 可本地跑,验证从等测环境 5–10 分钟到秒级)

- 受控读线上日志/配置/异常排查

- 走发布流程(卡住环节补 AI 操作能力,审批仍在人)

- 端到端验证(测账号走真实流,浏览器/模拟器检查)

Mono 越用越像知识库 +「熟悉规则的超管」:运维烦发版就把流程写进 Mono,全公司都能让 AI 做。共识:一个需求,一个人可以写完所有端,移动端约 7 人扛 2 产品、4 个 App,进度大致跟网页同步。

能推开的三因:探索边界本就是追求;无法忍受「AI 已能高效处理仍人工」;组织够扁,决策上下都快。

产品:怕优先级错位 → Builder + 全员交过代码 + 视频当 PRD

古法产品链人多、信息逐层丢;更难受的是优先级错位。Claude Code/Codex 抬高工程吞吐后,瓶颈翻面:产品经理不够用,高质量需求供给不上。

尝试:少数研发当 Builder(发现问题到上线一条龙);再淡化岗位,让 PM 也能改码,但交接仍卡、PM 缺研发视角,一度只能改文案交互。

Mono 之后:规范强制(如模型调用/成本须先找负责人确认);自建审核机器人(强模型审全量合入,支付等关键模块专门规则);Mono 用测账号走注册/支付并逐步录屏,PM 看录屏指出问题。

案例:一位 PM 做语音转文字,先让 Manus 测十多个模型再选型;经 Mono 拿前端按设计规范做 Demo,生成用户场景图逐张改;再用视频编辑把 Demo 做成片,然后自己把网页/桌面界面写完。人主要卡在:选模型、Demo 产品/设计评审、有发布权的研发审码。张涛称这是 Human in the loop → Human on the loop:人设计规则、监督多 AI、关键节点判断并担责。

Manus 2.0 视频能力上去后,部分需求从 PRD/稿变成 几分钟完整视频(文中称 PRV):场景、界面、点击后行为、状态与边界、实现逻辑一镜对齐上下游。约一半 PM 能独立需求到上线;所有 PM 都向 Manus 提交过代码;设计师也开始写码;Studio 用户可见界面、Video Editor 等多由 PM 写出。

市场:人在系统间搬运 → 数字同事

内容合作/投放流程散落邮件、合同、审批、表格、各后台,人少流程长,创意时间被挤。起点很小:合作内容/广告发出后公司往往不第一时间知道。先让 AI 侦测发布时间 → 看数据 → 复盘历史 → 合同/审批完成发信号更新进度并推进下一步 → 做成内部站:对人是看板日历,对 AI 是可调用工具集,于是有了「数字同事」。

数字同事特点(文中举例):

- 统一「工作台」Session 接需求,再拆并行 Session,避免注意力被占满;Slack 先判相关、是否打断(规则称开发中由 AI 自设计)

- 负责人把讨论转给它「学一下」,策略进知识、之后执行带上

- 未 @ 也能主动提醒项目阶段(「B 还在测,要不要等 A」)

- 主动跨团队问清能力边界(如骨骼绑定支持哪些物体类)再对外讲准

- 审脚本/价格时人愿拉它看历史;拍板仍是人

- 网站开反馈接口:用不顺直接提需求 → Automations 触发开发任务,会自己推动系统变好的闭环

横切:少「找人打断」

- 产研事务问题先问 AI(Slack 机器人跑在云电脑上,非研发用得最多)

- 看进度:打开彼此 Session(默认同项目可见,进对话发言仍需批准,权限还在打磨),不是少交流,是少临时打断

- 极端工作法:总 Session 只列「需要我定的事 + 推荐方案」;张涛自述 ADHD、待办 20+,交给 Manus 拆任务、能做的直接开、不确定的问背景与跟进人,再结合 Slack/Gmail/Notion 调研后交给 PM

人均约 1 万美元 AI 开销值不值

朋友圈引发质疑后文中正面答三点:买的是时间与注意力(组织变大时);贵因用最好模型摸边界(代码审核机器人投入后,同事称近半年未听说因合入问题致线上故障,而日提交量很夸张);成本会随自有产品(Studio)看见浪费而下降,用户也受益。信条仍是吃狗粮 + 探边界;今日万元级工作方式,两年后或数百美元,组织与工作方式资产更贵。

看到的产品机会与「人最后做什么」

Session 变多人协作对象(状态流转、管理面板);跨设备(一人管多机 → 本地/云与同事协作);Agent 进系统与知识库后主动发现人未想到的解法。

人角色未变小,更集中:定义问题、判断质量、决定什么值得做、对结果负责,并与 AI 共同成长。公司氛围与信任仍靠人日积月累,不是「各自 Agent 代班就不来公司」。仍在招人。半年一年后再写,形态未知;各司文化不同,未必有标准答案,但对 Agent 公司这是必答题。

Source details

meng shao · x.comPublished · added here

Original title: 来自 @ManusAI 联合创始人张涛 @hidecloud 发布在公众号的一篇文章「用 Manus 改造 Manus,AI Native 组织改造的实践和思考」,Agent 工程实践价值非常高,强烈推荐给各位 AI 开发者们。 https://x.com/i/articl...