三个月前我把团队过去十几次项目复盘的会议纪要翻出来认认真真看了一下午。发现一个挺尴尬的事实每次复盘都在重复讨论差不多的问题交付延期、需求变更失序、跨团队沟通断层几乎每场都会提但每场都没有真正落到行动项上。人一旦身处事后视角总是倾向于给自己找合理化的解释这个毛病叫“后见之明偏差”。所以当我决定在 Dify 上做一个叫hindsight的应用时想法很简单与其靠人脑去克服“事后聪明”不如用大模型强制我们回到事实本身把散落在各个文档里的项目过程数据捞出来生成一份结构化、可执行的复盘报告。hindsight 的核心价值就是把“后见之明”从一种主观直觉变成一种可控的 AI 分析能力。你只需要把项目的会议纪、周报、任务记录、缺陷清单这些过程材料丢给它通过 Dify 的 RAG 管道召回相关上下文再由大模型按照复盘框架Keep、Problem、Try进行归纳最终产出一份带证据、带行动建议的报告。它不负责下一个玄学判断只负责把发生过的事实重新组织成决策者可用的信息。这篇内容面向两类人一是背过复盘锅的项目经理、研发负责人二是想用 Dify 快速搭建 RAG 应用但还没找到合适落点的 AI 应用开发者。下面的所有步骤都是我在真实项目数据上反复调过的可以直接照搬也可以作为模板继续改。1. 为什么用大模型做复盘为什么选择 Dify1.1 人工复盘的三个硬伤复盘这件事本身不难难的是不被情绪和记忆忽悠。人工复盘至少有三个硬伤是写进人性的很难靠意志力解决。第一是选择性记忆。项目结束了大家还记得的往往是最后几周发生的事情前期的关键决策、当时的制约因素早就模糊了。没有完整的项目过程记录复盘就变成了“比谁记性好”的辩论赛。第二是自我服务偏差顺风的时候觉得自己英明神武逆风的时候觉得外部环境太离谱。这种偏差不是知识问题是心理问题开会的时候你直接说对方认知失调这会就没法开了。第三是真没时间。正常的项目流程里复盘通常被排在版本发布之后距离下一个迭代开始可能就一两天。让你把几个月的聊天记录、几十个文档翻完再写报告根本不现实。所以我当时想的很清楚要做一个能从原始材料里自动提取证据链的东西。它不需要聪明但一定要“记得全”并且不能有情绪立场。这件事恰好是大模型的强项。1.2 用 Dify 而不是纯代码是典型的效率取舍我最早想的是用 LangChain 写个脚本但很快就放弃了原因是维护成本不划算。复盘报告的需求变化非常快今天要按 KPT 出明天老板可能想要按风险等级出你不可能每次都去改代码。Dify 的价值在于它把 RAG 应用最常见的几块积木都预制好了。知识库上传和管理、文档分段、向量检索、工作流编排、模型接入这些在纯代码方案里要用几百行拼出来的东西在 Dify 里基本都是配置项。更关键的是Dify 的工作流把“输入、处理、输出”变成了可视化的连线哪怕你不会写 Python只要理解每个节点的作用也能搭出来一个能用的应用。这对我有一个很实际的好处后来产品经理也能自己在界面上调 Prompt 试试效果不会再因为我“改一行代码要等十分钟”而不耐烦了。当然Dify 不是没有学习成本。它的概念比较多知识库、检索节点、模型参数、查询变量第一次上手会有点绕。但相比之下纯代码方案的认知负担更重。技术债可以后面还项目复盘的需求等不了。1.3 hindsight 这个名字不是随便起的英文里 hindsight 是后见之明对应那句 famous 的话“hindsight is 20/20”意思是事后看一切都很清楚。但我做这个项目恰恰是想反过来说如果 AI 能把“事后才能看清的东西”在复盘的当下就整理好团队是不是可以少走一点弯路所以在这个项目里hindsight 有两层含义。第一层是它替我们处理的是“已经发生过的事实”这是事后视角第二层是它把这种视角输出成“未来可以改进的行动项”这是往前看。名字起得对能省掉很多向别人解释产品是什么的口舌。2. hindsight 的核心设计思路2.1 输入设计到底喂什么给 AI如果说 hindsight 是一个复盘分析器那输入数据的质量就是它的命门。我开始踩过一个坑什么文档都往知识库里丢以为越多越好。结果模型确实用功把无关的信息也当成背景讲了报告看起来四平八稳但跟这个项目本身没啥关系。后来我把输入收敛成五类每类负责复盘里的一个侧面会议纪要解决“当时是怎么决策的、谁反对、因为什么反对”。项目周报解决“节奏是怎样的、什么时候开始偏离计划的”。任务卡片和需求单解决“范围到底发生了多少变化、优先级怎么摇摆的”。缺陷清单解决“质量拐点出现在哪里、返工成本花在了哪里”。里程碑评审记录解决“阶段性的 OK 与 NOT OK 有没有客观留痕”。这五类材料不一定每个项目都全但至少要覆盖其中三类否则报告的证据支撑会明显偏弱。我在应用的说明里也写了一句材料越接近一手记录越好尽量不要让 AI 直接读别人的复盘总结那属于二手信息带着别人的框架偏见。2.2 RAG 管道让 AI 带着“记忆”去复盘为什么用 RAG而不是把整个项目文档一股脑塞进上下文因为现实中的项目记录太大了动辄几十万字。哪怕最强的模型有很长的上下文窗口把它们一次性灌进去一方面成本高另一方面模型在长文本里检索琐碎事实的能力其实没那么可靠。RAG 的思路是倒过来先检索出与当前问题相关的碎片再让模型基于这些碎片做分析。这就像让一个研究员带着一套索引去写综述而不是抱着整个图书馆背书。在 hindsight 里我先把所有过程文档切片、向量化存进 Dify 的知识库。然后每次复盘时工作流会把“这次复盘的主题”作为检索词去知识库里召回最相关的内容片段。因为复盘往往不是一次性的我可能先问“本次迭代延期的主要原因有哪些”再问“需求变更集中在哪几个模块”每次检索的上下文不同拿到的证据也不一样。RAG 管道的配置有几个关键参数直接影响结果我顺手记一下我的取值参数我用的值说明分段长度300 字左右太短语义不完整太长检索噪声大分段重叠40 字防止恰好把关键句切在两段之间Top-K5每次检索召回 5 个片段够写报告也不至于太杂相似度阈值0.65低于这个分数的片段直接丢弃避免驴唇不对马嘴这两个参数看起来简单但我调了两三轮才找到平衡。分段太细特征不明显分段太粗同一个片段里混了多个话题检索命中靠运气。这个取值组合在中文场景下表现相对稳定如果你换到英文项目记录可以把分段长度适当放大到 400 字左右。2.3 Prompt 设计把“后见之明”变成结构化输出如果说知识库是 hindsight 的骨架Prompt 就是它的灵魂。我最初的 Prompt 只写了一句话“请根据项目资料输出复盘报告”。结果模型确实很努力给了我一大篇流畅但空泛的废话什么“团队沟通有待加强”“建议优化流程”之类看完几乎想删掉整个应用。后来我把 Prompt 重构成了三个层次。第一层是角色约束明确告诉模型它不是写鼓励语而是一个中立的项目分析师必须基于提供的资料事实作答禁止使用“大家辛苦了”这类空话。第二层是框架约束采用 KPT 模型Keep哪些做法应该保持、Problem出了哪些问题、Try下一迭代尝试什么改变。KPT 的好处是比 SWOT 更贴近执行层每一条输出都必须对应输入资料中的具体事实不允许光给结论。第三层是格式约束要求模型输出 JSON字段包括 keep、problem、try、evidence。evidence 字段用来标出问题对应的原文片段或文档来源方便我追溯到原始材料。一个我调好的 Prompt 核心片段大概是这种感觉你是一个中立、严谨的项目复盘分析师。你会看到一份项目过程资料片段。 请严格按照 KPT 框架输出复盘结论。 规则 1. 每一条 Keep / Problem / Try 都必须引用资料中的具体事实或数据。 2. 禁止出现空泛判断例如沟通不足如果要写必须同时写出具体是什么环节、谁和谁、在什么节点上出现的沟通不足。 3. 输出格式为 JSON键名为 keep、problem、try、evidence。 4. evidence 中直接引用原文片段。这段 Prompt 看起来没什么花哨但效果立竿见影。模型的输出从“正确的废话”变成了可以开跟进会的具体事项。我后来让团队里的实习生也拿这个 Prompt 去测过别的数据同样能跑出可用的结果说明它不挑输入。3. 实操过程在 Dify 上把 hindsight 跑起来3.1 准备数据集从真实项目中抽取样本我拿来做测试的是一个真实的迭代项目跨度八周几十条任务。第一步是收集上述五类材料。我当时的做法是把云文档里的会议纪要、周报、缺陷单统一导出成 Markdown 或纯文本。处理过程中有几件事要注意。第一敏感信息要先脱敏人名可以保留但对外不会暴露密码、客户名这类绝对不能进知识库。第二要统一编码防止中文乱码我吃过这个亏导入后检索结果全是火星文。第三步才是文本清洗去掉聊天记录里的无意义回复、表情、投票接龙这些干扰片段。清洗规则我写在了一个脚本里import re def clean_text(text: str) - str: # 去掉 HTML 标签 text re.sub(r[^], , text) # 去掉常见表情字符 text re.sub(r[\U0001F300-\U0001F9FF], , text) # 合并多余空行 text re.sub(r\n{3,}, \n\n, text) # 去掉“收到”“1”这种纯表情回复 text re.sub(r^[收到1好]$, , text, flagsre.MULTILINE) return text.strip()清洗完的数据直接进入了 Dify 的知识库。我记得当时上传了差不多 150 多份文档切出了五百多个片段。第一次跑的时候我先调了知识库召回输入“这次迭代为什么延期”看一眼召回片段里有没有真正相关的记录。这一步特别重要你别急着跑完整报告先把 RAG 环节验证好后面模型再厉害找不到资料也是白搭。3.2 接入模型并配置知识库4 个关键参数别乱调模型选择上我至少试了三种通用旗舰模型、轻量模型、开源部署模型。测试下来复盘的输出质量差异比我想象中大。旗舰模型能理解更复杂的上下文关系但成本也高轻量模型速度快但在长项目记录上偶尔会丢掉较远的因果线索。最后我选了性价比适中的版本具体型号不贴了按你们自己平台能拿到的模型来选就行判断标准是能不能严格按 JSON 格式输出以及能不能遵循“禁止空泛结论”的指令。接好模型之后知识库配置还有四个核心参数每一项都要调不然结果就是翻车现场。第一个是文档分段模式。我选的是“自定义分段”分段长度 300、分段重叠 40。这里没人能帮你拍脑袋定死不同业务资料差异很大官方默认值不一定适配你手里的数据集。第二个是检索模式。我实测下来“向量召回”在代码写得好、文档语义清晰的情况下够用但如果你希望更稳定可以打开“全文索引”做混合召回。便宜大碗的方法是在 Dify 里开关键词检索和向量召回混合这样既吃语义相似度也吃字面命中。第三个是召回数量。Top-K 我设的是 5原因很简单5 个片段在 300 字分段下大约能给模型 1500 字左右的上下文写 KPT 报告足够了。K 值设太大模型会开始综合太多碎片反而容易跑偏。第四个是相似度阈值。0.65 是我反复测试出来的中位值。太高了容易召回不到相关片段太低了会混入无关内容。我给你的建议是先在 Dify 的调试界面上输入几个检索词看看每个分数段的召回质量再定阈值。3.3 编排工作流与调试Dify 的工作流是 hindsight 的组装车间。我搭建时用到了四个节点。开始节点接收用户输入我用了一个变量叫 review_topic就是“本次复盘想聚焦的问题”比如“迭代延期原因分析”或“需求变更影响评估”。输入方式我选了文本输入你可以随意填。然后是一个知识库检索节点绑定了刚才建好的知识库检索词直接取 review_topic 的值召回数量走上面说的 Top-K。这个节点跑完你会看到一个片段数组每个元素都带着原文内容和相似度分数。接下来是一个 LLM 节点。Prompt 里我引用了两个变量review_topic 和知识库的召回结果。知识库节点的输出会作为一个变量嵌入 Prompt告诉模型“以下是检索到的项目过程资料片段请基于这些内容分析”。这一步是把 RAG 和生成串起来的关键。最后是一个结束节点直接输出 LLM 节点的文本结果。如果你想对接通知、工单系统也可以在这里加 HTTP 请求节点把生成好的复盘 JSON 推到内部系统。连接关系非常简单调试时 Dify 会自动跑一遍你可以看到每个节点的输入输出。我调试时最喜欢用这个功能一旦输出不对劲直接看是知识库召回了错的片段还是 LLM 节点没按格式输出问题不用猜。3.4 验证运行与优化第一版跑通之后我先用三个月前的旧项目数据做了盲测。当时我不知道项目结果先让 hindsight 输出复盘再拿真实的复盘报告对比。结果最有价值的反而是一个问题hindsight 指出了“第 6 周开始缺陷单的解决时长中位数明显上升”而人工复盘里完全没有提这一点因为项目成员当时只记得“最后几周很累”。后来我做了两轮优化。第一轮是优化检索词。我发现直接拿“迭代延期原因”检索知识库召回的片段不够具体有时候会抓到一些泛泛的会议签到记录。于是我把用户输入改成“我负责的模块是 X项目周期是 M 到 N请分析缺陷率上升的原因是”。这样检索出的片段明显更定向。第二轮是优化生成输出为可操作性。最初的 JSON 里 problem 字段太笼统我加了一个 prompt 指令“每条 problem 必须包括发生时间、影响范围、可验证的触发条件”这直接推高了报告的可执行度。4. 常见问题与排查技巧实录4.1 数据清洗不彻底报告出现幻觉有一次我图省事把几十篇带广告尾巴的网文也传进了知识库结果模型在复盘报告里一本正经地引用了“某课程软文”里的名言场面非常离谱。解决办法是清洗阶段多花十分钟把任何不属于项目过程的网页痕迹、模板文字全删掉。知识库宁可少而精不要太而杂。复盘不是搜索引擎资料里混进一个不相干文档模型很容易把噪声当证据。4.2 检索效果差相关片段召回不到如果你发现模型输出虽然在结构上正确但总感觉在“闭着眼睛编”先去查知识库检索节点返回了什么。我遇到过两次。第一次是阈值设太高0.75相关片段全部被过滤掉了。调回 0.65 就正常了。第二次是分段粒度太粗一个片段里糅了好几个议题检索词在片段里占比太低向量相似度被稀释。把分段长度从 500 改到 300 之后问题立刻缓解。4.3 Prompt 输出不稳定JSON 格式偶尔崩这是 LLM 应用的经典问题了。我的解决方式是双保险。第一在 Prompt 里给一个 JSON 示例告诉模型“必须严格按如下格式输出不能输出任何多余文字”。第二用 Dify 的“结构化输出”节点或代码节点做一次解析校验解析失败就返回错误提示让用户重新生成一次。我这边的经验是给了示例之后失败率能从百分之二三十降到百分之三左右。完全消除不太现实但已经在可接受范围内。4.4 复盘报告过于“正确”却没有增量价值这是最隐蔽的一个坑。模型如果只是把数据梳理一遍那它的输出再工整也只是归档不是洞察。我调 Prompt 时特意加了两个字“归因”。要求每条 problem 不只要描述现象还要给出可能的原因链条。比如“缺陷集中出现在第6周可能原因是第5周需求变更引入了新的交互逻辑但这个改动没有同步到测试用例”。加了归因要求之后hindsight 的输出才真正有“后见之明”的味道了。问题现象可能原因解决动作报告引用无关文档数据清洗不彻底清洗时删掉非项目过程内容输出内容像在编造阈值太低或片段太粗调高阈值到0.65附近缩小分段JSON格式偶尔错误模型没吃到示例Prompt里加few-shot示例结论空泛无价值缺少归因要求强制结论带时间、影响范围和原因链我实际跑下来还有个体会hindsight 这个东西最花时间的不是 Dify 配置而是给喂进去的数据“立规矩”。你愿意花一天时间把过去项目的资料整理干净后面 AI 能帮你省下不知道多少个复盘会嘴上扯皮的时间。到了这一步后见之明才算真的用对了地方。