第 10 章 · 记下你为什么这么选
半年后你还说得出当时为什么这么决定吗？
没有被否决的方案，说明当时根本没做选择。
- 这一章回答
- 半年后你还说得出当时为什么这么决定吗？
- 你会做出来
- 至少三条含「当时考虑过但没选」的决定记录
这一章产出的东西，现在看起来最没用，半年后最值钱。
机制
记下决定、理由、依据，以及当时考虑过但没选的方案。
四项里最后一项最容易省略，也最不能省：没有被否决的方案，说明当时根本没做选择——你只是接受了第一个出现在面前的东西。
为什么必须写下来：
记忆会重写理由。 三个月后你只记得结论，不记得当时的约束。于是你会用今天的条件去评判当时的决定，得出「我当时真蠢」这种既不准确也没用的结论。
AI 时代尤其重要。 很多技术选择实际上是模型替你做的。如果不在当时记下「为什么是这个」，你永远不会发现哪些判断其实不是你的——直到需要你自己做决定的那天。
它是 Review 的原材料。 第五阶段要输出一份陌生人读得懂的复盘，而复盘的核心不是「我做了什么」，是「我为什么那么做、后来证明对不对」。没有当时的记录，复盘只能靠编。
什么值得记
不是每个决定都要记。标准是：这个决定如果换一个选择，项目会明显不同吗？
值得记的通常是：技术栈与关键依赖、数据怎么存、哪些功能砍掉了、某个难点选择手工还是自动、要不要做某个用户要求的东西。
不值得记的：变量命名、用哪个 UI 组件库的按钮、文件放哪个目录。
现实案例
记了的那条 —— 公司法律信息全部留空，并在代码里写明了理由：
在拿到核实过的法律信息之前，这些字段保持空或通用。页脚和法律页回退到公开品牌名 EONLOOM，而不是编造一个注册实体、地址或司法管辖区。
决定（留空）、理由（没核实过）、依据（页脚需要一个名字，但不需要是法律实体名）、没选的方案（随便填一个占位值）——四项齐全，而且就写在会被读到的地方。
没记的那条 —— Markets 那个产品从 Crypto Auto Research 改名成了 Crypto Market Radar，URL 也从 kkdemian.com/research 换到了 radar.gigstock.xyz。仓库里留了一条保留语言前缀的永久重定向，所以这显然是个经过考虑的决定。
但理由没有留下。两个月后品牌文档 v1.0 并进来时，两边对不上，只能从重定向的存在反推出「改名是更晚的、刻意的决定」，然后把它记成一条待解决的冲突。
第二条值得多看一眼：代码本身保留了决定的痕迹（那条重定向），但没有保留理由。于是后来的人能确认「这是有意的」，却没法判断「这个理由现在还成立吗」。
动手试
回看你这几天做的事，找出三个符合「换一个选择项目会明显不同」标准的决定。
对每一个，把四项补齐：决定是什么、为什么、依据是什么、当时考虑过但没选的是什么。
第四项写不出来的，说明那不是一个决定，是一个默认。把它标出来——默认不一定错，但你应该知道哪些是你选的、哪些是你没选而发生的。
你的行动
记录至少三条决定，每条四项齐全。
其中至少有一条的「没选的方案」是你真的认真考虑过的，不是为了凑格式编的。
检查标准
- 至少三条决定记录
- 每条都有决定、理由、依据、没选的方案四项
- 至少一条的「没选的方案」是真的考虑过的
- 我标出了哪些其实是默认而不是决定
- 每条都符合「换一个选择项目会明显不同」
容易搞错的地方
它说明你接受了第一个出现的选项。这不一定是错的——时间有限时这往往是对的——但你应该知道自己做的是这种选择，而不是误以为自己比较过。
三个月后回头补的理由，是用今天的认知编的，看起来比当时聪明，但没有任何参考价值。
记录的价值在于它保存了当时的无知：你当时不知道什么、在什么约束下做的判断。这才是以后能学到东西的部分。
本章自测
- 「没选的方案」这一项为什么不能省？
- 什么样的决定值得记，什么样的不值得？
- 为什么事后补写的理由没有参考价值？