AI 冲击组织，CEO 需要第二研发部

AI作为一个革命性力量，对传统的组织造成了极大的冲击。几乎每个CEO都在思考：我的组织能否熬得过AI这波范式转移，是会像国美一样快速崛起然后快速谢幕，还是像中国银行一样能够熬过百年变局？要对这个问题作答的不是别人，只能是组织的一把手，正如孙天澍教授在《AI下半场，企业如何赢得竞争？》所述，

AI+不会自下而上自然发生，企业不能指望一线员工用AI工具就自然长出一个AI原生组织。CEO必须首先成为AI架构师，自上而下架构下一代业务。

CEO 担当 AI 架构师，并不是指 CEO 要学习梯度下降去训练大语言模型，而是指 CEO 重新设计自己的组织结构以有机的纳入Agents到自己的团队中。孙教授说“理解Agent最好的方式，是把它想象成一个新员工”。

这个新员工非常不同，它：- 有人类所有学科的本科文凭- 能高分通过任何医师/司法/公务员资格考试- 能说人类所有主要语言，包括计算机编程语言- 一天工作24小时，在有闰秒的日子里还能工作24小时零1秒- 有金鱼的记忆- 缺乏一些你五岁小孩都知道的常识- 毫无主见，比人类历史上任何一个马屁精都没有原则- 完全没有屁股，但是也完全没有自主驱动力- 每个月以肉眼可见的速度在进化

那么，接下来的六个月陆续有一万个这种古怪新员工入职贵司，你的组织是会崩溃还是会兴盛？对于大多数没有牌照保护的企业来说，这是个生死题。

CAIO 不是一个完整的答案

有的 CEO 聘请了专职的 CAIO，Chief AI Officer，和CIO/CTO并列。这是一个很好的开端，但是不太妙的是，很多CAIO沦落为一个培训官，主要工作是在内部做AI通识教育，一遍又一遍的让财务同事停下工作听他讲神经网络的内涵和外延。有时候CAIO会打造一些提效降本小工具，比如《AI识别发票，降低员工报销时间从20分钟到30秒》之类的。时不时搞个 AI 应用大赛，从那些工作量不饱和的团队里选一些 AI 小能手，给他们发个小红花，把他们的照片贴在公司食堂或者男女厕所。有的CAIO还会搞 token 消耗排行榜，在商业组织里公开鼓励成本浪费。有的CAIO无处发力，会去统计有87.65%的文档/代码/会议纪要是 AI 生成的，然后拿出去炫耀一番，简直堕落成新时代的研发能效部部长。

这一切的失望都是来自于一个错位：CAIO没有自己的业务目标，只能想办法骑在其他部门身上试图向CEO证明“哥，你看我放大了他们的生产力十倍”，而其他部门千方百计想要把这个骑手摔下来，证明“没有这老哥，我能十倍速跑步”。这种冲突和CAIO个人能力无关，解决这种内在冲突的唯一方案就是：

给CAIO一个商业闭环的目标

一个CAIO有没有底气，就看他是否能负责一个产品线。能负责的就是将军，不能负责的就是门客。

只要CAIO负责一个产品线，对商业结果负责，自然就能消除“AI有没有用，Agents能不能打，CAIO配不配她拿的薪水”这些没有建设性的辩经，毕竟商业收益是检验Agents的唯一标准。

而承载这个商业闭环的部门，有各种名字，我建议称之为“第二研发部”

我有个朋友有犯贱的癖好，有一段时间改口管自己老婆叫“大老婆”，每天都能从老婆那里领几个耳光。显然，没有老婆喜欢被称呼为大老婆，也没有研发部喜欢被叫第一研发部。那么为什么我建议取名第二研发部呢？这并不是故意刺激现有的研发部，实在是因为CAIO领导的这个产品研发部，方方面面和原来的研发部差太远了，实在没法一桌吃饭，只能另立家室。

第二研发部的资产不是代码

传统的研发部，主要资产就是代码。我国的软件著作权保护的是代码。华为送去英国国家网络安全中心审查的是代码。各种水印和监控保护的也是代码。这是前AI时代的普遍常识，也是第一研发部的立身之本。

但是在Coding Agent能快速翻译需求书到代码的今天，代码不是第二研发部的核心资产。第二研发部交付的可以是传统软件，也可以是现代智能体。软件系统的核心资产是规格书和验收标准，智能体的核心资产是Skills和benchmark，都不是代码。这一根本区别是后续区别的基础。

第二研发部不交付标准品

我的朋友杨攀有个解释：传统的SaaS/盒装软件实际上是一个容器，里面装了100个功能，每个企业客户只用了20个功能，另外每个企业还有另外30个需求没有被满足。对于甲方来说，这是非常不愉快的体验。但是在没有AI的古代，软件开发成本非常高，因此绝大多数甲方只能捏着鼻子用标准品，只有央企和互联网大厂才有财力承担定制软件。

第二研发部改变了这个格局。有了编程Agents，代码不再是昂贵的资产，而是可以快速产生的中间物，因此第二研发部不再生产标准软件，不再像Salesforce那样砍客户的脚去穿它的均码CRM鞋子，而是为每个客户定制一套合体西装。

有传统软件的粉丝一定会指出”SAP/Salesforce是可以配置的，并不是一个均码鞋子“，我承认这个反驳在一定程度上成立，但是如我的朋友刘明皋指出，这种可配置性软件有巨大的开发成本，比如数据库里不再是一张老老实实描述业务的表，而要先搭一张 meta table 去描述"真正的业务表长什么样"。SAP 实施动辄几千万、上线两三年，这种可配置性带来的复杂度脱不了干系。另一个惨绝人寰的例子是 Magento，为了那点可配置性，把一个商品拆成几十张表来回 JOIN，架构图就像俄罗斯套娃一样难以琢磨。

刘总还指出“配置的软件是否成功应用，是否能达到客户的预期，性能是否满足系统运行，是否是最优配置，都取决现场实施人员或配置人员的技术水平和对业务的理解度。强的人虽能做好但后续不好维护，没人能懂他当初的配置逻辑，弱的人对系统会带来灾难性后果，最后会让开发买单，付出更多的精力解决无数的上线问题”

第二研发部交付的系统不需要考虑代码复用，它就为当时当地的那个客户服务，不需要1587个互相依赖的开关和1984个默认配置。如调皮话所说的那样，最好的配置就是没有配置。系统复杂性数量级的下降，用户满意度数量级的提升。

定制化交付的流程需要探索

不管是标准产品还是定制系统，所有开发工作的起点都应该是客户需求搜集。传统的客户需求流转链条是

这是一个冗长而失真的流程，商业价值在这个链条上流失，而成本在这个链条上累计。如果把总包/分包，内部团队/外包团队，前端工程师/后端工程师，架构师/程序员的传递再考虑进来，很可能第一个人画的孟加拉虎已经变形为一只吉娃娃了。

我的朋友优维科技CEO老王在他的AI Native团队立了一条规则：客户需求的流转不允许超过两次，要么首次接触人直接实现，要么传递给第二个人实现。这是和第一研发部非常不一样的流程。

业界流行一个说法，FDE应该在现场挖掘出客户需求，并且在现场实现它。我不太赞同这种说法。我们图凌人工智能公司积累的经验证实，现场环境非常复杂，把需求挖掘、资源协调、工程实现、商务谈判等任务全都压在一个人肩膀上，非常不经济。我们的经验是，一个PM负责商务和资源，一个FDE专注于落地实现，是比较合理的分工。对于上规模的系统，如果有一个领域专家，则团队技能更为全面。在不少项目中，这个领域专家来自于甲方。

支持新流程需要新团队

传统开发部，不管什么行业，岗位基本都差不多。CTO带着一堆架构师和产品经理斗智斗勇/密切合作，底下一群有奇怪头衔的码农负责写代码。说他们奇怪，是因为一群从来没有去过印度尼西亚的人自称爪哇（Java）程序员，一些不太谦虚的人自称红宝石（Ruby）程序员，还有人看着很普通却自称大蟒蛇（Python）程序员，稀奇古怪，无奇不有。这群人还会为看不见的tab和空格吵架，据说吵了三十年了。

第二研发部不再需要这些刻奇的头衔。编程Agents能用任何人类已知的编程语言编写代码。编程Agents也不需要一个DevOps工程师来帮助编写dockerfile。编程Agents也不会说自己只能站前端或者站后端。HR 再也不需要学习这些奇怪的概念了。

第二研发部会有两个主要分部：在办公室开发公共平台的研发团队，在客户现场交付成品的FDE团队。如何协调这两个分部的工作，是CAIO的重大课题。我们注意到有一些友商组建几百人的平台研发团队，打造全场景覆盖、全链路打通、全栈自研、全模态接入、全流程闭环、全要素整合、端到端拉通、自顶向下贯穿、自底向上沉淀、从 0 到 1 再从 1 到 N的一站式智能体平台，但是他们没有一个能交付成品的FDE团队，以至于塔克拉玛干那么大的智能体平台上几乎看不到活的智能体，只能依靠marketing撑住台子不倒塌。

新交付需要新的商业模式

传统的甲方会有一个固定的产品需求规格书，有一个认真讨论的验收标准，通过招标寻找供应商。传统的盒装软件/SaaS有一个敲定的目录价格，变量是销售掌握的折扣。这一套运作了很多年。

而第二研发部在派FDE入场的时候，甲方需求还是模糊的，底层数据是不完备的，SOP（标准操作流程）是未经定义的，交付范围极其不确定。这样的交付，显然无法通过传统的软件招标来履行。

在我们一些交付现场，我们的客户甚至提出“如果智能体核心资产SOP来自于我们，为什么我们要为这个智能体给你付费？”这是一个非常尖锐的问题，实事求是的说，我们图凌公司还没有一个双方都满意的回答，需要和业界同行一起探索。一些同行声称“我们给你提供数字员工，你为数字员工付薪水”，却没有考虑到这个数字员工的核心能力来自于甲方还是乙方，他们迟早会被甲方凌厉的质问“这个数字员工是我捏的，我为什么要给你付费？我认为你需要倒过来给我付学费！”

信息安全要适应新的范式

我们Agent特区社区分享过一个真实的事故。某个大厂的生产库被删了。复盘下来，是大模型自己在脚本里加了个删除参数。工程师的自然反应是“你看，AI果然不靠谱”，整改措施也是让一个人审核智能体的操作。

实际上，他们系统没有权限控制，分支版本被应用于生产环境，数据库没有基本的防呆保护，很多因素凑在了一起。根据人类组织原则，此时背锅的必然是狡辩力最弱的部门，在这个案例里，倒霉的就是没有出席复盘会的AI。

安全有一个理论：如果安全措施太难用、太麻烦，用户就会想办法绕过它，于是这个措施反而让系统更不安全。

比如密码策略要求"12位、大小写数字符号、每月换"，结果人把密码写在便利贴贴在显示器上。规则在纸面上很安全，落地后放大了风险。

AI不会写便利贴，如果你在skill里恰当的指示它，它对安全规范的遵从性远远高于人类员工。很多传统安全工程的良好实践，由于成本的原因无法落地，现在都可以让智能体践行了。在这个意义上，智能体是安全工程师最好的朋友。

当然，这不是说智能体没有引入新的安全风险。回到开头那个古怪新员工，它毫无主见、耳根子软，一致的输入并不会产生一致的输出。安全工程师视为噩梦。但这是一个可以通过管理手段或者工程技术解决的问题，不是安全工程师不给智能体发放通行证的借口。在一些需要确定输出的场合，比如权限控制，完全可以在软件层面实现，而不是指望那个耳根子软的新员工自觉。

摆脱转型思维，另设第二研发部

智能体研发和传统研发，从资产、交付、流程、团队到安全，全是两套逻辑。与其逼着CTO把原有的研发部做AI转型，让 CTO 陷入复杂的人事重组困境，CEO不如直接设置一个第二研发部。这个第二研发部可以让 CTO 管辖，也可以聘请专职 CAIO，也可以请外部顾问先帮你把它搭起来。

第二研发部该怎么建，业界都在探索。如果你也有兴趣，无论是学术探讨还是商业合作，欢迎在公众号联系瑞典马工。