Rationale 模板
Rationale 模板
Section titled “Rationale 模板”跟类型草图一起交付的说明文字。一页。标题用句子式大小写（只有第一个词首字母大写），不写套话。把斜体的提示换成实际内容。
一段。我们要做什么，现有系统或约束里有什么让形态不那么显而易见。如果 阶段 A 发现了设计必须遵守的约束（要对接的现有类型、不能弄坏的调用方、跨过我们边界的 invariant），在这里写出来，让读者看到你看到的同样的约束。
用法（调用方视角）
Section titled “用法（调用方视角）”先写这一节，再写类型草图。写出使用者会读的 README 或快速上手，再加两三个在他们自己代码里的真实调用点：导入什么、调用什么、拿回什么。形态 里的类型草图从这里推出来。两者必须一致。不一致时，改草图去贴合用法，不要反过来。调用方的体验就是规格，类型为它服务。
推荐的架构。先写数据结构，再写数据怎样流过各个签名。点出承重的决定。说清楚哪些 invariant 写进了类型，校验放在哪里，系统刻意不做什么。明确评估接口深度：公开接口藏住了哪些复杂度，还有什么暴露给调用方，为什么接口没有比需要的更大。每个决定都注明依据的原则（例如 per boundary-discipline），不要把原则再讲一遍。
由 arena 填写。记下哪个候选成了基底、为什么，从其他每个候选各借了什么，拒掉了什么、为什么。
选定的形态每做一个取舍，写一条。格式：「我们接受 X，换来 Y。」凡是将来的读者可能当成疏漏的地方都点出来，包括看起来像过早优化或过早简化的地方。
考虑过的备选
Section titled “考虑过的备选”必填。至少写出一个具体的备选形态，用一行说明它为什么落选。评判每个备选都看接口深度，不能只看实现是否简单。写出它暴露给调用方的复杂度和它藏住的复杂度。设计空间里确实有几个有力竞争者时，写两三个。约束只留下一个答案时，写一个也行，结论写成「这是唯一可行的形态，因为……」。不要把同一个形态的几种变体列成备选。这一节写的是选定形态考虑过并拒掉的设计备选，不是其他 runner 的候选。
未决问题和风险
Section titled “未决问题和风险”画草图时注意到、需要人来拿主意的事，以及实现开始前值得提出来的风险。写成问题，不要写成断言，这样人的回答本身就是结论，而不只是一条评论。
照着草图要先做的第一件事。一句话。综合完成后（如果选了确认点，就是阶段 D 前对方点头之后）你马上会开始写的东西。