三个阶段的组织形态组织改造经历了两个阶段还有一个是目标状态。第一阶段就是刚才过去式职能式分工已经说过了。第二阶段是现在已落地的状态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把脑子里的东西讲出来就行不用自己做PPTAI帮你做。这给持续培训提供了一个可行的基础。正式切换第9-11步第九步历史工作交接这一步和每个公司自己的情况强相关千差万别。我们作为产品加定制化交付的ToB公司面对不同客户各有各的版本在维护。有的项目在研发中有的在运维中。以前一个团队八九个人甚至十来个人现在每个团队5个人老项目和新团队怎么匹配项目跟着PM走还是跟着研发走一个项目好几个研发分到不同的FDE里怎么拆交接过程怎么保证不出大问题这些事情比较复杂只有一个通用建议根据自己实际情况出方案同时心里要知道一定会出问题要能接受出现问题。我们这边做了大概交接调整了一个半月。核心原则是老项目原班人马维护、跟着研发人员走新项目用新模式不会强行切。做之前先给客户打好招呼出了问题客户有预期就不会有太大反应。第十步组织正式调整两个试点项目都收尾后分别做了详细复盘整理所有问题做了一波流程和skill的改动补充了培训。到这个时候成立新部门就顺理成章了。具体动作就是发通知、调座位。但光行政命令不够做了两件事让新的PM和自己新的团队成员做一对一沟通我本人也对每个人做了一对一沟通确认岗位情况、转岗适应度、有没有顾虑和期望做针对性解决。第十一步按新组织持续运转搭了Token分发平台做统一管理监控谁用得太少、哪些FDE团队Token消耗过低。发现这种情况主动干预和沟通让它们尽快用起来。给用得多的做奖励但不能提前通知有奖励也不能反复奖励。用Token衡量工作本身不太合理只是初期用来判断谁对AI不熟做人为干预。新小组启动了陪跑机制每周找时间和各小组交流半小时到一小时了解问题、解决问题。绩效也重新设计了每个公司做法不同就不展开。最后还是Harness的持续改进每个小组交付完都做复盘看有没有新的想法可以在公司范围内优化。踩过的坑坑1多人协作比单人难十倍单人用AI写代码很流畅多人协作问题全暴露变更怎么管、工作怎么同步。以前的节奏是开晨会对接工作AI提速后半天就能产生比以前大得多的工作量晨会根本跟不上。目前的解法是缩小组织粒度从条状变块状。每个项目人很少坐到一起转身就能沟通很多问题当面解决。但这只解决了沟通这一个层面多人协作在AI时代的最佳实践还需要在持续实践中探索。坑2AI不稳定要持续迭代换了模型同一套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工具对他就是摆设。坑6Harness依赖人的能力实习生用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。QBug率变化了Abug率提高了大概60%。但bug类型完全不同了。古法编程时功能逻辑和体验优化问题占比最大现在占比最大的是功能遗漏和UI不一致。逻辑问题反而少了。从严重程度看重要和核心的bug其实很少一般性问题特别多。Q用的什么模型A主要是智谱的GLM-5.1和Kimi 2.6。体感上智谱比Kimi好一些。国产模型在coding场景已经够用了更重的工作在Harness工程上只要模型不是特别拉胯Harness做得好就行。用过Claude但买不到稳定账号被封了两次就放弃了。Q全自动化行不行A试过。用go模式批量生成所有功能的需求、设计、代码结果全是问题天天都在用bug调试技能改。现阶段模型能力至少国内模型还到不了交给人就不用管的程度中间必须有人去干预和检查。另外自动化程度越高人对项目的理解就越浅出了问题没人负责。所以流程中有一部分是自动化的开发环节但需求和需求产物交给开发、开发产物交给测试这些环节还是人来驱动。