hindsight 这个词英文直译是“后见之明”——说白了就是事后复盘的能力。但真正动手做这个项目之前我一直觉得复盘是个特别“虚”的事项目结束了、对话结束了、操作完成了大家坐下来聊一聊说完就散下次该踩的坑一个不少。所以当我把 hindsight 当成一个项目名来折腾时我的目标很清楚把复盘这件事做成一个能落地、能自动跑、能持续沉淀的 AI 应用。前后花了大概两周时间用 Dify 平台从零搭了一套复盘助手这篇文章就完整记录一下我的设计思路、搭建过程、踩过的坑以及最终沉淀下来的一整套可复用的配置和提示词。如果你恰好也在折腾 Dify 做 AI 应用或者一直在找一个能把“事后总结”这个场景真正落地的方式这篇内容应该能帮你省不少时间。我会把我自己的方案、参数、工作流配置、知识库搭建方式全部拆开讲不搞虚的。1. 项目定位与整体设计思路1.1 hindsight 到底要解决什么问题先说一个我自己的观察。绝大部分团队或个人做复盘时注意力都被“记录”这件事消耗掉了谁说了什么、当时怎么决定的、最后结果如何——光是整理这些素材就要花大量时间。等真正开始分析“为什么做得好/不好”的时候精力已经耗得差不多了。所以最后的复盘总结要么是流水账要么是几句正确的废话。hindsight 这个项目的核心就是要把“记录 结构化整理 根因分析 改进建议”这个链路完全交给 AI 去跑。用户只需要把原始素材丢进来——可以是一段对话记录、一份项目日志、一次客户沟通的回放文字稿甚至是一段语音转出来的文本——剩下的事情由工作流自动完成先清洗和归类信息再按复盘框架进行结构化拆解然后结合知识库里的方法论做深度分析最后输出一份包含根因、改进项、行动计划在内的完整复盘报告。说白了我希望这个工具像是一个“复盘搭子”它不替你思考但能逼着你把该看的细节都看一遍把该回答的问题都回答清楚。1.2 为什么选 Dify 而不是直接写代码其实最早我想过自己调 API 写一个 Python 脚本完成所有逻辑。但后来放弃了原因有三条。第一复盘的流程不是固定的今天可能只需要做“项目复盘”明天就得支持“客服对话分析”“销售记录拆解”不同场景的流程差异很大。如果用代码写死每次调整都要改代码重新部署折腾不动。而 Dify 的工作流编排是可视化的改流程就像拖拽积木改完立刻能测。第二复盘这件事需要大量外部方法论沉淀比如 STAR 法则、5 Whys、KISS 原则这些分析框架。Dify 自带知识库而且可以直接挂到工作流的“知识检索”节点里这样我就能把复盘方法论做成可检索的私有知识库让 LLM 在回答时能引用到这些框架而不是凭训练语料瞎发挥。这个能力如果自己写代码得额外接向量数据库、写嵌入逻辑、维护索引工作量立刻上一个台阶。第三Dify 提供了现成的应用发布通道——对话助手、API 服务、嵌入网页的聊天组件都有。我搭好之后让团队同学直接在网页上用或者通过飞书机器人调用全都有现成支持。从项目搭建到真正被用起来中间少走很多弯路。1.3 整体架构一个工作流 两层知识hindsight 的整体架构其实很简单核心是一个包含 6 个节点的工作流开始节点接收用户输入要求用户提供复盘对象的原始素材知识检索节点从复盘方法论库中检索相关框架LLM 节点 1对原始素材做结构化清洗和信息分类LLM 节点 2基于清洗后的结构化信息结合检索到的框架做深度分析和根因拆解条件分支节点根据输入内容类型是对话记录还是项目日志选择不同的指令模板结束节点输出最终复盘报告两层知识分别指外部知识库放复盘方法论、分析框架和系统提示词中内置的领域知识比如客服场景的沟通要素、项目管理的关键指标。前者是动态检索后者是静态约束。这样设计的好处是如果以后要支持新领域不用改工作流只要往知识库里加对应方法论再微调一下分支指令就行。2. 核心功能解析与关键配置2.1 复盘报告需要哪些必填模块这块是我花了最多时间琢磨的地方。最初版本的输出就是一段大文字总结但实测下来效果很差——LLM 总结出来的东西太“圆滑”没有结构性用户看完仍然不知道下一步该干嘛。后来我把输出格式强制拆成了七个模块事件概览用三到五句话概括这次复盘的原始事件关键时间线按时间顺序列出重要节点和决策动作做的好的地方列出具体证据不能只说虚话问题与根因每个问题对应一条根因分析且必须引用原始素材中的具体细节作为依据改进建议每条建议必须对应一个具体问题不能凭空提建议行动计划包含动作、负责人如果是一个人复盘就写“自己”、时间节点复用价值这次复盘中哪些经验可以沉淀为模板或清单供下次使用这样设计的目的很简单复盘报告不是用来“看”的是用来“做”的。没有行动计划的复盘都是白做。2.2 模型选型与参数调优模型我测试了三组GPT-4o、Claude 3.5 Sonnet、以及 Dify 平台内置的国内可用模型服务比如通义千问和 DeepSeek。最终主模型选了 Claude 3.5 Sonnet原因是它在长文本理解上表现最稳尤其是对口语化、带噪音的对话记录能够比较准确地区分“客观事实”和“主观表达”这一点对复盘分析非常关键。参数上我的配置如下参数数值说明温度 Temperature0.2复盘分析需要稳定输出温度太高会导致每次结果波动严重Top P0.7配合低温使用保留一定多样性但不至于发散Max Tokens4096复盘报告内容较长必须给足输出空间频率惩罚0不做额外惩罚避免影响输出完整性这里的核心逻辑是复盘场景下准确性远比“创造性”重要。温度调到 0.2相当于 AI 只会在一个相对紧凑的概率分布里挑选词句不会每次输出完全不同的结论。如果你用 AI 写文案可以温度开高一点但复盘报告不建议否则你连两次复盘的结论都对不齐。2.3 系统提示词让 AI 学会“追问细节”一开始我不写系统提示词直接让工作流里的 LLM 节点自由发挥结果输出内容非常“假大空”。后来意识到问题的根源在于复盘分析最忌讳的就是“想当然”而 LLM 默认行为就是顺着用户给的素材往下滑。如果素材里缺少某个关键信息它不会问而是自己脑补。所以我单独设计了一个系统提示词核心规则是你是一名专业的复盘分析师。你的任务是基于用户提供的原始素材进行结构化复盘而不是回答笼统的管理学问题。你必须遵循以下原则第一所有结论都必须引用原始素材中的具体信息如果素材中没有相关信息你必须明确标注“素材缺失需补充”不得编造第二在分析失败原因时必须逐层追问至少一次区分表面原因和根本原因第三输出严格遵守结构化格式不得自由发挥。这个提示词的效果立竿见影。特别是“素材缺失需补充”这条规则直接解决了 LLM 胡说八道的最大痛点。后续我在做长对话复盘时这个规则甚至变成了整个系统最核心的可靠性保障。3. 实操过程用 Dify 从零搭建 hindsight3.1 创建应用与基础配置打开 Dify 控制台点击“创建空白应用”选择“Chatflow”。这里有一个很重要的选择为什么不选“Workflow”而选“Chatflow”因为复盘助手是一个多轮交互场景——用户第一次输入素材后AI 可能会追问缺失信息比如“你说项目延期但没有说明延期发生在哪个阶段能否补充”这种对话往返就需要 Chatflow 的多轮上下文支持。Workflow 模式更适合一次性批处理任务没有多轮记忆。创建之后在“编排”页面开始配置。第一步是添加变量。我定义了一个必填输入变量source_text类型为“段落”用于接收用户粘贴的原始素材一个可选输入变量scene_type类型为“下拉选项”选项包括“项目复盘”“客服对话复盘”“活动复盘”“通用复盘”。如果没有选择场景默认走通用模板。3.2 知识检索节点把复盘方法论库挂进工作流我自建了一个“复盘方法论”知识库里面目前有 27 个文档包括5 Whys 分析法、STAR 法则、KISS 复盘模型、PDCA 循环、AARAfter Action Review军后复盘模板、客服对话质量评估标准等。知识库配置上有一个关键参数Top K我设置为 4。这个值意味着每次检索最多召回 4 个相关文档片段然后把这些片段一并作为上下文注入 LLM 节点。如果 Top K 调太大比如 10会出现一个典型问题召回内容过多LLM 反而不知道优先遵循哪个框架输出变得又臭又长。4 个对我来说是比较合适的平衡点。分段设置也踩过坑。原始文档如果整篇入库检索到的片段会包含大量与当前场景无关的内容导致 LLM 被干扰。Dify 知识库有“分段设置”选项我把每段长度设为 512 个字符重叠设为 50 个字符并开启“父子分段”模式。这样既保证了检索粒度又不会因为切断导致语义破碎。注意如果你用 Dify 自带的嵌入模型入库之后最好抽一条文档做一次召回测试看返回的片段是否是你要的。嵌入模型之间差别很大不能想当然认为“只要入库了就能查得准”。3.3 两个 LLM 节点的分工设计工作流里我设计了两个 LLM 节点功能完全不重叠。第一个 LLM 节点叫“结构化整理器”。输入是原始素材职责是清洗噪音比如把口语中的废话、语气词、乱码去掉然后按预定义结构输出一份结构化摘要包括事件背景、参与者、关键动作、时间序列、结果、当前遗留问题。这一步不需要做任何分析判断只做清洗和归类。之所以拆出来单独跑一次是因为直接让一个 LLM 节点既清洗又分析生成质量往往不稳定——信息量太大模型会顾此失彼。第二个 LLM 节点叫“复盘分析师”。它的输入是第一个节点输出的结构化摘要加上知识检索节点召回的方法论片段再加上系统提示词。这一步才是真正做分析的地方识别关键问题、逐层追问根因、输出改进建议和行动计划。这种“先清洗再分析”的两段式设计我强烈建议你在做任何需要深度分析的 Dify 工作流时都采用。效果真的不一样。实测对比下来两段式输出的报告质量比单节点一步到位高了不止一个档次——特别是在根因分析的深刻度上差距非常明显。3.4 条件分支按场景切换分析指令在第二个 LLM 节点之后我加了一个条件分支节点。它读取输入的scene_type值然后走不同指令模板选择“客服对话复盘”时会额外注入一组客服场景专属指令重点关注服务态度、问题解决率、话术规范性、客户情绪变化曲线并且要求输出时必须标注“四类沟通红线”是否被触发。选择“项目复盘”时会额外注入一组项目专属指令重点关注里程碑偏差、资源分配风险、沟通协作成本输出时必须包含“实际进度 vs 计划进度对照表”。这里如果你把知识库做的足够完善其实也可以用“知识检索替代条件分支”——让检索引擎自动匹配到对应模板。但我在实际测试中发现知识库召回的不确定性太强不如直接用条件分支来得干净利落。模板触发的准确率是 100%知识库召回做得好也就 90%在需要稳定输出的场景里我宁可选择前者。3.5 发布与接入测试工作流编排好之后发布成 API 服务。Dify 会生成一个 API 密钥和一个标准接口地址支持直接通过 HTTP 调用也提供 Python、JavaScript 等 SDK。我用 Python 写了一个简单的调用脚本放到自己的本地笔记本上跑了一轮真实测试import requests url https://api.dify.ai/v1/workflows/run headers { Authorization: Bearer app-xxxxxxxxxxxxxx, Content-Type: application/json } payload { inputs: { source_text: 我们上周五上线了新版本结果用户反馈登录页流转有问题转化率掉了30%技术说是前端某个组件在低版本浏览器不兼容但测试环境模拟不出来大家争论了很久最后临时切回了旧版本。, scene_type: 项目复盘 }, response_mode: blocking, user: hindsight-test } response requests.post(url, headersheaders, jsonpayload) print(response.json())返回的结果是一份完整的复盘报告。就拿这个例子说如果按我以前的习惯这种“上线失败复盘”基本就是承认问题、找一个人背锅、下次注意测试。但 hindsight 的输出明显更有结构感——它通过 5 Whys 逐层追问最后把问题从“前端组件兼容性”上升到“发布流程缺少灰度验证环节”并给出了一个非常具体的行动计划在新版本发布前先用 20% 流量跑一天灰度并针对低版本浏览器单独出一份兼容性测试清单。这个输出质量超出了我的预期也让我确定了一条非常关键的经验复盘质量的上限不是模型决定的而是你给它的分析框架和指令约束决定的。4. 实测过程中遇到的坑与解决方案4.1 LLM 输出格式不稳定怎么修最初我直接把七大模块的格式要求写在提示词里输出时一会儿多一个模块一会儿少一个模块甚至有时候会用 Markdown 标题有时候用序号格式乱七八糟。后来我换了一种策略在提示词里附上一段示例输出并且要求“严格参照示例格式输出不得增加或删减模块”。这个效果比单纯写“请输出以下七部分”要好得多。LLM 天然擅长模仿你给它一个模板它输出的结构基本就不会走样。另外一个 FIX 是在后处理阶段我加了一个“格式校验”逻辑——如果生成的报告里缺少“行动计划”标题就直接触发一次重生成让 LLM 把缺失的部分补上。这个逻辑可以用 Dify 的条件分支简单实现避免手动一遍遍人工检查。4.2 用户输入太简单分析和了个寂寞这是另一个高频问题用户随手丢来一句话“这周新功能效果不好大家找找原因”。这种素材信息量太低两个 LLM 节点再厉害也算不出什么东西。我的解法是在工作流里加了一个“信息完整性检查”节点。它会先对用户的输入做一个粗略的信息丰度评估——这里我设置了一个简单的规则统计素材中的时间点数量、行动主体数量、结果描述数量。如果三项里少于两项就在输出里追加一句“当前素材信息不足请补充以下内容具体时间节点、相关参与者、实际结果数据”。这句追加会自动出现在聊天界面里引导用户补充信息。实测下来这个检查逻辑至少帮我把“无效复盘”的比例降低了 60% 以上。如果你要做类似工具这一步真的不能省。4.3 长文本素材处理超时或超限做客服对话复盘时经常会出现一次复盘素材就有五六千字甚至上万字的情况。直接全部丢进 LLM 节点经常触发 Token 上限或者处理时间很长。我的方案是在第一个“结构化整理器”节点采用 Dify 的“流式处理”策略把这个 LLM 节点的Max Tokens设置得非常高同时把模型切换到了支持 200K 上下文的 Claude 长文本版本只在这个节点使用大上下文模型。第二个“复盘分析师”节点处理的是清洗后的结构化信息文本量已经大幅缩减所以可以切回普通模型省成本。如果你不想为长文本单独花大模型的钱还有一个笨但有效的办法把素材按 2000 字一段做切片分批调用“结构化整理器”再汇总所有摘要给“复盘分析师”。效果稍差一点点但能把成本压得很低适合自用。4.4 知识库检索到无关内容反而带偏分析这个坑我深有体会。有一次测试用户输入的是“客服被客户投诉态度差”知识库却召回了“发布会活动复盘模板”的内容LLM 在输出时强行套用了活动复盘的结构——“活动时间线”“物料准备情况”“现场人员安排”整个报告看完让人哭笑不得。排查后发现原因有两个一是知识库里文档类型太杂客服复盘模板和活动复盘模板没有做分区二是检索引擎是纯向量相似度它无法理解“客服”和“活动”的语义差异只看到“复盘”“模板”这些高相似度词。修复方式是把知识库拆成多个子库并按场景挂到条件分支之后——选择“客服对话复盘”时只检索客服复盘专属子库选择“项目复盘”时只检索项目复盘子库。这样从源头切断了串库的可能。4.5 多轮对话上下文丢失复盘不连贯这是 Chatflow 模式下很隐蔽的一个问题用户先输入一段素材AI 追问“请补充失败原因”用户补充了但 AI 的回答居然没有把刚才的素材和补充信息关联起来导致前后分析接不上。排查下来是 Dify 的“对话历史”设置在作怪。默认情况下上下文只保留最近两轮而用户补充的信息作为新对话轮次进入上下文时原始素材可能已经被挤出去了。修复很简单在“开始”节点前的“对话设置”里把“历史消息数”调大到 10 轮以上并确保source_text变量在每一轮都被传递。这样 LLM 在做分析时既能看到最新补充又能回头翻到最初的完整素材。5. 提示词模板直接拿走就能用复制我最终版本的“复盘分析师”节点提示词如下你是一名专业的复盘分析师。请基于用户提供的原始素材进行深度复盘分析。 你的输出必须严格遵循以下结构 ## 事件概览 用3-5句话概括本次复盘的核心事件。 ## 关键时间线 按时间顺序列出重要节点每个节点包含时间、行为主体、动作、结果。 ## 做得好的地方 列成清单每条必须引用原始素材中的具体证据禁止空泛评价。 ## 问题与根因分析 列成表格包含问题描述、直接原因、根本原因。根本原因必须通过逐层追问得出不得停留在表面原因。若素材信息不足明确写出素材缺失需补充并跳过该项。 ## 改进建议 每条建议必须对应上述一个具体问题禁止脱离问题的泛泛建议。 ## 行动计划 以固定格式输出包含行动项、负责人、时间节点、可验证的结果指标。 ## 复用价值 提炼本次复盘中可以固化为模板、清单或流程的经验。 总原则 1. 所有结论都必须有原始素材依据禁止编造。 2. 如果素材不充分宁可不写也不要瞎猜。 3. 输出顺序严格按照以上结构不得调整模块顺序。这个提示词我已经用了很长时间在项目复盘和客服复盘两种场景下都非常稳定基本不需要再动。你可以直接复制到自己创建的 LLM 节点里只需要把变量名和你的场景指令做微小调整。6. 一些个人体会把 hindsight 从想法变成能跑的应用整个过程最让我感慨的一点是真正有价值的不是 AI 本身而是你给 AI 设计的“思考路径”。Dify 平台把工作流、知识库、模型应用这些能力包装得很好用但用好它的关键还是在设计者的思路——你得先想清楚复盘该怎么做才能让 AI 帮你做复盘。最后分享一个小技巧在做这类分析型 AI 应用时多养成分步测试的习惯。每调整一次提示词就准备一套已经跑过的旧素材重新跑一遍做对比。你很快就会发现模型输出质量的细微变化——有些改动看似增加了逻辑约束实际效果反而变差了。用固定样本做回归测试是保证 AI 应用迭代质量最朴素也最有效的方法。