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 掉空行和制表符 |
| 全局摘要 | 小模型 LLM | Claude 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_marker=true。 输出要求： - 只允许输出 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，应该会比很多所谓的执行总结工具靠谱得多。\
