上周四我们做完一次线上故障复盘，最后一行 PPT 写着：下次加强测试。散会后所有人点头，可谁都说不清“加强”对应的是哪个具体动作。这种“事后什么都看得清楚”的状态，心理学里有个专门的名字：hindsight bias，后见之明偏差。它最坑的地方不是没用，而是会让我们误以为“看清了原因”等于“获得了改进”。
我做了一个叫 hindsight 的复盘工作流，把这事从人的口头总结变成了可执行流程。工具本身不复杂，核心是靠 Dify 把“回顾 → 反事实推理 → 行动承诺”串起来。运行了两个多季度，我明显感觉到一件事：真正值钱的不是那句“我当时应该怎么怎么样”，而是那句“下一次我具体会怎么选、怎么验证、怎么停下来”。这篇就当一次完整的使用记录，适合那些被复盘会折磨过、又不想把复盘做成形式主义的人参考。
1. 先把“hindsight”这词背后要解决的事拆清楚
1.1 事后追溯和反事实推理是两种完全不同的能力
很多人以为复盘就是“回顾”。回顾只是把发生过的事按时间线重放一遍，而做的事后追溯，往往是确认谁在什么时间做了什么。这很有用，但从 improvement 角度来说，它天然指向责任分派，而不是方案生成。
hindsight bias 真正影响人的地方在于：结果已知后，大脑会重新组织记忆，让“结果”看起来本来就更可预测。换句话说，你复盘的并不是当时那个不确定的世界，而是被结果污染过的简化版世界。所以工具的作用不是“更仔细地回顾”，而是强制生成反事实假设：这是动作 A，它不是动作 B，如果当时换了哪个决策变量，结果概率会有什么不同。
我做的最小闭环只有四步：提取事实，找到关键决策点，生成替代动作，写下验证替代动作是否正确的方法。Dify 里我分别用四个 LLM 节点来处理，不让它一次生成，因为一次生成长输出特别容易混合事实和脑补，分步执行对我后面的质检也方便。
1.2 能改变行动的复盘长什么样
复盘会开得低效，不是成员不认真，而是输出物没有约束。没有约束的结论长这样：“我们沟通不足”“节奏太赶”“测试不充分”。有约束的结论长这样：“下次发布审批前，必须有人单独检查 changelog 中涉及数据库变更的行，并记录 check 结果。”
为了在 Dify 里把“有约束的结论”变成默认选项，我把输出字段固定成几个维度：原始事实、关键假设、替代动作、验证替代动作的证据类型、下一次行动的截止前置条件。下面的对比表是我自己在配置里反复改了很多次才稳定下来的：
| 维度 | 泛泛复盘 | 可行动复盘 |
|---|---|---|
| 结论句式 | “下次要更谨慎” | “下次在步骤 3 增加一次静态检查，若检查失败则暂停发布” |
| 事实来源 | 凭记忆大概描述 | 引用当时记录的事件文本片段 |
| 对过去的态度 | 指责或自我批评 | 把历史决策当作受限于当时信息的选择 |
| 对未来的承诺 | 模糊、不可验证 | 有一句话能明确判断“做了/没做” |
| 可否定性 | 无法反驳 | 能设计一个小实验来验证替代动作是否真的更好 |
这张表其实就是我在 Dify 里提示词模板的骨架。每次生成复盘结果后，我会拿骨架里的维度逐条打分，不合格就退回重写。
1.3 为什么这个场景特别适合放到 Dify 里
我自己写过简单的 prompt 直接调大模型，也可以把即时脚本丢到命令行里跑。但如果想把复盘变成团队日常能持续使用的东西，就会遇到几个问题：要有多角色视角、要查询过去沉淀的经验、要按固定格式输出、要保留会话状态以便下次联动。Dify 的价值在这里就体现出来了：工作流编排帮我拆步骤，知识库用来检索历史经验，会话变量让每次结果能被下次调用。
而且 Dify 应用可以接到 IM 机器人或 API 上，这意味着触发复盘不需要专门打开一个后台，只要像聊天一样把当天事件发过去就行。对日常维护者来说，降低使用门槛比模型本身强一点重要得多。
2. 在 Dify 里搭出最小可用的 hindsight 工作流
2.1 我选用了哪几个节点，以及为什么是它们
第一版我保持了极简，只用了五个节点。别急着堆功能，先把链路跑通，后面再逐环加东西。
- 开始节点：接收复盘对象的文本描述，以及两个变量——事件类型和触发上下文。
- LLM 节点 1：负责从原始描述里抽取“事实时间线”。这一步只做抽取，不做评价，防止模型把主观感受混进事实。
- LLM 节点 2：基于时间线生成反事实分支。这里我会把“当前实际结果”和“其他可选动作”并列要求。
- LLM 节点 3：把反事实分支转换成行动承诺。核心限制是每条行动承诺必须包含“执行条件、执行动作、验证方式”三部分。
- 结束节点：输出整理后的 JSON 结果，并写入会话变量。
这五个节点听起来简单，但第一版跑完我就发现，最难的不是流程编排，而是节点的输入输出字段怎么设计。如果 LLM 节点 1 输出的时间线里混入了个人情绪词，节点 2 的反事实就会偏成“抱怨体”。我用了一个很笨但有效的办法：在节点 1 的提示词里加了一句“你只输出结构化事实，禁止任何含评价色彩的描述，例如‘失误’‘糟糕’‘优秀’”。
2.2 变量设置和知识库的初始配置
开始节点里我定义了三个输入变量：
- event_text：文本类型，表示复盘对象。我限制为不超过 3000 字，避免因输入过长导致后来的事实抽取失真。
- event_type：下拉选择，只有三个选项：项目复盘、日常任务复盘、沟通决策复盘。
- trigger_context：文本类型，可选项，用来描述触发本次复盘的外部信号。例如“用户反馈加载太慢”或“发布后监控曲线异常”。
会话变量是这套工作流里容易被忽略但很重要的部分。我在编排页面里新建了一个会话变量叫 last_commitments，类型是 array。复盘结束时，LLM 节点 3 输出的行动承诺会写入其中。下一次发起复盘时，系统会自动把 last_commitments 注入到节点 2 的上下文中，让模型先判断“本回事件是不是和上次某个未完成承诺相关”。
知识库我最初没有配，后来才加上。经验条目的来源只有一类：已经被实际验证过的行动承诺。比如“增加数据库变更检查”这个动作，在过去三次发布中确实阻止过一次问题，我会把它写成经验条目入库。不要把没验证过的猜测放进知识库，不然检索出来的全是噪声，会严重干扰反事实生成。
2.3 跑通第一版的时间成本
从零开始配置到第一次成功输出结构化总结，我大概花了四十分钟。其中大部分时间不是节点操作，而是调试提示词边界。第一次跑出来的结果让我印象很深：模型把“发布耗时过长”和“发布失败”混在一起，生成了一个看似合理但完全不基于输入文本的假设。
后来我在 LLM 节点 2 的提示词里强制要求：必须先引用输入文本中的原文，再用“可能”句式描述假设。这个规则立竿见影。如果你在自己的 Dify 工作流里也遇到“输出看起来很对，仔细读全是编的”，优先检查的是你的提示词有没有要求模型“引用原文”。
3. 复盘质量的核心不是模型，是提示词的结构
3.1 三段式提示词：时间线还原、反事实生成、行动转化
很多复盘工具难用的原因，是想让模型一口气生成一段漂亮结论。我的做法刚好相反，把一次输出拆成三个有明确边界的子任务。
第一段提示词我只让它提取时间点、角色、动作、结果。示例模板大概这样：
你是一个复盘助手。以下是一段事件描述。请提取事件时间线并输出 JSON。 限制： - 只输出事实，禁止加入评价性形容词。 - 保留原文中出现的具体数值和时间点。 - 每条事件包含三个字段：time、actor、action、observed_result。 - 如果原文没有明确时间，用 approximate_time 字段标注。第二段提示词做反事实推理，这是 hindsight 的灵魂。我不会问“哪里错了”，而是问“在哪个决策点上，哪个变量发生变化，可能会使结果不同”。
基于以上时间线，找出其中最多三个关键决策点。 对每个决策点输出： - decision_point：该决策点所处的事件序号 - actual_choice：原文中实际的选择 - alternative_choice：一个可执行、不依赖马后炮信息的替代选择 - possible_outcome：替代选择最可能带来什么不同结果 - probability_estimate：用低/中/高描述概率变化，并说明依据 注意：alternative_choice 必须是当时信息条件下的人也能做出的选择，禁止用“如果早知道”类描述。第三段提示词才进入行动转化。这一段我会重点限制数量，宁可只产出一条真能执行的承诺，也不要五条空洞口号。
将上一步的替代选择转换为行动承诺。 要求： - 每条承诺必须包含 when、action、check、fallback。 - when：触发条件或时间点 - action：具体动作，不能出现“加强”“充分”“提高”这类词 - check：你如何知道该动作生效了 - fallback：检查失败后的下一步处理 - 最多输出三条，优先级从高到低排列。这三段式如果合在一起写，模型有时也能输出相似结果。但分开之后，每个节点的输出边界更清晰，问题出现时我能很快知道是在哪个环节出错，而不是整条链路重新调。
3.2 强制结构化输出，从源头过滤鸡汤
复盘结果最终一定要落到数据库或者文档里，否则一切都是白搭。我在整个流程里好几个节点用了 JSON 输出，并且通过 Dify 的代码节点做校验，不满足结构的直接置为无效，请求重跑。
举个例子，我在 LLM 节点 3 后面加了一个 Python 代码节点，它只做一件事：检查输出的 JSON 里，action 字段是否包含“加强”“注意”“提高”“优化”“尽快”这类动词模糊词，若包含就自动剔除。这一招虽然机械，但效果极好，因为复盘最核心的价值是“一句话一测”，模糊动词恰恰是毒药。
一个可判断行动的表述应该长这样：“如果下次发布合并请求 diff 中存在 schema.sql 变更，则必须在合并前由第二人进行变更影响检查；若检查未执行，则合并流程自动暂停。”这个表述里有触发条件、动作、验证方式，还可以和后面的事件数据对照，是闭环的核心。
3.3 三种视角复盘可以让 hindsight 更接近真相
单一视角的 hindsight 很容易陷入个人惯性。我在 Dify 里加了三个角色视角，让模型分别切换身份做反事实推断：
- 当时执行者视角：优先考虑信息局限和操作压力，这个视角能减少“事后诸葛亮式的苛责”。
- 复盘管理者视角：关注流程缺口和决策点设计，这个视角负责把问题从个体身上移开。
- 外部观察者视角：假装完全没有内部信息，只凭事件描述提问题，用于发现前提假设和遗漏步骤。
我实现这个功能时没有做三个独立 LLM 节点，而是在第二个 LLM 节点里用 event_type 变量作为条件判断，通过 Dify 的条件分支进入不同提示词模板。例如项目复盘走管理者视角，日常任务走执行者视角，沟通决策走外部观察者视角。这样并联设计既不增加过多节点，也让输出内容贴合场景。
其实在跑几次之后我发现，最有价值的往往是管理者视角和外部观察者的组合。执行者视角容易让模型自动“共情”，从而为过去的选择找借口，这又是另一种形式的 hindsight bias。
4. 从“事后”到“事前”：记忆状态和知识库闭环
4.1 让上次的承诺进入下次的决策上下文
如果每次复盘都是独立会话，系统永远不会“记得”自己说过什么。那就只是个结论生成器，不是学习系统。
我做了一个很简单的闭环：在 Dify 中新增了一个会话变量 last_commitments，它是一个数组，里面每项保存上次复盘的行动承诺、检查结果状态以及发布时间。新的复盘会话启动时，系统会把 last_commitments 的内容追加到提示词前缀中：“以下是之前复盘产生的行动承诺。请先判断当前事件是否与其中某项相关。若相关，则本次的 action 必须显式包含围绕该承诺的推进或停止决策。”
这个设置跑了几周后，出现了一个非常有意思的现象：模型的输出开始频繁出现“该问题与上次复盘中的某条承诺相关，但我未发现该承诺有可见的执行痕迹”。它不只是在发现问题，还在追踪问题有没有被闭环。这种跨会话的连续性，是普通 prompt 完全做不到的。
如果你的项目涉及多用户协作，最好在会话变量之外加一层用户维度。简单做法是把 user_id 也作为会话变量保存，并在启动时映射到该用户的历史承诺列表。这样每个人都只看到自己的“旧账”，不会被别人的一堆历史承诺干扰判断。
4.2 知识库存什么、不存什么
知识库容易变成垃圾桶。很多人觉得既然有知识库，就把所有复盘记录全塞进去，结果检索时十条相关片段全是情绪性总结，毫无实际指导意义。
我的建议是只存“验证过的经验条目”。入库前的校验规则如下：
- 经验条目必须是由行动承诺转化而来。
- 转化条件是这个行动承诺至少在一个后续事件中被执行过，且执行结果满足 check 字段。
- 未验证的假设可以存在临时区域，但不会被知识库检索到。
Dify 知识库本身支持分段和向量检索，我在配置时把块大小设置得偏小，大概 256 字符左右，因为复盘经验往往本质是一句话，太大段落反而会稀释语义。触发查询节点时我设定了 top_k=4，并且只在“需要生成行动承诺”的那一步去检索知识库，其他步骤不检索，以此降低无关片段对事实抽取的干扰。
4.3 接入真实触发时机，别让工具停留在后台
复盘真正有用的时机不是“问题发生后的第二天”，而是“事件刚结束、信息还热的时候”。但现实是情绪化的当下不适合复盘，我的折中方案是设置固定触发点：每天下班前 30 分钟，把当天最值得复盘的一件事发到 IF 机器人里，机器人调用 Dify 应用开始处理。
你如果通过 API 或者 Webhook 接，可以更自由地定义触发条件，例如：
- 发布流程结束，自动捕获发布窗口的关键信息。
- 用户反馈工单被关闭后，抽取工单和解决过程。
- 某个自动化监控出现告警后，把告警信息和相关指标发给复盘应用。
这样做的好处是，输入信息来自系统而非人的记忆，事实漂移的问题被大大抑制。hindsight 工具的输入如果不可靠，后面一切都白搭，所以我后来大量工作都放在“如何把原始信息喂进去”上，而不是过度纠结模型选哪个。
5. 连续跑两个季度，改掉的四个实际问题
5.1 幻觉细节：它开始编造原文里没有的东西
这是最常见的坑。模型在处理长文本时，特别是复盘场景里，会把“最可能发生的事”当作“实际发生的事”输出出来。你一眼看过去发现时间线很合理，一对比原始记录就发现有两处细节根本不存在。
解决办法是严格要求节点 1 的抽取必须引用原文片段。我当时的做法很简单，在提示词中加了一个要求：“每一条事件都必须带有 source_quote 字段，内容是原文中的连续字符串；如果没有找到对应原文，则跳过该事件，不要推测。”
同时，我也尝试了把温度参数调低到 0.2。Dify 里的模型参数面板可以直接设置，这能降低生成时的发散程度。对于复盘这种需要客观性的场景，温度高只会带来优美的废话，不会带来更深的洞察。
5.2 行动项堆积，最后变成一张没人看的清单
跑了大概三周，我就发现一个尴尬现象：行动承诺越积越多，但真正被执行的占比没超过一半。工作流做得再精细，如果产出物没人消费，就还是固定流程。
我采取两个措施。第一，行动承诺数量上限收紧为三条，并且要求最后一条必须是“对当前最大不确定性的对冲动作”，也就是说前两条可以是改进型动作，最后一条必须是防护型动作。第二，引入承诺过期机制：如果一条承诺在七天之内没有被标记为完成，那么它会自动进入“冻结区”，在后续复盘里不再进入提示词上下文，除非当事人主动申请解冻。
这套机制会给人一点压力，但确实会让承诺更聚焦。为了不让人被压垮，我还在输出格式里加了一个 optional 字段，标明该承诺是否匹配当前团队节奏，提示模型不要一味堆高执行强度。
5.3 反思太频繁会把人搞疲惫
刚开始我把触发条件设得非常灵敏，任何异常事件都会自动引发复盘。结果有段时间，几乎每天都有两三次复盘产出，团队的反馈是“信息过载”。这给我们的教训和工具参数关系不大，而是使用节奏没设计对。
现在我把时间盒固定下来：每天最多触发一次，且只能在工作日结束时运行。紧急问题走独立应急通道，不进日常复盘。这样做的原因是，hindsight 本身需要一个安全距离，离事件发生太近，情绪还在高位，反事实推理容易变成自我辩护；离得太远，信息丢失严重，行动承诺和现场细节脱钩。24 小时到 48 小时之间是我个人测下来最舒服的窗口。
5.4 原始信息里的敏感内容和人工复核
复盘对象经常会拿到一些内部讨论记录或者客户反馈，里面可能有账号信息、内部代码路径，甚至是不该长期保留的文字。我一开始没意识到这个问题的严重性，直到知识库里检索出一条包含手机号的内容，这才吓出一身汗。
后来我在工作流前端加了一个代码节点做脱敏处理，规则也不复杂：先把常见的 11 位手机号、括号内项目代号、内部邮箱替换成占位符，再做后续节点。即便如此，我也不会让所有复盘结果自动进入知识库，而是保留“待人工确认”状态，确认无误后才入库。这块在任何工具里都应该是默认操作，不是额外加分项。数据安全这个东西，不是出了问题再补救，而是从入口处就把不该留的东西挡在外面。
6. 这段运行时间下来，我的几句实在话
如果你也想做一个类似的东西，我的建议是别一开始就追求功能完整。先用一个 Dify 工作流把“事件输入 → 反事实生成 → 行动承诺”这个核心链跑通，然后每天用真实事件去喂，连续喂两周，你会很清楚哪一步输出是废话，哪一步值得继续优化。hindsight 这个工作流真正让人愿意用起来，靠的是“它每次都能给你一句可验证的话”，不靠界面美观，也不靠模型多聪明。
现在每次开复盘会，我都会强制大家说“下一次在哪一个决策点做什么动作，结果会有什么不同”。这句话看着简单，但用工具强制起来之后，团队说话的方式变了，不再执着于给旧事定性，而是一直在讨论下一步可执行的选项。我认为这就够了。
最后再分享一个小技巧：把每一轮复盘的结果按固定格式追加到同一个 Markdown 文件里，文件名就叫 hindsight.log。这个文件非常朴素，但它积累了每一次反事实推断和行动承诺，长期下来会形成一份非常独特的团队决策史。后见之明这东西，只有能被重新翻阅，才会真正变成下一次判断的一部分。
