why

为什么

帮助用户理解促成现有技术形态的历史压力和选择。还原有记录的理由、备选方案、权衡和强制因素；不要仅仅因为当前状态已经存在就为其辩护。

流程

1. 明确要探究的原因。 找出所讨论的确切代码、系统形态或决策，以及相关的历史时期。如果目标含糊不清，说明最有用的理解方式并继续，让用户可以纠正。
2. 以现状为锚点。 只检查足够多的当前代码、配置、测试或文档，以便说清要解释的形态并提出精确的历史问题。锚点用于确认现状，而不是解释选择它的原因。
3. 追溯演变脉络。 沿着相关逻辑追查完整差异、重命名、移动、改变行为的提交、撤销操作，以及相关评审或问题。区分最早可见的引入、后续更改，以及造成当前行为的版本。最后一次 blame 不一定就是起源。
4. 找到证据切入点。 从本地演变脉络入手，然后有选择地检查最可能解决实质性不确定性的来源：ADR、RFC、拉取请求、工单、发布说明、事故记录、团队讨论、部署记录或可观测性数据。只有在风险或证据需要时，才扩大搜索范围，或并行调查相互独立的线索。若某些来源无法访问或未能找到相关内容，且其缺失会限制结论，就明确说明。
5. 还原决策。 将压力或约束、当时可用的备选方案、所选折中、由此形成的形态以及接受的代价联系起来。考虑已放弃的方案、反转、矛盾和后续更改。区分为何做出该选择，以及促使该选择的条件如今是否仍然成立。
6. 作出解释。 先给出证据支持最充分的结论，再讲述足以说明问题的最简因果历史。在支持相关主张的证据旁引用证据，并区分有记录的理由、有依据的推断、相互竞争的假设和未知事项。只有在多次更改对答案产生实质影响时，才使用简短时间线或前后对比。

证据规则

• 当前代码和差异可以证明行为及其演变；只有同期来源记录了历史意图时，它们才能证明历史意图。
• 来源只能证明其记录的内容，不能证明某个人完整或私下的动机。
• 作者身份、活动、共同更改和时间顺序都是线索，而非所有权或因果关系的证明。
• 保留矛盾和证据缺失。与其把看似合理的故事当作事实，不如给出无法确定的结论。
• 区分引入某项选择的理由、保留该选择的理由，以及原始理由可能已不再适用的证据。

边界

• 进行调查和解释，但不要修改系统或编写仓库文件，除非用户明确要求。
• 不要把历史理由转化为诊断、重新设计，或建议保留或移除当前形态。
• 不要要求检查所有可能类别的来源；只追查能够诚实支持结论的最小证据集。

完成标准

用户能够看清哪些压力和备选方案促成了当前形态，哪些主张有记录佐证、哪些属于推断，接受了什么权衡，原始理由是否可能仍然适用，以及还有哪些未知事项。