开场与 AIE 大会见闻
Speaker 2: 因为已经有八位朋友进来了，我们八位朋友可以在弹幕里面扣个 1 啊。早上好，非常感谢大家在星期日的早上加入我们这么严肃的讨论。
Speaker 1: 我还是第一次。因为我之前跟任鑫聊播客的时候，也基本上用它。我还是第一次发现，原来这个还可以做直播，居然还有 chat 的聊天间，还挺有意思。
Speaker 2: 就是您这次去这个 AIE 感觉怎么样啊？就是看你很忙的样子，就是经常被人群所包围一下。
一般而言，过去的话一般是说十一点钟到下午大概四点多钟左右，这个阶段是人还挺多的。但我没想到 AIE 是从早上九点一直到晚上六点人都很多，这个是非常超出我的预计的。
Speaker 1: 我在展会的那个时不时跑过去听一听，我发现根本都找不到位置，然后人巨多。我就说那我还是回展台那边干点活什么之类的。反正昨天我还特地去找去的群友，然后去要了一些现场的录音。我自己因为有一些人我还是挺好奇的，挺想听的，刚好大家做了一个自己的整理版。我还打算今天很认真、很认真地看一下。因为昨天基本上处于累到一天都在瘫痪的状态，可见 AIE 的这两天的交流的密度和浓度。
Speaker 2: 是的是的是的，好像比较火……我不知道您去看了哪几场，比较火的好像是有那个 Real 讲的那一个，对，Notion 的那一场非常火。
Speaker 1: 其实那一场的好评度很高，就说好像是听到了完全不同于说 AI 圈子里面更多专门做 AI 的人的那些不一样的视角。
Speaker 2: 对对对，因为有些分享还是偏技术类型比较多的，就是他们怎么做一些比如说 post-train 啊，比如说做 SFT 啊这样子的事情。但是屠龙可能更多讲的是应用相关的，可能大家引起的共鸣会比较深一点，我觉得是。所以也是广为热议啊，在那个圈子里面。
组织提效话题引入与展会反馈
大家好啊，欢迎大家来参加这个超线性学院的系列直播活动——AIE 和他的朋友们。我是本场活动的主持人，我叫 Golden。我之前是一位在 Meta 的工程师，也是超线性学院的老朋友了。
那 AIE 大会呢在本周四和周五在上海成功落下了帷幕。我本人也是到了线下，听了非常多精彩的分享，也了解到了许多有趣的公司在做的非常有趣的实践。那么其中呢，Manus 的分享关于内部的 AI 组织实践尤为受欢迎。所以今天呢，我们非常高兴请来了 Manus 的于一老师来和我们继续深入探讨这个话题：当 AI 能轻易地为个人提效的时候，我们如何思考整个组织应该如何被 AI 所提效呢？
首先我们请于一老师跟大家打个招呼吧。
Speaker 1: Hello，又见面了，我应该也是咱们的老朋友了。然后跟有一些人，我们应该在 AIE 上已经见到了。这场算是我和金老师刚才也都闲聊了一下关于 AIE 的感受，包括其实我们 Agent 的工程负责人范冰倩在大会上去做的那个分享。然后后面反正还有很多人也说没听完，希望能听到更多，包括说有一些可能那个会场也是大家错过了一些。
所以刚好后面我来补充一些作为一个刚刚加入 Manus 一个月的人，带着非常多的问题进入的时候去看到的一些我觉得挺有意思的一些解法，和我觉得接下来我还会重点去观察的地方。这个可能是今天的分享我们会主要去聊到的。
然后我跟金老师也谈到说，今天的话因为也是周日，大家经过 AIE 的轰炸估计也处于一种比较疲惫的状态，所以我们可能整个分享的过程当中也是属于大家可以随时提问，包括我跟金老师也会聊一些更加轻松一点的东西。希望能在线下在北京，或者未来很快我也又要去上海，跟大家再继续相聚。
Speaker 2: 好，我们欢迎于老师。我们也是熟客之间的老朋友了，所以我们现在聊点轻松的话题吧。我们刚刚在讲 AIE 嘛，讲到于老师在 AIE 非常忙碌，有没有什么有趣的故事可以分享呀？有没有什么有趣的事情可以跟大家分享的？
Speaker 1: 我觉得其实也挺惊讶的，这次可能也因为是上海吧，我觉得 AIE 选上海还是很正确的选择。因为对于我而言，包括那两天在展台，其实当时有一个期待，就是能够多听一些用户的声音、用户的视角：到底大家怎么去用 Manus 的？对 Manus 的期待是什么？
我其实没有预料到有来非常多的来自于海外的朋友，有来自于澳洲的，来自于美国的，来自于新西兰的。然后跟我们也聊了，包括也有那种给我们月付费一千美金以上的朋友，过来去聊他们到底怎么去使用 Manus，用得好的地方、用得不爽的地方分别都是在哪里。这个是我还挺惊讶的。因为我以为这次可能更多还是去聊到一些国内的用户，结果来展台聊的百分之二十到百分之三十其实都是海外的用户。可能他在这段时间回到了国内，然后来了 AIE，这个是我觉得挺有意思的。然后也用上了我久违的高密度的英语口语，很久没有这么高密度的英语口语，就像英语角。
他们其实有提到非常多有意思的事情，也有很多我觉得也是 Manus 我们后面要加强的。有很多感觉是很久没有抓到 Manus 的工作人员聊了，然后就开始疯狂地聊，包括有提到说自己拿 Manus 帮自己的小生意做起来了；但是又觉得说哎，你们 Manus 怎么都没有一些线下的聚会啊，让大家可以一起分享用法呀；包括我也会提到说其实 Manus 底下会有一个用户 Meetup 的活动。然后发现跟用户的沟通还是需要有更多的内容让大家知道。就是会发现说有很多我们很好的产品功能，其实用户都没有感知到，我觉得这个是一个非常好的视角。
然后我跟大家讲的时候，比如说可能借助模型，大家终于了解 Manus 的 project 这个功能对于团队协作好像是提供了一些新的解法，好像之前大家都还对此没有什么太大的感知。我觉得这个是 AIE 很棒的地方，就是直接接触用户。然后有很多的视角，包括由于它非常高浓度，当你发现好几个人，或者你大量地跟你的用户介绍某一个功能的时候，他们对此都会发现说：“哎，我不知道这个，但这个很好，这是我们需要的功能。”我觉得是对于去了解你的产品和用户之间的 gap 一个非常好的场合。这个反而是让我记忆最深刻的。
一个是聊到了非常多的海外用户；第二个是会发现有很多的功能大家还不太清楚。我觉得这也是线下交流刚才咱有提到的，有一些上下文现在已经大量地可以给到 AI 了，但是有一些像这种我也会把它称之为 small talk 的东西，AI 还没有。
另外一个事情就是其实我们全程放了一个录音在那边，把我们所有的对话，在展台里面的对话其实都录下来，到时候会交给 AI 去做进一步的处理。但你在现场更多的是去做那种感受，我觉得也是一次人机协同的展会吧。包括我们一开始准备的物料基本上都是英文的，然后会发现有些人说为什么没有中文，然后就现场十五分钟用 Manus 把所有的物料改成中文的然后上屏，我觉得也挺有意思。
Speaker 2: 是的是的是的。我尤其感觉今年以来线下的活动非常非常多。像 OpenAI 和 Anthropic，他们在美国这边也是经常会做一些这种线下的活动，然后可以直接地接触用户。我不知道您这边跟用户聊完，特别是海外的一些用户聊完之后，有没有发现：哎，大家居然在这么用 Manus？或者说有没有挖掘到一些 Manus 神奇的，或者可能内部团队都没有发掘到的一些用法呢？
Speaker 1: 我觉得倒还好。因为我自己是非常重度地在用 Manus，大家谈到的一些案例其实我之前也有在内部的 best use case 库里面有看到，包括我自己用起来大体上也都会这么用。所以惊喜的地方这次倒还好，反而是会发现说有很多我们自己内部用得已经非常爽的功能了，然后外界对此没有感知。这个是我在这次展会上甚至都跟内部的团队有聊到说：我们这个东西超好的，但外界不知道这是怎么回事。这个反而是让我觉得更深的地方。由于我自己非常重度地在用，所以大家的用法我大概也都能猜到。
Speaker 1: 一些 token 自由的快乐的凡尔赛。
主题分享：超级团队与组织摩擦公式
Speaker 2: 我们今天主题是讲 Manus 内部是如何用 AI 来进行一个组织维度上面的提效的，他们内部的组织架构、工作流程可能是什么样子的。我们刚刚是一个闲聊的模式，那我们现在就进入正题吧。我们请于一老师来分享一下，Manus 内部他们是怎么做这样子的组织提效的。
Speaker 1: 好的。还是跟刚才说的，大家有问题可以随时提，我们的 PPT 或者是分享的是一个引子。金老师，反正你这边有问题也可以随时提。
Speaker 1: 我让 AI 手戳了一个 PPT。
Speaker 1: 对，这是今天的主题，其实想跟大家聊一聊。我其实加入 Manus 也过两天就一个月了。我其实在之前的话，在写《从超级个体到超级团队》的时候，当时由于自己是一个超级个体的实践者，所以关于很多超级个体所会遇到的问题也好、困惑也好，当时有很多我们看到的东西以及我们自己实践的东西都已经在报告里去写了。
关于超级个体，我们当时是在写说“从超级个体到超级团队”嘛，但是关于超级团队其实是带着非常多的问题。然后这些问题甚至也是促使我加入 Manus 很强的一个触发因素。我很想知道说做一个 AI native 的超级团队，到底这个团队是怎么去做运转的？有哪些东西是不是可以解答我在写这个报告时候遇到的一些困惑？
这一次刚好一个月的时机，我觉得可以去谈一谈我在内部视角还有自己在做田野实践的一些观察。但我觉得这个说句实话，不是一个放之四海皆准的做法。很多时候我觉得也是给大家一些启发。包括它的解法是不是说现在一成不变？其实整个 Manus 内部也在快速的进化过程当中，也是会希望说跟大家在这一块有非常多的继续的交流。我自己这边也还在看超级团队的不同形态，Manus 其实只是其中的形态之一。
简单地介绍一下我自己，我可能跟很多人也都是老朋友了。现在我在 Manus；除了 Manus 之外呢，我也还在运营自己的 好玩AI 的一个 side project，有很多去跟大家去做一些相关的分享。
在此之前呢，包括跟这个话题非常有关的，我也是那个很火爆的报告《从超级个体到超级团队》的主笔。之前的很多经历其实都跟创新、孵化、加速有关。我自己的话，另外一个很喜欢的身份叫“AI 野生布道师”。现在可能带了一些官方布道师，但我自己还是非常喜欢“野生”的这个概念，更多的是以一种用户的视角和行业的视角去看很多 AI 会给大家的生活和工作带来的一些变化，以及把这些变化怎么样可以跟大家去做展示。好玩AI 嘛，到底一个人、一个公司怎么去用 AI，这个始终是我自己的一个研究还有实践的命题。
另外一个大家可能知道的就是花了很多时间把自己作为 AI First、AI-native、AI-me，就 AI 语义的寄生虫的这个实验怎么去做的。包括也有非常多的开源文档被大家看到了，然后我也把自己的微信放在里面了，欢迎大家。
前面也提到说关于超级团队还有超级个体不同的解法，我现在除了 Manus 之外，也还在始终地去看外部的一些相关解法，然后也欢迎跟大家有更多的交流。
这个是我们在报告的时候提到的一个公式，也是很多人会觉得很有共鸣的公式：到底怎么去看 AI 时代的组织竞争力？我们自己当时总结的一个公式叫做：
$$AI 人才密度 \times AI 杠杆 \div 组织摩擦$$
我们认为说超级个体，包括组织里面，现在大部分在写的时候大家在解决上面那个问题，就是 AI 人才的密度，也就是说独立闭环的人在你的团队里、在你的单位里占比有多少。第二个就是说 AI 的杠杆实际嵌入到你的工作流的深度和覆盖面。这个是分子的部分，也就是说你的生产力和你的速度无限放大的部分。
但是呢，我觉得好像从我们写完报告之后，包括大家也在内部推的时候会发现，OK，即便你的分子放得非常大，但是在分母这边，也就是组织摩擦这一块，它足够会消解掉非常多的速度也好，或者是生产力也好。这也是很多人会有体感的说，为什么个人提效这么快？为什么感觉我们在前面做得非常快，
Speaker 1: 但是实际上落到组织里面感觉没有提升太多，或者组织的生产力没有变成太多。这里面我们会觉得大部分的时候是体现在组织摩擦上面，就是快和生产，就是生产功劳，就是 AI 带来的最大的变化。但是它极有可能会变成你的组织的流程、你的组织的审批，甚至你组织的导向上，能够会把这种速度和生产的丰饶直接降下来。或者是说你只改变了某一个环节，你的临近的环节是很容易把你这里十倍的生产力、十倍的速度直接拖下来。
这也是我们当时去看的时候，说能不能有一个很简单的公式，帮助大家快速地去识别说自己的组织的竞争力目前在什么样的阶段，什么样的缺口是大家需要重点去补、重点去看外部的一个情况。这个是关于这个报告的，我们当时提出的一个觉得可以拥有很强生命力的一个公式，让大家持续地去看自己现在处于什么样的阶段，不会因为 AI 的一些进展或者是说大家用工具的变化，就让这个公式变得失效的一个用来衡量组织竞争力的公式。
在写报告的时候，我们自己还是会非常清楚地知道说超级团队它到底是由什么来组成、什么样的构建。因为之前我们也看了一些相关的调研，包括也聊到说在一些组织里面，其实它是不是称之为是超级团队，还是说只是超级个体的联盟，是一种聚会的产物还是结构的产物？
我们最终还是认为说，虽然我们会觉得 AI 也好，超级个体也好，会让团队处于一种不一样的新的形态，可能大家更多的是这种联盟制的，甚至说很多时候是大家由于一个任务聚集起来的这种新的团队的形式，也是会在 AI 成为新型的超级团队的一种构成。但是整体上而言，我们还会觉得放之四海皆准的地方还是在于说超级团队它是一种结构的产物。
到底这些结构应该包括哪些？我们当时是提了五块的基建，也是方便说去评估、去衡量我们到底处于什么样的阶段。
第一个是形态。就是你的超级团队到底是我们总结的三种形态——以 AI 和人所处的位置上面去定的，说到底是节点辐射，还是网络协作，还是 AI 中枢。
它的技术的地基，从你的信息可见性到你的能力的可协调性，到协调的可自动化这一块，到底你的技术的地基在为哪件事情所做准备？当你刚才一提到的三个方向，哪个你的技术是可以支持的？这些东西，信息可见、能力可协调，它其实并不仅仅是说我的主观意愿我希望能达到就做到的，其实是需要很多技术上的一些支持，或者是说产品、甚至说工作形态上的这种支持。
协调的话，就是透明化、路由的替代，还有主动的任务的编排。你的协调到底处于什么样的阶段？
最后，决策：集中、委托、共识，还是 AI 辅助？这个组织里面的很多事情的决定和行动到底是由怎样的形态去做成的？
最后是人。前面有提到人才的密度，但是怎么去留住这些人，怎么去发挥这些人的作用，我们觉得也是超级团队的结构里面非常重要的一个部分。如何给到自主权，如何给到成长环境、经济上的回报跟退出的自由怎么去做保障？这个是我们当时在写报告的时候，会觉得说如何去构建超级团队的结构里面很重要的事情。
这是当时有提到的五个问题。不同的形态里面我们觉得非常难的问题：选什么样的形态，单元到底怎么去切？
大家都知道说 AI 的话，我们大家的这种行动的单元或者是协作的单元一定是比以前更大更宽的，因为每个人能做的事情非常多。但是单元到底怎么去切？单元之间的彼此的协作到底怎么去切？我们当时有看到什么 POD 的模式，然后怎么去切它的行动单元。
然后第二个就是我们自己会觉得问题是 AI 怎么去看到全部的上下文。大家也知道说上下文的这个东西，相信大家越用越会觉得说，很多时候现在 AI 的智能里面，可能就是说你给 AI 的权限加宽下文会很决定 AI 在组织里能起到的作用。然后信息的同步，以及人在里面到底应该是怎么样？包括说这个效率和 AI 的效率差别十倍、一百倍的时候，人到底要怎么做，怎么留？
这个都是我们当时会觉得很重要，但是看到了各种各样的解法，但没有一个让我们觉得……都还在进化过程、还在探索过程中的一个事情。
刚好加入 Manus 之后，我是带着这五个问题重新去看，包括自己也在做，我自己称之为说从研究到完全的实践。我觉得有看到一些很有意思的地方，有在实践的地方。然后接下来其实就给大家分享一下 Manus 相关的解法。
我还是那句话，就是这不是一个唯一的解法，只是说这个组织从它在做的事情以及它现在拥有的一些能力里面长出来的一些解法。我依旧会很坚持我的看法，就是 AI 包括 agent 依旧是锯齿智能，以及每个团队的土壤和组织很不一样，照抄很容易抄坏。很多时候还是说借由别人的实践和解法去看看那个问题放在自己的组织和土壤里，到底是一个什么样的做法和解法在里面。
前面提到就是很难的那个问题：选什么样的形态，单元怎么切？其实 Manus 的做法也是我有看到其他组织里面，同样我觉得 AI 进展会比较快的，就是尽量让这个架构和这个单元是解耦的关系。前面也提到说超级个体，我们觉得是具有闭环完成一个任务的事情。现在的话，Manus 也好，以及说我有看到的其他的超级团队而言，都在做一件事情，就是让整个去生产或者是说组织里面的单元本身是一个可闭环的。
有一些的闭环的方式是说，我的一个整个的项目或者是整个的一个事情完全给到一个团队，他不用跟其他人去做协作。也有的做法是说，我尽量地把原来的小单元扩展成一个大的单元，这个单元里面的整个产出来的东西是可以单独去做评估的。你在说某个事情做得好与不好的时候，直接是评估这个单元，而不需要牵扯到说由于其他的环节、由于其他的单元跟我不配合导致我这件事情没有做好。这都是我看到的关于单元怎么切的不同的解法。
然后对于 Manus 而言是做了两个事情：一个是我们把整个的内核变得极度的精简，把所有的相关的架构和功能变成一个插件，你可以插在里面，你也可以拔出来。还是那个话，就是说这件事情让每个单元可以不受其他单元的阻碍也好或者联系也好，独立完成自己的架构里面的事情，然后同时又能被整个的中台所吸收。
另外这个好的地方大家也都知道，AI 的进展速度是非常快的，有很多时候你要不断地去做大的调整。如果这些单元其实和整个的大的架构是一个紧密的耦合的关系，其实会让插拔这件事情会变得非常难。
这也是我在进入 Manus 之前，其实我也跟他们团队有在问他们的一个事情：就是过去很多为了让 AI 做得更好的时候，你做了非常多的一些技术上的工程的事情；但是 AI 的进度很快，很大的可能是 AI 的能力会让你之前做的工程性的手段会变成一种债务，你到底怎么去解决这个债务？
他当时就跟我提到了，说他们其实在做的就是尽量让很多你做的工程化的手段变成可插拔的这种方式。当模型能力上来了之后，我可能就会快速地去评估说我过去的是不是变成了债务，然后把它迅速地从这个插件里面拔下来，然后更多地去释放 AI 的能力。
但是来 Manus 之前，我对于这个东西，我就说听起来挺有意思的，但是怎么去做？然后我会发现，它的解法不仅仅是在技术本身，同时也体现在组织里面。甚至我临时加入一个我们新想要的功能，它其实也是以这种方式不仅在技术方面、同时也是在组织方面进入。
Speaker 1: 这个的话其实是这样的，就是刚才大家可以看到这里的幻灯片：网页开发、视频编辑、电脑操作、定时触发，还有旅行。其实是每一个 team 他都在管一个自己的这种插件、自己的仓库和发版。
比如像我最近一段时间用得比较多的是视频的编辑和网页的开发。这里面我提到的有一些比如功能上的改进或者是说某些测试的能力，其实很多时候我在提完了之后，很有可能二十分钟、三十分钟之后他就跟我说：“这个东西我们已经改过来了，已经测过来了，你可以快速地去测一测你想要的功能、你想要的能力是不是已经在产品里面看到了。”
这个我也问过他们，他们就是属于说这一块的改进不会涉及到整个的组织这一块，或者我要整个架构的改变，就是我可以很快速地去调整我这个功能里面你所需要的一些发现的 bug 或者是所需要的能力。
这个就是一个是组织上的可插拔。第二个是说，当你的每一个小组有自己的相关的插件和服务的时候，无论你是上某些功能还是修一些 bug，都可以很快速地去做推进。这个也是可能大家会感知到说 Manus 在这一块特别快的原因，就是它不太涉及到说我去修我的视频的编辑，我需要跟整个的大版以及说网页开发或者是说什么幻灯片这边我要做非常多的一些协作，这个很多时候是独立的。当然有一些会涉及到整个的内核这一块 agent 的一些调，这就属于大版他需要去改的地方。
这个是我作为在内部看到的实际上的组织和架构会带来的一些影响和变化。
Speaker 2: 了解了解，就是说我们能够尽可能地减少 pod 跟 pod 之间的依赖，然后我们尽可能在某一个 pod 上面完成自己可以完成闭环。视频编辑就自己一堆人就可以做完了，就不需要外部的 dependency 了。
Speaker 1: 相当于是，对对。就是会尽量地把大的功能都会变成说大家拥有一个自己的 pod 的形式，然后有很多的功能。比如你要去下视频编辑的某一些已经形成了技术债务的模块，你不会涉及到其他的这个功能的模块我要跟着变。这样的话，一切就会进展得非常快。无论是大的插件的增和减，还是说不同的单元里面的增和减，大家都拥有自己的一些自主权和快速的反应能力。对。
Speaker 1: 对对对，好啊好啊。然后这里面其实之前也提到了几个张力吧。就是 pod 组织扁平化、架构插件化了之后，到底团队……大家都在想说：“哎，你 AI 化了之后是不是就开始大裁员？”但并没有，Manus 还在疯狂地招人。
包括这种架构也是确保说我的招人或者是说我的人员的扩充，不会因为说某个人的加入或者是人员的快速扩充就把这个团队的很多文化所改变了。另外的话，这件事情也确保大家看到，当我们想要重点去打视频编辑的时候，可能就以一个插件的形式进入到组织、进入到产品里面；如果我们想做其他的探索，也是以这种方式快速地插进去、拔出来，快速地做验证，速生速死。这个也是 AI 时代能够保持组织的生产力和快速的增长能力。
这个我之前其实跟洽金招募成员——洽金也有聊到，说到底你们是在招人，还是说这件事情会影响到你们招人的速度？他的答案其实跟 Manus 也很类似，就是说这件事情反而让你更敢去招人。因为你之前很多时候招人是会很担心说你无法可控，以及招来的人会不会对原有的产品和组织造成比较大的影响。反而以这种形态，你更敢去招人，更敢去做很多业务的尝试和探索。
然后扁平是结果还是设计？在 Manus，答案是说既是结果又是设计。当你感知到了 AI 的生产力之后，以及刚才也有提到的技术债务这个东西到底怎么解决，它其实从一种技术的解决变成了一种延展，到了组织里面：组织最好也能做到这一点才能配合，说你快速地把有一些技术的工程手段和债务之间的轮转可以快速地去做这种转变。
然后上不上中台？大家也有提到说，总感觉说做 AI 必须要上一个中台。到目前为止，其实更多的是在做基建而不是在做中台。中台的很多角色其实就是以 Manus 或者是说我们的 agent，让 agent 去做中台的一个角色，而并没有说强行地去上一个中台，让大家必须再去用这个。
Speaker 2: 就是想问一下于颖老师：“我是产品背景，现在找很多 PMF 的公司都开始把重心放在增长，运营工作岗位更加精细化。想问一下于颖老师在组织人才角度，对于如何保持初创公司执行力和人才垂类专用的复用程度的看法？”
Speaker 1: 人才复用，好久没有听到的词。是这样的，对于我目前在 Manus 所看到的都不仅仅说是人才的复用。包括我自己现在在使用上面，例如说我其实想要一个数据，其实我的第一反应都不是说去找同事，而是我们有一个 data agent。有很多时候我关于 Manus 的有一些相关的数据的看法和分析，我很习惯跟这个团队的 agent 先聊，因为它其实甚至比团队里面的成员拥有更多的上下文和数据在里面。然后包括说做增长等等。
现在我的感受就是我在 Manus 的一个工作形态是我基本上会跟这个团队还有这个人他 build 的 agent 先聊，聊完之后我再跟他本人去聊。所以这一点我觉得会带来的一个变化，就是 onboarding 这件事情会变得更快，甚至我会觉得说大家的岗位之间的边界其实是越来越淡的。产品经理也完全可以去看很多增长的事情。
包括现在我们有的时候，比如说我这边有的时候也会说：“这个产品的功能，我们后面应该配合怎么样的对市场去做这种讲解和布道？”其实我会要求开发把这个东西在代码层面最好就能做一些支持。
所以我所看到的一个很明显的趋势，就是岗位之间的划分其实是越来越淡的。包括我们现在开发最近一直说要给我做特训，就希望以后我自己提了 bug 和功能能够自己改，不要老烦他们。因为提的需求和 bug 太多了，他希望我自己主动去完成这件事情。
他们的话术是这样，他说：“你给我，我也是给 model，不如你自己跟他提，我不想做中介、做中间商。”包括现在我们有一个叫 mock web 夫的，它主要去排查一些网页上的问题。因为我自己网页编辑这一块用得比较多嘛，所以经常就是给他们提 bug。他们后来就说：“你去先跟 agent 聊，它能够给到一些 bug 的解决方案，你去试试。试的有结果了就告诉我们，我们从开发层面去把它固并下来。”或者对，他们就说：“你可以跟 model，让 model 直接去改，然后提 PR 之后我们来合并。相信你可以全栈的。”
这个是我在慢慢感受到的非常大的变化，
岗位边界的模糊与全栈交付
因为当你可以拿到上下文的时候，比如说我作为一个开发、作为一个产品，我直接能够在开发产品的时候，直接去问到比如说数据这一块的 agent，然后去问到我们 marketing 的 agent，去问到说接下来去做探索的、就是我做的那个 first-party 的 agent，到底这个东西会做成什么样子。其实很多时候就会体现在你自己去做产品或在做开发的时候。所以我觉得这个可能也是另外一个变化。虽然大家越来越重视增长还有用户，但是同时我觉得岗位模糊的边界，我自己还是非常清晰地感知到了的。
Speaker 2: 对对对，我也觉得。所以跟这位朋友提到的说工作岗位更加精细化，我也有不同的感觉，就是我现在反而觉得确实是岗位越来越模糊了。产品经理可能要写代码，工程师可能也要去做 UI，然后跑数据。
然后我可以分享一些我之前在 Meta 的一些经验。其实因为 Meta 本身这个公司的文化也都是非常全栈或者是工程师主导的。像我之前在公司里面的话，也都是会需要去做写代码之外的一些事情。比如说包括找产品方向，甚至跟 UI 设计师去讨论这个 UI 怎么去确定，然后做这个数据分析之类的都会需要去做。所以其实我觉得在越来越多的这种 AI 时代的这种人才垂类专业的复用程度的情况下，我反而感觉就是你需要去做更多的端到端的东西，就是你需要去全栈来交付。包括这位朋友提到的增长，我觉得也是现在任何一位全栈工程师或者说 PM 都需要去了解是怎么去工程化做增长的这么一些基础知识吧。我觉得相当于是，所以其实对于人才的要求我觉得是越来越高的。
Speaker 1: 我觉得是的。因为最近我也在面试一些人嘛，然后会感知到说你除了自己本职的工作之外，你用 AI 去做了一些你边界之外的探索，其实很多时候都是加分项的。我自己会觉得就是确实越来越卷了。大家 AI 能做的事情越来越多，大家其实会默认：如果你觉得这件事情重要，你应该把这件事情用 AI 做了，而不是说——就至少做过。
然后可能这些事情你进入之后倒不是你来做，那你一定会涉及到跟其他人的这种更多的协同跟合作。有没有你去用 AI 做相关的探索和尝试，让你跟人之间的这种合作和配合会变得更加容易。我觉得这个对于我们去看的时候也挺重要的。就是你这些事情不一定擅长，但你跟 AI 自己做过尝试，知道一些点，你后面跟真正很擅长的人的那种协作的摩擦其实也是会降低。
这也是我们有观察到的到底怎么去使用 AI 的一种方式。并不是说一个人要做完所有的，但我自己会觉得就应该尝试去做一下这个商业全流程里面的所有的事情。一方面是看自己在哪一块其实真的是更擅长的。有很多时候是原来能力或者资源所限，其实你没有发现自己更擅长的地方。第二个是如果进入一个团队，大家各自在用自己的长处耦合，你对于别人的长处——就是你见过 AI 产出和见过人的产出，然后你可能可以快速地对比出来说：哦，原来我应该用 AI 在这个地方，用同事在另外一个地方。这也是我在 Manus 在去做尝试的，就尽量让自己多去全流程地去用一用看一看。
但是我会很清楚地知道，我们并不是为了我自己都做，而是说希望我自己用 AI 操手过一遍，看看新手用 AI 用到什么样的程度，以及很厉害很牛逼的同事加上 AI 用在什么样的程度。其实对于个人的品味的提升，和怎么去降低你跟同事之间的摩擦，以及用好同事——就是 AI 能做到的就不用麻烦他了，用他就用他那个我跟 AI 做不出来的地方。这个也是我在内部关于组织摩擦和团队耦合，一个很有意思的自己的小实验吧。大体上那是我的一个认知。
Speaker 1: 对对对，我觉得这个是我进去一个月之后非常大的感受。就是原来的时候，因为也在大厂嘛，大厂你能看到的只是很小的一个部分嘛。但是在 Manus 看是属于任何一个东西你想插手去试一试，大家的开放度还是很高的。所以你可以加上 AI，先去看看我能做成什么鬼样子，然后再看看很牛逼的人做成什么样的鬼样子。这样对比下来，我觉得确实是一个个人成长也好，或者是说如何去让超级团队可以快速运转起来非常有效的一个方式。
Speaker 2: 了解了。我看现在观众朋友问的问题稍微有些多啊。于一老师，您是先跟观众互动，还是我们先继续分享呢？我来看一下，右边有个 chat。
Speaker 1: 没事，我们就边聊吧。然后看我们再回答一两个问题，我们就再继续往下走。我觉得有一些问题其实把我们下面要讲的东西都已经讲出来了，要不然我们就边聊。如果还有一些我们聊到然后缺的，我就打开 PPT；或者在聊的时候，我就随时打开 PPT 跟大家说：啊，其实这一页里面代表了什么。对。
观众问答与项目架构设计
Speaker 0: 好好好，对。那我们来看一下这个安娜同学的问题。关于金融机构的，稍微有点专业啊。金融机构不同 team 之间，比如说 data team 和 AI team 有很多业务合作和交叉，可能没法像产品功能这样拆得这么原子化。那就是说这样子的情况下面，这种插件化的架构好像是在金融机构里面不太容易实现。对，我不知道于老师对于这方面有没有一些独特的见解呢？
Speaker 1: 我可能对金融相对没有那么了解。然后其实就可以跟大家说，大家所有看到的这个 model 其实主要是面向于我们的产品和开发的。然后 Manus 有一个功能叫做 project，它其实是可以把相关人加入到里面，然后某些人是只能查看，某些人是可以编辑；然后有团队共同的知识库，然后 skill，还有做事的一些准则。甚至这个 project 其实主打的就是所有大家在做的事情，大家都可以随时看得到，不需要——比如说大家常见的一个场景，就是你问我一个事情，我说你等会儿，我去问一下我的 AI，然后我的 AI 给了我之后我给了你之后，你就再说：“哎好，我再给我的 AI。”就会发现人在里面是一个很无效地降低信息传输的情况。
除了 model 之外，我们其实还有数据的 project 和它的 agent。然后我自己这边带一个 first-party 的团队，我们 first-party 团队也有自己的 project。然后还有比如说市场 marketing 团队。其实你看到的 model 只是其中的开发的一个形式，其实整个公司是有非常多的 project 跟 agent 组成的。然后我们是在我们的 Slack 上面，比如说你在我的这个 project 里面，其实你是在更多的任务里面通过 agent 去做这个 project 和相关数据库的调用和使用。所以 model 的这个呢，只是给大家看其中的一些架构和相关的形态。
刚才也提到了，说并不是所有的业务都能像开发这样能拆得这么原子化。但比较好的地方是每个团队都可以拥有自己的自主权，去打造自己的 project 跟 agent。但这个 agent 和 project 又是——人在里面其实是可插拔的，然后 agent 就是所有公司有权限调用的还是那个 agent。然后这个也是说，到底组织的扁平化是设计还是结果的一种方式：它既是结果也是设计。设计的点是每个人、每个团队都有自己的权限去打造一个更符合自己的业务架构的组织形态；但是基本的原则就是希望人不要做 agent 当中信息的协调和传输。另外的话，所有的上下文对 agent 是可见的。然后第三个就是属于任何一个 session，人都是有能力或者是有权限随时加入进去。
比如说我的 project 里面我的 agent，其实他会去 @ 谁谁谁说：“我已经做出来了第一步，你过来看一下结果，验收一下，或者指导一下，或者告诉我别做了。”这是他 @ 的那个人的权限。我在里面会做介入的，有时候他 @ 人不对；第二个就是这个人做到一定结果了，或者我觉得他中间和最开始的那个架构做偏了，我可能就点开这个 session，我直接进入说：“这个东西做偏了，你应该停下来，然后应该注重看这个方向。”那我其实在里面的作用，只是说我把这个任务纠偏纠过来，但是这个 session 还是属于那个在做的那个人。但是我可以随时介入，避免当中的一些方向上的完全错误还有 token 的浪费。这个也是现在 Manus 的一个普遍的做法，把人作为插件。
包括如果说这种架构或者原子化，我觉得也不应该是说一开始就去切，而是说整个团队你自己跑出来了一些——刚才那些原则大家都能接受，有些东西我觉得很难设计出来，它是自然而然地长了出来。你觉得哪些东西可以原子化，哪些东西插件化，哪些东西就是得一起做。我还是觉得不应该照抄别人。应该首先把人和 agent 到底应该在一个怎样的 action space 一起工作，然后拿到结果验证的循环跑通，然后再去——当你有这个跑通了之后，自然而然就会觉得说：“啊，我的这个架构需要稍微变一变，然后我需要去做一些调整。”所以我自己会觉得该设计的地方是那些基础的底层原则和 action space。至于说结构是怎么样，我觉得是需要那些跑通了之后，让它自然而然地长出来，然后去做这种观察和调整修剪。我自己会觉得从一开始设计其实会出现很大问题，因为你根本不知道 AI 和人在你的业务里到底会怎么去做协作。
所以可能我对于金融相对没有那么了解，但就分享一下，我这边其实跟开发那边不太一样的做事方式，但也在长自己的这种 project 和架构的方法。然后我也觉得不要照抄。
Speaker 0: 对对对，它的底层逻辑是不变的，就还是中心化的上下文，然后端到端的交付，然后做这种比较透明的信息可见性。对，可能在金融领域上面可能会有一些权限上的问题，可能需要各种各样的一些限制，可能需要团队自己去进行一个探索，从 bottom-up 的这么一个探索，需要自己去慢慢搭，不能去照抄。
那我们刚刚有提到 model 嘛，然后我看到也有朋友反映说我们能不能先继续做分享，我看您这个 slide 刚好在讲 model。我们能不能具体再聊一聊 model，它具体在工作场景当中是一个什么样子的设计？我看您这边也介绍了一些。
Model 在工作场景中的具体设计
Speaker 1: 那我们这个 model 的话，我相信大家在 AGI 上也听阿斌做了更加详细的分享，我就给大家看一下，可能有些人在线上没有听到。
Model 其实是整个开发和产品团队都在共用的一个我们的 project 或者 agent。对于开发而言的话，它其实在上面我们是有自己的一个叫做 Manus project，所有有权利能够在里面去使用它的。
首先我们的使用方式是：我可能就要打开终端，然后连上本地的电脑，说帮我安装一下我们的 model。然后它就会调用本地本端，把相关的数据——当然你得在公司的 GitHub 里面，自动拉取下来之后，其实在 Manus 的 project 里面，你在里面由 owner 去确定你是有编辑权还是只能看的权利。包括很多开发的我们共享的团队的 skill，然后所有调用的工具，其实在你安装的时候以及你加入到 project 里面你都能拥有。包括所有的团队知识，还有仓库的地图，就是关于 Manus 所有所有的仓库其实都是被 model 可以去读、可以去编辑、可以去发出的。
这个是当时 Manus 内部在发现说大家的整个流程其实每个都在提速，它其实是一个大仓的概念。大仓里面配合着前面说的可插拔的各种小仓，然后大家一起都能看到。虽然你不去参与，比如说你是网络开发的，你不去参与视频编辑他们整个的什么插拔、涂抹、填卡等等，那你通过 model 是可以完全去知道他们的仓库里面到底写了一些什么、进展是怎么样。
甚至在 Manus 的 project 里面，我自己经常能看到正在活动中的三十多个、五十多个 session 在那边吭哧吭哧跑。如果你有编辑权限的话，其实你随便点开一个 session，你不仅是可以看到说这个任务最开始从哪来的，然后走到哪里了，甚至你可以说：“哎，我觉得——比如说这个需求是我提的，然后我看了一下 Manus 在做的，还有开发在做的，我觉得这个跟我当时提的那个需求完全出现了错误。”我可能会直接去参与到这个过程当中，说：“我遇到的问题不是这个，你现在改的方向完全错了。”这是一个很常见的在 model 里面需求方也好、产品方也好、甚至技术开发方也好很常见的一个做法。
另外一个呢，model 其实在我们的 Slack 里面是直接可以调用的。比如说我在里面其实可以直接说这里面有一个 bug，然后我可以 @ 它。除了 model 大的之外，有些人是基于 model 去改造了自己的 agent。我可能会比如说去 @ 负责后端的 agent，他其实是在 model 上做了自己的改造。我说他主要在管整个后端嘛，我说：“这里出了一个 bug，你能不能去改一改？”他就直接去改了。然后我能够在 session 里面——可能这个人不在，他没有在处理我这个问题，只是我跟他的 agent 一起在 Manus 里面的那个 session 里面去做协作。这也是我觉得挺魔幻的一个部分。
所以 model 属于在底层架构上是做了一个大仓的架构。所有的仓库都是属于面对所有人，包括产品，包括所有的非开发人员都可以去看到，然后借助 AI 去理解我们仓库里到底是一个什么样的情况。这是先做了一个整个技术开发上的调整，大仓的概念，以及前面的可插拔技术的地基方面。打好了之后，中间层就是借助 Manus 的 project，然后去完成了说所有团队能力的 skill 是大家共用的，有很多的规则也是共用的，然后外加所有的信息。前面提到了仓库的信息是可见的之外，所有关于这个仓库有关的在动作的 session 全部都是能看到的。
而且再加上说可调用性这一块，是所有的人可以通过 agent 也可以通过 session 直接去调用。甚至 AI 在里面甚至是拥有自主权，就至少是第一步把它做出来。这件事情很多时候是人家 agent 或者 agent 的自主去完成的。
Model 与 Agent 在团队中的分工与运作
Speaker 1: 这个是 model 在做的事情，包括里面后面会提到的是全流程的东西，不仅仅只是说生产，然后包括测试啊、线上的发版、测试 debug，还有数据的分析等等。这些的仓库和 agent 都是接入到 model 里面。所以你可以记住，他其实如果大家稍微改造一下，他就是一个自己的分身，或者是说自己的 agent 的下属。这个通过 model 我已经完全看到了，就是作为一个之前我自己用的非常溜的人，看见说团队的 agent 是这种运作的方式，我还是挺惊讶的。
包括我自己现在也很熟，后益就是有一些技术和开发上的事情，我确实比较少直接去找程序员或者开发。我很多时候就是在 Slack 的我们的 bug 的那个 channel 里面直接贴出来。然后我就或者是 @ 特 mertry merch 这么一个查 bug 的，去问他到底是什么样的问题。他会把这个 bug 直接分配给某个员工，说你过来看一下，这个是一个 P1 级的 bug，你赶快要修一下，这个任务是什么，以及还给出办法说我通过什么样的方式可以临时解决。
有的时候就是我现在比较熟悉了一点点，说到底谁的 moch mochch 到底能做什么，以及谁做了那个基于 moch 的这个 agent。我有的 dynamic 有些 bug，我觉得应该可以 AI 能自己去修好，我就会 @ moal，然后说或者 @ 谁的那个 model，说个 bug 觉觉你可以修，你要不要去修一下？然后我就会打开 moch，看他怎么去修的。所以这也是一种很不一样的运作工作方式吧。
Speaker 0: 就等于说在这个里面是每个人都会有一个自己的，相当于一个数字分身。然后你可以 @ 那个数字分身，然后去帮你解决你需要的问题。
Speaker 1: 不是，就是刚才提到的 moch 跟 moano 其实是公司去搭建的。然后只是有一些人也会搭自己的 agent，包括有些人会把公司的这个 agent 做一些相关的改造，或者是增加一些自己……除了放在 more modeal 和我 match 的那个 skill，其实是很少有人……就是大家不是说所有人都可以去改他的专属的 skill 嘛，因为他还是为整个公司去做服务的嘛，包括他的设定。有一些是说，我在这个基础上，我还要加入自己的一些专有的知识和专有的能力。他就会在那个上面基于 moal 或者是玩摸摸去去做自己的这个 agent。然后你就可以调用公司的员工，还是调用谁的专属的员工。反正这个还挺有意思的，就是说我有一个基座，但是基于基座，你也可以玩自己的花活。
Skill 的维护权限与项目规则
Speaker 0: 嗯嗯，了解了解。我看弹幕里面也有观众朋友在问嘛，就是关于这个 skill。现在的话就是我们比如说在整个 mono 里面，我们会有一些不同的职能部门。然后他们每个职能部门可能会有一些 skill，比如做视频的，会有做视频的 skill，做网站的会有做网站 skill。那么关于这些 skill 的维护以及上传，我想好奇想了解一下，Manner 内部它是怎么去做这个评判的？像什么样的 skill 可以落地到这个 model repo 里面，或者某一个 repo 的这个 skill，共享 skill？
Speaker 1: 这个共享的 skill 还是极少数的人有权限去定义。因为它是一个公版的 skill 嘛，都是属于反复验证过的，或者确实是某些 skill 需要更新。这些是只有极少数人，就跟所有人都可以在里面提 PR，但是都可以提，但是真正的落到产品里面还是极少数的人有权限。就所有人都可以提，所有人都可以 fork，但最终的权限还是在那几个最有权利者，就是真正的产品负责人。
真正的就是大家都可以有一种饱和式攻击。但是最后哪条路线能成功，还是会借助到非常重要的人的品味和最终的判断里面。所以这个是整个的 moanl 的设计。所以看到非常非常多的 selection，但是哪些东西能真正的真正地 pull 出去，这个东西还是会有人去做那个把关和整个的整理和处理这件事情，这个是。
然后第二个就是刚才也提到说，你有自己的，你可以基于公版的去开发自己的，把自己的很多东西挂上去，你对这个就拥有比较大的自主权。另外的话，除了公版的 model 之外，刚才也有提到，每个团队其实大概都有自己的一个 project，甚至多个 project。然后这里面就挂载了不同的 skill 也好，或者设定也好。然后大家可能不同的 project 也会有不同的做法。就比如说 model 的这个就是还是很少数人有这个权利，像我的那个就是所有的都可以改。就是你觉得那个 skill 需要去做更新，你就更新就好了。然后我们用的不对，我们就回滚就行。就是不同的项目它可以采用不同的规则。
因为我这边很多时候是一个偏探索方向的，所以很多时候我是希望大家群策群力，然后只是留好回滚的权限和做好回滚的准备就好了。至于其他的，就对我而言就没有那么重要。所以你可以定自己的规则，开发有开发的规则，然后比如说数据有数据的规则，然后视频编辑有视频编辑的规则。其实 mode 只是给大家去看到其中的一个 project 和比较我们集大成者的一个实践。但是有很多各种各样的大乱七八糟的长出来的个性化的实践，其实也在这个组织里面在做各种各样的生长。
组织内的分享动机与安全感机制
Speaker 0: 是，我相信在 Manner 内部所有人应该都是像于毅老师一样，在疯狂地探索最适合自己的这个 workflow 或者说是一些 skill，对吧？但是这个 fmme 同学的问题是，我们怎么样能够让大家愿意把自己擅长的东西和摸索的经验分享出来？
其实我说一下我自己的看法，我觉得其实如果我发现出来一个非常牛逼的东西，我是会非常愿意跟别人去分享的。我想象不出来有一个场景，就是说我分享出来一个非常牛逼的东西，我愿意自己留着。因为 skill 这个东西本身也不是不值钱的东西嘛，对吧？不是说你需要去保守商业机密的这么一个东西。所以在组织里面，我不知道于毅老师你们这边有没有看到，就是说有没有一些激励机制，或者说是有一些设置，能够让大家更加愿意去分享，更加愿意去探索这样子适合自己的 workflow 和 skill 呢？
Speaker 1: 这个也是会……我觉得就是我前面提到的没办法照抄，或者是 Manner 这个团队比较特殊的一个地方。首先这个团队节奏非常快，然后一旦快了，你有的时候就是在想说，我必须要保证其他人不要拖慢我的进度。我希望大家在同一个基础上往前走，要不然我这边快得要死，他那边可能生产力还不够，那直接会拖慢我的进度。
所以我们有时候有些分享纯粹是属于防御性的分享：“不是，你做这个东西太慢了，你直接影响到我的效率了。我有一个很好用的东西，你也来用一用。然后咱们这样的话，咱们就可以快起来了，一起快起来了。”一个是属于这种创业公司的快的节奏。第二个是属于你可能自己快了，就会很深刻地感受到其他的地方被拖慢了。有的时候由于我拖慢了别人，别人就直接上手说：“你这太慢了，我来帮你解决一下。”所以就不太存在说大家我得守着我的东西，我要体现出我比你快。因为对于创业公司而言，拿到结果是最重要的嘛。所以当别的环节慢了，甚至都不是说我会藏着我的，是大家会上手去帮你改造你的，避免你这个环节拖慢了我的环节让我难受。这个可能是一个创业公司和大公司比较不太一样，也是我还挺 enjoy 的地方。就是我有的时候我慢了，我就说：“你不帮我解决，你就准备难受吧。”然后大概是一种威胁式的让别人分享的一个状态。
然后第二个还是我觉得也跟我……我始终会觉得团队的文化和共识是很重要的。当大家都在用 USB 的接口的时候，有人用 USC 的接口，这个事情就会产生很大的问题。我来 Manner 当时跟那是有一个访谈嘛，就是说我来了很开心很开心。其实那个开心我觉得当时都不是来自于比如说投个自由……投会投个自由当然很开心，或者是你在做一些前面的威胁同事的事情很开心。还有就是团队里面是有一个……前面谈到了很多的术的操作，但是一个道的操作就是这个团队里面没有人默认我是要独立工作的，所有人都默认说我一定要用 AI 的。然后即便我现在不用，或者我手上的工作很忙，我可能就直接用同事做好的，或者是说我去找时间，我还得去做优化。就是使用 AI、跟 AI 去工作，然后跟 agent 一起工作，在这个团队里面是一个默认项，并不是一个可选项，甚至是一个植入到基因里面的默认项。
这件事情大家看似会觉得：“不就是所有人默认都要用 AI 吗？”但所有人都默认用 AI，和有一半的人或者有几个很重要的人默认不用 AI，这件事情是天差地别的差别。就是你还要兼容另外一套系统，还是所有人都在用这一套系统。当所有人都在用 USB 的状况，大家就会知道说慢在哪里。就回到前面那个问题：慢在哪里？我到底有没有办法解决这件事情，让整个团队可以运转起来？这个是 word a manager 可能会跟其他的组织里面我觉得会比较不一样的地方。
所以回到那个问题，关于 skill 如何去做激励？我觉得 maybe 不是属于做人的激励这一块。其实之前的话，毛蒂卡我跟佳园也有聊到他们在做的一件事情，就是你可以把你的 skill 挂在组织上面，甚至把电脑挂在我们整个组织里面。然后同事去使用的时候，你不是使用我的 skill，你就是属于 @ 我的 agent。这个上下文也好，这个东西也好，跑是跑在我的本地的，你只是拿到了结果。
现在大家不愿意去分享 skill 也好或者经验也好，是属于大家都很没有安全感。怎么说吧？就是你用了之后，这个东西算不算在我的身上呢？这个激励、这个成果算谁的呢？然后第二个就是我做这件事情对我有什麽好处呢？你是不是只是把我的东西所有拿走了，然后其实没有留下什么东西给我？
以及另外一个点，就是有很多 skill，不得不说，大家好像总觉得说：“skill 我拿来我就能抄，我就能用。”刚才也提到了，每个人的上下文跟环境是很不一样的。甚至这个 skill，如果我是为 ChatGPT 准备的，我拿给 Claude 用，它可能就存在问题；以及它在我的上下文里面跑，和在你的上下文里面跑，跑出来的结果也是完全不一样，天差地别的差别。然后另外一个所有人都知道，如果在重度使用的 skill，疯的话一天可能更新十几版，说我这个只有这个调一下、那个调一下。然后这个东西你让我上传上传哪一版呢？然后我每天都上传吗？
所以这里面其实不仅仅说是靠激励，我觉得激励都是小事，你能激励多少？你说你上传一个 skill，你最好的 skill 我给你加一百块钱。这一百块钱可能会干掉我的工作，员工肯定是对抗的关系嘛。所以我觉得这里面反而要解决的是安全感跟绑定的关系。就是你的 skill，你的 agent 出来的结果跟你本来是绑定的。就跟之前我在前年七月份的时候跟涛哥就聊到这个问题，就是把员工当 leader 去做管理、去做考核。它底下的 skill，它底下的 agent 是它的成果的一部分，就是组建一个好的团队，然后他的下属出来的结果应该也算到这个 leader 的成果里面。我觉得这个机制是需要去构建和调整的。
第二个就是说必须要承认 skill 是跟模型、跟这个人、甚至跟他的上下文的环境是绑定的。那从技术上而言，我怎么能做到可以去调用他在最好的环境里面跑？还是说我怎么去做好这两者之间的衔接？就是我可能放在公版上的，我的结果就是一般般。但是这个时候是不是公版上的 agent 和他本地的 agent 能够去做一下沟通，把这个效果提升，或者说做一些隐私的保护等等。这个东西到底怎么去做，我觉得也是值得去看的。
然后我们自己内部是属于，比如说我们没有去做这种共享 skill 的相关的东西。就比如说我需要同事帮忙的时候，其实我是会把我的那个 selection 直接分享给他，或者我就把它拉到我的那个 project 里面。project 里面虽然有一些共享的这个 skill，但是有一些任务是跑在我的本地或者我的云电脑里面，那个是有我自己一些很专属的 skill 也好或者 agent 也好。这个时候对于过来跟我协作的同事，他是能调用，但是他不知道那个背后到底是什么的。然后我觉得这个也是一种解法和方式吧。
然后另外一个我觉得很重要的地方，就是前面说的都是术，但是团队这个共识有没有建立，我觉得是很多东西很重要的基础。就是当你都快的时候，你就会看不得别人慢了。
团队激励与 AI 原生思维的落地
Speaker 0: 对对，所以总结一下，首先团队里面每个人都要有一个 AI 原生的思维方式，解决问题需要考虑怎么去搭一个 AI 原生的工作流。然后我搭建起来的 agent 其实就算是我的组员一样，然后他的产出应该是被算到我的头上，可能这样子会是一个比较好的 setup。
我可以分享一下我们在之前在 Meta 里面的时候，也是有一个类似的这样子的机制吧。就是我们会有一个 skill marketplace 或者 agent marketplace，然后所有人都可以上传，然后所有人都可以互相下载。然后你可以看到每个 agent 会被下载多少次，同时呢你也可以对于用得好的这个 agent 点赞。所以说大家就会筛选嘛，就是说有哪个 agent 到底用起来真的是不错。然后我相信你做的这些 agent 它接受的下载数量和被点赞的数量，最后也会被记到你自己的绩效考核里面去。所以通过这样子的激励，也是可以慢慢让大家从一个古法的思维方式，慢慢变成一个 AI native 的思维方式。
对，我们看一下，这边问题也差不太多了。于毅老师，您这边还有其他剩下要分享的 slides 吗？我们可以简单地再过一过。
Speaker 1: 好，我们简单地过一下。这一页其实都讲到了，就是任务的全公开、任务的结构到底是怎么去做的。包括“先问 AI”这件事情，我们在前面的论坛里面都聊了，我觉得这一页就不用去讲了。
然后这个我感觉也都提到了，就是这里面包括自动接单的这个系统，前面也有提到，就是我们的 model 跟 y web moch 就有一些 agent。然后另外一个很建议大家的点，就是有一块的上下文，包括我自己的那个 project 里面给 AI 的有一个很重要的知识的上下文，是在这个 project 里面的每一个人他们擅长的东西是什么，每个人的特点是什么样子？
人机协同机制与工作流重塑
Speaker 1：他过去比较擅长做做了一个，这有一个初始的版本。然后后面其实就是 AI 根据任务的结果去做一些更新。这个带来的结果就是刚才我提到说，其实把 Agent 和人都放在同一个主体的位置：人可以 cue AI Agent 来帮你去解决一些事情，Agent 也可以 cue 人来帮你去解决一些事情。
但是这里面还是需要你给他一些上下文。然后 Manus 这边就是有两个：一个是 AI 直接派单，就是他派到谁，他对于某些人的了解就是这个任务是跟哪些标签有关，然后谁在这一块是在负责这件事情、是熟悉这件事情，他去艾特了别人来做；第二个就是你可以抢单，因为有一个抢单广场，大家可以看到各种各样出来的 bug。AI 指定的人，你也可以把这个单抢下来。
这个我觉得也是一个很有意思的地方，就还是在解决那个问题：人、Agent 的这个 action space 到底是一个怎么去运转的机制？人在里面应该是一个什么样的位置，哪些事情 AI 可以做，同时也要留人的主观能动性和空间在里面。
所以这也是说，AI 越跑越快，人到底在里面是一个什么样的状态？更多的时候，其实我们现在默认就是 AI 做完第一步，无论是说他的派单也好，他对问题的排查也好，或者直接做完第一步也好。第一步或者第一步、第二步的事情，现在普遍默认给到 AI，因为 AI 在这块做得更快。然后基于结果去做一些相关的拍板和决策，这块还是很确定的，属于人的。
当然还有一些更激进的说，我直接拿到市场上去做一些反馈，和直接去做一些反馈和相关结果的循环。但是不得不说，这个东西只适合极少的业务、极少的部门。因为对与错这件事情，以及完全只用数据来做衡量这件事情，还是在极少的部门或者业务线上能做到。
这个是我现在 Manus 的一些做法，也是我比较认可的做法。淡化岗位边界也有提到。
然后这里有提到一个很有意思的事情，就是属于 Manus 现在非常神奇的，我们现在去很多东西的沟通——可能对于大家而言，之前的话大家觉得用 coding 去做沟通，现在也比较常见了——现在 Manus 内部很常见的做法就是，视频和图片、视频变成了一种新的沟通方式。很多时候我们在讲一个新的功能，或者想做一个什么事情的时候，直接就让 AI 戳一套系统出来。戳完了系统出来，再同时把视频做了，就告诉大家，站在用户视角，你直接去看每一步是什么。我觉得这个也是一个值得去关注的变化吧，就是生产和消费或者沟通的这种权限的一些相关变化。
生产丰饶，对，前面也有提到，最开始开场的时候嘛。我现在在时就真的很奇怪，比如说我的 onboarding 基本上是跟 AI 一起做的。就是我怎么去了解这个团队，然后 AI 建议我要跟谁去聊，他去跟别人去 book 日历。以及由于我的 Slack 和我的 Manus 其实都跟我的 Agent 绑定了，所以现在都很习惯说：“哎，你帮我回一下同事这个东西。”他每隔一段时间会去看一下谁 Slack 找我了，有什么重要的事情。然后我都是跟他聊，聊完之后，他直接去 Slack 上跟我的同事聊。
所以我现在最大的感触就是，事务性的事情我已经很少去找同事了，跟同事在一起聊都是聊那些 small talk。或者是聊完之后，我也会把上下文快速给到 AI。
刚才也有提到，我的一个 pod 里面就是收集各种各样的创意，然后他会给出新的方法，然后我去做决策，说这个东西要不要把它做出来。做出来了之后呢，他不是艾特我，是那个 channel 里面的所有人。比如说他自己做一个 IP 相关的，他就觉得说应该艾特一下我们管控风险的人，这个东西应该怎么发、渠道怎么发；包括去艾特说：“这个是游戏，我应该艾特谁”，然后来验收他的结果。这个也是一种新的——我之前在做超级个体的时候没有尝试过的方式，就是 Agent 以及他和其他的人、其他的 Agent 到底应该是怎么去工作的一种方式。
所以这也是一个变化吧。当 Agent 完全进入到了你的工作里面，人所处的位置、人所处的状态大概会是怎样。
团队协同与人机边界
Speaker 0：对，我们这边有一个问题。刚好讲完了。我们刚好有一个问题，就是您刚刚的话题，你可不可以举个例子，就是说什么事情是 AI 搞不定的，但是找同事显式可以搞定的呢？
Speaker 1：倒不是说找同事搞不定，还是有很多，比如说开发方面的问题，我还是不是很懂嘛。AI 给了我一个方案，有时候我会问他这个东西靠不靠谱。包括有的时候我自己在做一些 web coding 的时候，AI 给了你——可能也是我的调教——他经常会给我 A、B、C 三种方案。有的时候我搞不懂、搞不清楚这个方案到底哪个是真正的在我的环境里面、我的情况里面是……
这里有个案例，我前段时间在做手势识别控制电脑的一个软件，里面有一个涉及到安全方面的问题，他给了 A、B、C 三种方案。然后我就理解有这种方案，但我无法判断这件事情是不是对的。于是我就让我的 Agent，我说：“这三个方案你去看一下我的同事，我要问谁能够比较好？”他就给了两个人，一个是阿斌，一个是我们去做安全的一个同事。我说行，你帮我写一个如何去问他们、到底在问什么点的一个东西，发给他们。
发给他们之后，我两个同事都回答了我。后面我就会发现说，那个东西其实不是他说的三个问题，是另外一个——其实它不是问题。然后我又补充给了 AI，AI 又跟他们去说，说完了之后就把那个方案总结出来，然后就直接进入到他自己的开发环节。
这个是现在我可能比较常见的一种沟通方式：他给了一个问题，我知道你给了解法，但无法判断哪个解法是真正可行的或者是符合的。我就会让他去 Slack 里面找人，帮我问。问完了之后，我可能会跟他再对一下，然后他就直接进入到去开发的环境。
所以这里面更多的还是说，在我不擅长的地方的判断，和怎么去跟 AI 沟通、让他了解他要怎么做的这件事情，其实我还是会非常需要团队来帮我做这件事情。否则的话我就只能让 AI 去做，我根据结果去做验证，这里面就会涉及到非常多的资源浪费和你本人注意力的偏移。就等于说我就是要这个结果，在这过程当中属于我不能去判断的东西，他去找我同事。对我而言是一种资金上的节省、token 上的节省和注意力的节省，要不然我就要困在我不懂的这个问题里面了。
Speaker 0：对对，如果比较典型的场景，一开始这个计划可能就错的。比如说你写一个工程方案，它的计划有几个解决方案，你选错了，或者说你很容易陷进去了，然后可能做做好久，然后发现自己原来一开始就搞错了。所以在这种情况下，还是需要有专业的 know-how 的人，然后能够帮你去做一些更好的计划跟选择。我自己也是有时候经常有这种感觉，做了半天，结果发现一开始就搞错了，就是这种感觉，就很浪费。
Speaker 1：你要说这件事情让 AI 不能做吧，也能做，就是反复地试错、反复地抽卡嘛，但是值得吗？你投入的这个时间，可能放在你自己更擅长或者挣钱的事情上，收获更大了。这也是为什么当时我会说超级个体做久了，你会发现真的很需要团队的。
Speaker 0：是的是的，这也是为什么我们现在程序员面试还是需要去面一些比较基础的系统设计这样子的问题，这种基础的东西还是需要知道的。
组织转型与 ROI 衡量
Speaker 0：好，那我们下一个问题：从现在的组织成本来看，怎么衡量这些探索 AI 场景的 ROI，还是说现阶段因为还没有成型，所以可无上限地探索？我想这个问题也是很多可能想做 AI 转型的企业想问的，就是我们如何去平衡花多少资源去做 AI 转型，以及如何去平衡我们现有的业务。我们现有业务可能是用现有的工作流在做，那如果我们花了多少资源去做 AI 转型，这个 ROI 如何去计算？不知道于毅老师这边有没有什么独特的看法呢？
Speaker 1：这块其实好像没有很独特的看法。整个 Manus 其实是一个 AI 特种部队的方式，因为我们在去一个巨大的增长、巨大的探索的地方。但是对于组织而言，我自己还是会觉得，之前我就有聊过，我觉得超级个体跟超级团队并不是所有人都要成为超级个体，或者所有的团队都要成为超级团队。
我自己会觉得超级团队其实就是一个特种部队，能力很强，花钱也很多。一个超级个体可能一天花的钱是某些普通团队一个月花的钱，我们会知道这件事情是很容易存在的。特种部队的装备有很多时候，一个特种部队上面的装备可以养一个小队，这种情况也是很普遍存在的。
第二个就是说生产力虽然很强，但是由于它是特种部队、AI 特种部队，很多时候它的战术、它的装备都是及时更换，为了保证在最先进的地方，所以它其实是有非常多的波动性和浪费的。这是一个很现实的情况，不只是针对于 AI 的特种部队，现实生活中的特种部队也是一样。为了保证最强的战斗力，波动性、浪费以及对人的要求很高。
这就带来了一个选择：如此贵、生产力也强、同时又需要快速去做更迭的一个团队，你要用在哪？我觉得这是一个更重要的事情。如果你在一个低增长的业务，或者是其实需要安全稳定的团队，你把它变成一个所谓的超级团队，或者是当前希望他是 AI 特种部队，我觉得会出现双方匹配出现问题的一个状况。
我始终还会觉得，拿当前我们所界定的 AI 超级团队——很多人问我说怎么批量生产 AI 超级个体，我说等一年之后。如果你想要的是此刻的超级个体，等半年到一年，所有人都会是超级个体的。但是那个时候的超级个体是另外一个概念嘛。我说批量生产超级个体、超级团队，你等半年到一年就可以了，模型会带着你走向那里。但是你希望你的团队或者你的员工 always 是超级团队、always 是超级个体，这是另外一个概念，这是两个概念的区分。
所以我的点就是说，把超级个体或者超级团队用在什么样的地方？我觉得一定是那种开拓性的、高回报的，所以让他足够去承担这种高成本和高风险。与其在现在去算 ROI 或者是相关的，不如去想一想你的业务、你的团队里面能承受高风险、高投入，但是会有高回报的地方是哪里。
这个反而我觉得去用超级个体更好的时候。以及我始终会觉得，AI 的投入不是均衡分布的。且不说是投入在人身上，投入在产品或者投入在模型方面也不应该是均衡分布，什么地方用什么样的模型也是一样的。可能对于你的公司而言、大部分人而言，你需要他用好 AI，不要抵触 AI，能了解 AI 的边界在哪里就可以了。
但是真正开拓性的、真的给公司带来第二曲线或者带来变化的，假设是说两千美金的 token 费用，你可能需要一千五百美金交给这些人，让他去做探索；然后五百美金确保所有人都能够用 AI，不要抵触 AI，了解 AI 的边界。这些人做好了之后，大家能用。我也不认为所有人都应该成为 builder 跟做 create 的状态或者超级个体。
跟很多创业者也有聊嘛，他其实是一个创业者的状态，他有很多的标签都很像创业者的状态。你绝对不会希望在日常工作中用上创业人才这一种东西嘛，肯定还是适于大家风险投资嘛。我会觉得很多时候这个就很像风险投资和孵化，所以这是我此刻的看法。至于说过几个月我会不会改变，那就几个月之后再说，反正最近一年我都比较是这个看法。
Speaker 0：好的好的，于老师刚刚这一段话我已经可以想象切片里面我们可以切好多金句出来了，已经是非常多的金句。我自己的看法也是这样子，ROI 这个事情确实是要放在一个比较高风险、高回报的地方，你要做更多激进探索。
我可以再分享一些我自己之前在 Meta 的一些经历，也是一样的。我们会发现做这种激进的 AI 组织转型，往往在这种新的产品、新的项目上面会落得一个更好的提升，会有一个更好的验证；而往往现有的业务、现有的冗长的 workflow，你要去做优化的话，其实因为 workflow 更多还是需要稳定性嘛，像于老师说的一样，所以这种 ROI 和投资不光投下去可能回报比比较低一点，同时这种转型会比较困难一点，相比一些新的产品线来说。
好，那我们弹幕里面也没有其他问题了。如果有的话，我们可以再互动一下。于老师这边的分享应该差不多就已经结束了吧，就是主麦没有了。
Speaker 1：对，没有想到，我们聊了一个半小时，本来预期是半个小时。
Speaker 0：对对对，希望还是开心的，我觉得聊下来还是挺有意思的。观众朋友们有问题可以再问一问，没有的话，我们可以给于老师鼓鼓掌、点个赞，对吧？非常感谢于老师今天在这么忙碌的一天还来参加我们的线上活动。
Speaker 1：今天不是忙碌的一天，今天这天是疲惫的一天。
Speaker 0：我都想着是忙碌完疲惫的一天。
Speaker 2：对对对，好的好的。
Speaker 0：那我们今天的直播活动就到此结束了，非常感谢于老师，再次谢谢大家，也谢谢大家的参与。好，那我们下期可以再见，拜拜。