improve-architecture

改进架构

逐步改善系统结构，避免日后为重写付出代价。此技能负责诊断并提出建议，不会自行重写。

方法

1. 先绘制结构图。 先了解当前结构再做判断——入口点、模块、数据流以及调用关系。使用 module-map 获取一屏概览；不要跳过这一步直接发表意见。
2. 找出痛点。 关注影响架构的重大问题，而非风格上的小瑕疵：
   • 万能模块：所有内容都依赖它，却没有任何内容能安全地修改它。
   • 边界泄漏：某个模块直接访问另一个模块的内部，而不是使用其公开接口。
   • 重复逻辑逐渐偏离（同一规则以三种方式实现）。
   • 切分点不当——代码在不需要变化的地方被拆分，却在需要变化的地方被合并。
   • 循环依赖。
   • 架构与领域不匹配（参见 domain-modeling——代码边界应与领域语言中的边界对应）。
3. 提出最小改动。 针对每个问题，提出能缓解问题的最小改动：提取边界、合并重复实现、反转依赖或移动切分点。优先采用一系列安全步骤，而非一次大刀阔斧的改动。
4. 按杠杆效应排序。 按缓解痛点的效果与所需工作量排序。说明哪些改动现在可以安全进行，哪些需要先建立测试网（配合 tdd）。
5. 记录重大决策。 对于未来读者可能会质疑的结构性变更，在 docs/decisions/NNNN-slug.md 中编写决策记录，说明背景、选择、拒绝的替代方案及原因。

防护原则

• 只做诊断，不做重写。交付内容是一份计划，用户批准后才能进行任何代码变更。
• 不要为了个人偏好而折腾。每项改动都必须缓解明确指出的痛点；“更整洁”不是理由。
• 三行相似代码胜过过早抽象——除非重复代码确实逐渐偏离，否则不要用间接层替代重复代码。
• 保持行为不变。结构性改动属于重构；必须在测试全部通过的基础上提交。

输出

提供一份优先级列表：每项列出问题、最小改动、风险，以及是否需要先建立测试网。重大改动还需附上决策记录。用户选定要做什么之前，不得更改代码。