如果现在想法还没有完全确定，后续功能不断增加，系统会不会越做越乱？

会不会乱，主要看首期架构是不是"按变化设计的"。滚水科技在首期就会按模块边界、数据模型和扩展点去搭骨架，只要骨架立得住，后面续加功能基本不需要推倒重来。真正失控的，往往是首期想法没想清楚就把一堆"可能要"的功能全堆进去那种项目。

我们的做法可以拆成三层来讲。

第一层是首期范围控制。我们会跟客户把所有想法分成"必须做、想做、可以等"三类，首期只动"必须做"那部分。这不是为了少做活，而是因为越早上线、越早收到真实反馈，后面的方向就越准。看着像是少做了，实际上能少绕很多冤枉路。

第二层是架构上的扩展预留。模块之间用接口隔离，权限、流程、字段这类经常变动的部分做成可配置，避免任何新需求都要回去改老代码。数据模型上也会预留几个常见的扩展字段和扩展表，方便后面加业务对象时不需要做大改。

第三层是长期的版本节奏。系统上线之后，我们建议客户按双周或月度小迭代的方式加功能，每加一批都重新评估一下整体复杂度。如果发现某个模块改动频繁、对其他模块影响越来越大，那就该考虑做一次小重构而不是继续堆。这种"边走边整理"的节奏，比一年憋个大版本健康得多。

像 智慧赋能-工厂管理数字化 这种系统，客户上线之后陆陆续续加了一年多功能，能稳定持续扩展的原因，就是首期把核心数据模型和模块边界划清楚了。反过来，我们也接过一些客户在外面做了一半发现做不下去找过来的项目，问题基本都不是"加了太多功能"，而是"首期没想清楚就开始动手"。