上个月我在Dify上搭了一个叫做 hindsight 的小应用起因很朴素团队的周复盘写来写去都是那几句空话客服部门的质检记录翻出来全是流水账研发故障后的复盘会开完就散改进项从来没跟进过。我一直在想能不能让大模型把这些“事后总结”变成真正能指导下一次行动的东西。hindsight 就是干这个的——它基于 Dify 工作流搭建输入一段对话记录、事件日志或者项目总结自动输出一份有摘要、有时间线、有问题归因、有可执行行动项的复盘报告。这个项目不算复杂但我从需求拆解到工作流编排、提示词调优、再到接入团队使用前后迭代了将近三周。这篇就把完整的设计思路、Dify 里的配置过程、以及我踩过的坑和排查技巧都整理出来适合已经在用 Dify 做 AI 应用、或者想给团队做一个复盘/质检专用工具的朋友参考。1. 这个项目解决什么问题1.1 hindsight 到底是一个什么东西hindsight 这个名字就是我刻意取的。英文里 hindsight 是“后见之明”的意思心理学里还有个专门的概念叫 hindsight bias中文一般译作“后见之明偏差”。说的是人们在知道结果之后总会觉得“我早就知道会这样”会不由自主地高估自己事前预测的准确性。团队复盘恰恰是这种偏差最容易爆发的地方。研发故障复盘时大家说“这个设计一开始就有问题”客服客诉复盘时大家说“这条话术当时就不该这么说”项目复盘时有人说“我早就觉得排期太紧了”。但这些话都是看到结果之后才出现的对下一次没有任何帮助反而容易让复盘变成追责会、甩锅会。我做 hindsight 这个应用就是想用 AI 做一个尽量“无偏差”的复盘工具。它的核心流程很简单把原始素材丢给大模型让模型先提取事实再做因果分析最后给出行动建议。整个过程强调就事论事先讲发生了什么再讲为什么最后讲下一次怎么改而不是一上来就评判谁对谁错。和通用对话型 AI 应用不一样hindsight 不是让用户聊天它是一条固定结构的工作流。用户输入的内容不同但输出的报告骨架是统一的包括事件摘要、关键时间线、做得好与待改进点、根因分析、行动项这五个部分。这样做的好处是不管谁来用产出质量都不会太离谱也能横向比较不同复盘之间的质量。1.2 为什么复盘这件事需要 AI 帮忙有人会问复盘不是应该靠人来做的吗找几个当事人坐下来聊问题不就清楚了。现实是大部分团队的复盘质量都卡在三个地方。第一个问题是“不敢说”。特别是出了故障、丢了客户的时候当事人有强烈的防御心理话到嘴边会刻意过滤复盘记录里写满“已经加强意识”“后续持续关注”这类正确的废话。AI 没有这个心理包袱它只对输入文本负责不会因为怕得罪人而含糊其辞。第二个问题是“看不见”。复盘需要回溯很长的上下文一个故障可能跨好几天涉及十几个群聊记录、监控截图、代码提交记录、会议纪要。人不可能在半小时内把这些信息全部梳理干净但大模型读取长文本的能力正好适合干这个。配合 Dify 的知识库能力甚至可以把历史复盘报告都存起来让它生成新复盘时自动参考以前的做法。第三个问题是“记不住”。昨天复盘刚定了三个行动项今天就忘得一干二净下周复盘时又提出同样的问题。AI 要做的不只是生成一份漂亮报告更重要的是把行动项变成结构化的数据这样后续可以自动同步到任务管理工具里变成一条条待办。我在 hindsight 里把行动项单独抽取成一个 JSON 字段就是为了方便下游对接。hindsight 适合谁用我的经验是它最适合三类人客服团队的管理者想从聊天记录里定期挖出话术问题和流程堵点研发团队的技术负责人想做标准化的故障复盘以及任何想把“事后总结”和“行动跟进”串联起来的个人或小团队。它不替代人的判断而是把复盘里最累的信息整理、归纳、找差距这部分活先干完把时间留给真正需要人做决策的部分。2. 技术方案与整体设计2.1 为什么选择 Dify 作为搭建底座最初我想过直接写 Python 脚本调大模型 API写个函数把提示词拼好、把返回结果解析好再用 Flask 套一个网页。这种方案对纯个人工具没问题但有一个硬伤改提示词要改代码加一个判断节点要改代码输出格式变了又要改代码。整个复盘流程其实是需要高频迭代的我不想每次都在代码堆里挖逻辑。后来我换成了 Dify。选择它的原因很实际第一Dify 的工作流编排是可视化的LLM 节点、代码节点、条件分支节点可以像搭积木一样连起来调试时每一步的结果都能看到这对我这种喜欢频繁调参的人非常友好第二Dify 里的变量和上下文传递机制做得很直观我可以把长文本分段处理再在下游节点拼接不用自己管理内存第三Dify 支持把工作流发布成 API 服务团队其他成员可以通过接口或应用链接使用不用装任何环境。当然用 Dify 也有代价就是学习成本。如果完全没接触过工作流编排一开始会被“节点”“变量”“上下文”这些概念绕晕。我的建议是先照着平台自带的几个示例应用跑一遍比如客服问答、长文本总结那些熟悉了节点之间的连线关系再动手搭自己的复盘应用会顺手很多。2.2 工作流的整体架构hindsight 的工作流我设计成五个阶段每个阶段对应 Dify 里的一个或一组节点。第一阶段是输入处理。用户把原始素材粘贴进来可能是一段客服对话、一份故障时间线、或者一段项目复盘备注。这里我接了一个 LLM 节点做“素材归一化”让模型先判断素材类型然后提取出发言人、时间、关键事件输出一段标准化的事件描述。这样做的好处是后面的复盘主节点不需要处理乱七八糟的原始格式。第二阶段是上下文增强。如果开启了知识库功能这里会检索历史复盘报告把最相似的三条作为参考塞给复盘主节点。这个阶段我用了 Dify 的知识检索节点关键词用第一阶段提取出的“事件类型”和“问题关键词”。检索到的内容会通过变量传递到下一阶段让大模型参考历史做法避免每次都从零开始想改进方案。第三阶段是复盘生成也是整个工作流的核心。这里接入主 LLM 节点输入是归一化后的事件描述和知识库参考内容输出严格按照提示词里要求的格式来最终解析成五段式复盘报告。这个节点我单独会讲提示词怎么写非常关键。第四阶段是结构化提取。复盘生成节点的输出是一段很长的 markdown 文本直接拿来用也能看但如果要接入任务管理工具就需要把行动项单独拆出来。所以我在后面加了一个代码节点用 Python 解析主节点的输出提取所有“行动项”相关行组装成一个 JSON 数组。第五阶段是输出与展示。Dify 的最终输出节点把五段内容拼装成一份完整的 Markdown 报告用一个简单的页面渲染出来。前端不需要额外开发直接走 Dify 自带的应用预览就行。这五个阶段的逻辑是单向流动的中间没有复杂循环所以工作流并不难维护。真正需要花心思的是第三阶段也就是提示词的设计。2.3 复盘报告模板设计在写提示词之前我先把“一份合格的复盘报告应该长什么样”想清楚了。如果连模板都不明确大模型输出就一定会飘。hindsight 用的模板固定五段式。第一段是事件摘要用三到五句话讲清楚这次复盘是针对什么事件、发生在什么时间范围、核心业务影响是什么。这里要求模型只做客观概括不许夹带评价。第二段是关键时间线把原始素材里涉及的重要时间点按先后排列每个节点用“时间 事件 相关人员/系统”的格式。这段的主要作用是让读者快速还原现场。第三段是做得好的地方与待改进点各列两到三条每条必须对应到原始素材里的具体证据不能出现“沟通不够充分”这种没有出处的判断。第四段是根因分析要求从流程、工具、人员、信息传递四个维度归因而且每个原因都必须写清楚“是什么触发了这个问题”“它为什么没有被提前发现”“它是不是反复出现过的模式”这三件事。第五段是行动项每一条都必须包含“要做什么、谁来做、什么时候完成、怎么验收”四个要素。如果原始素材没有提供负责人信息模型必须输出“待指定”不许瞎编。这套模板是 hindsight 的灵魂。我后面调提示词的所有动作都是为了让模型更稳定地遵守这个模板。3. 核心实现提示词与节点配置3.1 复盘 Prompt 的写法与逐句拆解hindsight 的主 LLM 节点用了一长段系统提示词我以实际用的版本为基础拆解开讲一下设计意图。里面涉及的关键词是“从事实到判断”“引用原文”“无归因不行动”。你是一个专注于事后复盘的分析助手。你的任务是基于用户提供的素材生成一份结构化的复盘报告。 你需要遵守的原则 1. 严格区分“事实”与“判断”。先列出发生在时间线中的客观事实再进行原因分析。 2. 所有结论必须能在素材中找到对应依据引用时使用原文片段。 3. 不预设责任人不输出“某某应该负责”的表述而是指出“哪个环节在什么条件下出现了问题”。 4. 行动项必须可执行、有时限、有验收方式无法确定的信息写“待核实”或“待指定”。 请按以下结构输出报告 一、事件摘要3至5句话只概括事实 二、关键时间线每条格式时间 | 事件 | 涉及对象 三、做得好与待改进点各列出2至3条每条后注明依据 四、根因分析从流程、工具、人员、信息传递四个维度分析每个原因需回答触发条件、为何未被发现、是否反复出现 五、行动项每条格式动作 | 负责人 | 截止时间 | 验收标准 输入素材 {{#context#}} 这段提示词里我最看重的是“从事实到判断”这条约束。复盘最容易出的问题就是模型跳步看到结果后直接反推原因输出的内容表面上合理、实际上完全是猜测。所以我要求它先列时间线再给依据最后才做归因每一步都要有原文支撑。另一个关键设计是“不预设责任人”。这里不是要回避问题而是因为 AI 根本没有能力知道真实的责任边界。如果提示词里没有这条模型会凭文字里谁说话多、谁名字靠后这些表面特征随手把锅扣到某个人头上这是我最不能接受的输出。改成“哪个环节在什么条件下出了问题”之后分析明显更有价值也更安全。“行动项必须可执行”这条是为了防止模型写空话。之前测试的时候模型输出过“加强培训”这种行动项这根本不是行动项是一句愿望。所以我在模板里明确要求“动作、负责人、截止时间、验收标准”四要素齐全否则这条行动项就会被判定为不合格。效果立竿见影输出的建议基本都能直接贴到任务清单里。最后是输入变量{{#context#}}。在 Dify 里这个变量由上游节点传入是第一阶段归一化后的事件描述。也就是说主 LLM 节点接收到的不是原始乱糟糟的素材而是已经整理成相对规整的文本。这里做一个上游处理非常有用能显著降低主节点的输出漂移。3.2 在 Dify 中一步步搭出工作流具体操作部分我按实际搭建路径写出来如果你也想复刻可以照着走。第一步在 Dify 控制台创建一个空白工作流应用类型选择“工作流”而不是“聊天助手”。因为我们的场景是一次性输入、一次性输出不需要多轮对话状态聊天助手反而会带来多余的历史会话干扰。第二步添加输入变量。在工作流画布的“开始”节点里我加了一个名为raw_input的文本输入框用于接收用户粘贴的原始素材。同时在应用编排界面里写清楚输入框的提示语告诉使用者“请粘贴要复盘的内容支持对话记录、时间线、项目总结等”。这一步别偷懒好的输入引导能避免一大半用户迷惑。第三步配置素材归一化节点。这里加一个 LLM 节点名字叫“素材归一化”模型选的是 gpt-4o-mini 这个级别就够用因为任务不复杂不需要最强的推理能力。提示词里让它判断素材类型然后抽取关键信息格式化为固定结构事件类型、发生时间、参与者、关键事件列表。输出变量我命名成normalized_content。第四步配置知识检索节点。这一步是可选的但如果你的团队已经积累了一定数量的历史复盘强烈建议打开。我用 Dify 里的“知识检索”节点连接到一个上传了历史复盘文档的 Knowledge检索关键词取自上一步归一化结果里的“事件类型”和“关键事件”列表。检索到的内容输出为history_ref变量。第五步配置复盘主节点。LLM 节点选用更强的模型我这边用的是 claude-3.5-sonnet 和 gpt-4o 轮流测总体感觉 claude 的输出更稳重gpt-4o 的格式服从性更好。提示词就是上一节那段完整的内容系统角色填好输入变量从normalized_content和history_ref读取。输出变量命名review_report。第六步配置代码解析节点。这里用 Python 节点比较省事我在里面写了一个简单的解析函数把review_report里的“行动项”部分抽出来按行切分写入action_items变量。同时加上兜底如果解析失败就返回一个空数组。第七步配置最终输出节点。输出内容我用 Markdown 模板拼装把事件摘要、时间线、好坏点、根因、行动项依次列出来再把action_items以表格形式渲染。这一步也是用户最终看到的页面。第八步测试与发布。在画布右上角点击“运行”输入一条测试对话逐个节点查看输出是否正确。确认没问题后点击“发布”生成应用链接和 API 接口团队里的人就可以直接使用了。整套流程大概花一两个小时就能搭完剩下的时间全在调提示词和修边界 case后面会专门讲。3.3 结构化输出的兜底方案大模型输出不稳定是常态尤其是要求它输出 JSON 的时候。我在开发过程中遇到一个很典型的情况主节点的复盘报告生成得很好但代码节点解析不到行动项因为模型有时候用“Action Items”有时候用“行动项”有时候还会在上面加一句标题把解析逻辑搞崩。我的解决办法是双保险。第一层在提示词模板里明确要求“行动项”部分不要输出任何多余文字只要内容本身第二层在代码节点的解析函数里做兼容按多个关键词去匹配匹配不到就返回空数组不让整个工作流报错。代码逻辑大概长这样import json def main(review_report: str) - dict: lines [line.strip() for line in review_report.splitlines() if line.strip()] action_lines [] in_action False for line in lines: if 行动项 in line or Action in line: in_action True continue if in_action: if line.startswith(#) or line.startswith((一、, 二、, 三、, 四、, 五、)): break action_lines.append(line) if not action_lines: return {action_items: []} return {action_items: action_lines}这个节点说起来只是一个简单的字符串处理但实际价值很大。它意味着即使大模型的格式输出偶发出错工作流依然能正常返回结果不会在集成层直接崩溃。我在很多 Dify 项目里都习惯加这种兜底代码节点效果就是整体稳定率高了很多。4. 实操过程与效果调优4.1 用一组客服对话跑通全流程光讲架构有点虚我用一组实际测试数据演示一下 hindsight 的工作效果。这里我构造了一个客服场景输入内容如下:【聊天记录】 12月2日 10:02 用户A我买的东西两周了还没到物流信息一直停在“已出库”到底怎么回事 10:03 客服B您好请稍等我帮您查一下。 10:05 客服B查到了您的订单比较特殊需要从外省仓调货预计还要5天。 10:06 用户A你们怎么不提前说我等着用呢。 10:07 客服B非常抱歉我这边无法修改物流只能帮您催一下。 10:08 用户A那我要你们客服干嘛我要投诉。 10:10 客服B那我把您的问题记下来反馈给物流专员最迟明天给您答复。 10:12 用户A明天我现在要用啊 10:15 客服B实在不好意思目前仓库那边确实还没有更新。 【补充备注】 用户A已完成投诉工单Z001要求赔偿10元无门槛券。用户把这些粘贴进 hindsight 的输入框点击运行后工作流会依次完成五个阶段的处理。最终输出的复盘报告里事件摘要写的是“用户因订单物流信息长时间未更新产生不满客服未能采取即时补救措施导致投诉升级”。时间线把上面聊天的关键节点都列了出来。待改进点里有一条是“客服在首次回复时没有主动说明跨仓调货原因导致用户等待后才得到信息依据是聊天记录第2至5条”这个依据引用得就很准。行动项部分输出是这样的动作负责人截止时间验收标准在订单详情页增加“跨仓调货预计时效”提示产品部12月15日用户可自助查看预计到达时间客服首次查询物流时如发现跨仓情况必须主动告知原因客服组长12月10日质检抽听5条录音确认话术升级工单Z001的处理机制超时订单自动触发短信提醒技术部12月20日超过48小时未更新的订单自动预警看完这份输出我第一反应是这次调出来的效果终于能看了每条行动项都有人、有期限、有验收方式可以直接放进任务池里跟踪。而且注意它没有说“客服B态度不好所以扣奖金”而是指出“流程里缺少提前告知机制、缺少超时自动提醒机制”这就是我想要的复盘角度。4.2 评估复盘质量的四个指标应用不能只靠“感觉好用”还是要有一个客观标准。我给自己定了一套快速评测方法准备了 20 条测试素材涵盖客服投诉、项目延期、研发故障、活动效果复盘四类然后每次调完版本都把 20 条全部跑一遍用四个指标打分。第一个指标叫结构完整率看输出报告里五个大段落是否齐整有没有丢失某个部分。第二个是指标是依据覆盖率逐条检查做得好/待改进点是不是都带上了原文依据如果出现空泛结论就不给分。第三个是行动项可执行率统计输出行动项中四要素齐全的比例这个是所有指标里最关键的因为复盘再漂亮行动项不可执行就是废纸。第四个叫幻觉率具体做法是拿输出报告里的关键断言逐条回原始素材比对看有没有出现素材里根本没有的信息。这四套指标我直接用电子表格统计每跑完一个版本就打一次分。实际看下来结构完整率从最初的 55% 提升到 90% 是相对容易的只要提示词里把模板写清楚就能做到。真正难的是行动项可执行率从 40% 到 80% 花了我两周时间核心突破点在提示词里加的那句“动作、负责人、截止时间、验收标准”四要素约束。幻觉率一直保持在 5% 以下在没有接入知识库之前反而高一点接入历史复盘后低了很多因为模型更倾向于借鉴历史里的成熟表述。如果你也想做类似的应用建议保留这个评测习惯。没有评测你在调参时很容易被一两条好结果骗到以为效果已经很棒了实际上换个输入就翻车。用固定测试集持续跑才能确认每个改动是不是真的带来正向效果。4.3 指标差时的调优路线不同的指标出问题对应的调优方向完全不同。我整理了一条自己常用的调优路线。如果是结构完整率低比如经常漏掉根因分析或者时间线优先检查提示词的模板约束是否够强硬。可以在系统提示词里加一句“以下五个部分必须全部输出顺序不能变每部分用小标题分隔不要输出小标题以外的内容”这样能压住大部分模型跑题。还不行的可以试几个 few-shot 示例把一份完美的复盘报告作为例子直接放进提示词。如果是依据覆盖率低也就是模型爱自己发挥那问题多半出在没有强调“引用原文”。解决方案是在每个结论后面都强制要求写“依据原文摘录”。可以在提示词里加一个例子对比比如“好的复盘会写‘客服没有主动说明跨仓信息依据是聊天记录第3条客服回复’坏的复盘会写‘客服沟通能力不足’”。模型看过正反例之后输出质量会明显上一个台阶。如果是行动项可执行率低我强烈建议对提示词做“结构化输出”处理不要让模型自由发挥。比如明确要求每条行动项必须以“动作|负责人|截止时间|验收标准”竖线分隔然后用代码节点按竖线分隔符切分稳定性很高。自由文本格式下模型很容易写着写着就把某个要素漏了。如果是幻觉率偏高先检查是不是输入素材本身太乱。大模型对乱序文本里的细节把握不牢容易张冠李戴。这个问题我在客服对话场景里遇到过一次后来把素材归一化节点里“按时间重新排序”的要求写进了提示词情况立刻好转。第二个手段是加一个代码节点做基础校验把输出报告里的时间、数字和原文做简单比对不一致就打标记再由用户决定是否采信。这个节点虽然不能完全消除幻觉但能避免 AI 报告里的错误信息被直接当成事实传播出去。5. 常见问题与避坑实录5.1 典型问题速查表现象原因解决办法报告老是漏掉某一个段落提示词模板约束不够强在提示词里写明“五部分必须全部输出”并加一份完美示例结论找不到原文依据模型在凭常识推断提示词要求“每个结论后必须引用原文片段”行动项写得太空泛比如“加强培训”模型没有被强制要求结构化表达要求行动项按“动作/负责人/截止时间/验收标准”四要素输出输入很长时报告质量明显下降上下文过长导致关键信息被稀释先做素材归一化提取时间线和关键人物事件再进入主节点模型输出包含原始素材没有的信息幻觉增加编码节点比对时间和数字并在提示词里强调只允许引用素材两次运行同一条输入输出差异很大温度参数太高或模型不稳定把主 LLM 节点的温度调到 0.1~0.2并让输出全部以模板化结构呈现代码节点解析不了行动项模型标题格式不一致用兼容多个关键词的解析方法解析失败返回空数组兜底接入知识库后反而变差检索到的历史报告相关性太低优化知识检索的查询词只传事件类型和核心关键词不要传整段长文本这张表是我实际排查故障时的核心清单。如果你是完全新上手遇到问题不要马上动大模型相关的参数先从工作流的上游节点查起看看进入主节点的输入是否符合预期。往往问题出在前一步而不是模型本身。5.2 调试复盘 Prompt 的三个技巧第一个技巧固定测试集每次改动只动一个变量。我给自己定过一个规矩每次跑测试只改提示词里的一个地方比如这轮只改“依据引用”的表达下轮再改行动项格式。同时改多个地方效果好坏根本分不清是哪条改动起的作用。第二个技巧用正反例做“少样本约束”。模型对“不要做某件事”的指令理解得往往不如“应该怎么做”那么好所以我在提示词里放了一段强格式范例。具体到复盘场景我在接口里加了“以下是一个符合规范的输出片段”把之前手动调出来的完美报告放了进去。模型会把这份片段当作格式模板输出稳定性比只写规则强很多。第三个技巧模型用降级策略。我在 Dify 里给主 LLM 节点配了多个模型池优先用 claude-3.5-sonnet它结构感最好如果调用失败或者超时自动切 gpt-4o再不行降级到 gpt-4o-mini 保证流程还能跑。Dify 的模型管理里支持配置多个 provider我用的是阿里云和国外几个主流的兼容接口都统一封装成 OpenAI 格式接入切换模型只需要改一个参数非常方便。5.3 踩过的坑分步节点比单 Prompt 更可控我最开始做 hindsight 的时候图省事直接把原始素材连同复盘模板一次性丢给大模型让它“直接输出完整报告”。当时在自己手写的十来个测试例子上效果很好觉得成了。结果放到团队里一测问题全出来了客服记录太长模型到后面忘了开头的关键投诉点时间线顺序经常错乱根因分析和行动项经常互相矛盾。后来我把流程拆成素材归一化和复盘生成两步效果立刻改善。拆开之后第一个节点只需要做信息抽取任务简单模型不容易漏第二个节点面对的是已经整理好的结构化输入注意力可以全放在分析质量上。这个思路其实很老套就是“每个环节只做一件事”但在 LLM 应用里特别容易被忽视。模型一顿能做的事再多拆给几个模型分头干稳定性和可控性都会明显更好。另外一个坑是关于温度的。一开始我把温度调成 0.7图的是输出更灵活更有创造性。复盘这件事完全没有创造性需求它需要的是共识和稳定同一场故障复盘两次结果不一样团队就会对工具失去信任。我后来把主节点的温度压到了 0.2 左右输出稳定了很多代价是语句确实会显得平一点但复盘报告本来也不需要文采。还有一个小坑是 Dify 的变量传递。我一开始直接在代码节点里写死变量名结果上游节点一改名这边就找不到数据了。后来我养成了习惯所有变量的名字在工作流搭建初期就定好后面只改节点内部逻辑不改变量名。这个习惯让我少踩了很多坑。最后分享一点个人体会我在这几周里反复调 hindsight最大的感受是复盘做不好不是人不够聪明而是流程太容易返工。AI 不能替你思考但能帮你把素材里的事实摆整齐把落入思维惯性的判断拉回来。从实际效果看hindsight 真正帮我解决的并不是“下一次做得更好”这个宏大命题而是把“复盘产出”变成了可以跟进、可以考核、可以检索的东西。如果你也想搭一个类似的应用我建议不要一上来就追求全面。选一个最小的场景比如每周团队例会后的个人复盘或者客服周报里的投诉处理记录先跑通 Dify 工作流把提示词的稳定度调出来再慢慢叠加知识库和行动项跟踪。我现在已经在着手把行动项自动推送到团队的任务管理工具里让回顾和跟进形成闭环这条路走通之后复盘才真正变成了工作的一部分而不是每月一次的形式表演。