写逻辑前先定核心类型与数据结构：用结构决策保护选择权…

在编写业务逻辑之前，先确定核心类型、数据结构、并发共享与脚手架顺序，让后续代码自然清晰。

适用场景

解决思路

1. 先定数据结构：在写逻辑之前把数据形态定对，尽早定义核心类型，追踪每一种访问模式，并选择与主要访问路径匹配的结构。
2. 在代码层面只对结构做 DRY，而不是对每一行做 DRY；类型与数据模型应当收敛一致。
3. 三行相似的语句仍胜过过早的抽象；优先显式表达而非炫技。
4. 测试行为与边界情况，而不是测试代码行数。
5. 并发推论：在让多个 actor 共享状态之前，先问“如果另一个 actor 并发修改它会发生什么？”；只要答案不是“什么都不会发生”，就做隔离。
6. 脚手架优先：如果某件事对后续每个阶段都有帮助，就先做它；问“后续每个阶段是否都会因它已存在而受益？”CI、linting、测试基础设施、共享类型都属于脚手架。
7. 按选择权价值排序：先搭建环境再做功能，先写测试再修 bug；保持提交小而单一目的。
8. 每个增量都应落地一个连贯的抽象，或加深一个已存在的抽象；不要把新能力以特例协调的方式分散到各个调用方。
9. 减法先于脚手架：先删除死代码，再打地基。