重构还是重写有分歧，用有限技术试点提供决策证据

试点结束后如何作决定

将方案分歧写成一个可验证的假设

试点开始前先说明要回答哪个问题。发版困难、规则无人确认和运行时限制，需要不同实验；不能把“换框架以后好维护”当成已证明结论。

收集近期需求从提出到交付的过程，记录卡在哪里，再把主张改写成可观察条件。例如“把价格规则隔离后，新增价格条件只需调整所属模块且原样例仍通过”。同时记录当前基线与反例：什么结果会说明这条路线不适用。只需要验证本次分歧，不用在首个试点里顺便完成所有升级任务。

• 列明假设、已有证据、未知条件与可能的反例。
• 为试点设定业务样例、技术成果和投入范围。
• 先约定结果由谁判断，避免展示结束后改变标准。

先估计旧系统藏着多少未写下来的规则

代码往往记录了多年例外处理：历史客户价格、审批跳转、补单方式和报表计算。重新实现页面很容易，完整识别这些行为通常更困难。

让业务人员按真实任务演示正常和异常流程，再把关键输入、输出及状态转换记录下来。不是所有旧行为都要保留；已确认错误、废弃流程和重复功能可以取消，但要把“保留”“改正”“删除”分别由谁确认写入记录。无法确认的规则进入待决清单，不能由开发者猜测后悄悄改变。

• 优先识别金额、库存、合同状态和审批责任等关键规则。
• 为保留规则准备可重复的脱敏样例与期望结果。
• 对历史例外注明使用人群、业务依据及是否仍有效。

使用相同样例比较候选路线的真实限制

评估源码能否构建、关键入口能否隔离，以及模块之间如何读写。候选路线比较应使用同一业务任务，而不是旧系统做复杂流程、新框架只展示简单页面。

选一个有明确用户价值、依赖可盘点且规则能确认的流程，尝试补测试、建立接口或替换实现。记录为了完成它需要触及哪些共享代码、报表和任务。如果试点都不能建立边界，应先处理耦合与知识缺口；如果旧系统无法修改，则验证外部入口的控制能力。

实验记录包括源码版本、环境、样例、结果和人工操作。对未验证的依赖标为限制，保留失败尝试的原因；试点允许得到“不值得继续”的结论。不能删去困难样例后把剩余成功结果视为完整证明。

• 在隔离环境重建基线，使用相同条件运行候选实现。
• 验证完整业务链及至少一类重要异常，不只演示界面。
• 保留结果、差异和未覆盖范围，作为路线选择依据。

在 ADR 中保存决策依据和承担的代价

ADR 是架构决策记录。记录背景、候选方案、证据、选择理由、后果和复查条件，使后续人员可以理解当时为什么这样决定。

记录不必冗长，但应链接到实验样例与验证结果，并区分事实和推断。比较路线时列出评估建设、双系统共存、长期维护与最终退出的工作。试点成本不是全系统报价，可按发现的依赖说明下一阶段估算条件；无法验证的限制仍应留在 ADR 中，而不是被一个“方案已通过”状态覆盖。

为记录设定提出、接受、被替代等状态，并注明批准人与日期。之后的新证据推翻选择时，新建或更新决策关系，保留旧理由，避免文档只剩最终架构图而失去来龙去脉。

• 列出候选方案及未选原因，注明证据来源。
• 说明共存环境、适配层和运维的新增责任。
• 写明何种新证据会触发重新评估。

按继续、调整和停止条件关闭试点

试点有明确结束点：提交证据、核对假设、作出决策，并决定试点代码的去向。不能因为还有更多可以改，就让有限验证变成没有边界的正式建设。

先确认关键行为与接口条件是否通过，再看新增成本能否接受。通过的边界可以进入下一阶段；条件部分成立时调整范围再验证；关键前提不成立时结束当前路线。试点代码若进入生产，应补足质量、运维和交接要求；若只作实验，应清理临时环境并保留结果，避免演示代码被默认长期使用。

• 第一步：冻结实验范围并准备可重复的保护样例。
• 第二步：核对证据与预设条件，形成 ADR 决策。
• 第三步：决定扩大、调整或结束，并安排代码与环境收尾。

有些场景需要先稳住系统，再谈结构改造

本文适用于仍在服务业务、需要保留已有能力的企业软件。新建空系统、只剩很少功能的工具，或者必须迅速退役的产品，路线可能更简单。

若当前存在持续故障、无法备份恢复或账号权限无人掌握，应先完成运行保障和受控接手。若法规、合同或外部平台强制要求某个期限停止旧环境，渐进替换的共存窗口也会受到限制。任何路线都不自动带来性能提升，性能目标需另有基线、场景与验证结果。

• 没有完整规则清单时，避免承诺所有行为完全一致。
• 无法维持共存时，明确维护窗口与业务补救安排。
• 性能、合规和界面变化分别验收，不混成一个完成条件。

需求讨论中的问题