决策先落纸，再动手

我们把拍板、排除和翻盘先写进决策记录，再开始产出。这个顺序看起来多了一步，却让每次推进都有来路，也让不同的人能站在同一份事实前继续工作。

故障发生的时候

我们曾遇到一次间歇性的生图故障。页面上的功能忽然不能正常工作，但强制刷新之后，症状又消失了。眼前看起来已经恢复，真正的问题却没有因此变得更清楚。

这种现场很容易催着人立刻给出解释。刷新改变了页面状态，于是前端缓存自然成了第一个怀疑对象。如果沿着这条直觉直接改下去，我们很可能得到一个看似及时、实际没有证据支撑的答案。

恢复不等于定位

一个动作之后症状消失，只能说明两件事在时间上相邻。它不能单独证明动作触到了病因，也不能排除故障恰好在此时自行退去。越是快速恢复的现场，越需要把“现在能用”和“已经定位”分开记录。

如果把恢复当成结论，下一次复发时仍然只能从头猜。更麻烦的是，一个未经验证的解释会进入后续讨论，让所有人都围着错误前提继续工作。我们宁愿暂时保留未知，也不急着用一个顺耳的说法填满空白。

让证据互相印证

我们没有只盯着页面，而是同时核对不同模型的表现、部署配置、前端资源版本和任务触发链路。每个方向都回答不同的问题，也可能推翻前一个方向留下的猜测。排查的目标不是找一个最像答案的点，而是让几组证据能指向同一个判断。

过程中，我们把已经确认、仍待验证和可以排除的内容分开。新的现象出现时，先看它改变了哪一项判断，再决定下一步查什么。这样推进虽然比立即改一处代码慢一点，却让定位逐步收敛，也避免一次偶然恢复把排查带偏。

把判断写在前面

决策记录不是完成后的总结，而是下一步动作的起点。我们先写下看到了什么、哪些解释已经排除、还有什么不知道，再写准备采取的选择和理由。拍板、排除或翻盘发生时，记录也随之更新，而不是等成果出来后补一段漂亮说明。

把记录放在行动之前，还有一个直接作用：人和 AI 都以同一份当前事实为准。后来加入的人能看见判断怎样变化，也知道哪些路已经走过。讨论因此更容易落在证据和取舍上，不会反复争论早已验证过的猜想。

客户应当看见依据

这套习惯也影响着我们怎样为客户做事。范围为什么调整、某个方案为什么放弃、眼前的结果能不能算完成，都应该有可以回看的依据。客户不必跟着检查每一行代码，但不该只收到一句没有来路的结论。

当关键决定被及时留下，合作中的变化就不再像临时起意。客户能看见我们掌握了什么事实、做了什么取舍，以及下一步为什么值得继续。对我们来说，这比表现得永远确定更重要：不知道时诚实保留，知道时拿出证据。