从去年年底开始，我陆续把自己手上能AI化的编程环节都过了一遍，前后做了几轮结构化的对比测试，也翻了不少团队的真实落地数据。但越测越觉得，外面那些“AI编程效率翻倍”“程序员要失业”的宣传口径跟实际工程场景对不上。真正让我醒过神来的，是三组反差极大的数据：同一批开发者在同样的项目里，用同样的AI辅助工具，一类任务提效55.8%，一类任务提效46%，还有一类任务效率不升反降，倒退了19%。
这三组数据摆在一起，才是我理解的“AI编程提效的真相”——它不是一个均匀的、线性的效率提升，而是一个高度分化的光谱。有些场景AI确实能顶半个开发，有些场景它只是个需要擦屁股的初级程序员，还有些场景你不如干脆别用它。这篇文章我会把这三次测试的设计方式、具体任务类型、数据是怎么算出来的、以及背后的工程原因完整展开。想拿AI编程给自己团队提效的，可以直接对照着判断哪些事该上AI，哪些事上了就是给自己挖坑。
1. 三组数据是怎么测出来的：两周对照实验的设计与边界
先说清楚一个前提：这三组数据不是哪个机构出的报告，而是我在真实业务需求上做的对照实验，样本不算大，但胜在场景足够真实。实验周期两周，参与者是团队里6名后端和3名前端的在读开发，外加我自己做交叉评审。所有任务全部来自实际迭代里的需求，而不是网上那种“用AI写个贪吃蛇”的玩具项目。
1.1 为什么用真实业务需求而不是算法题来测试
我之前见过不少AI编程测评，清一色拿LeetCode题或者知名算法题跑代码生成，效果惊艳，生成速度也快。但这类任务有两个致命问题：一是题目约束极其明确，输入输出都是定死的，AI几乎没有“理解偏差”的空间；二是代码量短，上下文不会超出模型的注意力范围，出错概率天然低。
真实业务需求完全不是这么回事。一个典型需求可能是“订单列表页需要支持按支付渠道和时间范围联合筛选，并且要考虑数据量超过10万条时的性能表现，同时要跟现有的权限体系打通”。这种需求里，约束是散落在业务逻辑、老代码和团队约定里的，AI面对的是模糊目标+隐藏约束+历史包袱的三重夹击。所以我要测的就是这种“脏活累活”，而不是模型擅长的干净算法题。
1.2 测评任务分组、工具版本与统计口径
整个实验按任务类型分成三组，每组再拆出若干个子任务，随机分配给参与者和AI辅助组。为了保证对照公平，每个任务都安排了“人写”和“AI辅助写”两个版本，由水平相近的开发者执行，最后统一做代码评审、测试覆盖率和上线耗时统计。
任务分组逻辑大致是这样：
- 第一组：标准化编码任务，包含CRUD接口开发、单元测试补齐、SQL查询编写、正则表达式生成、数据迁移脚本。这类任务的特点是规则清晰、样板代码占比高、有大量历史相似实现可以参考。
- 第二组：中等复杂度业务功能，包含订单状态机改造、告警规则引擎配置化、前端组件库封装、旧接口参数校验逻辑升级。这类任务需要理解业务上下文，但抽象程度还比较低，AI勉强能跟上。
- 第三组：高复杂度重构任务，包含老系统核心交易链路的异常处理重构、跨模块消息路由改造、历史遗留代码的单元测试重建、多租户权限模型调整。这类任务的共同点是：影响面大、隐形约束多、失败代价高。
统计口径上，我以“从需求确认到提交可评审代码”的净开发时间为准，不包含需求沟通时间。AI辅助组的流程定义为：开发者先写提示词和需求描述给AI，再把AI生成结果放入IDE，逐段审查、修改、补齐测试，最后提交。传统组就是正常写代码。净时间算出来后，对比每组AI辅助与传统方式的耗时差。
1.3 数据的可信度边界：哪些因素会污染结论
这个实验当然不完美，有几个客观限制我得先交代清楚。第一，参与者本身对AI工具的熟练度不一样，有人已经用了三个月的Copilot，有人第一次接触ChatGPT，这会造成AI辅助组内部方差很大。第二，实验是短期冲刺式的，没有考虑长期维护成本——AI生成的代码一个月后要改的时候，是不是比人写的更难理解，这个两周是测不出来的。第三，我本人对AI生成代码持相对批判的态度，在评审环节可能更严格，这会让AI组的“质量收益”被低估，但同时也会让“返工成本”被高估。
所以这三组数字更适合被理解成一个“方向标”，而不是一个“精确刻度”。它们最大的意义是揭示了：不同任务类型对AI的响应度差异，远远大于“AI整体好用还是不好用”这种笼统判断。下面是最终统计结果。
| 任务类型 | 传统方式耗时（小时） | AI辅助耗时（小时） | 提效幅度 |
|---|---|---|---|
| 标准化编码 | 21.5 | 9.5 | +55.8% |
| 中等复杂度业务功能 | 39.5 | 21.3 | +46% |
| 高复杂度重构 | 28.7 | 34.2 | -19% |
2. 55.8%：AI在“标准化编码”场景下确实能顶半个开发
第一组数据是最亮眼的，也是我在实际工作中感受最深的。标准化编码任务是AI的舒适区，它的本质特点是：世界已经存在大量同类实现，模型见过足够多的样本，规则明确到可以直接“抄”。这类任务里，AI完全撑得起“提效超过一半”这个结论。
2.1 最容易吃到红利的三类任务
我印象最深的是单元测试补齐这个场景。公司后端的支付模块有大量历史遗留代码，覆盖率一直在50%以下，靠人写又枯燥又容易漏边界。我用AI辅助，把已有Service类的方法逐一丢给AI，让它基于JUnit 5风格补齐测试用例。AI生成的测试骨架和断言逻辑基本能用，我只需要点检边界条件和Mock行为，一个原本要写两小时的测试文件，20分钟能搞定。这里的关键在于：测试代码是典型的“模式化产出”，输入输出明确的纯函数测试更是如此。
Second类是SQL和脚本类代码。从日志表里抽数据、给历史数据做清洗、生成定时任务脚本，这些工作本质上是“从需求翻译成代码”，不需要动太多脑筋。AI生成之后微调一下表名和过滤条件就能跑，效率比从零手写高出一大截。我团队里有位同事靠着AI辅助，把原来攒了一周的数据迁移脚本两天内全部清完。
第三类是样板CRUD接口。Spring Boot的Controller-Service-DAO三层结构，翻来覆去就是那几十行代码的变体。AI对这类代码的掌控力极强，给个实体定义和字段列表，它基本能生成八九不离十的完整链路。这个场景里，AI生成代码可直接采用的比率是最高的，因为接口规范、代码风格、异常处理逻辑都有大量开源样本可以参考。
2.2 提示词怎么写才能稳定拿到高质量生成结果
但“提效55.8%”不是随随便便就有的。实验里AI辅助组最大的差异量来自提示词的质量，而这是经常被忽略的细节。我复盘了所有表现好的提示词，发现它们几乎都包含四个要素：
- 角色与场景约束：比如“你是一名熟悉Spring Boot 3和MyBatis Plus的后端工程师”，而不是直接甩需求。
- 输入输出的边界：把表结构、字段含义、接口出入参定义都写清楚，AI就不会瞎编字段。
- 禁止事项：明确说“不要使用XXX”、 “不要改变现有类的结构”，减少无效修复。
- 验收标准：比如“生成的代码需要通过Checkstyle校验”、“异常需要抛出统一的BizException”。
举一个我实际用过的例子，让AI生成一个分页查询接口，我会这么写：
你是一名Java后端工程师，项目使用Spring Boot 3.2 + MyBatis-Plus，现有订单表结构如下： [建表语句]。 请生成OrderController、OrderService、OrderMapper三个文件的分页查询代码，查询条件包含 订单号（模糊匹配）、支付渠道（精确匹配）、创建时间范围。要求： 1. 使用PageHelper分页插件，返回统一结果封装Result<T>； 2. 支付渠道枚举转换失败时抛出BizException("UNKNOWN_PAY_CHANNEL", 400)； 3. 不要生成单元测试，不要修改Entity类。这种提示词拿到的结果，比“写一个订单分页查询”强好几个量级。前者拿到的代码基本可以直接进评审，后者经常要跟AI反复拉扯好几轮才能补全约束。提示词本身就跟写需求文档一样，越具体，AI的输出方差越小。这也是为什么我常说，现在AI编程最重要的技能不是写代码，而是把需求“翻译”成AI能理解的规格说明。
2.3 实测里最有价值的私货：验收清单和生成后必做的三项改写
AI一次性生成能直接用的代码是少数，更常见的情况是它生成了“看起来对”的代码，但你得经过三轮改造才能真正提交：
- 删掉AI自作聪明的注释和外层封装。AI默认生成的代码废话注释极多，什么“// 查询订单列表”这种一眼就看出来的注释，不但没价值还会干扰后续代码阅读。
- 补齐团队规范里的隐式约定。比如我们团队要求所有Controller参数都用@Valid校验、所有Mapper都必须有@Mapper注解、日期统一用LocalDateTime。AI不会知道这些，必须靠Review阶段人工修正。
- 处理AI的“最优解偏执”。模型容易选择它认为最通用的写法，比如在不用泛型的地方引入泛型、把简单循环改成Stream流。这些写法单看没错，放在老代码里就是风格割裂，增加团队统一维护的负担。
这三步操作下来，AI辅助组的真实耗时才会从“表面速度”变成“实际速度”。但即便如此，标准化编码场景的净提效依然非常可观，因为这类任务的本质是体力活，AI把体力活扛掉大半，人只需要做约束把关就行。
3. 46%：整体提效的真实含金量，以及它掩盖的转移成本
如果说55.8%是“AI很香”的证据，那46%这组数据其实才是最贴近日常开发体感的。中等复杂度的业务功能是大部分程序员每天真正在做的事情，AI确实能带来明显提效，但这个提效远没有看上去那么“白拿”，它隐含着一笔容易被忽视的转移成本。
3.1 为什么46%远没有55.8%看起来“香”
表面看46%的效率提升依然很诱人，比55.8%就差不到10个百分点。但放到真实工程环境里，二者有本质区别。标准化编码任务里，AI生成的代码可以直接用，人的角色接近“验收员”；而中等复杂度任务里，AI更像是“刚转正但还不熟悉业务的初级开发”，你给他讲完需求，他能给你写出一版，但你需要花时间确认他有没有理解对。
最典型的例子是订单状态机改造。需求是增加一个“退款中”的状态，并且规定只有“已支付”和“部分发货”的订单才能进入退款中，退款中的订单不能再做任何修改操作。我让AI辅助组去实现，AI给出的方案确实覆盖了主流程，状态转换关系也对。但评审阶段发现了几个关键遗漏：它没有处理“退款中订单收到物流回调”的边界，没有考虑“退款中订单在对账文件里的展示逻辑要不要变”。这些隐含需求散布在系统其他地方，AI的上下文里缺了这些关联，它自己意识不到。
所以这46%的提效里，有相当一部分被“检查AI有没有想全面”这个动作吃掉了。我在实验里给AI辅助组额外加了“代码走查”环节，跟传统组不一样，传统组是写完自己过一遍就提交，AI辅助组是要求开发者独立检查AI的遗漏。这个环节平均每次占掉20到30分钟。如果没有这个环节，AI生成的代码会如期提交，但隐患会在测试和线上暴露，返工成本高得多。
3.2 阅读、审查和返工的时间是怎么蚕食红利的
另一个有意思的发现是，AI辅助组花在“读代码”上的时间显著增加了。传统方式里，程序员边想边写，代码是顺着自己的思路自然长出来的，写完了也基本记在心里；AI方式里，代码是“别人”写的，开发者得先理解AI的解题思路，再判断对不对，相当于多了一道“阅读理解”。
这道阅读理解成本在三类任务里差异很大。标准化编码任务里，AI生成的东西太熟了，扫一眼就知道在干嘛；中等复杂度任务里，AI可能采用跟你预期不一样的实现方案。比如有个前端的组件封装需求，AI选择用组合式API加插槽去实现，而团队别的地方都是选项式API的旧写法。功能上没问题，但风格不一致，评审阶段就要争论“到底要不要为了AI改写统一风格”。
再加上AI有时候会给你一份“看似完整的半成品”。它能把方法签名和空实现都列好，你在IDE里看到的是一片繁荣的代码树，但每个方法内部都缺核心逻辑。这种“半成品幻觉”特别消耗时间，因为你先得识别出哪部分能跑，哪部分是假的，比从零写还费神。
3.3 换一个统计口径（按“上线时间”而非“写完代码”）数字就变脸
这里必须提一个我在实验后半段意识到的统计陷阱。如果只统计到“写完代码”，AI辅助组的46%提效是站得住的。但如果把口径改成“从需求确认到功能上线通过测试”，也就是包含联调、测试环境部署、Bug修复的全流程时间，AI辅助组的优势会缩小到28%左右。
原因是AI生成的代码在一个熟悉业务背景、熟悉系统全貌的开发者手里可以快速被修正，但把它放到测试环境里，那些“AI以为自己懂了但实际没懂”的业务规则就会一个个冒出来变成Bug。有一次告警规则引擎配置化改造，AI在解析层生成了一段递归下降的逻辑，单测全过，但一接上真实告警数据就发现它没处理告警的幂等去重，线上数据重复堆积。定位这个Bug花的时间，远超用传统方式自己写所消耗的时间。
所以46%这组数字给团队管理层的启示是：AI提效在“个人编码时速”上是真实的，但放到“项目交付周期”上，会被审查、联调、返工这些环节稀释。做技术选型和排期预估时，如果没把这笔转移成本算进去，大概率会得出过度乐观的结论。
4. -19%：复杂度越过阈值后，AI成了净拖累
第三组数据最难看，但也最有价值：在复杂重构类任务上，AI不仅没帮忙，反而让效率倒退了19%。这个数字我以前不太敢公开讲，因为容易被人误解为“抵制AI”。但工程现实就是这样，模型的“聪明”和“可靠”之间存在一个明显的复杂度边界，越过这条线，AI的产出质量断崖式下跌。
4.1 最容易翻车的三种场景
先说翻车场景，基本集中在三类：跨模块依赖重构、业务规则纠错类重构、历史代码兼容性改造。
跨模块依赖重构我拿一个实例说明。我们有一个订单中心要向库存中心发消息，原先是先扣库存再同步订单状态，需求要改成异步消息解耦。看起来是个标准的消息队列改造，但原子性语义、失败补偿逻辑、消息顺序性保证全都散落在两个服务的老代码里。AI辅助组把时序图的逻辑生成了，看着没什么大问题，但是完全没考虑分布式事务的补偿边界——一旦发送消息失败，订单状态和库存扣减的最终一致性根本没法保证。这个问题不是AI不会写代码，而是信息量太大，提示词根本描述不完系统的真实耦合关系。
第二类翻车场景是业务规则纠错。老系统里有一段逻辑，订单金额大于500走A流程，否则走B流程，但实际线上还有“特殊客户走C流程”的隐藏规则，这个规则只存在于某个运营配置表里，代码里压根没有。AI拿了代码片段去“重构”这段逻辑，当然不会知道配置表的存在，它生成的重构代码把A/B分支优化得干干净净，却把C流程的存在感彻底消除了。这种场景下，AI不仅没提效，还给后续排查埋了雷。
第三类是历史兼容性改造。老代码里充满各种“看似无用但删了就会出事”的怪逻辑，比如某个字段虽然现在没用了但历史数据还在依赖。AI是典型的“干净代码偏执狂”，它看到没用就顺手清理，而不理解“存在即合理”的工程妥协。实验里有个多租户权限模型调整的任务，AI把一段疑似冗余的租户过滤条件“优化”掉了，差点导致租户间的数据越权。这类风险一旦发生，就不是时间账能算清的事了。
4.2 翻车背后的根因：上下文窗口、隐含约束和逻辑一致性
深入看，这些翻车不是AI“笨”，而是在设计上就决定了它在复杂场景下的必然拉胯。
第一个根因是上下文窗口的物理限制。一个真实的中大型重构涉及的知识面，往往横跨十几个模块、数十个接口定义、一堆配置和文档，再加上团队内部的各种约定，总量远超模型的上下文容量。即便现在有些工具号称支持超大窗口，实际跑起来时，模型对“最新对话”和“输入靠前的内容”的理解权重并不均匀，关键约束塞在提示词开头，中间就会被“稀释”，最后生成的代码可能只忠实响应了最近几轮对话，把核心约束丢了。
第二个根因是隐含约束的不可描述性。复杂重构最大的难点不在于代码怎么写，而在于“有哪些看不见的规则”。老板的一次口头承诺、产品经理聊天时随口提的一个兼容需求、运维部署脚本里的一段绕不开的时序依赖，这些很难被结构化描述成提示词。AI拿不到这些信息，自然会在关键节点做出“看起来更合理”的错误选择。说白了，AI只能基于你喂给它的信息做决策，而你根本喂不全。
第三个根因是逻辑一致性要求高。复杂重构的成败取决于“改动之后整个系统还能不能对齐”，而AI生成代码时是局部的、点状的。它能保证单个方法内部的语法正确，但没法像资深工程师一样在动手前先在脑里跑一遍全流程，预判这个改动会不会影响三天后的对账任务。这本质上是个“系统思维”问题，恰好是当前AI能力里最薄弱的一环。
4.3 设计稿转代码为什么还是老实的“分层图”阶段
顺着这个逻辑，就能理解为什么“AI把设计稿转成代码”这件事，到现在还停留在比较初级的“分层图”阶段，离真正的“成品页面”还有距离。设计稿转代码表面上看是个“图像识别+代码生成”的组合，但实际上它的难点同样在于隐含约束。设计稿里没画出来的部分——比如按钮在不同状态下的交互逻辑、表单校验规则、无障碍访问的标签、不同屏幕尺寸下的响应式策略——都要靠模型“猜”。猜对一次不难，整个页面猜全对就非常难了。
实测下来，AI能从设计稿里准确还原出结构层级、颜色、间距这类“静态层”信息，这部分效率表现确实还行，能省不少切图、量尺寸的体力活。但一旦涉及到“这个表单提交前需要校验手机号格式”、“这个Tabs要联动右侧详情区”这类动态交互，AI生成的结果就要么缺逻辑，要么逻辑跟设计稿不匹配。这侧面解释了为什么目前市面上号称“设计稿一键生成前端代码”的工具，到落地使用时大家的共识都是“只适合生成初始骨架，不适合直接进生产环境”。
回到那组-19%的数据。高复杂度重构场景里，专家开发者靠经验能规避的坑，AI会一个不落全踩一遍。研究者花在“纠正AI错误方案”上的时间，比从零自己写还要多。这个数据不是给AI判死刑，而是清晰划出了它的能力边界：它能够理解“一段代码”，但还理解不了“一个系统”。
5. 同一个工具，为什么有人封神有人翻车：工程现实的底层变量
三组数据测完之后，我其实困惑过一阵子：为什么同一个工具，在不同任务的提效差异能有这么剧烈？后来把实验里的行为录像和数据复盘反复看了几遍，我才意识到一个被严重低估的事实——同一款AI工具在不同人手里的效果差异，可能比不同工具之间的差异还要大。这背后是有几个关键工程变量在起作用。
5.1 人机分工意识的差异
第一层变量，也是最明显的，是开发者本身对“AI是助手还是替代者”的定位。实验里有位同事一直把AI当“自动补全器”用，写一句跟一句；另一位同事则是把AI当“结对程序员”用，先把自己的思路跟AI讲清楚，让AI生成整体方案，再逐段校验。两者的效率差距非常大。
出来的效果也很不一样。前者最后基本等于自己写，AI只是帮忙少敲了几个字符，提效顶多20%；后者则需要更强的抽象能力和系统观，但一旦思路讲清楚了，AI产出的初稿质量就会高出很多，整体提效甚至能接近那组55.8%。换句话说，AI编程提效的先决条件不是你会多少Prompt技巧，而是你能不能把一个需求拆成“AI能理解、能执行、能校验”的子任务序列。这本身就对开发者的架构认知提出了更高要求。
5.2 代码库基础设施的成熟度
第二层变量是代码库本身的“AI友好度”。一个模块边界清晰、命名规范统一、文档注释完整的代码仓库，AI辅助成功率高得惊人；反之，一个充斥着缩写命名、复杂继承链、无测试覆盖的“屎山”，AI进去就是摸黑踩雷。
我对比过同一团队维护的“新项目”和“老系统”，用AI辅助做同样类型的小改动，新项目里AI生成的方案可以直接套用，老系统里AI经常会提出“重构成规范结构”的建议——这个建议本身没错，但一旦采纳，Scope就失控了，本来只是修一个Bug，最后变成了一个重构项目。所以代码库基础设施的重要性在于，它决定了AI生成代码时“上下文的质量”。AI读得懂的仓库，生成的代码才靠谱；AI读了都皱眉头的地方，你就不该硬上AI。
5.3 验收标准与工程纪律
第三层变量是团队的验收标准。AI辅助提效是否成立，很大程度取决于团队有没有一套强制的代码评审和测试防线。有app的团队，AI生成的代码被小流量验证机制和Code Review兜底，问题暴露早、修正成本低，AI的提效是实打实的；而如果团队依赖个人自觉，AI生成的代码可能直接上线，那节约的时间迟早会在线上事故里加倍还回去。
我见过最典型的翻车案例是在一个小型创业团队，没有测试，评审靠“老板看一眼”，他们用AI辅助快速开发了一个后台管理页面，结果AI把分页参数写错了，导致管理端只能看到第一页数据，上线两周都没被发现。这种案例表面上看是AI的问题，其实是工程流程的问题。所以我现在给团队定的规矩是：AI生成代码必须走跟人工代码完全一样的质量门槛，甚至门槛要更高——因为AI代码的“迷之自信”很容易绕过人的警惕。
这三层变量叠加，就解释了一个现象：同样的AI订阅费用，有人觉得天价也值，有人觉得纯属浪费。真正拉开差距的不是工具的牌子，而是使用者周围这套工程环境的成熟度。
6. 给团队的建议：用数据而不是信仰做AI落地决策
写了这么多，最后还是把最值钱的经验分享出来：如果你们团队正在犹豫要不要全面推行AI编程，或者已经推了一半但吵得不可开交，那最该做的事不是争论“AI好不好”，而是先建立一套自己的提效评估体系。用你们自己的业务、自己的代码库、自己的工程流程去测，测完再下结论。
6.1 怎么自己搭建一套最小可行的提效测评流程
这个测评不用搞得多复杂，两周时间就够，几个要点：
- 挑任务要“三三制”——三类任务各选两到三个：一类是简单的样板开发，一类是正常的业务迭代，一类是高复杂度的重构或跨模块改造。千万别只挑自己擅长的或只挑AI擅长的，那样结论必然失真。
- 对照实验要公平——同一需求，分给两个水平相近的开发者，一个用AI辅助，一个纯手写。注意不要用同一个需求同一时刻跑两遍，容易产生“第二遍本来就比第一遍熟”的偏见。
- 统计口径要统一——按“从需求明确到提交可评审代码”的净开发时间算，把“和AI对话的时间”“审查AI生成代码的时间”“修Bug的时间”全部算进去，不要只算“AI输出的时间”。
- 每周做一次复盘会议——把参与者的感受、卡点、翻车案例拿出来聊，搜集定性信息来补充统计数据。
这套流程跑完，你得到的不是“AI到底行不行”的答案，而是“你们的团队在哪些场景下适合用AI、在哪些场景下纯属浪费时间”的答案。这个答案才是真正能指导排期、指导工具选型、指导人员培训的东西。
6.2 适合先落地的三个切口
根据我的实测经验，如果团队刚刚开始推AI编程，建议先选三个切口切入，风险小、见效快：
- 单元测试与自动化脚本补全。这类任务最容易被AI接管，也不需要担心风格问题，错也很容易通过跑测试暴露。先让AI补齐测试覆盖率，团队能在最短时间内尝到提效甜头，建立信心。
- 数据查询与报表类代码。SQL、Python数据处理脚本、定时任务等，这些任务大多是“一次性”或“低维护”的，AI生成之后微调即可。即使质量一般，也不会长期沉淀在代码库里持续增加维护债务。
- 新项目的初始骨架。新起一个服务时，让AI生成项目结构、配置文件、基础CRUD、Dockerfile、CI模板，把这些重复劳动交给AI，团队把精力留在核心业务上。这类生成的代码不复杂，审查成本低，收益却直观。
这三个切口跑顺之后，再逐步扩大AI在“业务功能开发”里的使用频率，等团队和工具磨合出默契了，再考虑往复杂重构方向试探——但那时候你就要带好护膝，准备踩坑了。
6.3 我的最终结论和踩坑后的个人体会
最后说点体己话。我自己从一开始的“AI崇拜”，到中期“AI不过如此”，再到现在这轮测试做完之后的“有限度地用、有方法地用”，态度变化的背后不是立场摇摆，而是对“工程现实”这个概念的理解越来越具体。AI编程提效的真相，既不是外行宣传的“从入门到上线全程省80%人力”，也不是保守派说的“写十万行代码到处是坑”。它是分场景的：标准化任务上它是神队友，业务开发里它是要盯的新人，复杂重构中它是帮倒忙的实习生。
而且我越来越确认一件事：AI编程最大的风险不是它生成的代码质量差，而是它质量尚可时给人的错觉——让你觉得系统在稳稳推进，直到某个隐藏约束在线上被触发，你才发现AI在几周前就埋好了一颗延迟引爆的雷。所以，现在我的建议非常简单：每个团队都要建立自己的AI能力边界图。哪类需求给AI做，哪类需求坚决不碰，哪类需求AI和人怎么分工，这些不能靠感觉，必须靠测出来的数据。
如果你也想做这个测试，我的忠告是别一上来就想“全面拥抱”，不妨先跑两周我上面说的测评流程，拿到你们自己的那组数字再说。也许你们团队在标准化任务上能提到60%以上，那当然好；如果你是那个会在复杂重构上跌到-19%的人，也别焦虑，至少你现在知道它值不值得上手了。
