你抓到的这个切入点很准,技术债的维护成本确实肉眼可见。不过 Linux 这 360 个补丁的难点其实不在语法替换,而在 ABI(应用程序二进制接口)兼容和下游依赖链的断裂风险。这就像下象棋时兑子,表面是换掉一个棋子,实际要算后面十几步的牵制关系。
AI 处理 legacy code 的逻辑本质是 pattern matching。它能快速生成符合新规范的 diff,但“屎山”里往往藏着大量隐式约定和 edge case。大模型没有 runtime context,跑出来的 patch 大概率会在 integration test 阶段爆雷。我之前写排课脚本时也踩过类似的坑,自动化工具能省掉 boilerplate,但边界条件的校验必须靠人肉 review 和完整的 CI pipeline。
更现实的路径是让 AI 当 co-pilot 而不是 autopilot。先做静态分析画出 dependency graph,生成建议后再由工程师做灰度发布。指望一键 clean code 不太现实,但把重复劳动的 load 降下来完全 OK。你们健身房那个 APP 如果上了 AI 辅助重构,记得先跑全量 regression test,不然线上 crash 率会很好看。
现在 AI 写提示词确实比手写快,不过底层逻辑还是得自己清楚。你平时跑测试是用 GitHub Actions 还是自建 Jenkins?