在老项目里做迭代，最难的往往不是“怎么做出来”，而是“怎么做，才不会把已经稳定的东西一起带坏”。很多需求表面上只是加一个模块、补一段流程、改一组页面，但一旦顺手重写旧结构，风险和验证范围就会迅速放大。所以我现在越来越倾向于一种更现实的策略：先保留已经跑通的主链路，在外层新增入口、页面壳子、流程编排或展示层，把新需求低风险接进去，再逐步收口。
在真实项目里做迭代，很多时候最难的不是“怎么做出来”，而是“怎么做，才不会把已经稳定的东西一起带坏”。
尤其是在一个已经运行很久的老项目里，这种感觉会更明显。
你手里拿到一个新需求，表面上看可能只是：
- 加一个新模块
- 改一组页面
- 补一段流程
- 接一条新链路
但真正开始动之前，你很快就会意识到，事情没那么简单。
因为老项目最可怕的地方，不是代码旧，而是：
- 很多链路已经跑通
- 很多行为已经被线上验证过
- 很多看起来“不优雅”的写法，背后可能是历史兼容结果
- 你不知道哪些地方一动就会带出连锁反应
在这种场景下，我现在越来越倾向于一种策略：
先加壳，先收边界，先低风险接入。
而不是一上来就重写。
一、为什么“看起来更干净”的方案，往往不是最好的方案
技术上很多事情都可以做得更漂亮。
比如：
- 直接把旧页面整个重构掉
- 顺手把历史结构一起整理
- 一次性统一新的状态和数据模型
- 把旧流程彻底替换成新的流程
这些方案在纸面上都很诱人。
它们的问题不在于错，而在于真实项目里，代价通常比想象中大得多。
因为一旦你决定“顺便把旧的也一起改了”，需求的性质就变了。
原本只是“接一个新模块”，很快就会变成：
- 入口改了
- 页面结构改了
- 状态流改了
- 历史兼容要重新确认
- 验证范围一下子扩大
程序员在项目里其实经常会遇到这种“看起来只是顺手整理一下”的时刻。
比如：
- 原本只是想加一个新入口，结果顺手把原来的页面生命周期也改了
- 原本只是想补一个说明页，结果顺手把底层启动时序也重做了
- 原本只是想把一个大页面拆干净，结果连状态机和数据流一起改掉了
- 原本只是想换一层 UI 壳子，结果把核心执行页也推翻重写了
这些动作单独看都很合理，问题在于它们一旦和当前业务需求绑在同一轮里，风险就会叠加。
最后最常见的结果是：
代码也许确实变“新”了，但风险被成倍放大了。
所以我现在越来越警惕一种冲动：
看到旧结构不舒服，就想顺手一起重写。
在真实项目里，这种冲动往往不是工程能力强，而是对风险不够敏感。
二、为什么我现在更偏向“低风险加壳”
这里说的“加壳”，不是糊弄，也不是逃避结构问题。
它真正指的是：
- 先保留已经稳定的主链路
- 在外层新增新的入口、页面壳子、流程编排或展示层
- 把新需求先安全接进去
- 等边界收清楚之后，再考虑更深层的结构优化
如果换成程序员更容易代入的话说，“加壳”通常像是在做下面这些事：
- 原本直接进入执行页，现在先在外面加一个首页或入口页
- 原本执行页自己承担权限判断，现在把权限流程外移到单独入口层
- 原本一个大控制器里同时承担展示、流程和结果，现在先把新增 UI 和流程壳子拆出去
- 原本结果展示直接绑死底层值，现在先加一层展示 DTO 或映射层
这些动作的共同点是：
你没有急着去动最深的地方，而是先在外层建立一个更稳的接缝。
换句话说，它不是“不优化”，而是把优化顺序调整成更稳的方式。
我现在更愿意把这类工作拆成两层来看：
第一层是“业务闭环先成立”。
第二层是“结构和表现逐步收口”。
这样做的好处很直接：
- 已经跑通的主链路不容易被误伤
- 验证范围更可控
- 新模块可以先上线到一个可用基线
- 后续如果要继续重构，也有稳定起点
很多时候，项目真正需要的不是一次性变完美，而是先把事情稳稳推进下去。
三、低风险加壳，不代表什么都不改
这里也有一个容易被误解的地方。
“低风险加壳”不等于保守到什么都不动。
它真正强调的是：
- 先改低风险层
- 先把变化控制在清晰边界内
- 不把结构重构和功能修改混成一轮
通常来说，我会更优先考虑下面这些位置：
- 入口层
- 页面壳层
- 流程编排层
- 展示层 DTO
- 独立组件层
而不是优先去动：
- 已跑通的核心状态机
- 已稳定的生成链路
- 已成立的历史落库结构
- 已验证过的核心执行流程
因为经验上看，真正容易出事的，往往不是“壳子还不够优雅”，而是你动到了那些原本已经能跑、但依赖关系很深的地方。
很多工程师在老项目里都会有一种熟悉的挫败感：
- 明明只是想做一个看起来不大的需求
- 结果一改就牵出一串历史问题
- 最后花掉的大量时间，不是在写新功能，而是在收拾意外回归
这也是为什么我现在越来越愿意把“先动哪一层”当成一个独立问题，而不是直接进入实现。
原因不是这些地方永远不能动，而是它们往往是高风险区。
在需求刚落下来时，最不适合做的，就是把高风险区和新需求一起打包处理。
四、为什么我越来越重视“先划边界，再决定怎么改”
老项目的复杂，不只是代码量大。
真正麻烦的是，你很难靠直觉判断哪些地方能动、哪些地方不该碰。
所以我现在每次遇到这类需求，都会先问自己几个问题：
- 这次真正要交付的结果是什么
- 当前项目里哪条链路已经稳定成立
- 哪些问题只是结构不好看，哪些问题已经影响交付
- 这次如果只允许动一层，最应该动哪一层
- 有没有可能先通过新增外层壳子，把需求落进去
很多时候，只要这几个问题先想清楚，方案本身就会收敛很多。
而一旦这些问题没先想清楚，AI 其实也很容易把事情越带越偏。
因为 AI 很擅长给出“看起来都能做”的路径：
- 重构一版
- 抽象一层
- 顺手统一
- 一起改掉
但它不会天然替你承担项目风险。
所以在这种场景下，我越来越觉得，AI 最适合做的是：
- 帮我把方案空间摊开
- 帮我把边界列清楚
- 帮我分析哪种改法改动半径更大
而不是让我顺着它的热心建议一路往下重写。
这也是为什么我现在更喜欢在动手之前先把边界写出来。
因为边界一旦不清楚，工程师最容易在做的过程中“顺手多改一点”。
而真实项目里，很多风险恰恰就来自这些“顺手”。
五、我为什么不再把“重写”当成默认优雅解
以前我也会天然偏向一种思路：
如果结构不好，就趁这次一起整理掉。
后来做真实项目越来越多，我反而越来越克制。
因为我发现，工程上真正成熟的选择，很多时候并不是“从头做一版更优雅的”，而是：
在当前约束里，找一条风险最小、可验证、可迭代的路径。
尤其在这些场景里：
- 项目历史比较久
- 现有业务不能出问题
- 验证资源有限
- 需求节奏比较紧
这时候，“先低风险接入，再逐步收口”，往往比“重写一版更漂亮的结构”更符合实际。
它不一定最理想，但通常最能推进事情。
六、低风险加壳真正带来的，不只是风险更低
这套做法最直接的好处当然是稳。
但它带来的价值不只是稳。
我越来越觉得，它还有另外两个很重要的作用。
第一个作用，是帮助你把系统边界看清楚。
因为当你决定不急着重写内部逻辑，而是先在外层加壳时，你会被迫去思考：
- 哪些能力其实已经可以复用
- 哪些逻辑应该沉在内核层
- 哪些页面只负责展示，哪些层才应该负责流程推进
这会让项目结构比“一上来重写”更清楚。
第二个作用，是让后续优化有了更好的起点。
很多结构问题并不是不能改，而是不能和当前业务接入混在一轮里改。
如果先把新需求稳定接进去，后面再做“纯结构整改”，风险就会小很多，判断也会更干净。
很多时候，真正成熟的节奏不是：
- 一次把事情全做完
而是：
- 第一轮先让业务闭环成立
- 第二轮再做结构收口
- 第三轮再谈样式、命名、目录和更深层抽象
这听起来不够“理想化”，但在真实项目里往往最有效。
七、这其实是一种工程判断，而不是技巧
我现在越来越不把“低风险加壳”看成某种具体技巧。
它更像一种工程判断方式：
- 已跑通的主链路优先保护
- 新需求优先找低侵入接缝
- 结构优化和功能实现分轮处理
- 先建立稳定基线，再继续演进
这种判断并不花哨，但在真实项目里很值钱。
因为很多时候，项目真正需要的不是一个“最漂亮的技术方案”，而是一个“能稳定推进、不会误伤、还能继续演进”的方案。
八、为什么我想把这件事单独写下来
我后来发现，这类判断其实很少被单独认真讨论。
大家更容易讨论的是：
- 怎么重构
- 怎么拆组件
- 怎么上新架构
- 怎么提高代码质量
这些都重要。
但在真实项目里，还有一个更朴素、也更常见的问题：
当你不能轻易乱动现有主链路时，你该怎么继续把事情做下去。
对我来说，这才是很多工程工作更真实的样子。
所以我想把它单独写下来。
不是因为“低风险加壳”是什么新鲜概念，而是因为它太常见、太实用，也太需要被认真说清楚了。
尤其在 AI 开始进入开发流程之后，我更觉得这类工程判断值得被反复强调。
因为 AI 可以帮你分析方案、拆边界、整理路径，但最终值不值得动、先动哪一层、什么这轮不该动，还是要回到工程师自己的判断。
而我最近越来越看重的，也正是这种判断本身。
如果你也长期在老项目里做事，应该很容易理解这种感觉：
很多时候，真正的技术成熟，不是敢不敢重写，而是知道什么时候该忍住，什么时候该先加壳，什么时候该把结构优化留到下一轮。
