AI转型不是技术问题，是组织问题

本来我认为本文内容整体来说是一些正确的废话。但后来我发现好多人无法判断什么是正确。所以我把我认为的正确放出来，给大家分享下。

AI转型的瓶颈从来不在工具层，而在组织层。先搭Harness基建保证AI的产出可靠，再建特区让新组织长出来。这两步的顺序不能反。

一、先做Harness，让AI的产出可靠

企业做AI转型，最常见的起点是买工具、搞培训。三个月后复盘，人效基本没变化。工具只是放大器，它放大的是整个系统的吞吐量，系统本身有瓶颈，工具只会让瓶颈更疼。

正确的起点是搭Harness。

Harness不是某个具体产品，是一套AI编程的工程基础设施，目的是让AI的产出持续可靠。它解决三个核心问题：AI理解意图的准确度够不够、隐性知识能不能外化为上下文、AI产出偏离了能不能自动发现。

模型贡献15%，Harness贡献80%，剩下5%是时机和运气。大部分团队觉得"AI不够好用"，其实是Harness没搭好。

有些CEO会觉得这套基建太重，想直接上工具让团队先用起来。可以理解，但跳过这一步的代价是AI产出不可控、不可预期，后面所有基于AI产出的管理动作都建立在沙子上。先搭Harness再改组织，这个顺序不能反。只搭Harness不改组织，等于建好了高速公路还开着三轮车在上面跑。

二、效率上去了，组织扛不住

Harness搭好了，AI能持续可靠地产出代码了。然后呢？

以前卡点在研发。需求等人写代码，测试等人开发完，整个组织的节奏围着研发转。AI把编码速度提上去之后，卡点转移了。

需求供给跟不上AI的消费速度，测试验证跟不上代码的产出速度，AI一天能写的代码量，传统测试团队可能一周都测不完。

研发不再是瓶颈了，但其他环节一个没少。需求确认、开发联调、测试验收，每一个交接点都在等，每一步都在丢信息。职能分工的交接链条才是效率的真正敌人。AI降低了编码耗时，但没有缩短这条链。代码写快了，写完之后该等的还是等，该丢的信息还是丢。

代码生产效率提升10倍，交付效率只提升2到3倍。中间的差额就是被交接链条吃掉的。

砍掉的不是人，是交接点。这就是组织转型要解决的核心问题。

方向确定了，但转型路上有几个几乎一定会踩的坑，提前知道能少走弯路。

三、转型路上的六个坑

历史包袱会被AI暴露得更快，而不是被绕过

老系统、老架构、老的技术债。AI生成的新代码跟老代码风格冲突，棕地改造的难度远大于绿地项目。AI会让这些历史问题暴露得更快，而不是帮你绕过它们。

岗位描述没改，人就不知道该干什么

传统开发岗变成了"AI协作开发岗"，职责定义变了，但岗位描述没改，绩效考核没改。这个问题不解决，Harness搭得再好也发挥不出价值。

一个人要干的活突然变宽了

以前一个前端只管前端，现在要能写需求规格、能评审AI生成的代码、能调测试。一个人的职责跨度突然变大，能力模型跟不上。每个人都需要突破原来的岗位边界，这比学一个新工具难得多。

交接靠文档，但文档还没建立起来

AI生成的代码谁来维护？需求规格谁来写？知识怎么传递？以前交接靠人，靠口头传递的隐性知识。现在交接靠文档和流程，但文档和流程还没建立起来，组织就先乱套了。

管理工具背后的假设已经过时了

任务管理平台、知识库、文档平台，这些工具承载的管理逻辑是给人设计的，不是给AI+人协作设计的。任务拆分的粒度、进度追踪的方式、文档的结构，都需要围绕AI的工作方式重新设计。老工具能凑合用，但它背后的管理假设已经过时了。

令牌用量是衡量AI介入深度最直接的指标

容易被忽视但非常实际。两个原则：不要限制大家用，但要知道大家用了多少。用统一平台做密钥分配、成本追踪和权限管理。不管好这件事，组织对AI的使用就是一笔糊涂账：谁在用、用来干什么、花了多少钱，全不知道。

四、核心组织设计

组织是长出来的，不是设计出来的。不要一开始就追求完美的组织架构，先选对人，让对的人在正确的环境里跑起来。

严格5人小组，超过5人协调成本就超过新增产出

项目经理统筹管理、对外沟通、控版本节奏。两个技术负责人带着AI写代码，一个偏前端一个偏后端，但都要求跨职能：能谈需求、能做测试、能端到端交付。产品负责人专职需求分析，输出场景剧本。质量负责人全程护航质量，从需求评审阶段就介入。

严格5人。AI提速编码后沟通协作成了真正的瓶颈，小团队天然占优。超过5人，项目经理的协调成本会超过新增产出。

三阶段迭代：先跑通，再融合，后升级

前三个月是稳固期。角色按岗位分工，技术负责人按前后端侧重分配，目标是让新模式先跑通。

第四到六个月是融合期。质量负责人和产品负责人突破岗位边界，用AI辅助做对方的领域工作。

第七到九个月是升级期。成熟小组取消岗位限制，按负责人角色工作，每人端到端交付一个模块。

不要一次到位，边跑边调。

从代码评审转到文档评审，投入产出差一个数量级

这是最关键的一项转变。

传统模式下评审的重点是代码。AI时代，AI生成代码的质量几乎完全取决于输入文档的质量。花30分钟评审一份场景剧本，可能省掉3天因为理解偏差导致的返工。花30分钟评审一段AI代码，可能只发现一个命名风格问题。投入产出比差了一个数量级。

场景剧本替代产品需求文档，差别在于上下文

具体做法分两步。

第一步，把产品需求文档改成场景剧本。产品需求文档描述"系统应该做什么"，场景剧本描述"用户怎么用"。比如产品需求文档写"支持微信一键登录"，场景剧本写"小明在地铁上打开软件想查昨晚的订单，从微信一键授权后直接进订单列表页，3秒内完成"。差别在于上下文。AI理解意图的能力不强，给两种不同的描述，产出质量天差地别。

第二步，场景剧本由前端、后端、质量负责人三人各从不同视角评审一遍，上下文在每次交给AI之前花两分钟检查。

五、基建配套

全团队统一工具链，一个人踩的坑另一个人能直接复用

先最小可用，边用边换。但全团队必须统一工具——包括AI编码工具、智能体工具、项目管理工具，全链路统一。

统一工具的核心价值不是省钱，是保证问题的一致性。五个人用五种工具，同一个问题会出现五种解法、五种排查思路、五种文档格式，沟通成本直接翻倍。统一工具之后，团队面对的是同一套操作逻辑、同一套问题模式、同一套解决方案。一个人踩过的坑，另一个人能直接复用经验，不用先搞清楚"他用的是什么工具"。

更关键的是，跨职能协作变多之后，统一工具是快速上手协助别人的前提。前端要帮后端调一个接口问题，打开同一套工具就能直接上手，不需要先适应对方的环境和配置。AI时代每个人都要能端到端协助，工具不统一就是给人添绊子。

选一个主力工具全团队统一用，不够用了再换。关键是每次换工具都是因为"遇到了具体问题"，不是因为"听说XX更好用"。

翻车分享比任何课程都有效

分阶段、持续的在岗学习，不是一次性的"AI培训课"。转型初期覆盖基础认知和工具操作，中期覆盖各角色上岗技能，后期覆盖产品思维和交叉交付实战。

实际操作中，效果最好的不是正式培训，是每周的"翻车分享"。某个人这周AI用得好，讲一遍他怎么写的提示词、怎么做的上下文；某个人踩了坑，把AI生成的烂代码投屏出来让大家一起看问题出在哪。这种分享比任何课程都有效，因为它解决的是"我不知道我不知道什么"的问题。培训的真正目的是缩短每个人从"不会"到"会用"的距离，这个距离靠上课缩不远，靠身边的人示范才缩得快。

令牌用量能反推效率瓶颈

用统一平台搭建AI使用入口。每个团队分配独立的额度和密钥，成本可追踪、可分摊。管理者能看到每个团队的AI使用情况，不限制使用，但让使用可见。

令牌数据还能反过来帮团队发现效率瓶颈：用得多但产出没变化的，大概率是Harness没搭好；用得少的，可能是转型意愿或能力的问题。

六、过渡策略

新老组织完全分开，各走各的路

各用各的工具，各走各的流程。这是保护新组织不被老习惯吞掉，同时也是保护老业务不被转型折腾。新组织在独立环境里验证新模式，跑通了，老组织的人逐步过来，靠示范效应带动迁移，不靠行政命令强行推动。

新团队绝对不能背着老系统跑

新特区绝对不能背着老系统跑，否则转型团队会被老系统的维护和联调拖垮，新组织还没长出来就先夭折了。

具体做法是两手：一手让转型团队完全脱离老系统，只接新项目或独立模块，保证他们的AI+人协作模式能跑通；另一手给老系统安排明确的归属——要么抽出专人或专组做运维保障，要么让暂时不参与转型的人继续维护老系统，保证业务不中断。

这里有一个现实的分化：不是所有人都能跟上转型节奏，这很正常。跟不上的人手里的经验恰恰是维护老系统最需要的东西。让他们做老系统的运维和保障，业务稳定了，转型团队才能放手往前跑。

等转型团队的新模式验证成功、产出效率明显提升之后，再把老系统逐步拆解成独立服务，分批交接给转型后的团队做渐进式改造。顺序是：先让新模式跑通，再回头处理老包袱，不是先清债再出发。

转型期间最大的风险是业务先崩了

转型搞到一半业务先崩了，这比新模式跑不起来更致命。客户不会因为你正在转型就多给一个月的耐心。

整个落地方案必须同时回答两个问题：新组织怎么长出来，老业务怎么稳得住。前面的每一步——历史包袱归属、新老组织分开、工具统一——都是围绕这两个问题设计的。不能只要转型不顾业务，也不能因为怕影响业务就不转型。两者是并行线，不是二选一。

理解了"为什么要分开"和"为什么要先做Harness"，后面的执行方案就容易理解了。整条逻辑链是：Harness保证AI产出可靠，产出可靠后交接链条成为瓶颈，新老组织分离、历史包袱专人兜底，在特区里让新组织长出来，新模式跑通后逐步回收老包袱。

七、跑通之后长什么样

以我们自己的团队为例。标准产品+企业级定制开发，Spring Cloud + Vue技术栈，项目周期2到4个月，团队60多人。下面是转型九个月之后的状态。

单体效率5到8倍，绿地和棕地差距很大

写新功能、新页面、新接口这类绿地工作提升最明显。以前前端开发一个完整的管理页面需要两到三天，现在半天到一天。后端标准增删改查接口加单元测试，以前半天，现在一两个小时。

改老代码、对接第三方这类棕地工作，提升大概2到3倍。AI对已有系统的理解跟不上人，这也是为什么前面强调新团队要脱离老系统跑。

瓶颈被拉高了，不只是峰值被拉高了。

整体效率2到3倍，差额被需求和测试吃掉了

需求澄清省不掉，客户不会因为你用AI就把需求想清楚。测试压缩了但没消失，业务逻辑的正确性还得人验证。真正省下来的是编码时间和返工时间，编码从40%压缩到10%，返工从15%压缩到接近0。

原来一年能交付20_{30个项目，现在预期能交付60}80个。人变少了，成本没涨。这个数字比单体效率更有商业意义。

每个人的工作内容变了

技术负责人从80%写代码变成80%评审和沟通。质量负责人从等开发完变成从需求阶段就介入，开发和测试从串行变成并行。项目经理从60%时间传递信息变成20%，省下来的时间跟客户沟通需求。

内部小工具变多了，每个人都在造自己的铲子

以前团队只有公共平台和通用工具，没有人自己造工具。转型之后反过来了，每个人都在用AI给自己写效率工具。

产品负责人觉得需求池管理不顺手，让AI帮着写了个需求采集工具，当天就能用。项目经理嫌项目看板跟不上节奏，自己搞了一套，还能根据场景剧本自动生成每日进度统计。这些工具以前提需求走排期，起码一两周，现在每个人想用什么就让AI写一个，半天出原型，不好用就改。

这个变化说明一件事：团队从"等人提供工具"变成了"自己解决问题"。人跟AI的协作越深，个人解决非标准问题的能力就越强。

三个意料之外的收获

招聘标准变了。以前看技术深度，现在看学习能力和系统思维，人才池一下子大了很多。

新人上手变快了。以前融入至少一个月，现在第一周就能跟着AI做任务，因为场景剧本把上下文写清楚了。

文档质量被迫提升了。场景剧本要给AI看、给团队看、给客户确认，每句话都得准确，这个习惯倒逼了整个项目的知识沉淀。

八、给CEO的三句话

第一，AI转型是组织决策，不是技术决策。技术选型可以换，组织惯性一旦形成就很难改。先动组织，再动工具，或者至少同步进行。

第二，不要等"准备好了"再开始。没有完美的转型方案，最好的时机是有5个愿意试的人的时候。先建特区，让特区先跑起来。

第三，衡量标准是交付效率，不是AI使用率。用AI写了多少行代码不重要，一个迭代能交付多少功能才重要。AI使用率上去了但交付效率没变，说明组织没跟上。

单体效率提升5到8倍不稀奇，整体效率提升2到3倍才是真正的胜利。模型贡献15%，Harness贡献80%，组织决定了这80%能兑现多少。先搭Harness再改组织，不能反过来。