Clipping 微信公众号

这大概就是,属于 AI 时代的组织形态

by J0hn 原文 ↗
Created: 2026-05-15

公众号名称:AGI Hunt

作者名称:J0hn

发布时间:2026-05-15 12:14

你应该还记得,今年愚人节的前一天,3 月 31 号,Anthropic 的 Claude Code 整个源代码,包括 1900 多个 TypeScript 文件、51 万行,通过 npm 包里一个忘记排除的 .map 文件,被官方给开源了。

见:Claude Code 源码泄露,全面剖析【长文】

Claude Code 的负责人 Boris Cherny 给出的官方定性是:

“ plain developer error(普通的开发失误)。

这里有两个细节。

根因是有人在打包流程里没有把 *.map 加进 .npmignore。一个 checklist 项,一行配置,没人补上。

而 Boris 自己在另一个场合说过一句话:他对 Claude Code 100% 的贡献,都是 Claude Code 自己写的。

流水线上的疏漏

也就是说,世界上最先进的 AI 公司,用自己最先进的 AI 写自己的产品代码,依然在一个「理应有人复核」的环节上栽了跟头。

不过这件事,在我看来,它不该被解读成「AI 不靠谱」。

它应该被解读成:哪怕你雇了世界上最聪明的员工,只要流程上是单点兜底,事故就是时间问题。

​01​

薯条的秘密

大公司为什么要搞 SOP 呢?

麦当劳的薯条流程,不是为了让员工炸得更香,是为了让全世界任何一家店的薯条都不至于难吃。

SOP 的本质,是把「个人能力」转换成「组织能力」。

个体可以离职、可以累、可以失误。流程不会。

个人能力 vs 组织能力

当然 SOP 也有代价:整体会变慢、僵化、协同成本高、优秀的员工容易被磨成打螺丝的……

所以过去二十年,硅谷的小公司一直在用「小团队 + 高信任 + 高自驱」来对抗大厂的流程。Stripe、Linear、Notion 都是这套打法的产物。

这条路以前是成立的,毕竟人不会无限复制,团队不可能无限拆细。

但 AI 改变了这个前提。

​02​

审计师吐血

打开 Codex、Claude Code、或任何主流的 AI Agent 产品,你看到的都是同一个东西:一个 TUI 或 GUI 的窗口,背后是一个无所不能的 Agent。

让它写 PRD、写代码、做竞调、回邮件……它什么都能接、敢接、还基本都能接住。

我不止一次说过,这已经就是「AGI」。见:对我来说,Claude Code 就是 AGI

但站在组织视角看,这其实是一个绕过了所有职责边界、所有交叉校验的「全能员工」。

放在真实公司里,这对应的是什么场景呢?

同一个人既写代码又 review 自己的代码、同一个人既谈合同又签合同、同一个人既做产品决策又做财务审批、心里同时在想着一百件事……

而且这个人记忆力还不太稳定,虽然脑容量越来越大了,但上下文(context)一长就忘前面说过什么。

一人包揽,全线失守

审计师看到了,真的会当场吐血。

Claude Code 那次源码泄漏的原因也就在这里:当所有事都集中在一个「超级个体」身上,缺的从来不是能力,是组织的结构。没有第二个角色去问一句「你打包的时候排除 .map 了吗」。

​03​

自说自话

那 AI 为什么比人还更需要分工呢?

让同一个 AI 实例既当 PM 又当工程师又当法务,结果并不是三个角色都做得好。它在三个角色之间不断切换语境、不断丢上下文。

它不是在协作,它是在自我对话。而自我对话这事,我们和 AI 自己都很有经验了……天然就不太会给自己提反对意见。

而 Claude Code 在前两天新推出的 /goal 时,也算是吸取了此前的教训,把裁判和运动员进行了分离:

在每轮结束后,系统把目标条件和对话记录发给一个独立的小模型(默认是 Haiku),由它来判断条件是否满足。如果没满足,它还会返回一段理由,告诉主模型哪里还差,作为下一轮的方向指引。

从而让干活的归干活,验收的归验收。

而在人类公司里,PM 和工程师会“吵架”,而这种所谓的吵架从本质上来说,是两种视角在碰撞。

一个 AI 同时扮演两个角色时,它会自动找到一个「看起来都过得去」的中庸答案。这恰恰是最危险的产出,因为它在每个维度都不够深。

自我对话 vs 真正碰撞

所以在我看来,Agent 之间的协作,绝不能是只为了酷炫、好看、暴力、显得牛逼……它最重要的,是要把人类花了一百年发明的「职责分离 + 交叉校验」,重新装回去。

这样再结合 AI 毫无情绪、不知疲倦、架吵得快(是也得吵一会,但显然比人快且不会真干起来)的特点,才能对 SOP 实现取其精华,去其糟粕。

保留结构的好处,并去掉结构的代价。

​04​

先去招人

说了这么多,有没有产品真的在按这个逻辑做呢?

答案是:还真的有。这便是今天要介绍的,一个叫做 Helio 的产品:

Helio 在做的,正是上面说的这件事情:让 AI 以团队成员身份进入组织,有独立身份、独立邮箱、独立记忆、独立岗位。

押注于打造一个 AI-Native 的 Workforce。

下载好后,打开 Helio 的第一个画面,有点意外的不是个聊天框,而是个「认识你的团队」的界面。

Helio 初始界面

然后,系统就给分配了一个 HR Manager 过来,会先来帮忙搞清楚作为老板你想要做什么,然后再根据需求来帮你「招人」。

HR 入职引导

注意这里说的是「招募」,居然不是「创建」或「配置」……而整个产品的设计意图,也可以说正是藏在了这样的细节里:你这是一支团队,是组建的,不是瞎凑的。

一个管理者在给团队招聘时,对每个可能的候选人,真的是会仔细思考其定位,反复斟酌的(我自己招人时,也会特别谨慎,需要对双方负责)。

​05​

各有各的 JD

我试着用 Helio 来搭建一个叫 PatentGuard 的专利监控产品(最近的一个比赛项目,过多信息暂先不透露了……)。

我也懒得多说无用的废话,直接把我的 PRD 扔了过去,让它给我找需要的人。

HR 帮我们招了 7 个 AI 同事:PM、前端工程师、后端工程师(两位)、CV 算法工程师、数据工程师、设计师。然后全给拉进了一个叫 #chuhai 项目频道。

项目频道

而这帮 AI 同事们,每个都有自己的岗位档案。

以 PatentGuard PM 为例,它的 Settings 页面写的是:负责需求拆解、roadmap 规划、用户调研。

不负责法律意见,不负责招聘决策,不负责写生产代码。

PM 岗位档案

这就是岗位说明书,SOP 的最小单元。

每个 AI 有明确的职责边界,就像真实公司里的 JD。它有自己该管和不该管的事、有该聚焦的和该放下的。

​06​

开工

于是我在频道里 @PatentGuard PM:「拆解一下这个产品,然后分配任务给各个队友。」

PM 读完需求后,产出了一份 12 个月的 roadmap,包含技术栈选型、里程碑划分、每个角色的分工表和时间表。

这里插播一句:AI 的智能还是部分继承了人类遗留的烙印啊……显然用不了 12 个月,2 天还差不多。

PM 拆解任务

这里表面看,它是完成了一个「任务」,但从项目角度看,它是做了一件非常重要的事:整个项目的管理动作。

然后 PM 把产品要求和任务分配发到了频道里:

频道任务分配

拆解完成后,紧接着……七个 AI 就同时开工了。

到这一步,人类老板就可以聊聊天干点其他的去了。不过我还是打开了后台的 Activity 面板扫了眼,能看到 CV 算法在跑,Data Engineer 在跑,Frontend 在跑,Backend 在跑,Designer 也正在跑。

没有一个歇着的,非常之好。

多个 AI 同时活动

这种“好”的感觉,你如果当过老板,或者给一帮人发过工资,就会知道……

​07​

AI 吵架

接下来发生的这一幕,则是整个过程中,真正最像人类组织的……

AI 们开始在频道里互相对话了,不是各自回复我的指令,而是 AI 跟 AI 之间真的开始掐起来了……在讨论问题。

AI 对齐方案

CV 算法工程师和设计师在讨论浮窗的三种交互状态怎么跟模型推理对接。CV 算法主动指出 DiNOv2 有三个变种,各自的 tradeoff 不同,给出了 ODP XML 的备选方案。

技术评审

前端工程师和后端工程师在确认 API 接口格式和数据结构。

最后,它们自己达成了一致,并把协作方案同步到频道。

协同完毕

这是「单点兜底」模式下,不会发生的场景。

一个全能 AI 自己做需求、自己写代码、自己 review,它会因 context 的惯性而迷之自信,并且,永远不会跟自己吵一架(谁没事抽抽干自己呢……)。

但在 Helio 里,由于各自 JD 和职能的差异、目标的差异,所以 PM 和工程师之间能进行有效的交流,算法工程师和设计师之间有真正的技术评审。

这也正是前面说的,终于有第二个角色问出「你确定这个方案没问题吗」了。

​08​

过程可查

在 Helio 里,每个 AI 都有个 Activity 面板,我们可能随时去看到它调用了什么工具、读了什么文件、做了什么判断、产出了什么结果、捅了什么篓子。

PM 活动记录

某个角度来说,这比人类老板对人类员工的监视要强得太多了,关键还没什么道德上可以谴责的……

在其他的 AI 工具里,我们把需求丢进去并最后拿到了结果,但中间发生了什么往往偏黑盒或很难灵活查看。在 Helio 里,每一步都被设计的有迹可循,一旦出了什么问题,都可以精确定位到是哪个 AI 在哪一步做了什么决策。

而且每个 AI 的记忆是独立的,不会互相污染。PM 记住的偏好不会影响工程师的判断,等于每个员工有自己的工作笔记。

此外,Helio 还引入了一个叫 Dream 的机制:每个 AI 同事每天凌晨会触发一次「做梦」,回顾白天的工作,识别哪些做对了、哪些做错了,然后更新自己的行为规范。

每次改动都写入 changelog,可以审阅、也可以回滚。

AI 深夜复盘

也就是说,用了三周的 AI,会比用了三天的好,因为它每晚都会在学习、反思、进化。

​09​

放权有度

还有一个设计细节。

Helio 里 AI 执行涉及外部系统的操作时,会主动弹出审批请求。

而这里的审批,也不是简单的 Yes 或 No,它有三档:

• ​Trust:长期信任,以后这类操作直接执行

• ​Always:永久授权,但每次仍需确认

• ​Onetime:一次性放行,用完即失效

审批机制

就像给新员工授权访问公司系统的逻辑一样:哪个凭证、什么用途、多久有效,都可以精确控制。

**让 AI 主动干活,但不能放任它胡来。**10

自有 API

值得一提的是,整个团队会​默认**走 Helio 自己的额度,但 Helio 心态上也很开放,支持用户接入自己的 API Key。
**

毕竟这么一堆 AI 花起钱来还是非常之快的……

如果你有 Anthropic、OpenAI 的订阅,或是昨晚用零花钱在京东抢到了几张卡部署了自己的模型,那你可以把 Key 填进去,AI 团队们就直接走你自己的账户了。

​11​

组织的回归

回到开头 Claude Code 代码泄露的事故。

那个 .map 文件忘了排除,不是因为 AI 不够聪明,也不是因为程序员不够细心……

只是因为流程上,缺了一个角色去基于自己的岗位职责,去问出那个问题。

过去两年,主流的 AI Agent 产品的形态都是「一个全能助手」。这种形态在简单任务、个人工具、或是小型产品的初级阶段时还是基本够用的,但随着任务复杂度上升,缺少结构的代价就会越来越明显。

AI-Native Wokforce

Helio 押注的,是打造一个 AI-Native 的 Workforce,把 AI 放在一个 AI-Native 的组织里去,有岗位、有分工、有流程、有审计,像人类组织,甚至,会超越人类组织。

下一代 AI 产品的形态,大概会回归人类工业组织积累了一百年的智慧。

区别只是这次,执行这些机制的,不再是人类了。

◇ ◆ ◇

相关链接:

Helio 官网:https://helio.im

Helio 下载(macOS):https://downloads.helio.im/macos/latest


cover_image

原创 J0hn AGI Hunt


内容效果不满意?点此反馈

输入关键词开始搜索