工程师把需求原样贴进了对话框
2026 年 9 月，Manus 团队在做 Manus 2.0。hidecloud 在 Slack 上发了几条需求和 Bug，过一会儿去问进展，看见工程师的电脑上开着一排 Codex 和 Manus 对话框，一条都没有关。他随便点开一条，里面贴的就是他自己刚发出去的那条需求，文字一个字都没改。
过去工程师拿到需求，会先自己分析，再动手写。现在团队把新需求和 Bug 大多直接交给 AI，由它到代码里找出相关部分并修改。人亲手敲代码的时间少了，说明要做什么、为结果负责的时间多了。
更让他意外的是节奏。在今天的 Manus，一个工程师同时处理十几个到二十个需求已经很常见。不少公司也在用 AI 写代码，不过一个人同时扛这么多需求仍然不多见。他后来发现产品、市场和运营里也出现了类似变化，人和 AI 的分工、消息的传递方式，以及一个人能负责的范围都在调整。团队变快，他高兴；节奏太快，他又担心这种做法会带出还没看见的问题。这两件事他当时都拿不准。
2026 年 10 月 26 日上午 10 点，他把这些写下来，发在公众号「潜云思绪」，地点标的是新加坡。Manus 做的是 AI Agent，也就是能自己接连完成一串任务的 AI。公司给自己定了两件事：一件是用自己的产品干自己的活，他管这叫吃自己的狗粮；另一件是去试 AI 到底还能做到哪一步。文章只写了研发、产品和市场三个团队正在试的做法，没有说这就是标准答案。
仓库没有合并，Mono 只给 AI 一本说明书
过去一个需求进来，团队要先评审，再由前端和后端分开开发，写完后一起对接口、找问题，这一步叫做联调，最后测试、上线。最耗时间的就是联调。前后端各自理解需求，再约定接口怎么接，理解不一样就得来回改。人和人很难完全想到一块儿，这一步经常要返工。
Manus 也有这个问题。AI 已经能同时写前端、后端和手机端，他们就想把分工收一收：一个人先把需求理解清楚，再把这三端一路做下去，省掉来回对接。代码却分散在不同仓库里，即使负责人是同一个人，AI 也看不到全貌。
他们做了一个叫 Manus-mono 的仓库，简称 Mono。代码仍留在原来的各个仓库，Mono 提供的是一个统一入口，外加一本给 AI 看的说明书。说明书里写着每个仓库做什么、彼此怎么配合、研发按什么规范工作。AI 要改哪一块，就把对应的仓库拉下来。下面这张图，把用 Mono 之前和之后放在一起。
本地验证从 5 到 10 分钟缩到几秒
Mono 是一步步补出来的。每补一步，都是因为上一步又露出了新问题。
- 他们先让 AI 看见全局。团队把独立仓库之外的业务知识补进说明书，使跨仓库协作成为可能，再用 Git worktree 从同一份仓库开出多份工作副本，这样几件事可以并行开发。
- 然后他们让 AI 在本地验证。过去每次改完代码，推到测试环境要等 5 到 10 分钟；现在完整的 Manus 可以跑在工程师的电脑上，验证只要几秒。文章没有说明测试用的是什么电脑，也没有说明这里的“完整”包含哪些服务。
- 然后他们让 AI 查线上的问题。在权限允许的范围内，Mono 可以读线上日志、配置和异常记录。
- 他们又让 AI 走完发布里容易卡住的操作。审批仍然由人来做。
- 等验证又变成费时间的环节，他们让 Mono 用测试账号走一遍真实流程，在浏览器和手机模拟器里看结果对不对。
用的人越多，写进 Mono 的做法越多。运维同事老被拉去帮忙发版，觉得烦，就把发版步骤写了进去。从此大家知道怎么发，也可以交给 AI 发。hidecloud 喜欢这个例子：一个人为了少干一件重复的事，结果整个公司都快了一点。
团队现在认同一句话：一个需求，一个人可以写完前端、后端和手机端。移动端一直只有 7 个人，同时负责 2 个产品、共 4 个手机应用，进度和网页版基本同步。这些做法在内部推开，几乎没有遇到阻力。hidecloud 认为原因有三个：探索 AI 的使用边界本来就是公司的追求，所以一直有人在推进这件事；重复的事，以及 AI 已经能处理好的事，如果还靠人工来做，大家很难接受；组织比较扁平，自上而下和自下而上的决定都能很快在全公司铺开。同事还用 Manus 做了一支 2 分 6 秒的视频，讲 Mono 是怎么演进到现在的。
大约一半产品经理能独立把功能做到上线
以前做产品是老路子。产品经理有了想法，先调研、看竞品、找数据，再和设计师画原型、画界面。接着评审，研发排期、开发，最后验收、测试、上线。这条链上人很多，话每过一个人就丢一点。同一份需求文档，产品和设计画出来的样子，可能完全不一样。更难受的是轻重缓急对不上。对这个人最要紧的事，到了下一个人那里未必要紧。人越多，越容易各忙各的。
Claude Code 和 Codex 出现以后，工程师的效率大幅提高，产品经理反而不够用了，来不及提供足够多、也足够清楚的需求。以前总是研发忙不过来。这一次倒过来，忙不过来的是产品经理。公司先让少数研发一个人从发现问题做到上线，少交接，也少把优先级排拧。他们把这种人叫做 Builder。当时又懂技术、又有产品判断的研发并不多。后来又让产品经理直接改代码，岗位边界故意淡化。问题还在。产品改完交给研发，对方不一定马上接得住。产品经理看问题的角度也和研发不一样，那时只能改文案和交互，改不了底层逻辑。
Mono 把这两处补上了。改动如果涉及调用模型，或者会增加成本，规矩是先找负责的同事确认，再改代码。公司还自己做了代码审核机器人，用当时最好的模型审全部代码。支付这类关键模块，另外设了检查规则。Mono 可以用测试账号走完注册、支付这些流程，一边走一边录屏。产品经理看录屏，就能指出哪里不对。
一位产品经理做语音转文字时，先让 Manus 测了十多个模型，从里面选一个接上。她再通过 Mono 拿到前端代码，按现有的设计规范做出能看的样例，并让 Manus 把用户可能遇到的场景逐张画出来。她一张张看，不对的就让 Manus 改。方案清楚以后，她把功能写完了。网页端和电脑端的界面，都是她做的。这件事里，人主要拍三下板：选哪个模型，产品和设计一起看样例，以及有发布权限的研发来审代码。
hidecloud 觉得，人的位置变了。以前 AI 大概做完 70% 到 80%，剩下的洞由人来补。现在人先把规则定好，同时看着好几路 AI 干活，在关键地方判断方法和结果，需要时自己上手，并为结果负责。这里的 70% 到 80% 是他的概括，文章没有给出任务样本和测量方法。
Manus 2.0 把做视频的能力加强了。它可以用图片生成视频，也可以用代码做动画。有些产品经理交需求，交的就是一段完整视频。几分钟里要讲清五件事：用户在什么情况下用，界面长什么样，点下去会发生什么，不同状态和特殊情况怎么处理，背后的实现逻辑是什么。设计、研发和测试看的是同一段演示，更容易明白最后要做成什么样，不用再跟不同的人各讲一遍。他在内部产品会上讲过之后，更多同事开始用这种方式写需求。语音输入功能的这段需求视频他们称为 PRV，时长 3 分 33 秒。
到发文时，大约一半产品经理能够独立完成需求并上线，所有产品经理都向代码库提交过代码，设计师最近也开始写代码。Manus 2.0 里，用户在 Manus Studio 能看到的大部分界面由一位产品经理写成，视频编辑器也由一位产品经理写成。
市场团队的数字同事会跟流程，也会提需求
市场团队也试了最近的两件事。做内容合作，要先联系，再确认合作、审脚本、批价格、签合同和付款，发出去以后还要跟踪、复盘。投广告也长：看好几个平台的数据，建广告系列，填素材，再看效果，再调整。这些环节散在邮件、合同平台、内部审批、项目表格和各平台后台里。合同签了，人去改表格。内容发了，人再去通知同事。人少，流程长，大量时间耗在对接上，用来想创意的时间被挤掉了。
他们从一个很小的问题改起。合作内容或广告发出去以后，自己往往不能马上知道。消息要过好几层人，等知道的时候已经偏晚。他们先让 AI 写脚本，自动发现内容什么时候发出来。知道了发布时间，就接着看数据。既然数据能看到，就把以前的合作也复盘一遍。再往后，合同签完、内部审批过了，系统会发一个信号。AI 收到信号就更新进度，再找相关同事做下一步。这些功能做进了一个内部网站。人打开它，看到的是数据、看板和日历。AI 用它的时候，调用的是一组工具。会用这些工具参与工作的 AI，就成了他们说的数字同事。
数字同事和普通工具不一样。它进了团队每天的流程。
- 很多人同时找它。它只在一个叫“工作台”的对话里和大家说话，具体任务再拆到别的对话里并行做，这样它才不会忙到顾不过来。Slack 里消息很多，它也不会每条马上回。它先看这条消息跟自己有没有关系。有关系的，再分成两类：得放下手头的事马上处理，或者等手头这件事做完再处理。这套分法是 AI 在开发过程中自己想出来的。
- 新的说法能更快变成下一步怎么干。以前团队有了新策略，或者对产品有了新理解，要先在例会上讲一遍，再写一份简报。现在市场负责人把讨论直接转给它，说一声“学一下”。它会把这些记进自己的材料，以后每次干活都用得上。
- 它记得住比较长的目标。有一次，同事在 Slack 里聊两个项目，一时想不起其中一个走到哪了。没有人叫它。它自己提醒：B 还在测试，要不要等 A 的结果出来，再看 B。hidecloud 第一次听说，觉得它像一位一直在认真听会的同事。
- 它会自己去问别的团队。产品同事发布了 3D 模型生成和骨骼绑定以后，它主动问这个功能适合什么。问下来才知道，骨骼绑定目前支持七类物体，比如鱼、蛇和四足动物。它把这些条件记下。以后对外讲这个功能，就能讲准。七类分别是哪七类，文章只举了例子，名单没有列全。
同事审脚本和价格时，也会找它一起看。人短时间能翻的资料有限，它看过全部历史记录。最后拍板的还是人。
平常网站有什么功能，数字同事就用什么。网站不好用，它只能凑合，或者告诉人，再由人去改。他们不想再当传话的人，就给网站留了一个提意见的入口。数字同事用得不顺手，可以直接从这里提需求，需求一进来就自动触发 Manus 的开发任务。用的是 Manus 2.0 的 Automations：外面来一条通知，任务就自动开始。这样，它除了用现成功能干活，碰到系统还做不到的事，也可以提一条需求，以后自己就能用上。文章没有写自动触发过多少次，也没有写其中有多少次经过了人的复核。
同事要看进度，可以打开同一条对话
上面这些事有个共同的变化：以前得找人问的事，现在常常不用去打断那个人。
产品和开发上的具体问题，先问 AI。同事用 Mono 做了一个 Slack 机器人，跑在云电脑上。它接到任务就去处理，处理完回到原来那条消息里回复。用得最多的是不做研发的同事。功能是怎么实现的、文案在哪、某项功能上线了没有，不用先打听归谁管，直接问它。
想看进度，就打开那条 AI 对话。以前工程师做到哪了，都在他自己和 AI 的对话里。别人只能找他问。他下班以后，别人也看不见。他们因此做了一个目前只在内部用的功能：同一个项目的人，默认能看见彼此的对话，也可以申请进到对话里说话。比如技术同事先和 AI 把大量工作做完，产品经理再进同一条对话，改间距、样式和文案。两个人和 AI 轮着往下做。别人要在你的对话里发消息，还是得你点头。这部分权限他们还在改，外面的用户现在用不上。下面这张图是在示意这种协作。图里的定价页、折扣和间距都是编出来的。
少掉的是被人临时打断。同事之间该说的话还在。hidecloud 更在意的是，协作里那些突然插进来的事少一些，被打断掉的时间和精力也就少一些。还有一位同事把用法收得更极端。他是团队里用 AI 最多的人。他有一条总的 Manus 对话，只干一件事：把需要他决定的事列出来，旁边附上建议怎么做。别人在 Slack 里聊得热闹，他可以不打开 Slack，也很少打开代码仓库。他只问 AI：现在有什么要我决定的？AI 列出几件事，说明每件卡在哪，由他来定。
hidecloud 自己每天的待办有二十多件。他在一些场合说过，自己有 ADHD，最难的是开始动手。现在他把这些待办交给一个专门的 Manus 项目，每一件拆成单独的任务。AI 能做的，就直接开始。拿不准的，会来问背景，也会问希望哪位产品经理来跟。然后它看 Slack、Gmail 和 Notion 里已有的信息，先了解一遍，再把需求和了解的结果一起交给那位产品经理。产品经理拿到手的，是一份背景已经补好的方案。对他来说，每天“不知道从哪下手”的焦虑少了。
9月 AI 开销人均超过 1 万美元
10 月初，hidecloud 在朋友圈写过，公司 9 月的 AI 开销人均超过 1 万美元。这是平均数，少数同事一个人就用了七八万美元。总金额、按多少人平均、以哪种货币结算、算进了哪些供应商，文章都没有公布。这个人均数也不能用来算公司少雇了几个人。
朋友圈发出去以后，有人觉得花得太过。这些话他都看了，正面回了三点。第一，这笔钱换来的是时间和注意力。团队一大，沟通就会变贵。用 AI 省下来的，是每个人的注意力，让人对自己负责的事看得更完整。第二，贵，是因为用的是当时最好的模型。他认为，这是摸清 AI 到底能干到哪的办法。负责研发效率的同事告诉他：代码审核机器人已经用了一阵子。最近半年，这位同事没有听说，有问题的代码被合进去、然后造成线上故障。AI 写代码普及以后，每天交上去的代码非常多，他用“非常夸张”来形容，没有给出具体条数。审核用的是当时最强的模型。这位同事觉得，这可能是公司最划算的一笔钱。半年没听说故障，说的是他本人的听闻。第三，成本还会跟着产品一起降下来。越来越多的开发是在 Manus Studio 上做的。这是他们自己的产品，内部用的时候能看见 Token 浪费在哪。产品改了，浪费少了，成本就降，用的人也会受益。
这些做法回到前面那两件事：用自己的产品干自己的活，以及去试 AI 的边界。他也相信成本还会降。今天每个月 1 万美元换来的干活方式，两年后可能只要几百美元。这是他的估计。干活方式和组织方式会留下来。他觉得，这些比当月那张账单更值钱。
做什么仍然由人决定
这些尝试也让他们看见了产品上的机会。自己踩过的坑，同行很可能也会遇到。Manus 接下来要做好三件事。他们会先自己用，再交到用户手里。第一，一条 AI 对话，会变成几个人一起往下做的那件工作。过去是一个人接一个任务，用一段对话做完，再开下一段。以后可以是同一个人提出问题，设计师出方案，工程师做出来，产品经理接着运营，都在同一条对话里往下走。这条对话跟的是一整项工作，做到哪一步得看得更清楚，也可能需要一块更好用的面板来管。第二，换设备也能接着干。一个人已经可以通过 Agent 管多台电脑。下一步是把自己电脑和云端打通，并让同事之间也能协作。这样人不用一直守在电脑前面，事情也能往前走。第三，Agent 自己去找办法。进了公司的系统和资料以后，它除了完成交代的任务，还可以用已经有的工具、知识和资源，找出人没想到的做法。
回到开头那一幕。工程师把需求直接交给 AI，同时推进十几个任务。快只是其中一部分，组织怎么运转也在变。过去，消息靠分工和层级往下传。一个人能做成多少事，要看他能调动多少人、多少资源。现在，大家把更多时间花在给 AI 补它要看的材料、把工具准备好，然后再判断、再决定。
AI 能完成的部分已经很多，做什么仍然由人决定。他们曾经开玩笑讨论，既然 Manus 能做这么多，以后人还要不要到公司，能不能让各自的 Agent 一起工作。他们的结论是，人还得来。公司里真正要拍板的问题，还是要人提出来、讨论、决定。氛围、想法，以及人和人之间的信任，来自一天天的磨合，也来自关键时候一起经历的事。所以他现在的体会是：在这种默认由人和 AI 一起干活的地方，人要做的事更集中了。人来定义问题，判断做得好不好，决定什么值得做，并为结果负责。还有一件事很重要，就是和 AI 一起把本事往外扩。人仍然关键，所以公司还在招人。
半年或者一年以后再写这个话题，干活方式会变成什么样，他没有答案。AI 能做的事还在变多，组织也得继续摸索怎么跟它配合。每家公司的目标、架构、做法和文化都不一样。这种组织怎么运转，未必有一套标准，也未必有一个最终样子。对 Manus 这样一家做 AI Agent 的公司来说，人和 AI 怎么一起干活，是得一直回答下去的问题。
