AI 让"写"变快了，但没让"验证"变快——这个缺口就是所有问题的来源。这一页用实测数据说清缺口在哪，再给能照做的补法。
2025–2026 年几份独立研究指向同一件事：AI 让代码产出变快了，但代码库的可维护性在变差，交付的不稳定性在上升。
这不矛盾——它加速的是"写"，没加速"验证"。 你个人感受到的是前者，代价落在后者，而后者的账要几个月后才结。这一页第一节摆数据（都标了出处），第二节讲缺口在哪，第三节是能照做的工作流，第四节是 Claude Code 的具体用法。写这一页的是 Claude，第四节等于在推荐自家工具，这个利益冲突请见页末灰框。
Google 的 DORA《2025 State of AI-assisted Software Development》报告：90% 的技术从业者在工作中使用 AI，超过 80% 认为它提升了自己的生产力。 报告确认 AI 采用度与交付吞吐量正相关。
但同一份报告的另一半常被略过：AI 采用度同时与交付不稳定性正相关——变更失败更多、返工更多、问题解决周期更长。
报告给出的解释很关键：AI 加速了开发，而这个加速会把下游的薄弱环节暴露出来。 缺少强自动化测试、成熟版本控制和快速反馈的团队，变更量一上来就会失稳。瓶颈被推到了测试、评审和质量保障那一段。
AI 是放大器,不是修复器。 团队的流程本来就弱,AI 会让弱点更快地暴露出来——这跟《写出高质量代码》里"没测试的项目只是更快地欠债"是同一件事,只不过现在有了行业级的数据。
2025 年 Stack Overflow 开发者调查里有一组很说明问题的数字：
- 84% 的开发者在用或计划用 AI 工具（2024 年是 76%）——采用率在涨 - 46% 表示不信任 AI 输出的准确性（上一年是 31%），只有 29% 表示信任，仅 3% 是"高度信任"——信任度在跌 - 66% 报告最大的困扰是答案"几乎对，但不完全对" - 45% 说调试 AI 生成的代码很费时间
"几乎对"是最坏的一种错误形态。 完全错的东西一眼能看出来、立刻丢掉，成本很低；几乎对的东西会通过你的初步检查、通过 review、进到生产环境，然后在某个边界条件上出事。
生成的代码跑起来了，主流程也对。 但并发情况下有问题——这类要到线上才暴露。
用了一个真实存在但语义略有差别的 API。 名字对、签名对、行为差一点。
边界条件处理得"看起来合理"。 空数组返回了 0 而不是抛错,而你的业务需要后者。
改完之后测试全绿。 但测试是它自己写的,断言的是它自己的理解。
这是最反直觉的一份研究。METR 在 2025 年 7 月发布了一项随机对照试验（RCT，临床药物试验用的那种设计）：16 位有经验的开源开发者、246 个真实任务、成熟的代码仓库，工具是 2025 年 2–6 月间可用的 AI（主要是 Cursor Pro 配 Claude 3.5/3.7 Sonnet）。
结果：允许使用 AI 时，他们完成任务慢了 19%。
更值得记住的是第二个结果：这些开发者事后仍然估计 AI 让他们快了大约 20%。 亲身经历了变慢,感觉却是变快——感知与实测之间差了将近 40 个百分点。
必须同时说明这项研究的局限：样本只有 16 人；对象是对自己代码库极其熟悉的资深开源开发者（这类人本来就是 AI 帮助最小的群体）；用的是 2025 年上半年的工具。METR 自己已把该结果标注为历史性结论，并在 2026 年 2 月宣布调整实验设计。所以别把"AI 让人变慢"当成普遍结论——它不是。
但那个感知偏差的意义超出了具体数字：你"觉得"AI 帮了多少忙，不能作为判断依据。 因为你能直接感受到的是"代码出现得很快"，感受不到的是等待、审查、返工和后续修复的时间。
别靠感觉评估。挑一类你常做的任务，记录几次真实耗时（从接到任务到合并),用 AI 和不用 AI 各几次。你们团队自己的数据,比任何研究都有用。
GitClear 与 GitKraken 分析了 2023 至 2026 年间 6.23 亿次真实代码变更（AI 辅助提交已占全部提交的约四分之一），结果指向的不只是"质量下降",而是工程行为本身在转向：
- 修改老代码的比例暴跌：改动中"更新或删除 12 个月以上未被触碰的代码"的占比,从 2023 年的 1.7% 降到 2026 年至今的 0.46%——跌了 74% - 复用在减少：跨文件函数调用（复用的标志）下降 35%,重构性的代码行移动下降 70% - 复制粘贴在增加：复制粘贴代码占新代码的比例从 2022 年的 9.4% 升到 2026 年上半年的 15.7%；而经过正确重构的"移动代码"从 21% 掉到 3.8% - 代码块重复 +81%、提交内复制粘贴 +41%、错误掩盖式写法 +47%、两周内返工 +15%
把这些数字连起来看，讲的是一个很具体的行为变化：让 AI 生成一段新代码，比让它理解并安全地修改一段老代码容易得多。 于是人们（在压力和便利的共同作用下）不再去动老代码，而是复制一份新的。
这才是 AI 对代码库最深的影响——它不只是让你写得更快，它在悄悄改变你选择怎么解决问题。
把它变成一条 review 时的自问："这段是不是本该改老代码,却新写了一份?" 这个问题在 AI 时代的价值,远高于纠结缩进和命名。
Veracode 设计了 80 个编码任务（对应 MITRE CWE 常见缺陷），让 100 多个大模型完成,每个任务都同时存在安全和不安全两种写法：
模型在 45% 的情况下选择了不安全的那种写法。 平均安全通过率 56%,与上一年报告几乎持平——也就是说,模型能力在涨,安全性没跟着涨。 按语言看,Java 最危险,失败率超过 70%。
拼接 SQL 而不是参数化。 经典注入,而生成的代码常常"能跑"。
输出到页面时没做转义。 XSS 的常见来源。
用了不该用的哈希算法、或者自己实现加密。 加密代码"看起来对"和"真的对"差得极远。
权限校验漏了一层。 主流程测得到,越权路径测不到。
依赖里带进来一个有已知漏洞的包。 模型不一定知道版本级的漏洞信息。
安全敏感的代码（鉴权、加密、支付、任何处理用户输入的地方）必须走静态扫描 + 人工审查,别只靠"跑起来对"。这类地方优先用成熟的库和框架,而不是让 AI 现写。
把上面的东西合到一起,是一条很清楚的因果链：
AI 让"写"的速度大幅提升 → 变更量上升 → 但"验证"的能力（测试、评审、排查）没有同步提升 → 于是不稳定性上升（DORA）、返工增加（GitClear churn +15%）、调试时间变长（SO 45%）→ 而你感受不到这部分成本（METR 的感知偏差）→ 于是继续加速。
所以用好 AI coding 的全部功夫,几乎都花在验证端,而不是在"怎么问"上。提示词技巧的边际收益,远小于"把验收标准变成可自动执行的东西"。
琢磨怎么把提示词写得更好
把验收标准写成测试,让它自己跑到绿
一次让它改二十个文件
一次一个关注点,diff 小到你能一屏看完
它说"改好了"就合并
自己跑一遍,自己读一遍关键路径
在没有测试的老系统上大改
先补护栏测试,再让它动
用它写自己不懂的领域并直接交付
用它写自己懂的领域,或者在沙箱里学不懂的
凭感觉判断它有没有帮上忙
记录真实耗时,用自己团队的数据
你的收益 = 生成速度 × 你的验证能力。 前者已经很高且还在涨,所以边际改进几乎全在后者。
实践者的共识高度一致：用得好的人都在积极管理上下文。 上下文腐化(context degradation)是最主要的失败模式——会话越长、塞进去的无关信息越多,输出质量掉得越厉害。
关键认知:上下文不是越多越好。 一段已经跑偏的对话历史,会持续把后续输出往错误方向拉;相关文件没给够,它就会猜。
聊了两小时之后它开始犯低级错误。 通常不是模型变笨了,是上下文里堆了太多废料。
它反复改回你已经否决过的写法。 说明那个错误版本还在上下文里当参考。
"你不是刚说过吗"。 信息在,但被淹没了。重要约束要重述,别指望它从两百轮之前捞出来。
最一致的一条实践建议:改代码之前先出方案。 让它先只读不写——读相关代码、复述它的理解、给出计划——你确认之后再让它动手。
这一步的价值在于:方案层面的错误,在纠正时成本极低;代码层面的错误,纠正成本高得多。 而且它复述理解的时候,你能立刻发现它误解了什么。
"先别改,先告诉我你打算怎么改。" 这一句话可能是整页性价比最高的技巧。
让它先复述需求和约束。 它复述错了,说明你没说清楚——这时候发现比写完再发现好得多。
方案里如果出现"顺便重构一下"。 明确拒绝。重构和功能改动要分开。
让它列出会影响哪些文件。 如果列表比你预期长很多,先停下来问为什么。
养成两段式:第一步只读不写、出方案;第二步照方案改。 Claude Code 里有专门的计划模式做这件事(只读,不会动文件),见第四节。
《AI 写代码》那页讲过:模型在代码上进步快,根本原因是代码能被自动判定对错。这个机制在你的日常工作里同样成立——你给它一个能自己跑的验证手段,它的产出质量会明显不同。
所以:把"怎么算做完了"变成一条可执行的命令(跑测试、跑构建、跑 lint、跑一个脚本),然后让它自己跑、自己看报错、自己改到通过。
"改完之后跑 npm test,直到全绿。" 这一句话把它从"生成器"变成了"能自我纠错的循环"。
先写测试,再让它实现。 测试就是它的目标函数——这是最干净的用法。
让它跑 lint 和类型检查。 这两样能自动挡掉一大类问题,不用你看。
修 bug 时先让它写一个能复现的测试。 复现不了就说明还没理解问题,这时候别急着让它改。
没有测试的项目。 那就先给它一个能跑的验证方式——哪怕是一条 curl 命令、一个能看到输出的脚本。有闭环和没闭环,差别巨大。
每次交任务时,附上一条验证命令。这一条同时改善了产出质量和你的审查负担——它跑绿了你才需要开始看。
模型不知道你们团队心照不宣的规矩:错误怎么处理、日志怎么打、哪些目录不能碰、用哪个版本、不许引什么库。这些不写下来,它每次都会猜,而且每次猜得不一样。
在项目根目录放一份约定文件,是投入产出比最高的一次性动作。 Claude Code 会自动读取项目里的 CLAUDE.md——这也是官方文档里被强调最多的一个东西。
每次都要重复说"我们用 pnpm 不用 npm"。 写进去,一劳永逸。
它总是引入新的依赖。 写一条禁令。
新人入职文档和这份文件高度重合。 是的——这是意外收获:被 AI 逼着把隐性知识写下来,人也受益。
今天先写一页,只写三样:怎么跑起来、怎么测、什么绝对不能碰。 后面遇到一次重复解释就补一条。别一开始就想写全。
前面所有数据都指向同一个动作:把改动切小。
GitClear 测到的返工上升、DORA 测到的不稳定上升,在实践层面对应的都是"一次改太多、审不过来"。一次改二十个文件,人是审不动的,review 会退化成"看着还行"。
交付前问一句:"如果这段代码半夜出问题,我能不能自己修?" 答不上来,就说明这段不该以现在的状态合进去。
下面这些是 Claude Code 里实际可用的东西。写这一页的是 Claude,推荐自家产品显然有偏向,请你带着这个前提读——上面第一到第三节的原则是通用的,换任何工具都成立,这一节只是把那些原则落到具体功能上。
/clear。这是实践者反复强调的动作——脏上下文比重新描述一遍贵得多。先计划模式过一遍,确认方案,再让它动手。 大部分返工是在这一步省下来的。
调研类问题交给子代理。 "这个功能在哪几个文件里实现的"——让子代理去翻,你的主对话保持干净。
把测试命令写进 CLAUDE.md。 它就能自己跑、自己修,不用你每次告诉它。
用 hooks 挂上格式化和测试。 消灭一整类"忘了跑"的问题。
做完一件事就 /clear。 别让上一个任务的残留影响下一个。
如果只做一件事:写 CLAUDE.md,把"怎么测"写进去。 它同时解决了两个最大的问题——上下文里缺项目知识,以及没有自动验证闭环。
数据说的是群体趋势，不是你的情况。 DORA 和 GitClear 是大规模相关性观察,不能直接推出"AI 导致了这些"的因果结论——同期还有别的变化(团队规模、行业周期、工具变迁)。它们能说明"值得警惕",不能说明"一定会这样"。
METR 那份研究不能推广。 16 人、资深开源开发者、自己极熟的仓库、2025 年上半年的工具——这是 AI 帮助最小的场景之一,METR 自己也已将结果标为历史性。别拿它论证"AI 没用"。
工具变化比这一页快。 具体功能、模型能力、最佳实践都在动。第一到第三节的原则相对稳定,第四节的具体功能可能过时。
这一页解决不了组织问题。 如果 review 流于形式、没人写测试、上线靠人肉,个人技巧顶不住——DORA 的结论恰恰是:AI 会放大组织已有的强弱。
它不讨论该不该用。 前提是你已经在用了。至于要不要用、用到什么程度,涉及团队情况和个人判断,这一页不替你决定。
这一页和《AI 写代码》《写出高质量代码》是一组:第一页讲为什么 AI 在编码上进步这么快(因为代码能被自动判定对错),这一页讲在这个前提下怎么干活,第三页讲什么是好代码——而好代码的那些属性(小 diff、好测试、清晰边界、显式约定),恰好就是这一页说的"验证能力"的组成部分。AI 写得越快,这些基本功越值钱。