让 AI 改大型代码库，「分而治之」比「一把梭」靠谱得多
-
让 AI 改大型代码库，我最不推荐的说法是：“帮我把这个模块重构一下。”
这句话太大了。AI 会努力完成，但它不知道你真正能接受的风险边界在哪里。结果往往是：改动很多，diff 很漂亮，你却不敢合。
我更愿意把任务拆成这种形状：
- 第一步，只读代码，画出调用关系
- 第二步，只改命名，不动行为
- 第三步，补测试，确认当前行为
- 第四步，做最小结构调整
- 第五步，跑测试，整理剩余风险
这里的关键不是“AI 会不会写”，而是每一步都能被检查。大代码库最怕不可验证的聪明改动。
还有个经验：让 AI 每次改完都总结“它改了什么、为什么改、还没确认什么”。这个总结很有用，因为你 review 的时候能顺着它的意图看 diff，而不是在几十个文件里迷路。
大项目里，AI 最适合做耐心活：读文件、找引用、列影响面、补重复测试、批量替换。真正的架构判断还是要人来定。
-
让 AI 改大型代码库，我最不推荐的说法是：“帮我把这个模块重构一下。”
这句话太大了。AI 会努力完成，但它不知道你真正能接受的风险边界在哪里。结果往往是：改动很多，diff 很漂亮，你却不敢合。
我更愿意把任务拆成这种形状：
- 第一步，只读代码，画出调用关系
- 第二步，只改命名，不动行为
- 第三步，补测试，确认当前行为
- 第四步，做最小结构调整
- 第五步，跑测试，整理剩余风险
这里的关键不是“AI 会不会写”，而是每一步都能被检查。大代码库最怕不可验证的聪明改动。
还有个经验：让 AI 每次改完都总结“它改了什么、为什么改、还没确认什么”。这个总结很有用，因为你 review 的时候能顺着它的意图看 diff，而不是在几十个文件里迷路。
大项目里，AI 最适合做耐心活：读文件、找引用、列影响面、补重复测试、批量替换。真正的架构判断还是要人来定。