当AI 真的进了你的开发团队。那么，谁先被改变？是写代码的程序员？是研发流程？还是组织和管理的方式？

网易智企邀请深圳天石科技的技术负责人秦慧伟，一位天天带着团队写代码、做项目、守生产系统的一线指挥者。与他对话的是网易智企·CodeWave 解决方案专家陈旭。

秦慧伟关心的是整个团队把 AI 用起来之后，交付数据发生了什么真实变化：返工率、缺陷率、新人上手速度，以及团队的分工、士气、加班情况。

"我们从一年多前开始系统性地把 AI 引入研发流程，到今天，坑踩过不少，账也算过几轮。今天就把这些东西原原本本地摆一摆，好的坏的都说。"

流程再造：提效的大头，在编码的前后两头

陈旭：团队引入 AI 之后，最先被改造的是哪个环节？是不是写代码？

秦慧伟：最先装的确实是代码补全类工具，Copilot、Cursor这一类。装得很快，个人层面也确实快。写函数、补单测、抄样板代码，内部测过，单个开发同学的日常产出能提升 20% 到 30%，手快的人甚至觉得自己"翻倍"了。

但很快我们发现一个问题：个人提效，换不来组织提效。一个人写得再快，需求进来还是不清楚，测试还是等人肉，Code Review 还是排队，整条链路堵在中间。写代码的那点速度，最后只是变成了"下游的等待"，项目整体周期根本没动。

所以我们调整了思路：不盯着"写代码"本身，而是把 AI 往编码的前后环节塞。现在回头看，真正提效的大头，反而是下面这几个地方。

第一，需求澄清。让 AI 陪着产品和研发做"自我问答"，把需求掰开揉碎，用EARS那种"当什么发生时，系统应当做什么"的格式，把模糊需求改写成可验证的条目。这一步看起来不快，但它减少的返工是最多的——需求清楚一块，下游全受益。

第二，测试用例生成。需求文档进去，测试用例出来，连测试脚本一起生成。测试同学的编写工作量差不多砍半。

第三，Code Review 辅助。AI 先过一遍，把规范、命名、常见缺陷这类基础问题筛掉，人集中精力看设计和业务逻辑。

第四，存量代码和老系统理解。这个最容易被低估。每家 ISV 都有老系统，没人敢动，新人上手要两个月。现在让 AI 先生成讲解文档、调用链分析，新人理解老系统的速度明显变快了。

第五，文档与知识检索。内部 wiki、历史项目资料接上 AI 问答，找东西不再靠问老员工。

所以这里我可以给一个有点反直觉的结论：大家都以为 AI 插在编码环节，其实提效的大头，在编码的前后两头。

陈旭：那我们把"需求—设计—开发—测试—交付"完整链路走一遍，哪些环节 AI 已经深度融入了，哪些还不敢全放给 AI？

秦慧伟：我按链路顺序一个个过。

需求澄清和拆解：需求文档、用户故事、EARS 条理化，都是 AI 初稿、人来修订确认。

方案设计：AI 出初稿、对比方案，但架构决策、技术选型，最后还是人来拍板。设计错了后面全白干，这个板必须留在人手里。

开发编码：补全、生成、重构都用 AI，但定了条规矩：AI 产出必须过 Code Review 和平台校验，不允许直接合入主干。

测试：用例生成、脚本生成、回归覆盖补充，基本以 AI 为主，人做抽检和兜底。

交付发布：构建、发布按钮、生产环境配置、权限变更，全部留人工卡点，关键操作还要双人复核。

一句话总结：AI 干前半段，人守关键卡点。AI 写得越快，关键位置越要有闸门。否则 AI 造出来的不只是效率，也可能是放大了的风险。

陈旭：有没有实测的提效数据？也请实话实说，哪些环节提效并不明显？

秦慧伟：我给一些数据，都是最近两个季度复盘出来的，口径是大概数，大家听个方向。

需求到原型的周期，以前大概 10 天，现在 6 到 7 天，压缩了 30% 到 40%。这是体感最明显的，因为需求清楚了，开发过程返工少了。

测试用例编写时间，差不多减半。这个对比很干净，数据扎实。

Code Review 的问题前移。AI 先筛一遍之后，首轮评审发现的问题数量下降了大概 40%，基础问题基本在提交前就被拦住了。

新人上手。有知识资产沉淀的项目，新人从入职到提交第一个需求，比以前快了 1 到 2 周。

但我也老实说不均匀的地方：复杂架构设计、跨系统集成这类环节，提效接近零。它靠经验、靠人的判断、靠跨部门协调，AI 目前只能帮做信息整理。

所以我今天的数据，大家听区间，别听神话。提效明显的我给明确数字，提效不明显的，我明确告诉你不明显。

陈旭：这里我想把秦总刚才的关键判断提炼一下。个人工具提效，不等于组织流程提效。只是给团队发工具，AI 散落在每个人的个人 IDE 里，提效靠个人自觉，效果没法汇总，复盘也拿不出报表。真正有效的做法，是把 AI 插进流程，给它带上规则、加上卡点。

这也正是网易智企·CodeWave SDD 的思路：用 EARS 把需求标准化，用 Spec 驱动开发，把 AI 嵌进"需求—建模—生成—校验—发布"这条完整的工程链路，让 AI 成为流水线的一部分，而不是挂在团队外面的一个孤立工具。

秦慧伟：我们现在已经用着一堆工具了，需求管理有系统，发布也有固定流程。CodeWave SDD要接进来，是不是要推倒重来？这个成本对 ISV 来说很吓人。

陈旭：不推倒重来，这是个原则问题。现实路径是增量迁移：先在现有流程里，把最痛的环节嵌上 AI 卡点，比如需求澄清、测试生成、CR 辅助，先跑起来；原有的需求管理系统、工单系统、CI/CD 照常用，通过集成点接进来就行。先挑最痛的一个环节，跑一个 4 到 6 周的小闭环，看到数据再扩，不要一上来就大动干戈。

组织冲击：从"解题"到"出题"，从"救火"到"防火"

陈旭：流程变了，人不会自动跟着变。AI 进了工作流之后，团队配置发生了什么变化？

秦慧伟：变化很直接，我讲三个。

第一，纯编码执行的角色收缩了。以前一个项目一多半人在写代码，现在样板、重复的代码 AI 接过去了，纯执行型的工作量明显压缩。

第二，出现了新分工。现在团队里有人专门做需求建模、写 Spec，有人专门审核 AI 产出。有意思的是，最抢手的变成了能把需求写清楚、把业务规则拆明白的人。

第三，小项目开始一人端到端。以前一个标准小项目要 3 个人，现在一个人带着 AI，能从需求干到发布，另外两个人被腾出来投到别的项目上。

我自己也变了。以前我是那个"解决最难问题的人"，团队技术问题最后都堆到我这儿；现在我主要干两件事：定标准、审 AI 产出的质量。技术负责人的重心，从解题变成出题，从救火变成防火。

陈旭：能力模型变了，现在招人、评人，最看重什么？

秦慧伟：编码能力的权重确实在明显下降，这个我必须承认。现在面试，我更看四样东西：

需求拆解能力。给他一个模糊需求，他能不能问对问题，拆成可验证的条目。这是 AI 时代的基本功。

业务理解。ISV 赚的是懂行业的钱，不懂业务，AI 产出的东西对不对都看不出来。

对 AI 产出的判断力。一眼看出这段生成的代码哪里有坑：权限漏洞、边界条件、性能隐患。

工程规范素养。测试意识、安全意识、发布意识，因为 AI 写得快，规范不好，问题扩散得也快。

陈旭：管理方式怎么变？怎么考核？怎么防止"用 AI 划水"或者"用 AI 藏风险"？

秦慧伟：我们先去掉了一样东西：不考核 AI 使用率，也不考核代码生成占比。 因为这类形式主义指标一考核，团队就表演给你看。简单模块也故意让 AI 生成一下，数字挺好看，实际效率没提升。

我们只看交付结果：交付质量、线上缺陷率、Code Review 一次通过率、返工率。这些指标，AI 演不出来。

然后加了一条流程规则：提交 Code Review 的时候，必须声明 AI 生成范围。哪部分是 AI 写的，哪部分是人写的，讲清楚。评审人对 AI 生成的部分重点看，有的放矢。

再加一层兜底：平台级校验。静态扫描、自动化测试、规范检查，这些机器把关的底线不依赖个人自觉。

所以管理方式是真的变了，从"管代码量"变成"管标准和卡点"。以前问的是写了多少行、加了多少班；现在问的是标准是什么、卡点在哪、兜底机制过没过。

陈旭：团队里有没有阻力？老骨干抵触怎么办？

秦慧伟：有阻力。而且我发现一个规律：最抵触的往往不是新人，是核心骨干。新人没什么包袱，新工具上手快；老骨干会想：我写了十年的架构经验，现在让 AI 来写，那我算什么？这本质上是怕经验贬值。

一开始我们强推，效果很差，表面配合，实际消极。后来换了个思路：不是推老骨干用 AI，而是请他们当"标准定义者和 AI 训练师"。把老骨干的代码规范、架构约束、历史踩坑案例，沉淀成团队知识库和平台规则，让 AI 按这些规则去学、去生成。

AI 相当于老骨干亲手调教出来的"徒弟"，老骨干的角色从"亲自写"变成"带徒弟、审徒弟的活"。这样一来，他的经验不但没贬值，反而变成了团队资产、变成了平台规则，说话比以前更管用了。利益一对齐，阻力就变动力。我们现在平台规则库维护得最积极的，恰恰是当初最抵触的几位老骨干。

陈旭：大家能感觉到，组织变化总是慢于工具变化。工具选型一个月就能完成，组织调整可能要做一年。AI 落地，一半是技术问题，一半是管理问题。所以到这里，答案其实出来了。先被改变的，不是写代码的人，而是先定标准、先做审核、先管卡点的人。团队的形状也在变，从传统的"金字塔"（底层大量人写代码），逐渐走向"小精英＋平台"：少数人定标准、判产出、守卡点，平台承载规则和经验。

落地真相：三分工具，七分流程与组织

陈旭：进入今天最实在的部分。坑和收益。秦总，这部分请一定实话实说，教训比任何广告都值钱。

秦慧伟：最大的坑有三个，都是交了学费的。

坑一：让团队自由选工具、自由发挥。当时我们觉得这样开放，每个组挑自己喜欢的用。结果三个月下来，买了七八个工具，账号各买各的，数据散落各处，安全审计完全抓瞎。更要命的是，大家用法五花八门，规范统一不了，提效也没法汇总，最后要做复盘，报表都拿不出来。后来统一到一个平台加工具白名单，白名单外的一律禁用，才慢慢理顺。

坑二：只看"生成快"，忽略"审核慢"。当时数据很好看，生成效率提了三倍。但 Code Review 还是人肉一行行看，审核速度跟不上生成速度，评审成了最大瓶颈，项目整体并不快。这个坑很隐蔽：看单点数据都很开心，看全链路是堵的。后来补上了 AI 辅助评审加自动校验，才疏通。

坑三：形式主义指标。我们一度考核 AI 使用率、代码生成占比，结果团队开始表演式使用：明明手写更快的模块，也特意让 AI 生成一遍再手工改。数字好看了，效率反而降了，还制造了一堆低质量代码。

这三个坑，其实可以归结成一句话：坑都踩在"把 AI 当银弹"上，以为买了工具，就等于落地了。

陈旭：ROI 怎么算？哪些收益算清了，哪些还没算清？

秦慧伟：分两类说。算清了的，有三个：

重复类项目的交付周期明显下降。我们做同行业客户的切换项目，很多需求类似。把需求模板、组件、行业方案沉淀成资产之后，第二个类似项目，周期至少省 30%。这笔账很硬。

新人上手成本下降。 AI 加上知识资产，新人不用全靠老员工手把手带，从入职到第一个需求提交，比以前快 1 到 2 周。带教成本省了，按人头算得出账。

回归成本下降。 AI 把测试覆盖补上去之后，发布阶段的回归缺陷明显减少。这块省的不只是测试人力，更是发布回滚的风险，出一次线上事故，几个月利润就没了。

没算清的，也有两个：一是架构质量的提升，AI 对长期架构健康度到底有多大帮助，需要更长的观察窗口；二是长期维护成本，AI 生成代码两三年后的可维护性怎么样，还得再看一两年。

所以我的原则是：算清的先算，算不清的先别硬算。但心里要有数。算不清的，可能是大头。

陈旭：如果重来一遍，您会怎么推？

秦慧伟：三句话，顺序不能乱。

统一规范，再推工具。我们当时是先上工具、后补规范，结果返工。正确的顺序应该反过来：先把编码规范、评审规则、安全底线定清楚，再选工具去落实这些规则。工具是承载规范的，不是规范追着工具跑。

先建卡点，再谈提效。卡点不是效率的敌人，卡点让效率可持续。没有卡点的提效，迟早要还回去，而且利息很高。

选一个项目组试点打样，再推广。挑一个需求清晰、负责人愿意配合的项目组，从需求到交付跑一个 4 到 6 周的完整闭环，跑出数据、沉淀经验，再往其他组推。千万别搞全员运动。全员运动声势大，其实最贵，因为相当于让所有团队同时犯错。

陈旭：最后一个问题，给还在观望的技术负责人一句实在话？

秦慧伟：就两句，都是大实话。

第一句：别看 Demo 看交付，别看个人峰值看团队均值。Demo 永远是漂亮的，高手用什么都快，那都不代表组织效率。你要看的，是一群普通水平的同学，用了这套东西三个月之后，交付数据是不是真的好看了。

第二句：AI 落地不是采购一个工具，是一次流程和组织的改造。如果你只做好了买工具的心理准备，我建议先别上；如果你做好了改流程、调组织、重新算账的准备，那现在就可以上。早上车不关键，上对车才关键。

结语：谁先被改变？

陈旭：最后，我们把今天的话题收回来。AI 进了企业开发团队，谁先被改变？

今天聊下来，我的答案是这样的三种人：先动手的人，先沉淀的人，先改流程和组织的人。工具浪潮来的时候，大家的起点其实都差不多，真正拉开差距的，是你比团队先走的那几步。

秦慧伟：我也用三句话收尾。

第一句：先被改变的，不是程序员，是技术负责人的管理方式。管理方式不变，团队发再多工具也没用。

第二句：提效来自流程，不来自工具。工具只是放大器，放大的是你的流程；流程不行，放大的就是混乱。

第三句：先把经验沉淀成资产的人，先赢。个人经验会贬值，沉淀下来的经验会增值。

本文基于网易智企「AI 实战派」系列整理，内容经精编删减。