为什么维护生产系统时，我越来越重视最小改动？

第一次做软件时，很容易把“顺便优化一下”当成好事。代码结构可以更漂亮，页面风格可以更统一，旧功能似乎也能顺手重构。

但当系统已经进入真实使用阶段，我逐渐认识到：不必要的修改，本身就是一种风险来源。

生产系统不是演示工程

演示工程出问题，可能重新启动就能继续看效果；生产系统承载的是人员日常操作、业务记录和持续的数据状态。

一次与当前Bug无关的重构，可能改变接口字段、权限判断、数据库行为或页面交互。修改者只看到当前目标，使用者却可能在其他模块遇到新的故障。

我在公司CRM和其他行业系统的维护中，更重视已验收功能、实际运行版本与代码冻结点之间的关系。问题出现以后，先确定故障位置，尽量不要把稳定区域也拖进修改范围。

最小改动不等于不专业

工程上可以用最小必要变更（Minimal Change）、变更影响分析（Impact Analysis）和回归测试（Regression Testing）来理解这套原则。

首先弄清问题发生在哪个版本、哪个入口、哪个业务状态；其次确认需要改哪些文件和数据；然后测试修复目标及直接受影响的关键路径。

如果确实需要触碰数据库结构、权限或资金数据，就不能机械追求文件数量最少，还必须具备必要的备份、验证和回退条件。

所以最小改动的含义不是“偷工减料”，而是让变更范围与真实问题相匹配。

AI时代为什么更需要控制变更？

AI可以迅速重写一个模块，甚至给出一份很完整的系统重构建议。但执行速度提高，并不自动降低变更风险。

如果AI每遇到一个问题都扩大范围、增加依赖、建立新服务，开发者最终可能很难解释系统为什么变成现在这样。

我逐渐倾向于固定当前真实运行入口、明确需要修复的具体问题，保留可追溯的版本基线。对于未经批准的架构扩大，宁愿暂停确认，也不急着执行。

维护生产系统的价值，不在于每次修改了多少代码，而在于用可控的变更恢复正确业务，同时尽量不伤害已经稳定的部分。