给每个决定留一条反悔条件

去年三月，我把项目里的定时任务从 Celery 挪到了一台跑 cron 的机器上。当时理由很清楚，我也记得自己很满意。半年后这套东西出了问题：一个任务静默失败了两天，没人发现。我坐在屏幕前想复原当时的判断，结果只剩下四个字——「Celery 太重」。

为什么排除掉另一个方案？当时觉得最大的风险是什么？我是怎么说服自己「够用」的？全没了。

那次的教训不是「要写文档」。文档我写了，写的是「定时任务已迁移至 cron，见 deploy/cron.d」。这句话描述结果，不包含任何判断。我真正缺的，是做决定那一刻的输入。

从那之后我加了一个很小的动作：凡是三天后还想不起来为什么的决定，当场花五分钟记三行。我管它叫决策日志，但实际形式更接近于给未来的自己留一张便条。

三行，写在代码旁边

模板大概是这样：

2025-04-12 搜索从 ES 换成 Postgres 全文检索
已知：日查询峰值约 5k，中文分词只要求能切词；未知：明年要不要做相关性排序
反悔条件：查询 P95 连续一周超过 300ms，或出现「必须支持同义词扩展」的需求

第一行是决定本身和日期；第二行分「已知」和「未知」；第三行是反悔条件。

第二行的「未知」是最值钱的一栏，它逼你说出自己在赌什么。上面这条里，我赌的是明年不做相关性排序——如果赌输了，换回 ES 的成本大概是三天，可以接受。写下来的时候我才意识到自己在赌。

存放位置跟项目走，一个 decisions.md，新的加在最上面。我不放笔记软件，理由是它必须出现在我会自然看到的地方——翻代码、看 PR 的时候顺手就扫到了。有几条我是在 PR 描述里直接贴的，评审的人会追问一句「这个反悔条件怎么监控」，比很多设计评审都有效。

成本要算清楚：一条五分钟，一个月真正值得记的也就四五条。小决定不记，改了也就改了。

反悔条件得是一个能报警的东西

我最初写的是「如果性能不行就换回去」。这条等于没写：性能不行是谁说了算？不行到什么程度？换回去的成本谁承担？

后来改成三段式：一个指标、一个阈值、一个持续时间。或者换成一件具体的事。「客户提出按拼音搜索」是事件，可以观测；「体验不好」不是。

这个要求有个副作用，我觉得比日志本身更有用：写反悔条件的时候，你得先确认那个指标现在有没有被采集。十次里有六七次，答案是没有。于是你顺手加一条查询或者一个埋点。这个习惯在悄悄补监控的洞。

还有一种情况是反悔条件写不出来。我的经验是这通常意味着两件事之一：要么这个决定根本没有退路，那它是承诺不是决策，得单独对待；要么你还没想清楚自己在赌什么。后者居多，这时候先别急着动手。

回看只在触发的时候

记录本身不产生价值，回看才有。但我在这件事上失败过：试过每周回顾，两周后就变成走形式，第三周就停了。

现在是一季度一次，只扫两类：反悔条件已经触发的，和明显已经不成立的。十分钟能扫完。

翻了一年多，看到几个自己的固定毛病。都不是什么新鲜道理，但有了日期和当时的原话，就没法再糊弄自己：

• 我系统性地低估跨团队沟通的时间，大致要乘二。不确定这是不是我一个人的问题，但在我身上很稳定。
• 我高估周末的产出，大概高估一倍。
• 我做的技术选型里，一多半最后没有换回去。但这不代表当时选对了，只说明还没到换的成本线。

最值得看的是第四类：反悔条件触发了，但我什么都没做。这类条目才是日志真正起作用的地方，它把「我当时就知道」变成了一条有日期的证据。没触发不等于决定正确，触发了没行动才需要解释。

我还没想清楚的部分

工作上的决定我基本不记。涉及人的、涉及组织的那类判断，写下来本身就是风险，而且很多反悔条件不可观测——「如果这个项目被降级」你说不清降级的标准是什么。所以我的日志里几乎全是技术选型、个人投入、时间分配。这是个明确的限制。

另一个疑问是：写下来会不会让人变保守？我自己的观察是没有，反而变快了，因为动手前就先看过退路长什么样，纠结的时间短了。但样本只有一年多，我不好下结论。

下次你遇到一个回滚要超过一天的决定，先打开一个空文件，敲三行。第三行如果写不出来，那不是文笔问题，是这件事还没想清楚。