组织转型 #AI团队 #FDE
最近在Agent特区做了一次组织转型的分享，讲了我这几个月把一个传统研发团队改成AI Native团队的完整路径。下面是分享的核心内容，后面附了大家讨论比较集中的几个问题。
起点：职能式分工的死穴
我们是一家做标准化产品加定制化交付的ToB公司，我是技术一号位。原来的组织是很传统的职能式分工：销售部签单，产品部写PRD出原型，研发部分前后端和测试。一个需求从客户嘴里到上线，要经过5次交接，每个环节都要排期。
这种模式下，单点效率再快也解决不了整体效率问题。交接本身就是损耗。
三个阶段的组织形态
组织改造经历了两个阶段，还有一个是目标状态。
第一阶段就是刚才过去式职能式分工，已经说过了。
第二阶段是现在已落地的状态：FDE跨职能5人小组。每组一个PM、一个PO、两个TO、一个QO。PM管项目整体和外部协调，同时是个补位角色，哪弱顶哪。PO是需求分析师，把大产品的业务知识转成开发用的feature。两个TO是技术owner，主要监管AI写代码。QO负责全流程测试和质量保障。
这个小组要端到端地完成项目交付：配合销售做售前报价和技术评估，配合产品部做技术分析，到客户现场做需求调研和确认，然后根据实际情况决定是带回公司开发还是现场开发。全程带着AI做，现在的要求是不管开发还是需求，不用自己手写内容，所有东西都是和AI对话产出的。
产品部也有变化。以前产品部是研发的上游，现在缩编了，变成一个大产品经理的概念，管除了销售和交付以外所有产品工作，要求对业务有深入理解。FDE里的PO更偏传统的需求分析师，只做细节设计，不用特别精通业务。FDE部门和产品部之间是内部客户关系，产品部门要下发的东西都需要FDE部门先报价，然后再做详细的需求设计和开发交付。
第三个阶段是我们的目标方向：岗位深度整合。以后不分PM、PO、TO、QO了，大家只有项目Owner，一个人从需求讨论到上线部署，AI是他的另一个"同事"。岗位只有侧重没有分工：以前做前端的，前端部分更复杂的活还是交给他；以前做需求的，复杂业务场景的需求还是他来设计。但边界会越来越模糊。
十一步转型路线
建立信任（第1-4步）
第一步：拿到CEO的背书
这是最重要的一步，没有CEO的背书推不动，就算有，推动起来也比较困难。
我的做法比较直接：给CEO灌输焦虑。我几乎每年12月或1月都要跟他说公司要完蛋了，以前说的理由是业务不行、高管躺平。今年换了说辞：AI时代来了，别人改了成本会比我们低很多（说的也是事实！）。这种话不是一次就够的，吃饭的时候、汇报的时候，逮到机会就说。
他感兴趣以后，给他装工具体验。最早装的是opencode，后来小龙虾出来第一时间给他装上。焦虑灌输到位之后，CEO变得比我还要着急。到这一步，团队转型就顺理成章了。
第二步：让-1层建立体感
这一步的核心是不要让管理层成为转型的阻力。我通常不直接接触一线工程师，他们有自己的+1和+2。
具体做法：周例会上演示AI能力，给大家买账号做环境配置，让管理层用AI解决实际问题。AI使用初期大家会有"AI是神"的错觉，你要趁这个阶段推动他们，让他们在各自团队里渲染气氛、推动使用。
这个过程一定要做好管理。不能安排下去就不管了，要观察有没有管理层对AI反对或不积极，发现了及时沟通处理。
第三步：各种场合渲染AI能力
周会、项目复盘、技术分享，只要有机会就展示AI做了什么、省了多少时间。没有提"转型"两个字，但一直在铺垫。
有个例子：团建路上跟一个前端同事聊AI，他对AI不屑一顾，了解后发现他用的是通义千问的补全插件。吃饭的时候我给他安利claude code和opencode，讲效果讲案例。他饭都不想吃了，着急回去试。给了他我的key，没过两天就自己买了智谱的模型开始研究工作流。
我做这个事情的时候，AI还没有像现在这样如火如荼。假设你的团队现在已经对AI不存在不信任问题了，这步可以跳过。
第四步：搭Harness工程
早期比较耗精力的部分。需求怎么拆、feature怎么分、设计怎么做、代码怎么生成、变更怎么管，全部流程化。这套流程要适应你自己的团队，因为团队要靠这套流程和产物来协作，只有标准化的流程和产物才能让团队相互协作。
Harness不是一次成型的，是在工作中迭代出来的。我们搭了一套完整的目录结构：01需求澄清、02 PRD、03架构、04项目级进度管理、05 feature级别（包含需求规格、接口设计、数据库设计、开发计划、代码评审）、06原型、07测试。所有项目都按这套结构来。
配套的有四套角色、29个技能：产品8个、技术12个、质量6个、项目管理3个（PM进度管理、FM进度管理、监理技能做门禁扫描）。
验证推广（第5-8步）
第五步：选试点项目一，跑新项目
选一个没有历史包袱的新项目，体量不要太大也不要太小。太小体现不了能力，太大失败了承受不了。选的人精力不要被其他事干扰，必须全身心投入。
模式是1个PM加4个FDE。具体做法是找了个会议室集中办公，我全程参与但不介入具体开发，更像一个AI教练的角色。验证周期跑了两个多月快三个月。
核心目标两个：验证以前八九个人才能完成的项目，5个人带着AI到底能不能做出来，做出来的东西质量怎么样；同时让试点小组学会带AI做交付，学会Harness的调整和项目规约的设计。
第六步：试点项目一跑到一半，启动试点项目二
第一个项目磕磕绊绊但跑完问题不大的时候，直接启动第二个试点。第二个项目选了一个棕地项目：有历史代码、有历史数据、有真实客户在用，做二期。主要测试新模式在老项目上的兼容性。
这个项目暴露的问题就多了。需求文档、代码文档、数据库文档都有，但都不完整，和代码匹配不上。不能按老文档让AI分析生成新代码，因为老文档本身就是错的。在这个过程里又补了一些skill和流程，花了更多时间补充项目规约。
两个试点并行跑的时候，出现的问题会急剧增加。但这正是你要的：在可控范围内把问题都踩一遍。
第七步：持续改进Harness
试点过程中Harness每天都在修。今天变更管理没覆盖到，明天测试用例生成太慢，后天换了模型版本之前的prompt不工作了。流程改进是持续动作，不是一次性交付。
举个例子：最开始我的流程是先写PRD再画原型，实操发现根本行不通。跟用户第一天聊出一部分功能，第二天又聊出一部分，但你每天不能光聊不产出。产出什么？原型。拿着原型和用户聊。这个时候没法出PRD，因为还没聊完。所以加了一套需求澄清的技能来做前期调研。
再比如：一开始不同人用了不同模型（智谱、Kimi、MiniMax、GPT），同一套流程在不同模型上可用程度差异很大。只能针对不同模型逐个优化调试，让Harness适配模型。专门找了一个人来做这件事，避免每个团队自己摸索。
第八步：准备培训体系
PO、TO、QO的上岗培训，Harness使用培训，AI基础培训。因为从传统职能团队转过来，有些人是转岗的：开发多、需求和测试少，转型后开发要往中间收，涉及到转岗和新招。
培训分两部分：一部分是Harness从试点中发现的问题持续迭代更新，另一部分是基础知识。内容包括FDE的认知培训、PM专项培训、需求/质量owner的项目结构和工程规范培训。
培训的建议是持续做、一直做。以前鼓励团队分享比较费时费力，现在有了AI，把脑子里的东西讲出来就行，不用自己做PPT，AI帮你做。这给持续培训提供了一个可行的基础。
正式切换（第9-11步）
第九步：历史工作交接
这一步和每个公司自己的情况强相关，千差万别。我们作为产品加定制化交付的ToB公司，面对不同客户各有各的版本在维护。有的项目在研发中，有的在运维中。以前一个团队八九个人甚至十来个人，现在每个团队5个人，老项目和新团队怎么匹配？项目跟着PM走还是跟着研发走？一个项目好几个研发分到不同的FDE里怎么拆？交接过程怎么保证不出大问题？
这些事情比较复杂，只有一个通用建议：根据自己实际情况出方案，同时心里要知道一定会出问题，要能接受出现问题。
我们这边做了大概交接调整了一个半月。核心原则是老项目原班人马维护、跟着研发人员走，新项目用新模式，不会强行切。做之前先给客户打好招呼，出了问题客户有预期就不会有太大反应。
第十步：组织正式调整
两个试点项目都收尾后，分别做了详细复盘，整理所有问题，做了一波流程和skill的改动，补充了培训。到这个时候成立新部门就顺理成章了。
具体动作就是发通知、调座位。但光行政命令不够，做了两件事：让新的PM和自己新的团队成员做一对一沟通；我本人也对每个人做了一对一沟通，确认岗位情况、转岗适应度、有没有顾虑和期望，做针对性解决。
第十一步：按新组织持续运转
搭了Token分发平台做统一管理，监控谁用得太少、哪些FDE团队Token消耗过低。发现这种情况主动干预和沟通，让它们尽快用起来。给用得多的做奖励，但不能提前通知有奖励，也不能反复奖励。用Token衡量工作本身不太合理，只是初期用来判断谁对AI不熟，做人为干预。
新小组启动了陪跑机制，每周找时间和各小组交流半小时到一小时，了解问题、解决问题。绩效也重新设计了，每个公司做法不同就不展开。最后还是Harness的持续改进，每个小组交付完都做复盘，看有没有新的想法可以在公司范围内优化。
踩过的坑
坑1：多人协作比单人难十倍
单人用AI写代码很流畅，多人协作问题全暴露：变更怎么管、工作怎么同步。以前的节奏是开晨会对接工作，AI提速后半天就能产生比以前大得多的工作量，晨会根本跟不上。
目前的解法是缩小组织粒度，从条状变块状。每个项目人很少，坐到一起转身就能沟通，很多问题当面解决。但这只解决了沟通这一个层面，多人协作在AI时代的最佳实践，还需要在持续实践中探索。
坑2：AI不稳定，要持续迭代
换了模型，同一套skill同一个prompt，在Kimi和智谱上表现完全不一样，差距很大。Harness工程要反过来适配模型，按模型特性逐个调整。专门找了一个人来做这件事，避免不同团队各自摸索。
坑3：开发快了，质量掉了
这个问题到现在也没有完全解决。
初期的判断是：以前不做TDD、没有集成测试、没有E2E，全靠人工测试加简单的mock。AI来了以后，TDD、mock测试、集成测试、E2E全都能低成本做，理论上质量应该飞跃式提升。
实际上没有。该做的都做了，TDD、Mock测试、集成测试、E2E测试，甚至文档测试全都上了，质量还是不如预期。单人使用时问题不大，多人协作时质量波动明显。
关键发现是：bug类型变了。AI编码会产生自己特定类型的bug，和手工编程出的bug类型差距很大，等于换了一波新类型的bug。
具体分布上，功能遗漏和功能不一致成了占比最大的问题。这些功能在feature规格文档里都写了，但实际代码出来要么漏了，要么细节和feature对不上。古法编程时期这类问题占比很小，大概3-5%，AI编码后变得严重。原因和大模型本身的能力有关，也和Harness门禁检查不到位有关。
UI不一致是另一个难点。AI无法检查页面，生成的页面和预期差距大，加上大部分页面没有设计稿。早期没有专门给AI用的设计系统，自己编写UI规约效果不理想，后来尝试Design.md形式，效果稍好但仍无法根治。
反过来，以前占比最高的功能逻辑和体验优化问题，在AI编码时反而少了很多。从严重程度看，重要和核心的bug其实很少，一般性问题占比高。
目前没有完美的质量方案。人工测试又拉回来了，给自动化兜底。AI生成代码快，但判断功能对不对还得靠人，否则上线风险很大。
坑4：测试用例过度冗余
不管做业务feature还是做测试用例，都遇到了类似的问题。以前人工写测试用例，写得没这么细但能覆盖住。AI写测试用例以后，一个简单功能能生成五六十条，其中三十条可能是冗余的。
具体例子：一个表单100个字段，AI给每个字段生成三条用例（加一、减一、标准值），100个字段加起来400条。逻辑上没毛病，但让人去测这些实在冗余。
另一个例子是AI过度设计：一个删除的二次确认弹框，正常写提示语固定就行。AI偏要在这个弹框里加业务逻辑，找出这条数据关联的所有数据列出来。设计本身没错，但过度设计了。
优化过skill，改了四五轮，效果有限。约束收太紧会漏用例，放太自由又过度设计。目前的平衡点是AI生成初稿后靠人工精简，保留核心路径和边界值用例。
坑5：人不信任AI形成恶性循环
初期有人提示词写得不好或上下文给不够，产物质量差，于是更不信任AI，更不愿意用，产出更差，形成恶性循环。发现这种情况只能一对一纠偏，坐过去教。信任建立之前，AI工具对他就是摆设。
坑6：Harness依赖人的能力
实习生用AI做单点登录，踩了一堆坑：看不懂feature文档，看不懂model和API文档，AI给什么就用什么，没有判断力。说明Harness是放大器，替代不了基本功，要安排能力匹配的人做对应的事。
坑7：培训要持续做
有人上班打开一个会话一直用到下班，完全没有上下文管理。上下文管理这些内容其实培训过，但并没有真正学会。培训要持续做、反复做，每个月复盘使用习惯，发现新问题及时纠偏。
另外AI工具的使用方式一直在变，培训内容也得跟着变。比如最早推荐用opencode，后来claude code用多了觉得也不错，又在公司推claude code。工具迭代了，培训就得同步更新。
三个还没解决的问题
一是质量怎么靠AI短时间提高。目前靠人兜底，但代码生成速度太快，人盯不过来。这不是长期方案。
二是项目周期和报价怎么预估。单个功能可能快了5倍，但整体项目周期只快了2倍，因为协作和返工的时间你没法精确计算。
三是多人协作下的Feature变更怎么管，才能让岗位间协作更清晰。
问答精选
分享结束后大家讨论了很久，挑几个讨论最多和比较重要的问题整理在下面。
Q：转型后效率到底提高了多少？
A：单个功能大概快了5倍，但整体项目交付周期只快了2倍。卡点在协作和返工。你感觉单个功能做完了，隔半个月测试发现漏了东西，回去改的时间也要算到项目周期里。加了feature检查环节也解决不了这个问题，因为开发和检查是两个时间节点的事。
两个试点项目都跑了，新项目和棕地项目效率提升差不太多。虽然棕地项目要花时间整理老代码的规约，但一个星期就够了，对整体项目周期影响不大。
Q：转岗成功率怎么样？
A：大约10%的人被淘汰掉了。其中一部分是意愿特别低，怎么聊都不用；另一部分是转岗后又裁掉的。开发转测试裁得最多，原因是习惯和意愿都不太行，开发转岗到PO（需求设计）的接受度反而比较高。
Q：前后端分工怎么处理？
A：现在不分前后端了，但工作分配有侧重。流程是先有feature规格说明书，然后带着AI生成API文档和数据库文档，这三个作为输入给到工作流生成开发计划，计划里前后端文件都在里面，一次性把前后端全写了。先写测试用例再写代码，编译不通过就打回去让agent重新改，通过以后跑TDD，再跑代码评审2-3轮，最后自动提交。关键是不存在前后端交接问题，因为提前做好了接口契约。
Q：代码Review还做吗？
A：代码层面基本不做了，因为AI生成太快查不过来。文档层面做，重点是feature规格文档、技术feature文档、接口设计和数据库设计。代码评审是在开发过程中由agent自动做的，不是事后人工review。
Q：Bug率变化了？
A：bug率提高了大概60%。但bug类型完全不同了。古法编程时功能逻辑和体验优化问题占比最大，现在占比最大的是功能遗漏和UI不一致。逻辑问题反而少了。从严重程度看，重要和核心的bug其实很少，一般性问题特别多。
Q：用的什么模型？
A：主要是智谱的GLM-5.1和Kimi 2.6。体感上智谱比Kimi好一些。国产模型在coding场景已经够用了，更重的工作在Harness工程上，只要模型不是特别拉胯，Harness做得好就行。用过Claude但买不到稳定账号，被封了两次就放弃了。
Q：全自动化行不行？
A：试过。用go模式批量生成所有功能的需求、设计、代码，结果全是问题，天天都在用bug调试技能改。现阶段模型能力（至少国内模型）还到不了交给人就不用管的程度，中间必须有人去干预和检查。另外自动化程度越高，人对项目的理解就越浅，出了问题没人负责。所以流程中有一部分是自动化的（开发环节），但需求和需求产物交给开发、开发产物交给测试，这些环节还是人来驱动。
Q：AI写代码但人不了解细节怎么办？
A：代码不是人写的，确实很多细节不清楚。我们的做法是合并回主干之前，让AI把整个功能流程串一遍，了解脉络就行，不用去看具体代码实现。另外遇到探索性的技术方案问题，可以让AI生成多个方案对比测试。有个同事用AI写算法，性能不好，跟AI交流出四套方案，半小时全部生成完，统一输入输出只变算法，四套都跑了一遍选出效率最高的。