手把手用Dify搭建AI复盘工作流，让大模型成为你的决策外脑

“hindsight”这个英文词直译是“后见之明”。英文里有句老话叫“hindsight is 20/20”意思是事后再看一切都清清楚楚就像视力 20/20 一样完美。但问题也恰恰在这里——生活里几乎所有重要决策你都只能在“视力模糊”的情况下做等你看清楚了事情早就过去了机会也溜走了。我做了一个叫 hindsight 的小项目把这句话变成了一个可以运行的 AI 工作流让大模型当你的复盘外脑定时吞掉聊天记录、工作日志、会议纪要然后站在现在的视角把那些当时被你忽略的信号、做错的选择、以及本可以更好的做法一条一条挖出来。这个项目是基于 Dify 搭建的。Dify 是目前相当成熟的开源大模型应用开发平台擅长把多步提示词、模型调用、知识库和外部 API 串成可视化工作流。hindsight 这个名字也是故意起的它不预测未来不帮你做决策它只干一件事——把“后见之明”从一种事后感叹变成一套可重复、可量化、能沉淀的复盘流程。这篇文章我把整个设计思路、工作流编排细节、每个节点的提示词写法以及我在调试中踩过的坑全部摊开讲适合两类人看一是想用 AI 做个人复盘或团队回顾工具的开发者二是已经在玩 Dify、想进一步提升工作流质量的玩家。1. 为什么叫 hindsight把“事后聪明”变成可复用流程1.1 复盘难难在信息早已散落我先说一个扎心的观察。大部分人的复盘是根本不存在的。年底写总结的时候翻聊天记录才想起来三月有个项目差点黄了、六月有个客户差点丢了、九月有个 bug 差点上线。问题出在哪出在复盘依赖的不是“当时的痕迹”而是“现在的记忆”。而人的记忆是最不可靠的存储介质它会美化选择、模糊因果、淡化痛苦。比如你明明当时犹豫过某个供应商的报价事后却只记得“这个供应商一直很靠谱”。这种失真会让同样的坑在半年后再踩一次。所以我想得很清楚复盘的原始材料不是脑袋里残存的印象而是历史文本数据——IM 聊天记录、飞书文档、邮件往来、会议转写文本。这些材料有两个特点一是量大动辄几十万字人根本看不完二是信号密度低关键信息淹没在寒暄、语气词和无关讨论里。这恰恰是大模型的强项。它可以做无损压缩把十万字聊天记录压成十个决策点还能严格基于原文给出结论。hindsight 的第一步就是从“把材料喂给 AI”开始。1.2 为什么选 Dify 而不是自己写代码你可能要说这不就是写个 Python 脚本调 OpenAI 接口吗我一开始也是这么想的但越做越觉得不对。复盘这个场景不是“一次调用”能解决的它天然是一个多步流水线先分段提取事实再识别决策点再做对照分析最后输出结构化报告。如果用代码写你得管理 API Key、处理长文本截断、自己写缓存、做并发控制还得考虑以后怎么把报告推送到飞书或 Notion。而且提示词只要改一版代码就要重新部署非常痛苦。Dify 为我省掉了这些脏活。它把“开始节点 → LLM 节点 → 代码节点 → 结束节点”串成一个可视化工作流每个节点相当于流水线上的一道工序。我改提示词只需要打开对应的 LLM 节点编辑保存就能生效。它自带变量管理可以在工作流里传递文本、数组和对象也有知识库功能可以把历史复盘结果入库作为下一次决策的参考。最关键的是 Dify 支持自托管数据不出内网对于涉及工作敏感信息的复盘场景这一点比用公开的 SaaS 工具安心很多。1.3 hindsight 的整体结构概览在动手之前我先定下整条流水线的逻辑骨架。整个流程一共五个阶段收集原始材料把聊天记录、日志、会议文本按时间范围整理好作为工作流输入。事件提取让模型只做“事实还原”禁止评价把材料压缩成带编号的时间线事实列表。决策点识别从事实列表里找出那些“存在其他选择、可以重来”的关键节点。对照复盘针对每个决策点对比当时的预期和实际结果提炼信号、教训和可复用动作。结构化输出以 JSON 格式输出摘要、亮点、失误、被忽略信号、下一步行动清单。这个结构不是我想当然拍出来的。我参考了企业内部常用的 AARAfter Action Review方法论——先回顾目标再对比结果分析偏差原因最后沉淀经验。Dify 的节点编排天然适合把这种流程数字化。下面我会按这个结构把每个环节的细节和提示词都展开讲。2. 核心设计复盘工作流的四个层级2.1 第一层事件还原先做“没有感情的记录者”很多人做 AI 复盘之所以失败第一句话就写错了。他们让 AI“帮我总结一下这周发生了什么”结果模型输出的是评价“本周团队沟通效率较高项目推进顺利”——这种话对复盘毫无价值。问题在于评价是复盘的终点不是起点。起点必须是干净的事实。所以我在第一个 LLM 节点里设置了非常强的约束系统提示词是这样写的你是 hindsight 的事实提取器只做一件事从用户提供的原始材料中提取客观事实。 硬性约束 1. 禁止输出任何评价性内容禁止使用“高效”“顺利”“不足”“优秀”等价值判断词。 2. 事实必须按时间顺序排列每条事实分配编号 E1、E2、E3... 3. 每条事实包含四个字段时间原文未提及就写“未提及”、涉及人物、事件描述、已知结果。 4. 只允许基于原文提取原文没写的内容一律不填禁止推测。 5. 如果某个时间段没有任何关键事件直接输出“该时间段无关键事件”不要硬编。这里的关键词是“禁止推测”和“原文未提及”。我给足了这个约束的权重因为后续所有复盘结论都建立在事实列表上一旦事实层出现幻觉后面的分析就是空中楼阁。另外一个容易被忽略的小点给每条事实编号。这个编号非常有用后面的复盘节点可以引用“E7”“E12”来指代具体事实既降低了模型输出长度又让结论有据可查。2.2 第二层决策点识别找出“故事的分岔路口”有了干净的事实列表后第二层要做的是从时间线里识别决策点。什么是决策点就是当时存在至少两个可选方案、而你最终选择了其中一条的节点。这是复盘的关键单元。比如“延期上线并接受客户投诉”“临时换了供应商”“拒绝了一个看似不靠谱的合作”。当时看起来稀松平常事后回头看往往是整个时间线里最重要的分岔路口。第二层节点的提示词我这样设计你是 hindsight 的决策点识别器输入是事实列表。 任务找出所有“当时存在选择余地”的关键决策节点。 对每个决策点输出以下 JSON 字段 - decision_id: 决策编号 D1、D2... - decision: 决策内容描述不超过30字 - context: 当时掌握的信息引用事实编号如 E3,E7 - alternatives: 根据原文列出的备选方案原文没提就写“原文未提及备选方案” - final_choice: 最终选择 - timestamp: 决策发生时间或时间范围 注意只输出事实层面的内容本层不做任何好/坏评价。为什么要单独拆一个“决策点识别”层而不是直接让模型边读边评我实测下来的原因是模型在“提取评价”双重任务下总会不自觉地把注意力放在出彩的总结上而漏掉细节里的备选方案。拆层之后模型在这一步只有一个目标识别率明显提升。Dify 的 LLM 节点天然适合这种单任务处理你不需要额外写代码只是多编排一步而已。2.3 第三层对照复盘让模型当“有证据的批评者”这是整个工作流最核心的一层也是提示词最难写的一层。我希望模型输出的是“有依据的洞察”而不是“正确的废话”。什么是废话“加强与客户的沟通”——等于没说。什么是洞察“项目延期 3 天时负责人曾在群里提出要压缩功能范围但这个提议被忽略了最终导致产品演示时核心功能缺失”——这才是复盘要的东西。为了让模型输出这种级别的结论我在提示词里做了三个强制要求每条洞察必须绑定原文事实编号每条建议必须改写成“如果当时…就可以…”句式禁止出现没有主语的泛泛总结。具体的系统提示词如下你是 hindsight 的复盘分析师。输入是事实列表和决策点列表。 请针对每个决策点 D1、D2... 逐一进行分析 1. 预期对比当时的预期目标是什么实际结果是什么请引用对应事实编号。 2. 被忽略的信号回看原文找出当时已经出现、但未被重视的信息线索。每条信号必须引用原文片段或事实编号。 3. 因果解释用 2-3 句话解释“为什么会出现预期和结果的偏差”禁止归因于“运气不好”这类无法验证的说法。 4. 重启建议每一条教训都必须改写成“如果当时…具体动作就可以…具体收益”的格式。 最后用 JSON 输出全部结果。写提示词时有个细节我喜欢把“要求模型做的事”和“要求模型不要做的事”分开写。“不要做的事”往往比“要做的事”更管用。比如上面明确说“禁止归因于运气不好”否则模型特别容易偷懒把一切偏差归因于“外部环境变化”。另外这一步的输出已经是结构化数据了所以 Dify 节点的输出解析方式我设置成 JSON确保下游代码节点能直接使用。2.4 第四层结构化输出让复盘结果可沉淀可推送最后一层是把前面的分析汇总成一份“能行动”的报告。我见过太多复盘工具死在最后一步报告写了人没看收藏了等于没收藏。要让复盘真正起作用输出必须满足三个条件足够短、绑定时点、明确行动。hindsight 输出的 JSON Schema 我打磨过好几版最终固定成这样{ summary: 用 3 句话概括本周期整体情况, wins: [可复用的成功经验每条注明事实编号], mistakes: [明确的失误项每条注明事实编号], signals: [被忽略但很重要的信号], next_actions: [ { action: 具体可执行的动作, owner: 负责人角色如果原文提及, due: 建议完成时间节点 } ] }同时Dify 的结束节点支持输出 Markdown所以我还加了一个“报告格式化”节点把上面的 JSON 渲染成一页纸的复盘报告包含标题、信号高亮和行动清单。这样既方便直接读也方便后续用 Dify API 推送到飞书、钉钉或者自己的笔记系统。这里我强烈建议你保留 JSON 和 Markdown 双格式输出JSON 给程序用Markdown 给人看各司其职。3. 实操过程在 Dify 中搭建可运行的 hindsight 工作流3.1 环境准备版本与模型选型建议动手之前先确认环境。我用的是自部署的 Dify版本在 0.6 以上界面已经相对稳定。如果你只是想快速验证直接用云端版也行但注意数据隐私复盘内容往往涉及内部信息我更建议自部署。Dify 的部署方式很友好官方提供了 Docker Compose 一键启动脚本一台 4C8G 的服务器跑起来完全够用还不吃太多资源。模型的选型我强烈建议你不要只绑定一个大模型。hindsight 的流水线里不同节点吃到的任务难度完全不同事实提取节点读的是长文本、干的是体力活用便宜且上下文窗口大的模型最划算我实测国产的 DeepSeek、Qwen 或 GLM 系在事实提取上表现足够好成本还低分析复盘节点对推理深度要求高这时候再上 Claude 或 GPT 这类旗舰模型。Dify 的模型供应商配置支持同时接入多家工作流里每个 LLM 节点能单独指定模型这一点是它比普通封装接口方便太多的地方。我的经验是提取层用便宜模型分析层用好模型最终效果不输全流程用旗舰模型成本能省 60% 以上。3.2 工作流节点编排与参数设置在 Dify 里hindsight 的工作流从“开始节点”出发。我需要详细说明每个节点的配置因为这里踩坑最多。开始节点定义三个输入变量raw_text文本类型导入的原始材料整段粘贴进来。time_range文本类型时间范围描述比如“2025年1月1日至2025年3月31日”给模型做边界参考。focus文本类型选填本次复盘的重点方向。比如“本月我们要复盘为什么续费率下降”模型会优先关注相关事实。第一个 LLM 节点事实提取的模型参数我把 temperature 调到 0.2max_tokens 给到 4000 左右。为什么 temperature 要低因为事实提取是还原任务越低越稳定宁可不输出也不要胡编。这个节点我建议不要设 max_tokens 太高4000-6000 已经够因为第一次提取的粒度不需要特别细后面还有识别层做二次加工。第二个节点是“代码节点”作用是把上一个 LLM 节点的文本输出转成结构化数组。需要说明的是Dify 自带 LLM 节点的“输出解析为 JSON”功能两种方式我都用过。如果文本输出有轻微格式不齐用代码节点的json.loads()再补个异常处理更稳。我最终选择了“LLM 输出解析 代码兜底”的组合在 LLM 节点里直接勾选 JSON 输出模式然后在代码节点里做一个简单的字符串清洗把所有可能出现的前后缀说明去掉再转成数组。这个兜底代码不长但对后面的流程稳定性贡献巨大。第三个 LLM 节点是决策点识别temperature 同样设低0.3max_tokens 给 3000 就够。第四个 LLM 节点是复盘分析这里我建议 temperature 设在 0.5 到 0.7 之间给模型一点点生成空间因为分析本身就是发散性任务太低会显得机械化。最后一个结束节点我设置成支持output_format变量让它既能输出 JSON 也能输出格式化后的 Markdown 报告。3.3 长文本切分处理“上下文塞不下”的尴尬如果你直接把一整周的 IM 聊天记录粘贴进工作流大概率会遇到两个问题单个 LLM 节点的上下文窗口不够以及模型在处理超长文本时严重“分心”。我的解法是在工作流里加了一个“文本切分器”代码节点规则非常简单按历史格式中的会话时间戳切块如果没有明显分隔符就按每段 800 字左右硬切保持段落完整性。每块文本独立送进事实提取节点得到局部事实列表最后再用一次汇总节点把局部列表合并、去重、统一编号。这里有个细节值得注意事实提取的切块如果太小比如少于 200 字上下文信号太少模型很难判断哪些信息值得保留如果太大超过 1500 字又容易丢信息。800 字左右是我在中文聊天记录上实测下来比较稳的点。另外如果你用的是 Dify 的知识库功能可以直接把长文本塞进知识库然后用“引用”方式做分段召回但这和复盘场景不太搭——复盘需要的是全量时序信息不是相似度召回所以我整条链路没用知识库而是靠切分节点。3.4 提示词模板速查表写提示词是后悔药的核心我把自己最终跑通的提示词整理成一个速查表。注意下面这些提示词是从“节点功能”角度写的实际使用时要根据模型的指令遵循能力微调。节点角色定义核心约束输出格式事实提取没有感情的记录者只提取事实、禁止评价、编号 E1/EnMarkdown 列表决策点识别分岔路口发现者只选有备选方案的节点、引用事实编号JSON 数组复盘分析有证据的批评者每条结论绑定事实编号、禁止无主语总结、用“如果当时…”句式JSON最终汇总报告排版工压缩到一页纸、行动清单必须可执行JSON Markdown我特别想强调一点提示词不是一次性写对的。我前两版提示词让模型直接输出整个复盘报告结果它总是自说自话“原则上”“一定程度上”这类废话满天飞。后来我把“禁止出现的词”直接写进提示词列了一组红牌词“提升”“加强”“完善”“可能”“大概”。效果立竿见影。如果你发现某个模型比如一些国产开源模型遵循复杂指令的能力有限可以适当减少约束数量把最重要的三条放最前面其余放进示例里。4. 踩过的坑与排查技巧实录4.1 模型幻觉原文没有的信息它给你编出来了这是我把 hindsight 跑起来后遇到的第一个严重问题。事实提取阶段的提示词明明写了“禁止推测”结果模型还是在事实列表里编出了一句“客户表示对价格不满意”——这句话在原始材料里根本不存在。后来我一排查发现原因有两个一是输入材料里确实有一句“价格有点贵”的类似表述但说话人不是客户是项目经理二是模型默认把“产品真正用户的抱怨”当成了一个“理所当然”的背景信息自动补齐了主语。解决办法是双管齐下。首先我在事实提取提示词里增加了一条更硬的要求“每条事实中的描述必须能在原文中找到逐字对应的片段。找不到对应片段的一律删掉。”这就让模型必须回溯原文。其次我在工作流里加了一个“证据校验”代码节点自动检查每个生成结论是否引用了有效的事实编号如果一条规则没有绑定任何 E 编号直接剔除。模型还是有概率出错但配合这两个约束之后幻觉率下降非常明显。4.2 长文本输入被截断复盘结果缺胳膊少腿最开始我把整段讨论直接丢给分析节点导致上下文太长后面的内容根本没进模型的处理范围。输出结果经常缺少最后一个决策点的复盘看起来像报告被腰斩了。排查的时候我用 Dify 的调试日志发现 tokens 用量根本没有超上限才意识到问题出在“知识库检索”和“上下文拼装”的机制上。解决思路就是把“切分合并”作为标准动作。现在我的工作流里专门有一个代码节点做文本切分按 800 字一块确保每块都小于模型上下文的一半。然后每个分块单独过事实提取最后再汇总成完整时间线。这个改动看似简单但收益极大——不但解决了截断问题还让每一步提取的专注度更高输出质量整体上了一个台阶。另外提醒一句Dify 的 LLM 节点上下文窗口中要记得把“系统提示词”和“历史对话”的占用也算进去我见过很多人只看用户输入的大小忽略了提示词本身也消耗 tokens。4.3 输出的结论太抽象全是“正确的废话”我最早跑出来的复盘报告充满了“需要进一步梳理流程”“建议提升跨部门沟通效率”这种句子。问题不是模型不会分析而是我没有给它一个具体的“表达格式约束”。后来我在提示词里加了两条硬规矩每个结论必须包含“事实编号 原文片段”的引用没有引用不算有效结论。每条行动建议必须用“谁在什么时间做什么事”的结构化格式写。修改之后模型的输出立刻变得像人话。比如“运营团队在用户反馈群看到功能使用率下降却在 3 天内没有同步给产品团队”这样有主语、有时间、有因果的描述。这里我建议你去看一眼《清晰的表达》里对“具体性”的定义——AI 最难模仿的恰恰是具体的人话而提示词约束能有效引导它往这个方向走。4.4 在 Dify 中调试的实用技巧Dify 的工作流调试功能一开始让我有点懵因为它的预览模式和正式运行是两个隔离的环境。我建议你在每个节点上单独跑一遍测试数据确认单个节点的输出正常后再整链运行。排查的时候优先看“节点运行日志”里的输入输出很多问题一眼就能看出来——比如某个变量是undefined那就是上游节点给的 key 对不上。另一个技巧是变量的命名规范。Dify 的变量 key 不支持中文但你仍然可以在“显示名称”里写中文。我强烈建议 key 用英文蛇形命名比如raw_text、fact_list、decision_points这样在代码节点里写 Python 引用时思路清晰得多。我最初命名得随心所欲结果代码节点里全是“变量 a”“变量 b”维护起来叫苦不迭。4.5 成本控制别让每次复盘都烧掉一杯咖啡钱最后讲一个很多人会忽略的问题成本。hindsight 如果直接跑一条链每次要调假设 3-5 次模型按旗舰模型算一次复盘的成本不低。我最终的成本优化方案是基于层级分模型的事实提取和决策点识别全部用 DeepSeek 或 Qwen 这类低成本模型分析阶段才切换高推理模型。实测下来单次复盘的 API 成本能控制在不到一杯便利店美式的水平。如果你用的是 Dify 云端版记得在“模型设置”里分别配置供应商而不是在工作流里写死模型——这样后续换模型不用改节点。5. 扩展方向从“事后复盘”到“事前预案”5.1 定时自动复盘给团队配一个永不停歇的记录员hindsight 跑通之后我做的第一件事就是给它加了一个定时触发。Dify 支持通过 API 的方式调用工作流所以我写了个简单的 cron 脚本每周五下午自动把团队本周的飞书消息、会议纪要拉下来组装成raw_text传入 hindsight然后把生成的复盘报告推送到团队群。这一步的接入很简单——Dify 的 API 接口是标准 REST 风格脚本本身不到 50 行代码。我实际跑下来效果比我预想的好很多因为机器不会忘事也不会因为情绪回避问题。周报里提到的“上周三讨论中已经有人提出的风险信号”往往是当事人在当时根本没注意到的盲区。5.2 团队复盘把多源数据汇入同一套流程个人复盘用聊天记录就够了团队复盘则需要接入更多数据源比如 Jira 工单状态、Git 提交记录、在线会议转写稿。这些数据的格式差别很大但处理逻辑可以复用统一转成“带时间戳的原始事实”再走 hindsight 的流水线。我在团队版本里额外增加了一个“系统因素 vs 人为因素”的标签维帮助团队避免无休止的互相指责——这一点对复盘特别重要复盘的目的不是追责是把“下次能做得更好”沉淀下来。5.3 复盘结果入库成为个人决策外脑这是我正在做的下一步也是我觉得 hindsight 最值得延展的方向。每次复盘生成的 JSON 都会写回 Dify 的知识库作为“过往经验”保存。当工作流分析新决策点时会先做一次相似度检索把历史相关案例拉到上下文里让模型参考“上次同样的场景下我们踩过什么坑”。这就实现了从“hindsight后见之明到 foresight预见力”的升级——复盘的终点不该是叹息而是下一次决策前的预案。我个人实际使用中最有感触的一点是AI 永远不会替你反思但它会把那些你早就看见、却总是故意忽略的细节一条条摊开在你面前。现在每周做复盘时我会先让 hindsight 出报告再花十分钟自己补一段“机器看不见的东西”——比如当时某个同事的表情比如会议室里的沉默。两相对照往往才是最完整的真相。这个小项目从动手到跑通只花了一天时间耗掉的思路却比代码多得多。如果你也想搭一个自己的复盘系统我最大的建议是别一开始就追求大而全先用一周的材料跑通一条链再慢慢加定时、加知识库让它长成你需要的样子。