这个框架要解决什么

人机协作的多数失败不在模型能力, 而在过程无法被检查: 目标说不清、判断无据可查、结果无法复盘。本框架把这个过程拆成五个有明确产出与完成判据的步骤, 使它可以被复核, 也可以被改进。

五步是一个循环, 不是一条流水线。沉淀的产出是下一轮观察的输入。

观察

做什么。 收集与这件事有关的原始材料和现象, 不做解释。包括: 实际发生了什么、谁说了什么、数据是什么、既有做法是什么。

产出。 一份未加工的事实清单, 每条可回溯到来源。

完成判据。 清单里每一条都能指出来源; 且不含"因为…所以…"的句子。

特征性失败: 提前解释。 人在记录时会自然地把观察与解释混写——"客户抱怨响应慢 (说明系统性能不足)"。括号里的东西是假设, 不是观察。混写之后, 后续所有分析都建立在这个未经检验的判断上, 而且再也分不出来。★ 在这一步里, 模型的作用主要是提问而非归纳: 让它追问"这条是观察还是推论"。

理解

做什么。 重述问题, 直到目标、边界、判据三者齐备。目标是完成的样子, 边界是不能动的东西, 判据是凭什么算对。

产出。 一份三者齐备的任务陈述, 双方都能复述。

完成判据。 能说出反例——什么样的产出算不合格。说不出反例, 判据就还没成立。

特征性失败: 判据缺席。 目标和边界都写了, 唯独判据留白, 因为它最难写。后果是结果的好坏只能靠感觉, 而感觉在事后总是倾向于接受已经拿到的东西。

假设

做什么。 提出若干可能的解释或方案, 并为每一个标注它成立所依赖的前提。

产出。 一组互斥或至少可比较的候选, 每个附带失败条件。

完成判据。 每个候选都能回答"它在什么条件下会失败"。

特征性失败: 只有一个候选。 只提出一个方案, 意味着决定已经在暗中做完了, 后面的验证只是走过场。★ 这一步是模型贡献最大的地方——它能给出人因为熟悉而不会考虑的角度; 但前提是明确要求"给出彼此不同的方案", 否则它倾向于给同一思路的几种措辞。

验证

做什么。 设计能分辨候选之间差异的检验, 而不是寻找支持既有倾向的证据。

产出。 保留下来的候选, 以及被排除者的排除理由。

完成判据。 至少排除了一个候选。一个都没排除, 说明检验没有分辨力。

特征性失败: 确认偏误式验证。 设计出的检验无论哪个候选为真都会通过。识别方法很直接: 在做检验之前先问"如果这个候选是错的, 我会看到什么不同"。答不上来, 这个检验就没有价值。

沉淀

做什么。 把结论、被否决的选项及否决理由、仍然存疑的部分, 写成下一轮可直接使用的输入。

产出。 一份可被他人接手的记录。

完成判据。 一个没参与过程的人读完, 能复述判断链条并指出其中最弱的一环。

特征性失败: 只记结论不记理由。 结论会过期, 理由不会。只留结论的记录, 在条件变化时无法判断结论是否还成立, 于是只能整个推翻重做。

什么时候适用

• 问题尚未被清楚定义, 且定义本身是工作的一部分
• 判断的后果不对称——错了的代价明显大于慢了的代价
• 同类问题会反复出现, 因此积累有价值

什么时候不适用

• 执行明确的任务。目标、边界、判据都已确定且无争议时, 走完五步是纯粹的开销, 直接做即可。
• 一次性且低风险的事。沉淀的价值来自复用; 不会再遇到的问题, 沉淀是浪费。
• 需要即时反应的场合。本框架的节奏以小时到天计, 不适合分钟级的决策。

代价

诚实地说三项:

1. 前期更慢。 理解与假设两步会显著推迟第一个产出的出现。在压力下这两步最容易被跳过, 而跳过它们正是失败的主要来源。
2. 要求把隐性判断外化。 原本留在脑子里的东西必须写出来。这对个人是额外负担, 收益归于团队。
3. 需要有人维护沉淀。 记录不会自己保持有用。没有人定期整理, 沉淀会退化成一堆没人读的文档。