从“一行补全”到“一整个函数被接受”，写代码的方式确实变了。GitHub 在 2022 年公开过一项对照实验：95 名开发者实现同一个 HTTP Server 任务，使用 Copilot 的组比对照组快 55%。出处：GitHub Blog《Research: quantifying GitHub Copilot’s impact on developer productivity and happiness》，2022-09-07，https://github.blog/2022-09-07-research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/。
先说明一个方法问题：AI编程采用率的公开调查口径差异很大，有的统计“用过一次”，有的统计“每天使用”，单看百分比容易误导。下文不纠结具体的采用率数值，只看四个环节的使用结构差异。
这个 55% 的实验结果经常被用来证明 AI 编程效率，但它只覆盖了一件事：按描述把代码写出来。没有覆盖代码上线半年后的维护成本。工程的真实评价指标不是“写出来多快”，而是“改动一次要多久”。AI 编程是辅助还是替代，先要看四个环节的采用率，以及采用率背后的边界。
从四个环节看采用率：代码补全领先，语义层靠人
代码补全的采用率最高，主要原因是侵入性低，不是生成质量最好。Tab 一下，不满意再 Tab 一下，纠错成本发生在写代码的同一时刻，开发者随时可以介入。
单元测试生成明显没那么普及。工具确实能根据当前代码生成用例，但生成逻辑容易顺着实现走：“实现错了，测试也跟着错”。测试本来应该固定期望行为，AI 生成的测试固定的是“当前代码行为”。开发者如果发现几次“测试全绿但需求没被验证”，就会把断言逻辑收回到自己手里，只让 AI 做数据构造和边界补充。
代码审查排得更靠后。Copilot Code Review、CodeRabbit、Qodo 都有自动审查能力，使用率却没有补全高。审查是语义密集型工作：一个改动有没有破坏跨服务约定、有没有引入数据一致性风险，这些信息大部分不在 diff 里。AI 只看 diff 时，给出的大多是“缺少错误处理”“命名可以更清晰”这类通用提醒，真正值钱的判断还是依赖人。
重构要拆开讲。语法层重构，比如重命名、提取函数、统一 import，AI 可以自动完成，IDE 的传统重构功能也够用。语义层重构，例如把同步调用改成异步、把本地缓存换成 Redis，AI 能生成一份看起来 API 没变的代码，但并发行为、缓存失效策略、异常路径都可能不一样。这样的代码一旦被合入，问题通常在流量上来后才暴露。
四个场景放在一起，边界就清楚了：越靠近语法层，采用率越高，自动化越安全；越靠近语义层，采用率越低，人工兜底越不能省。
“看着很快，改起来更久”：隐性成本藏在生产环境里
一个典型场景是时间处理。开发者让 AI 修一个到期时间格式化问题，AI 很常见的输出是：
def format_expire_time(raw: str) -> str:
dt = datetime.fromisoformat(raw)
return dt.astimezone().isoformat()这段代码在开发机本地跑，大概率没有问题。如果 raw 的值来自数据库，并且数据库存的是 UTC 时间，astimezone() 会以 Python 进程的本地时区为基准来转换。在 UTC+8 的机器上，结果会比预期多出 8 小时。
AI 不缺少 datetime 的语法知识，它缺少的是一个上下文判断：存储的时间到底是 UTC 还是本地时间？这个信息往往不在当前打开的代码文件里，可能在建表脚本、服务启动参数、或者另一个服务的接口文档中。AI 补全那一行只花了几秒，开发者排查整个报错链路时，要把存、取、展示三层时区逻辑重新读一遍。生成成本越便宜，这部分修复成本就越贵。
这类问题不是个别工具的问题，而是 AI 生成代码的三个结构性弱点：
- 上下文缺失：单文件补全看不到调用链、部署环境、数据库方言。
- 语义假设：它倾向于把“看起来能跑”当作“行为正确”，空值、时区、舍入、并发都是重灾区。
- 测试同源：它给自己的实现写测试时，测试和实现共享同一套错误假设。
写代码正在变成审代码：初学者的训练场被抽走了
团队里感受最直接的，可能不是资深开发者，而是刚开始接触业务系统的初级开发者。以前从需求到函数，需要自己走一遍：查字段含义、看接口文档、写分支判断、跑测试验证。现在 AI 直接给出几十行代码，初级开发者的工作变成“审”。问题是，审的前提是知道正确行为是什么。对一个还没理解业务的初级开发者来说，一段风格良好的 AI 代码和一段隐患代码，看上去并没有区别。
代码产出不再稀缺，验收变成瓶颈。团队结构因此出现一种变化：AI 负责产出初稿，初级开发者负责验证和修补，资深开发者负责定义“什么叫正确”，并把验收规则固化成检查项。若这个规则缺失，AI 编程带来的就是更快的错误代码进入主分支。
团队工作重心的变化比个人能力问题更值得关注：AI 把任务从“生成代码”推向了“验证代码”。谁对系统行为边界更清楚，谁就掌握最终决定权。
可落地的策略：三类任务，三种自动化程度
| 任务类型 | AI 适合做什么 | 人工必须做什么 |
|---|---|---|
| 机械重构 | 修 import、重命名变量、格式化 | 检查改动范围，跑全量测试 |
| 样板代码 | 根据 OpenAPI 生成 DTO、客户端桩 | 核对协议字段和兼容性 |
| 业务函数 | 生成初稿、列边界情况 | 确认业务规则，补异常分支 |
| 单元测试 | 生成测试数据和边界值 | 先确定期望行为，再决定断言 |
| 代码审查 | 找局部空指针、资源未释放 | 看跨服务影响和数据一致性 |
| 安全敏感逻辑 | 解释漏洞原理、给修复方向 | 人工验证攻防路径，禁止直接合入 AI 修复 |
这份检查单可以当团队的合入门禁用：
- 把 AI 生成的测试保留，删除函数实现，测试真的会失败吗？不失败，说明测试没有锁住行为。
- 时区、空值、并发、金额精度这类隐含语义，有没有指定负责人确认？
- 是否存在一个不依赖本次 AI 实现的独立测试？
- 支付、权限相关改动，是否经过第二人手工复核？
- 对 diff 里的每一段，你是否都能解释清楚“为什么必须这么写”？
参考来源：GitHub Blog《Research: quantifying GitHub Copilot’s impact on developer productivity and happiness》，2022-09-07，https://github.blog/2022-09-07-research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/。本文引用仅代表该实验设置下的短期任务速度，不代表所有软件工程场景。