做项目管理第十年，我越来越觉得 Hindsight 这个词很妙。它的英文原意是"事后的理解"，落到工作里就是我们常说的复盘、回顾、后见之明。你没法在项目进行时拥有它，但它往往比任何事前计划都值钱。为了把这种"事后视角"变得可复用、可量化，我用 Dify 从零搭了一个叫 Hindsight 的 AI 复盘助手：往里面扔一段项目记录，它能顺着时间线把事实、影响、根因、行动项一层层拆开，最后生成一份可以直接拿去开复盘会的结构化报告。这篇文章就写从需求拆解、工作流设计、提示词调优到踩坑记录的全过程，给正在捣鼓 Dify 或者想给团队搞一个"复盘机器人"的朋友做个参考。
这个工具不挑行业。研发团队做项目 post-mortem 可以用，运营团队做活动回顾可以用，一个人做周度自我复盘也能用。核心就一句话：把散落在聊天记录、会议纪要、工单系统里的信息，变成结构化的决策资产。下面进入正题。
1. Hindsight 这个项目到底在解决什么问题
1.1 复盘这件事，难在哪儿
先说一个观察：大部分团队的复盘会开得都很敷衍。不是大家不想复盘，而是复盘这件事天然有几个坎。
第一是记忆偏差。一个项目拖了三个月，过程中谁拍过什么板、哪个环节延迟了几天，每个人的记忆版本都不一样。开会的时候大家各说各话，最后得出的结论往往是"下次注意"这种正确的废话。
第二是情绪卷入。项目搞砸了，当事人本能地防御；项目成功了，大家开始抢功劳。真实信息在这种氛围里根本出不来。
第三是缺少结构化框架。没有框架的复盘会很容易变成吐槽大会，或者变成领导一个人的一言堂。时间花了两个小时，出来一堆散装观点，落不到任何行动上。
Hindsight 项目想解决的，就是这三件事。它假设一个前提：即使原始记录是混乱、主观、残缺的，只要有足够的上下文，AI 可以用中立的框架把信息重新组织成"事实—分析—洞察—行动"四层结构，把人的精力从"回忆和争吵"里解放出来，放到"判断和决策"上。
这里要强调一个区别：总结不等于复盘。总结是在问"发生了什么"，复盘是在问"为什么会发生""哪些假设被推翻了""下次怎么把这件事做对"。Hindsight 的整个提示词设计，都是围绕后面这几个问题展开的，这是项目最核心的定位。
1.2 为什么选 Dify 而不是自己写代码调 API
一开始我也纠结过：这功能不就是一个 prompt 包一个 API 吗？自己写个 Python 脚本调模型不就完了？后来实际做了才明白，复盘的难点根本不在"调一次模型"，而在反复迭代提示词、维护多轮对话上下文、对接不同输入渠道。这些恰好是 Dify 最擅长的地方。
我自己选 Dify 有三条理由。
一是可视化编排省掉了大量胶水代码。事实提取、条件分支、根因分析、报告生成，这些节点在画布上拖一拖就连起来了，改流程不用动代码，业务同学也能参与调试。
二是提示词管理和版本对比是刚需。复盘提示词我前后改了不下二十版，Dify 自带版本记录和调试会话，哪个版本效果更好一目了然，回滚也就是点一下的事。
三是发布集成太省事。Dify 应用可以一键发布成 API，也能配置成网页应用，后面接飞书机器人、接定时任务都是现成的接口，不用自己再搭服务。
补充一句，Dify 支持替换模型供应商。我前期用 DeepSeek 跑通流程，后期实验不同的模型做输出对比，只需要在模型提供商配置里切换就行，整个工作流不用改动。
1.3 一个复盘助手需要哪几个模块
我在设计 Hindsight 时，把整个项目拆成了五个模块，每个模块对应 Dify 工作流里的一个或几个节点。
| 模块 | 职责 | 对应 Dify 能力 |
|---|---|---|
| 信息收集 | 接收原始项目记录、会议纪要素材 | 开始节点 + 长文本变量 |
| 事实提取 | 把杂乱内容清洗为时间线、关键事件 | LLM 节点 + 结构化输出 |
| 目标对齐 | 对照原始目标找偏差 | 目标变量输入 + LLM 分析节点 |
| 根因追问 | 通过多轮提问逼近深层原因 | 对话流 + 条件分支 |
| 报告生成 | 产出 Markdown 报告 + JSON 数据 | 结束节点 + 模板渲染 |
这里我特别想提"目标对齐"这个模块。很多复盘工具做出来只有梳理没有判断，AI 把信息捋一遍就算完事。但复盘真正的价值在于"偏差分析"：当时定的目标是多少，实际结果是多少，差在哪。所以我在工作流里专设了一个输入变量叫 target_goal，让用户把项目立项时的目标贴进去，模型才能做有参照物的分析，而不是凭空感慨。
2. 核心设计：提示词工程与结构化输出
2.1 提示词不该是"帮我总结一下"
如果你直接把项目记录丢给模型说"帮我总结一下这次项目的经验教训"，你会得到一份看似通顺、实则空洞的东西。因为我试过，真的试过。模型会自己脑补出因果关系，把相关当因果，把猜测当事实。
Hindsight 的提示词设计遵循三条原则。
第一是角色和任务分离。先告诉模型它是什么角色——"你是一名有十年经验的敏捷教练"，再给它明确的任务——"基于用户提供的复盘素材，完成事实提取、偏差分析、根因判断、行动建议四个步骤"。角色决定语气，任务决定输出逻辑，两者不能混在一起。
第二是输出约束前置。告诉模型每一层输出应该长什么样，甚至给它章节模板和示例，让它照着填，而不是自由发挥。
第三是禁止事项明确化。我明确写了三条禁止项：禁止在事实层加入猜测，禁止在没有证据的情况下给出因果结论，禁止输出无法落地的空泛建议。这三条禁令是压住模型幻觉的关键。
2.2 "事实—分析—洞察—行动"四层模型
这个四层模型是 Hindsight 的提示词骨架。每一层对模型的要求都不同。
事实层要求绝对忠实输入。模型只能从原始素材里提取事件、时间、人物、数字，并标注信息来源。哪怕素材里明确说了"我感觉是排期的问题"，模型也要把它标为"主观陈述"而不是"事实"。
分析层要求对比与计算。把实际结果和目标放在一起看，算出延迟天数、超支比例、达标率，找出偏差最大的几个节点。
洞察层要求原因推断与证据绑定。每一个 root cause 后面必须挂上对应的现象证据，"为什么会这么认为"要能回溯到事实层的某一条记录。
行动层要求可执行。每条行动项必须包含动作、负责角色、完成时点。没有负责人的建议等于没建议。
我把这个框架直接写进了系统提示词里，模型每轮输出都必须按这个层次走，这样产出物才真的能拿去开会。
2.3 输出格式：Markdown 给人看，JSON 给机器用
复盘报告两种用途：人要读，机器要存。所以我让 Hindsight 一次输出两套内容——一段完整的 Markdown 报告用于展示，一个 JSON 对象用于后续归档和对接工具。
JSON 结构我设计成下面这样，你也直接可以复制去改。
{ "summary": "一句话总结本次项目复盘结论", "timeline": [ {"date": "2025-03-01", "event": "需求评审完成", "source": "会议纪要"}, {"date": "2025-03-15", "event": "开发延期3天", "source": "周报"} ], "deviations": [ {"target": "4月10日上线", "actual": "4月18日上线", "gap": "延迟8天"} ], "root_causes": [ {"cause": "测试环境数据未提前准备", "evidence": "3月20日联调记录", "type": "流程问题"} ], "action_items": [ {"action": "上线前2周冻结环境配置", "owner": "测试负责人", "deadline": "下一个迭代启动前"} ] }注意，我在提示词里特别加了一句：只输出 JSON，不要用 Markdown 代码块包裹。这一步看起来小，但能省掉下游解析时一大半的麻烦，后面我会在排查章节再讲一次。
3. 在 Dify 里从零搭建 Hindsight 工作流
3.1 环境准备
动手之前先把三样东西备齐。
一是 Dify 环境。用云端版还是社区版都行，社区版自己 docker 部署也不复杂，不过我自己更喜欢云端版，省去运维精力。
二是模型 API Key。Hindsight 建议选上下文窗口 32K 以上的模型，因为复盘素材动不动就七八千字，窗口太小三轮对话之后就爆了。DeepSeek-V3、GLM-4 这类都能跑，我默认用的 DeepSeek，成本低效果也够。
三是可选的团队知识库。如果你想把团队的复盘方法论、编码规范、OKR 文档也喂给模型作为参考，可以在 Dify 里建一个知识库，挂到"目标对齐"节点前面。前期没有知识库也可以跑，只是生成的建议会比较通用。
3.2 工作流节点的搭法
下面是我实际搭出来的节点链路，你可以照着画。
第一个节点：开始节点。配置四个输入变量：project_name（项目名）、raw_content（原始复盘素材）、target_goal（原始目标）、review_type（复盘类型，可选"项目复盘""活动复盘""个人周回顾"）。raw_content 用长文本类型，其他用字符串。
第二个节点：事实提取 LLM。把 raw_content 丢进去，温度设置为 0.1，输出结构化为前面说的 timeline JSON。这一步我直接开启 Dify 的"结构化输出"模式，并给一段 JSON Schema 示例。
第三个节点：条件分支。判断原始素材里缺失的关键信息。判断逻辑我用的是一个简单的提示词问模型"以下信息的完整度百分比是多少：目标、时间线、结果数据、责任人"，低于 60% 就走追问分支，高于 60% 直接进分析分支。
第四个节点：追问问题生成 LLM。这个节点比较关键。它根据缺失信息生成 1 到 3 个澄清问题，通过消息节点发给用户。用户回答后，回答内容会回流到事实提取节点，再更新 timeline。我给这个流程设置了最多 3 轮的循环上限，防止无休止对话。
第五个节点：根因分析与报告生成。这是两个 LLM 节点：第一个做四层分析，第二个把分析结果渲染成 Markdown 报告。之所以分开，是因为分析需要看完整事实，而报告需要压缩表达，混在一起会让输出变长且不稳定。
第六个节点：结束节点。同时输出 Markdown 报告和 JSON 结构化数据，分别对应"展示"和"下载/归档"两个出口。
整体流程一句话描述就是：接收素材，提取事实，不够就追问，够了就分析，最后生成报告。没有花哨的东西，但每一步都是必要的。
3.3 变量配置与模型参数
变量和参数是我踩坑最多的部分，直接给大家一个参考表。
| 参数 | 推荐值 | 说明 |
|---|---|---|
| temperature（事实提取） | 0.1 | 越低越忠实录，不允许模型发挥 |
| temperature（根因分析） | 0.4 | 需要一点推理自由度 |
| temperature（报告生成） | 0.3 | 保持严谨，避免华丽辞藻 |
| max_tokens（事实提取） | 2048 | 长项目 timeline 可能很长 |
| max_tokens（报告生成） | 4096 | 报告包含 Markdown 和 JSON 两部分 |
| 循环追问上限 | 3 轮 | 防止死循环，成本可控 |
这里有个技巧：事实提取的温度一定要压住。我刚开始设成 0.7，模型把"版本上线"和"线上故障"之间的前后顺序都给你改写了，看起来合理但完全是幻觉。后来压到 0.1 之后，这类问题几乎绝迹。
4. 让复盘不流于形式：多轮追问与上下文管理
4.1 单轮生成和真实复盘的差距在哪
市面上一堆"AI 总结工具"只能做一次性总结，给一段文本，出几段要点，就结束了。这种工具拿来日常记录没问题，但拿来做复盘是不够的。
真实的复盘是一个对抗记忆惰性的过程。项目经理说"测试环节出了问题"，好的复盘引导者会追问："具体是哪个测试环节""延迟了几天""当时测试负责人有没有提出风险预警"。这些追问逼着当事人把模糊的表达落到实处，而这个"追问—澄清—再分析"的过程，才是复盘里最值钱的部分。
所以在 Hindsight 里，我把单次调用变成了工作流内循环。如果事实提取后发现关键信息缺失，模型先不急着分析，而是生成澄清问题抛给用户，等用户补答之后再进入分析环节。这一步简单但极其重要，也是我做这个项目时觉得最像"真人引导"的设计。
4.2 追问问题的生成逻辑
追问问题不能乱生成。我给追问节点定的约束是：问题必须按四个分类输出，补全的信息也要按分类更新。
四类是：事实类问题、影响类问题、原因类问题、行动类问题。
- 事实类："版本发布时间比计划晚了几天？""这次改动的负责人是谁？"
- 影响类："测试延期影响到了哪些下游里程碑？""这个故障波及了多少用户会话？"
- 原因类："为什么联调阶段没有提前发现环境配置问题？""当初是什么假设让团队决定跳过性能压测？"
- 行动类："下次上线前，你打算在哪个环节补上环境检查？""这个行动项的验收标准是什么？"
追问提示词的写法关键，我直接贴一版给你参考。
你是复盘对话的引导者。 基于事实提取阶段发现的信息缺口，生成1-3个追问问题。 问题必须按以下分类输出，每个问题前标明分类： [事实类] 用于补全缺漏的事件和数据 [影响类] 用于量化影响范围 [原因类] 用于探索深层原因 [行动类] 用于让建议落地 规则： 1. 优先问事实类问题，因为事实不清时其他问题没有意义。 2. 问题要具体，不能问"还有其他问题吗"。 3. 当前对话轮次已经问过的问题不要再问。 只输出问题列表，不要输出解释。实测下来，加上这个分类约束之后，追问质量提升非常明显。没有约束之前模型最爱问的是"你能提供更多背景吗"这种废话。
4.3 上下文管理：如何避免对话历史污染
多轮对话最头疼的就是上下文越来越长，模型越聊越糊涂。我一开始直接把全部历史消息堆给模型，结果第三轮以后模型开始漏掉第一轮里的关键事实，甚至自相矛盾。
后来我做了两件事。
第一，用会话变量维护核心事实表。每次追问得到新信息后，我不把历史消息原样丢给下一个 LLM 节点，而是维护一个 timeline 变量，把新事实合并进去，作为系统上下文传给后续节点。这样模型面对的永远是一个精简过的事实表，而不是一坨聊天记录。
第二，超出窗口就压缩。如果原始素材特别长，超过了上下文窗口的一半，我会在事实提取之后加一个"摘要压缩"节点，把原始素材压缩成 1000 字以内的关键概要，再进入分析阶段。压缩这一步会有信息损失，所以我特意把 timeline JSON 当成"不可压缩的底层数据"，压缩的只是原始文本，不压缩结构化的 timeline。
5. 常见问题与排查实录
5.1 问题速查表
用了一段时间，把最常见的几个问题整理成一张表，方便你排查。
| 症状 | 可能原因 | 解决方式 |
|---|---|---|
| 输出格式不稳定，JSON 解析失败 | 模型把 JSON 包进了 Markdown 代码块，或夹带了解释文字 | 开启结构化输出模式，提示词里写明"只输出 JSON，不要代码块" |
| 多轮追问后模型忘掉关键事实 | 历史上下文过长，关键信息被稀释 | 用会话变量维护 timeline 事实表，后续节点只读事实表 |
| 追问问题太泛，没有信息量 | 提示词缺少问题分类约束 | 按四类问题约束生成，优先补事实类 |
| 报告行动项空洞 | 分析节点缺少目标输入和目标约束 | 确保 target_goal 和 constraint 变量传入根因分析节点 |
| 知识库内容没起作用 | 没有设置检索模式或召回阈值过低 | 检查知识库检索设置，把召回条数调大，阈值降到 0.5 左右 |
5.2 两个真实排查案例
挑两个最典型的案例展开说。
第一个案例是 JSON 解析失败。Hindsight 第一次跑通的时候，结束节点总是报解析错误。我打开调试日志发现，模型输出的 JSON 前面带了一行"```json"，后面还跟着一句"以下是分析结果"。原因很简单：不管你提示词怎么说，模型在低 temperature 下也偶尔会模仿 Markdown 输出习惯。我的解决办法是双保险——Dify 的 LLM 节点开启"结构化输出"并给它训练样例，提示词里再重复强调"不允许输出 Markdown 代码块和任何解释文字"。改完之后解析成功率从 80% 提到了 99% 以上。
第二个案例是"模型失忆"。测试时我用了一个真实项目的 8000 字复盘素材，前两轮追问都很正常，到第三轮的时候模型居然忘了素材里明确写过的"3 月 20 日联调因环境配置失败"。排查发现是 Dify 默认把历史消息全部带进了上下文，导致早期内容被长文本淹没。我把工作流改成：追问节点和历史对话解耦，所有补充信息先写入 timeline 会话变量，分析节点只读这个变量。改完再测，第三轮模型依然能准确引用 3 月 20 日的环境问题。
这两个案例背后是一个通用教训：在大模型工作流里，不要依赖模型做"笔记"或者"记忆"，把关键状态显式地放在变量里，交给流程管理，才是稳定可靠的方案。
6. 从项目复盘到更多场景的扩展
6.1 把 Hindsight 用到个人周回顾
项目复盘跑通了之后，我很快就发现这套框架完全可以平移到个人回顾上。每周五晚上，我把这一周的日记、待办清单、聊天里的事务性内容塞进 Hindsight，把 target_goal 设成"本周三个重点目标"，review_type 选"个人周回顾"，它就能输出一份个人版本的复盘：本周事实时间线、目标偏差、分散注意力的原因、下周三条行动建议。
一开始我以为是玩具，实际用下来发现比很多效率软件都管用。因为电子的日记和待办本来就是零散的，缺的就是这么一层"结构化的回顾"。
6.2 接进团队工具链
更常规的扩展是把 Hindsight 发布成 API，接到飞书或钉钉机器人上。具体做法是：在 Dify 里把应用发布为 API 端点，然后在飞书开放平台建一个机器人，把消息回调转发到 Dify 的 API。这样团队成员在群聊里发一句"复盘一下 XX 项目"，机器人就可以拉起整个工作流并把报告回传到群里。
定时复盘的场景也常见。Dify 的 API 配合外部定时任务，比如每周五下午五点调一次接口，自动把本周工作周报喂给 Hindsight，生成团队周度复盘发到指定群。这一步没有任何魔法，就是把"喂数据"这件事自动化了。
6.3 我的实际使用体会
最后说点真心话。Hindsight 这个项目教给我的最深一课是：AI 复盘工具真正的价值不在它写出来的那份报告，而在它逼你养成的输入习惯。为了让它识别 timeline，你必须把事件和时间写清楚；为了让偏差分析准确，你必须把目标量化；为了让行动项落地，你必须写负责人和时点。这些约束本身，就是生产力和管理能力的提升。
另外一个体会是提示词迭代的收益永远大于换模型。同样的工作流，我从 GPT 换成 DeepSeek 再换成 GLM，只要提示词里四层结构写得清楚，输出质量差距并没有想象中大。反过来，提示词含糊的时候，再贵的模型也给你一份漂亮的废话。
如果你也想搭一个类似的东西，我的建议是不要一开始就追求功能齐全。从一个最简单的版本出发：收集素材、提取事实、生成报告。跑通之后再加追问，再加知识库，再接机器人。每加一个环节都验证一次价值，你会发现这个项目最终长成的样子，跟你最初设想的完全不一样，但那通常是一个更好的样子。
