1. 项目思路拆解为什么偏偏是“事后诸葛亮”hindsight 这个词英文里多少带点自嘲——“事后诸葛亮”的意思。大伙儿聊天时说某某人 hindsighted通常不是夸人。但做 AI 应用这两年我反而越来越觉得“事后”这个视角是被严重低估的黄金视角。这个项目是我用 dify 搭的一个会话复盘工具名字就叫 hindsight。核心干一件事把会议录音、群聊记录、项目周报日志这些乱七八糟的原始素材丢进去它能在事后站在“上帝视角”把当时没吵明白的、没记下来的、没想透的问题二次咀嚼然后用一整套复盘框架输出结构化报告——包括决策点回溯、情绪张力分析、争议焦点提炼以及下一步行动计划。当时起这个名儿还有另一层意思bias 是“既有偏见”hindsight 反向操作把偏见变成生产力。人脑的 hindsight bias 让我们总记着“我早就知道会是这个结果”但大模型没有这种记忆包袱它是真的能掰开揉碎看全过程。所以我做的不是又一个会议纪要工具而是要逼着 AI 当一个“高情商的、记忆力完好的、事后才开口说话的老同事”。这项目适合谁说实话第一批用上的人是产品经理和项目经理——他们每周的周报、复盘会、需求评审多到吐。后来发现做知识管理的个人用户和做用户访谈增长的人也爱用因为他们手里有大量聊天记录需要提炼结论。只要你的工作里存在着“说完了就完了”的场景hindsight 就比任何总结工具都值得试一次。2. 核心细节剖析dify 底座的优势和复盘框架的设计逻辑2.1 为什么选择 dify 而不是直接调 API 或写死代码很多朋友问我一个复盘工具为啥非得用 dify自己写几十行代码调用大模型不行吗当然行但你会死在三件事上历史上下文管理、知识库检索、可视化调试。我自己最开始就是用 Python 调 API 裸写的本地跑通很容易一接真实数据就崩。会议记录五六千字聊天导出更夸张动不动就几万 token哪怕是 Claude 的 200K 上下文也烧不起。用 dify 最大的收益不是省那点代码量而是它自带了一套完整的“数据管道工作流编排长文本处理策略”。具体到 hindsight 这个项目dify 帮我解决了三个最头疼的问题长文本的分段和摘要策略dify 能在知识检索节点里自动做分段处理配合重排序模型把超长记录拆成多个相关块只取每个块的摘要进入后续分析节点。这比我自己写文本切割函数稳得多。工作流的可视化调试复盘分析不是一个 LLM 调用能搞定的至少要 3 到 5 个不同角色的 LLM 节点接力。dify 的流程图模式可以让我在浏览器里拖拽、随时查看中间输出结果不需要反复 print 调试。多模型混用分段摘要用小模型省钱深度分析用最强模型情绪分析用一个专门微调过的小模型。在 dify 里每个节点独立配置模型成本能压到纯调 API 方案的三分之一。注意不是买 dify 的云服务才叫用 dify。自托管版本完全够用docker compose 拉起来就能跑只要你有一台能联网的普通服务器或本地机器。数据敏感的项目建议直接走私有化部署这点我后面细说。2.2 复盘框架别让大模型自由发挥我踩过最大的坑是让大模型“自由发挥”复盘。输出乍一看很华丽细读全是正确的废话“本次会议讨论了项目进展明确了下一步方向建议加强沟通。”这种复盘毫无价值。所以我在设计 hindsight 的工作流时先锁死了一套复盘框架再让模型填充内容。这里用的是经典的“四层复盘法”不是我自己发明的是从埃森哲的 AAR行动后反思方法论改造来的第一层 · 事实还原发生了什么按时间顺序提取关键事件、决策动作、发言要点。第二层 · 偏差分析原定目标和实际结果的偏差在哪是哪几个决策导致了偏差这里要输出因果链不能只列表面现象。第三层 · 情绪与协作复盘会议里的争论点、情绪爆发点、沉默点分别在哪里哪些人的观点被忽略过第四层 · 可复用经验如果再来一次哪些动作要保留、哪些要杜绝、哪些要新增输出成“保持/停止/新增”三类清单。这套框架被我用提示词固定下来模型没有发挥空间只能按这四个模块填内容。效果立竿见影。2.3 三个关键参数温度、上下文窗口、分段粒度在 dify 里配置 LLM 节点时有三个参数我和团队反复调了一周。温度Temperature复盘任务不是创意写作温度必须压在 0.2 以内。最开始我用了默认的 0.7结果模型在“事实还原”部分就开始加戏把猜测写成事实把推断说成确信。后来我把所有分析类节点统一设成 0.1-0.2生成类节点如报告美化、建议润色才放宽到 0.4。上下文窗口dify 里有系统提示词、前缀指令、用户查询几个不同的输入位置。我的经验是复盘框架指令放在系统提示词里历史素材放在用户查询里中间变量用前缀指令传递。不要把几万字素材全塞进一个 LLM 节点——我在 2.1 提过要靠分段和摘要传递这一步能把 token 占用缩小 80%。分段粒度dify 知识检索的分段长度不是越短越好。我调过 200 字、500 字、1000 字三档。200 字分段分析太碎前后文关系很容易断1000 字分段输出里经常漏掉转折和冲突点。最终平衡在 500 字左右重叠度设在 50 字这个参数组合在大多数会议和对话记录上效果最稳。不同语料特征可以从 300 字起测多试几个值看分段摘要质量的差异不要盲目相信默认值。3. 实操全过程从零搭一个 hindsight 复盘工作流3.1 准备工作数据从哪里来hindsight 的输入分三类我分别做了适配会议录音先用 Whisper API 转成文字输出格式选择带时间戳的 SRT。这里有个小技巧——dify 的文本处理模块可以直接读取 SRT 文件按字幕分段天然就是一段一段的时间戳还能保留方便后续做“哪一分钟发生了什么”的定位。转写模型的参数 fever 和 temperature 都调低避免口语废话被模型自动“修正”掉。群聊记录微信群、钉钉群、飞书群导出后格式都不一样统一清洗成一个格式[日期] 发言人内容。清洗用 dify 里的一个前端小工具完成不需要写代码正则替换几轮就行。项目周报/日志这类已经是结构化文字了但格式五花八门。我同样先清洗成 Markdown 列表再塞进知识库。3.2 dify 工作流节点的完整布局这是 hindsight 在 dify 画布上最核心的布局每个节点我都标注了实际配置参数节点类型核心配置开始输入设置两个字段raw_text文本、session_type下拉选会议/群聊/日志分段与清洗代码节点Python按 SRT 时间戳或发言人分块strip 掉空行和制表符全局摘要小模型 LLMClaude Haiku 或 GPT-4o-mini温度 0.1产出 800 字以内的全局概要事实还原LLM温度 0.1输出 JSON 数组每个元素含{time, event, speaker, decision}偏差分析LLM温度 0.2输入需带全局摘要和事实列表输出因果链情绪分析LLM温度 0.1需要给它每条发言的上下文窗口而非全文报告生成器LLM温度 0.4接收前四步的输出合并成最终 Markdown 报告结束输出导出为 Markdown 文件同时做一份 JSON 结构化数据供后续统计这个布局的精髓在于没有把“复盘”压在一个节点里完成而是拆成五个各司其职的小节点。这样调试时不至于一崩全崩每层输出都能单独检查质量后续想换任何一环的模型也不影响整体。3.3 提示词模板的设计细节提示词设计是这项目里最花时间的部分。我把最核心的“事实还原”节点的提示词贴出来你可以直接抄你是 hindsight 复盘系统的【事实还原模块】。你的任务不是总结不是提建议而是像审讯录像带一样把输入素材中的事实性信息无损提取出来。 输入将提供一段或多段对话/会议记录用 sention 标签包裹。请提取以下四类信息 1. 时间节点说话或决策发生的具体时间来自 SRT 时间戳或 [日期] 标记如果没有时间信息标记为 unknown_time。 2. 关键发言对决策有直接影响的发言删除客套话和语气词保留原意的同时压缩到 50 字以内。 3. 决策点任何形式的拍板、这个定了、那个不行、先做 A 再做 B 等话术后面紧跟的结论。 4. 遗留问题被提出但没有结论的开放问题标注 question_markertrue。 输出要求 - 只允许输出 JSON 数组格式如下 [{time: 00:12:35, speaker: 产品经理, event: 确定砍掉高级筛选功能v2 不再做, decision: true}, ...] - 严禁输出 JSON 以外的任何解释、总结、过渡句。 - 事实不完整宁可保留原文片段也不准脑补。注意最后一句“不准脑补”这是整个 hindsight 项目的底线。事后诸葛亮的前提是“事”本身得是真的这一步错了后面全崩。3.4 跑通第一个完整复盘实际效果和输出示例我用一次真实的 45 分钟产品周会做了验证。原始录音转写后 6200 字经分段摘要后喂给分析流程最终输出的报告全文本不到 3500 字但信息密度比我自己的人工笔记高得多。举个最有价值的片段“决策点 3确定将支付流程外包对接不再自研。偏差分析本次决策与 3 月内部评审结论自研产生直接矛盾矛盾触发点是研发人力的中期评估变化。因果链人力评估变化 → 排期风险上升 → 自研成本超预算阈值 → 管理层否定自研 → 外包替代。情绪复盘该议题是全场争论最激烈的焦点第 28-36 分钟研发负责人的反驳被两次打断产品经理的“别想了”发言触发对抗情绪后续 10 分钟内两项非相关议题讨论效率明显下降。复盘建议保持——人力风险周期评估制度停止——在议题未达成共识前强行推进新议题新增——争议议题增设 5 分钟各自陈词环节防止打断。”这种颗粒度的复盘靠人工整理至少需要两个小时而且很难抓到“第几分钟谁打断了谁”这种细节。当天我直接把这个结果贴到了团队群里当时就有两个同事问我是怎么做到“记得那么清楚”的。4. 常见问题与排查技巧实录这个项目跑了三个多月碰到的问题少说也有几十个挑出 5 个最典型的分享给你。问题一录音转写结果人名混乱Whisper 在多人会议里经常把发言人的名字张冠李戴。跑了三个多星期我这里实际遇到的比例超过了五分之一,非常坑。我的解决方法不是改进转写模型而是绕过去——在“分段与清洗”节点里加一个“人物归一化”步骤提供一份发言人名单来自会议邀请或群成员列表代码用文本相似度做模糊匹配把人名统一成标准称呼。准确率能到 90% 左右剩下的 10% 人工修一下就好了。问题二全局摘要丢失关键细节小模型做全局摘要时会过滤掉它觉得“不重要”的细节但事后复盘恰恰需要那些细节。我现在的策略是分段摘要和全局摘要同时做——分段摘要保留颗粒度信息全局摘要只提供叙事框架事实还原节点的输入以分段摘要为主全局摘要为辅。两路信息有冲突时以分段摘要为准。问题三大模型输出结构不稳定JSON 输出偶尔会多一个注释行或者数组末尾多一个逗号。整条工作流最怕这种小毛病因为后面节点一接 – JSON parse 直接崩。解决在 dify 的代码节点里加了一个重试机制解析失败就把报错信息返回给大模型让它重新输出一遍。实测重试 1 到 2 次成功率从 85% 提升到 99% 以上。“让大模型自己报错给自己看”这招是真的很好使。问题四会话太长成本爆炸有一次群聊记录导出了 12 万字照原方案跑一遍大概要烧掉 30 万 token。后来我把整个流程升级成“先过滤后分析”在清洗阶段就先把 70% 的无效对话如表情包刷屏、签到、纯表情回复过滤掉“12 万字直接瘦身到 3 万字成本立刻降下来一半多”。滤波器用的是规则小模型分类器开销极低。要碰几万字的历史数据一定要先做这步不然钱包顶不住。问题五模型输出的建议太“对但没用”“加强沟通”“优化流程”“提高效率”这些话我的报告里一开始全是。这时候我就知道偏差分析的提示词里对因果双方的要求还不够严格。后来加了一条强约束每个建议必须对应一个本次记录里真实出现过的负面事件并且指明“如果不这么做下一次大概率会重复哪次问题”。加入后建议质量明显变实了不再像以前那样云山雾罩的。复盘建议这块宁可少而精也不要一堆空话因为读者只有对号入座到一个具体场景时才会真的去执行。排查心得在 dify 里排查工作流问题优先看两个地方——节点输入详情和原始输出。前者能确认上游有没有把数据传对后者能确认大模型当下到底“说什么胡话”。一次问题 90% 都出在这两处别急着改提示词。5. 聊聊这个项目的边界和几个容易踩的隐性坑老实说hindsight 不是万能的。它最大的边界在于它复盘的只有“已经发生的对话”对“没在对话里出现的事情”一无所知。比如一场会议里大家心照不宣的潜规则、某个人的未说出口的真实顾虑这些不在文本里的话模型猜也猜不准。这也正是我在提示词里反复写“不准脑补”的核心原因——一旦允许脑补事后复盘就成了故事会。还有几个隐性坑你如果照着搭一个八成也会碰到坑一把复盘报告直接发给当事人情绪分析模块能识别出“某人的发言被打断”“某方的反驳被忽略”这类敏感信息。这类信息适合发给主持人和管理者做自我觉察不适合直接发到全员群。我在项目里做了一层权限过滤情绪分析结果默认只对管理员可见。坑二复盘模型的前后一致性同样一份素材喂给 Claude 和 GPT 得到的结果在事实层基本一致但在偏差分析层风格差异很大——Claude 更谨慎更爱用“可能”“需要进一步确认”GPT 更果断因果链提得特别硬。选定哪款模型做主分析器就固定下来不要今天换这个明天换那个不然历史复盘之间根本没有可比性。坑三忘记周期性复盘hindsight 这名字还有个隐藏彩蛋它不只是一次性工具它应该被周期性地用于回顾短期项目。比如把过去一个月的周报全部丢进去做月复盘比每周单独复盘能多出一层“进化视角”。后来我专门加了一个批量模式能一次性输入 4-8 份周报输出月度趋势报告。用着用着你会发现月度报告里体现的协作模式演变是单次复盘里永远不会存在的内容。从最开始用脚本裸写调用 API到后来用 dify 搭完这套工作流再到连续跑了三个月逐步打磨整个过程里我最深的一个体会是**hindsight 这个工具真正值钱的不是那一份份漂亮的报告而是它逼着我们把“复盘”这个动作固定了下来而且复盘的颗粒度从“凭印象”变成“凭记录”。**有了记录打底很多当时觉得是别人的问题的事回头看其实有自己的责任在里头这种自我觉察没有足够准确的事后记录撑着是谈不上的。如果你手里也有一堆常年没被有效利用的聊天记录、会议音频、项目日志按这套思路搭一个属于自己的 hindsight应该会比很多所谓的执行总结工具靠谱得多。\