一个约7万行代码的Django 3.2单体应用，在6个工作日内被升级到了Django 5.2 LTS。这次迁移并没有采用一步到位的跳跃式方案，而是由开发者将升级路径拆成多个版本节点，并让Claude Code承担其中大量重复性修复工作。整个过程中，真正关键的并不是某个巧妙的提示词，而是对AI能力边界的严格限制。
从Django 3.2到5.2：一次被拖延多年的升级
Django 3.2已于2024年4月结束生命周期，但该项目直到2026年仍停留在这个版本。原因并非团队不重视，而是升级任务本身过于沉重：从3.2到5.2之间横跨多个主要版本，每次有人打开升级工单，看到四个大版本的变更说明后，往往会选择暂时搁置。
项目还面临现实约束：开发者只有一个sprint的时间，且不能冻结功能开发。因此，升级必须以小型、可评审的PR形式持续合入，团队成员可以继续围绕这些分支并行开发。
在这种背景下，作者选择让已经用于日常重构的Claude Code参与这项多版本框架升级，核心问题不是AI能否写代码，而是它能否在有人设定规则的前提下，稳定完成长链路、重复性强的迁移任务。
拆版本、报废弃警告、先跑codemod
这次升级最重要的决策，是拒绝直接从Django 3.2跳到5.2。Django的废弃机制决定了：某个功能在X版本被标记弃用后，通常仍可继续工作到X+2；如果跨版本过大，原本能提示问题的警告会消失，最终只剩ImportError。
因此，升级路径被拆成多个阶段：
- Django 3.2 + Python 3.9
- Django 3.2 + Python 3.10
- Django 4.2 LTS + Python 3.10
- Django 4.2 LTS + Python 3.12
- Django 5.2 LTS + Python 3.12
每一个阶段都是独立分支、独立通过CI、独立部署。Python和Django版本不会出现在同一个PR里，一旦测试环境出现问题，开发者可以立刻判断变量来自哪里。
同时，作者将Django默认通常不显眼的RemovedInDjangoXXWarning等废弃警告，转成测试中的硬性错误。这样一来，原本模糊的“升级Django”任务，被转化为一份具体、有限、带有堆栈信息的失败测试清单。这类任务恰好适合AI代理逐项消化。
对于第三方库产生的废弃警告，由于无法直接修改其源码，作者在测试设置中通过warnings.filterwarnings做了按模块屏蔽，确保项目自身代码仍保持严格要求。
在让Claude Code介入之前，作者还先运行了django-upgrade。这个确定性重写工具处理了大量机械性迁移，包括url()改re_path()、ugettext改gettext、request.is_ajax()替换、index_together调整等。一条命令就涉及约340个文件。
作者强调，这类工作先交给确定性工具更合适：成本更低、速度更快，也不会产生幻觉。AI应该把精力留给需要判断的部分，而不是做全局查找替换。
Claude Code的任务被压缩成一个“单调循环”
Claude Code收到的指令非常窄，接近一个固定流程：
- 运行升级测试脚本
- 只处理第一个失败测试
- 阅读完整traceback和对应的Django发布说明
- 做最小修复，不顺手重构周边代码
- 重跑单个测试及对应模块测试
- 以统一格式提交
- 回到第一步
其中，“只处理第一个失败测试”这条规则显著降低了任务复杂度。如果放开限制，AI可能会面对上百个失败项，同时尝试修复几十个，最后生成难以评审的巨大diff；而在规则约束下，产出变成了连续的小提交，多数改动不超过20行。
另一条关键规则是“停止并询问”。当修复涉及设置默认值变更、迁移文件修改，或第三方包需要升级时，Claude Code必须停下来交由人类确认。这几类问题往往正是生产环境升级中最容易造成事故的位置。
依赖项是这次项目真正的进度风险。46个依赖包在动代码之前，先由Claude Code整理成一张表格，列出当前版本、是否支持Django 4.2、是否支持Django 5.2，以及后续动作。
最终盘点结果是：
- 38个依赖只需升级版本
- 5个依赖需要配置调整
- 3个依赖需要替换或vendored处理
这张表让升级风险在第一天就被摊开。作者抽查了约三分之一条目，发现AI有两次错误判断，原因是它过于相信PyPI上的classifier信息。这也说明，即使Claude Code能完成大量信息整理，仍不能完全脱离人工核验。
AI编程进入大型重构流程的真实位置
从这次案例看，Claude Code在大型框架升级中的作用并不是“替人完成一切”，而是嵌入一条经过工程化设计的流程。它擅长消化明确、重复、带反馈闭环的任务，但在配置默认值、迁移文件、依赖生态判断等高风险环节，仍然需要人类开发者把关。
尤其值得注意的是，这次升级成功并不依赖某个聪明的prompt，而是依赖几个传统工程原则：逐版本迁移、让警告显性化、拆分PR、先跑确定性工具、限制AI的自由度。AI的价值，是在这些规则下持续稳定地执行。
对于很多长期停留在旧版本框架上的团队来说，这类实践提供了一种新的可能：大型重构不再只是靠人力硬扛，也可以被拆成可由AI协作完成的流水线任务。但前提也很明确——AI必须被放进严格约束的工作轨道里，而不是被赋予过多自主权。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/yi-ci-da-xing-kuang-jia-sheng-ji-de-ai-xie-zuo-yang-ben
