一家中文技术社区这周出现了一篇高阅读量文章，主题是「用 AI 做代码重构前评估」。表面是写给程序员的，但我们读完后的判断是：这套方法论对所有正考虑用 AI 改造老系统的管理者都值得借鉴。核心观点一句话——「代码难看」不等于「值得改」。

这是什么

文章把待改造的代码按调用频率和风险分成四类：

  • 高频区：频繁被调用、问题持续发生——优先评估重构
  • 核心区：涉及资金、权限、数据一致性——小步重构，先补测试
  • 低频遗留区：很少调用，近期无需求——通常不要主动改
  • 即将下线区：已有替代方案或明确下线计划——不要大规模投入

作者强调的工程流程是：先让 AI 做影响范围分析（调用方、依赖、副作用），再判断七维收益（理解成本、修改成本、测试可行性等），再判断七维风险（行为变化、数据一致性、回滚难度等），最后才决定要不要动手。他特别警告：没有稳定测试的核心代码不适合直接大改——AI 没办法判断那些奇怪分支是不是历史兼容的产物。

行业怎么看

支持者认为，这套方法把「想重构」从情绪反应变成可验证、可控制的工程任务。一位架构师在评论区说：过去十年他见过太多项目死于「顺手优化」。

但反对声音也不少。第一种批评：过度评估本身也是成本。如果每次小改都要走一遍七维分析、七维风险评估，初创团队根本跑不动。第二种更尖锐：这框架默认企业有「稳定测试」这套基础设施，而国内大量公司的核心代码恰恰没有任何测试覆盖——按这个标准，几乎所有改造都不能做，结果就是永远不改造。

我们还注意到一个隐忧：这套框架假设的是「不改变行为」的代码结构整理，但 AI 时代企业要做的多数改造恰恰是要改变业务行为的——这种场景下，框架适用性会打折扣。

对普通人的影响

  • 对企业 IT：业务部门提「用 AI 重构 XX 系统」时，第一步不是立项，而是先问这段系统属于四类中的哪一类、影响范围多大、测试覆盖是否足够。没有这三问，预算大概率打水漂。
  • 对个人职场：「先评估再动手」的工程文化正在向产品、运营岗位蔓延。能用 AI 写不代表值得用 AI 写，这条判断力本身会越来越值钱。
  • 对消费市场：「AI 一键改造企业流程」的产品宣传与一线工程师的实操经验之间存在明显鸿沟——这是企业采购时需要警惕的信号。