p.19方法⏱ 约 4 分钟
陷阱 #19:改 A 弄坏 B(回归)
修好了这个,却悄悄弄坏了那个
🔎 最后验证 2026-05📚 来源:《AI编程实战三卷书》卷二🧰 Claude Code、Git✅ 74 人学过👁 120 次阅读
为什么学这个
你让 AI 修一个 bug,它修好了——你很高兴。但与此同时,它的改动悄悄弄坏了另一个本来好好的功能,而你当时根本没注意。这叫"回归":摁下葫芦浮起瓢,是 AI 大范围改动时最常见、也最难察觉的副作用。
💡 打个比方
就像修水管:师傅把漏水的那截换好了,却在动手时碰松了隔壁的接头——眼前的漏点不漏了,新的漏点几天后才被发现。代码的回归就是这种"修一处、坏一处"的连锁反应。
这个坑长什么样
- 改了"计算价格"的逻辑,顺带影响了"显示价格"的地方 → 别的页面价格错了
- 重命名/调整了一个被多处用到的函数 → 没改到的调用方全崩
- 你只测了"刚修好的那个功能",没回头测"原本就好的功能"
为什么会犯 & 怎么识别
- 为什么:代码各部分相互依赖,一处改动的影响面常超出 AI(和你)的预判
- 识别信号:
git diff改动牵涉到被多处使用的东西;改完后"看似无关"的功能出问题
怎么防
- 自动化测试是核武器(m.8):每次改完跑全部测试,回归会让相关测试变红、自动暴露
- 改完回头测"老功能":不只测刚改的,也手动过一遍原本就好的关键功能
- 小步改 + 勤提交(m.1 / 6.12):范围小、有存档,出回归好定位、好回退
❓ 测验
防止'改 A 弄坏 B(回归)'最有效的手段是?
⚠️ 避坑越是'大刀阔斧重构',越要先有测试护着
让 AI 做大范围重构很爽,但也最容易引发回归。重构之前先确保关键功能有测试覆盖(没有就先补),改完跑一遍全绿再说。没有测试就让 AI 大改,等于蒙眼走钢丝——这把 m.8 的测试思维和这里的回归防护连成了一条线。
🤖 改动后查回归(收藏)
你这次的改动,请评估它的影响面:1) 改到的东西还被哪些地方用到?这些地方会不会受影响?2) 请列出我应该回头验证的'原本就正常'的功能清单。3) 如果项目有测试,请把全部测试跑一遍并报告结果。
🔎 来源与核验· 1 条,点开核对
本节每个关键论断都对应一个可追溯的来源 —— 这是本课程"靠谱、不过时"的底线。
「AI 的改动易引发回归(改一处坏另一处),自动化测试是主要防线」
📚 《AI 编程实战三卷书》卷二✓ 已核验 2026-05
🔧 试一试:改一处,跑全部测试(5 分钟)
让 AI 改一个功能,改完跑全部测试(不只是改的那部分)。
你会看到:它修 A 时常常弄坏了看似无关的 B——这叫回归。
怎么防:每次改动后跑全量测试;没测试的项目,改动范围越小越好。
✅ 小结
代码层面的坑差不多齐了。最后三节回到"AI 这个对话者本身"的坑。下一节:它会非常自信地给你错误的解释。
下一节 → 陷阱 #20:盲目自信的错误解释
都看到这了，打个赏呗！
接下来 · p.20
陷阱 #20:盲目自信的错误解释
继续读下一节 →