promptgarten 🌱
🌍 DE
指南●●●4 分钟 · +40 XP

使用 AI 智能体进行安全重构

智能体在重构时可能会悄悄改变行为,而不仅仅是结构——测试和小步骤可以防止这种情况。

重构到底意味着什么

重构(Refactoring)意味着:在不改变代码对外可见行为的前提下,改善其内部结构。这个概念主要因 Martin Fowler 的同名著作而广为人知。"不改变行为"是其中最关键的部分——而这一点在使用 AI 智能体时,如果没人明确要求,很容易被忽略。

智能体为何容易在这里出错

智能体在重构过程中经常会发现一些它觉得"不对"的东西——一个奇怪的条件判断、一个重复的检查。如果没有明确指示,它会顺手把这些也"修好",而不只是重新组织结构。一次单纯的重构就这样在不知不觉中变成了行为变更。

三项最重要的保障措施

  1. 先写测试:重构之前必须存在一套能保障当前行为的测试套件。没有测试,你就无法判断是否发生了变化。
  2. 小步前进:每次只改一处,每一步之后运行测试,每个通过的步骤单独提交。
  3. 明确要求保持行为不变:清楚地说"重构,但不要改变行为",而不是只说"把代码改好一点"。

常见陷阱

智能体悄悄更改了一个公开接口,删除了它认为是死代码但实际上是被动态调用的代码,或者把重构和新功能需求混在同一次改动中一起完成。

示例

提示词:"把 processOrder() 中的校验逻辑提取到一个独立的函数 validateOrder() 中。行为不能改变。提取完成后运行现有的测试套件,如果有测试失败,先向我报告,再继续。"

🛠️ 练习——自己动手试试

从你自己的项目中找一个做了太多事情的函数,让智能体以小步骤、有测试保障的方式对它进行重构。

  1. 先检查是否有测试覆盖这个函数。如果没有:先让智能体写一个测试,记录当前的行为。
  2. 明确要求智能体:"把[部分 X]提取到一个独立的函数中,行为不能改变。每一步之后都运行测试。"
  3. 提交之前通读一遍 diff——专门查找那些超出单纯结构调整范围的改动。

✅ 自查清单

  • ☐ 重构之后所有测试是否仍然通过——之前是否已经检查过这一点?
  • ☐ diff 中是否有某一行不只是移动了代码,而是改变了一个条件、一个值或一条错误消息?
  • ☐ 是一次性全部提交的,还是各个子步骤可以分别追溯?

小测验

在 AI 智能体对现有代码进行较大规模重构之前,最重要的前提条件是什么?

来源

相关主题

用 agent 做测试：让它写测试，再把测试当成 gate ●●○模式：先计划，再写代码 ●●○写给 vibe coder 的 Git 与 GitHub 入门 ●○○Agent 卡住了？这样解套 ●●○