做AI应用这几年我越来越觉得真正值钱的功能往往不是那些看起来很酷的而是藏在日常流程里、能帮人省下大量重复劳动的东西。hindsight这个词本义是后见之明说白了就是我们常说的复盘——事情结束之后回头看把当时的决策、执行、结果重新捋一遍找到改进点。听起来简单但真要做起来大多数团队的复盘都是靠人肉翻聊天记录、手动整理会议纪要又慢又漏。所以我用Dify平台做了个叫Hindsight的复盘智能体项目把散落在对话、文档、工单里的信息收拢起来交给大模型做归因分析和结论沉淀最后输出一份结构化的复盘报告。Dify是目前很常用的开源LLM应用开发平台工作流编排、知识库、模型统一管理这些能力开箱即用我把项目落地过程中踩过的坑、想清楚的逻辑、实际配出来的方案全部分享出来供正在做类似复盘类Agent、知识库应用的开发者参考。1. hindsight到底在解决什么问题1.1 复盘的难点不在回头看而在看得全很多人以为复盘就是把聊天记录翻一遍、把文档读一遍然后写个总结。但实际做过就知道真正的难点在于信息是散的。拿我一个真实的场景举例一个客服团队一个月能处理上千条用户咨询分布在聊天工具、工单系统、邮件里。人肉去翻这些记录两三个小时只够看几十条而且看的时候注意力早就涣散了很容易漏掉关键转折点。复盘的核心其实是归因——这单用户为什么会不满是流程堵了还是话术没到位这个问题是偶发还是必然这些归因信息分散在不同渠道里单靠人去记必然丢三落四。而大模型天然擅长做信息聚合和因果推断所以复盘这个场景非常适合做成AI应用。1.2 Hindsight的定位做团队的第二大脑我给Hindsight设了一个很朴素的定位它不是聊天机器人不是一个什么都能答的助手而是一个只做复盘的专用工具。输入是一堆原始素材——对话记录、问题描述、处理结果、用户反馈输出是一份复盘结论——原因分类、关键节点、改进建议、风险预警。这样的定位有个好处功能边界清晰提示词和工作流都好设计不会变成干啥啥不行的大杂烩。我见过太多AI项目死在不专注上今天想让它写文案明天想让它查数据最后提示词互相打架效果稀烂。Hindsight从一开始就咬死复盘这一个点反而做出来的东西真的有人天天用。1.3 为什么选Dify而不是从零搭一套系统说实话我自己也能用Python写一套API、接大模型、做个简单的前端页面但那样做的话80%的时间都会耗在非核心的事情上处理模型API的切换、写知识库检索逻辑、做可视化调试、配权限管理。用Dify的好处在于工作流可视化编排复盘流程里的每一个环节都能在画布上直接拖拽搭建调试的时候一眼就能看到哪一步的输出出了问题。知识库和RAG开箱即用Hindsight需要查阅历史复盘记录和业务手册Dify的知识库直接支持文档导入、向量化、检索召回省掉一大块开发量。模型统一管理切换不同大模型只需要在后台配置不用改代码。我实测过用不同模型跑同一条复盘流程效果差异确实明显能方便地做对比选型。部署简单Dify开源版可以Docker一键起数据完全在自己手里没有平台绑定焦虑。现在想一想如果从零搭光一个提示词调优就得花掉我两个礼拜的业余时间而Dify把这一层的调试体验做得相当顺手我能把精力集中在复盘逻辑本身。2. 一个复盘智能体需要哪些核心素材与能力2.1 素材层散落的信息如何统一收口复盘智能体的原材料是过去发生了什么但这些过去形态各异。我归纳下来主要有三类素材类型常见来源原始形态需要做的处理对话记录在线客服、社群群聊json、csv、txt清洗、脱敏、按会话分组结构化数据工单系统、ERPcsv、excel、数据库导出字段映射、关键指标提取非结构化文档复盘纪要、周报、邮件docx、pdf、md分段、摘要、归档我在Hindsight里做了一层素材预处理不直接让大模型处理原始导出文件而是先通过脚本把这些内容转换成统一的文本格式。比如客服对话记录我会按会话编号时间戳发言人内容的格式转成纯文本工单数据则转成问题描述处理人耗时结果。这样做的原因是大模型能处理的数据量有限提前结构化能省下大量token而且减少无关噪音对判断的干扰。2.2 知识层让大模型查得到再答得准复盘不是凭空造结论它需要参考业务背景。比如判断某个客诉是不是已知问题得先查历史工单和知识库文档看是不是老毛病又犯了。这类能力靠的是RAG检索增强生成在Dify里体现为知识库功能。我建了两个知识库一个是业务手册库放产品说明、流程规范、话术模板另一个是历史复盘库把每次复盘产出归档进去。第二个知识库尤其关键因为模型看过历史复盘后就能识别出这个问题在三个月前就出现过这类关联结论的参考价值完全不同。这里有个容易踩的坑知识库的切片粒度直接决定检索质量。我试过把整个文档做成一个大切片结果检索时经常召回一段无关的引言也试过切成几十字的小片段结果语义被割裂模型找不到完整上下文。Dify里知识库切片可以自定义长度我最后调成500字左右一段、重叠30-50字效果比较稳定。2.3 流程层从材料到结论的完整链路Hindsight的工作流我设计成五个阶段收集接收用户提交的原始素材支持文本粘贴或上传文件。清洗用代码节点做格式化和脱敏过滤掉无信息量的内容比如哈哈哈哈收到这类纯闲聊。检索根据素材内容去两个知识库做向量检索取出业务背景和历史先例。归因大模型综合原始素材、知识库背景、历史先例输出结构化的复盘结论。沉淀把本次复盘结果写回历史复盘库作为下一次复盘的先例。前两步是把饭煮熟第三步是备好佐料第四步才是真正炒菜第五步则是给下次做饭攒菜谱。整个流程的核心在第四步但前几步做不好第四步输出必然变形。3. 手把手实操在Dify上把Hindsight搭出来3.1 环境准备与项目初始化我用的是Dify社区版Docker部署一套命令就能跑起来。需要注意的是服务端环境最好单独准备一台2核4G以上的机器因为Dify本身要跑API服务、Worker、向量数据库等多个容器资源太紧张会导致推理速度明显变慢。部署完成后进入Dify控制台的第一步是创建应用。这里有个类型选择的讲究Hindsight需要和用户进行多轮交互比如用户补充素材、追问复盘细节所以我选了Chatflow对话流而不是Workflow工作流。两者的区别很直接Workflow适合一次性的批处理任务比如传一个文件进去出来一份报告Chatflow则自带对话管理能力可以维持多轮上下文适合交互式场景。3.2 知识库搭建把复盘素材变成可检索的资产在Dify左侧菜单进入知识库我分别建了业务手册和历史复盘两个知识库。业务手册库导入的是团队已有的规范文档。导入前我做了三件事把pdf转成文字版mdDify对md的支持最干净、删掉封面目录等垃圾页、统一用标题-正文的格式。切片参数我选的是自动分段Dify会按语义段落切分段落长度设500字符分段标识符留默认。历史复盘库比较特殊它最初是空库靠Hindsight自己喂大。每次复盘结束时我通过一个HTTP请求节点调用Dify的知识库API把本次复盘报告作为新文档写入这个库。刚开始库是空的检索不到东西但用了大概两周之后库里有几十条历史复盘再跑新案例时模型会自动匹配类似的坑之前踩过吗效果一下子就出来了。这里有个体验上的提醒知识库从零积累需要时间别指望第一天就有用。想快速验证效果的话可以先手动导入一些过去的复盘纪要当种子数据。3.3 编排核心工作流我把Hindsight拆成了这几个节点Dify的Chatflow画布左上方是节点面板搭建逻辑是从左往右拉连接线。我的核心工作流节点顺序如下开始节点定义变量conversation_text用户粘贴的对话内容。这一步要勾选用户输入这样前端才会有输入框让用户填内容。代码节点执行数据清洗脚本把原始文本按会话编号、时间戳、发言人、内容的格式解析成标准文本。我在Dify的代码编辑器里写了段Python按换行切分每一条记录过滤掉包含收到/哈哈哈/在吗这类词的纯水消息输出标准化的字符串。知识检索节点接两个知识库检索query用清洗后的文本截取前500字。Dify支持一次检索多个知识库这个API建议设3-5分数阈值设0.3——太低会把无关内容也召回太高又容易漏掉有用信息。LLM节点这个节点是归因核心系统提示词里明确写你是复盘分析师把清洗后的素材和检索结果拼进上下文让模型按固定格式输出。变量聚合节点把模型输出转成固定变量方便下一步展示。直接回复节点把复盘报告以Markdown形式回复给用户。这里面最容易出错的是代码节点的输入输出变量绑定。Dify里代码节点必须声明输入变量名和起始代码输出也必须在代码里定义成可被后续节点引用的变量。我一开始没声明输出变量导致后面的LLM节点死活取不到清洗后的内容后来在代码节点右上角看了半天文档才弄明白。大家搭的时候留意一下这个细节。3.4 提示词设计复盘Agent的灵魂在一套固定模板里模型能不能给出高质量的复盘80%取决于提示词。Hindsight的LLM节点提示词我打磨了很多版最终稳定在这个结构你是资深复盘分析师。你的任务是基于给定的原始对话记录和知识库背景输出一份复盘报告。 报告必须包含四个部分 1. 事实摘要用3-5句话概括发生了什么只陈述客观事实不推断动机。 2. 问题归因列出导致问题出现的直接原因和根本原因每条原因标注证据编号引用素材中的原文片段。 3. 关键节点找出对话中改变走向的关键转折点说明如果在那一步采取不同处理结果会有什么不同。 4. 行动建议给出3条可执行、可验证的改进建议每条注明建议依据。 约束 - 不要猜测素材中没有出现的细节。 - 如果某部分证据不足直接在对应段落写证据不足需要补充严禁编造。 - 输出使用中文用Markdown格式条目清晰。这套提示词有几个关键设计分四段强制结构没有模板的话模型容易写成一团浆糊。分段之后每部分都能单独检查质量。证据编号约束这是用来对抗幻觉的。我要求模型每条归因必须引用原文片段引用不出来就说明这条结论没有依据宁可不要。明确证据不足选项给模型一个安全出口免得它硬着头皮编造。实测下来加了这句之后模型看不懂但强答的概率显著下降。3.5 模型选型不同场景我用两种模型Dify后台可以配置多家模型服务商。我试过用同一个Hindsight工作流跑不同模型结论是总结归因类任务强推理模型明显优于普通对话模型。对于需要深度归因的分析任务处理复杂客诉、项目复盘我用的是推理能力更强的模型虽然单次调用token成本高一截但结论的可信度高很多少花时间返工整体反而是省的。对于简单场景例行周报、会话摘要用轻量模型就够了速度快、成本低。这里额外提一句Dify的模型管理里有个模型能力开关可以限制某个模型只用于特定后端调用避免误用。建议把强模型只分配到LLM节点其他辅助节点比如分类、摘要都用轻量模型。4. 复盘类Agent最常翻的4个车我全踩过了4.1 上下文窗口爆了拆成分批处理汇总真实业务里的对话记录经常超长一次客服会话可能有几十轮粘贴进去直接超过模型上下文窗口。更麻烦的是Dify的知识检索结果也会占用上下文空间一旦超限要么报错、要么模型只看了部分内容就开答结论自然歪。我的解法是在代码节点增加分批处理逻辑如果清洗后的文本超过8000字就按对话时间切成多个批次每批单独让LLM做一次本轮摘要最后再让模型基于所有批次摘要做总分析。这其实是经典的MapReduce思路损失一点点细节但换来了稳定性和可控成本。如果素材实在太多我还会在开始节点加一个用户选项只复盘最近N轮对话让用户自己决定范围。4.2 模型脑补不属于素材的事实用证据约束事后抽查还有一个坑是幻觉。有一次我拿一份真实的客户退款纠纷素材去测模型在问题归因里写了一条客户是因为在社交媒体上看到了负面评价才选择退款但实际上素材里根本没有提到社交媒体纯粹是模型根据刻板印象脑补出来的。如果不是我熟悉这个案例这条假信息就会被当成真问题写进复盘报告误导团队决策。解决思路除了刚才提示词里的证据编号约束我还加了一道代码校验LLM节点输出的每条归因都要在代码逻辑里检查是否包含证据xxx的字段标记没有标记的部分直接丢弃并提示该结论缺少证据已移除。虽然代码层面没法真正验证引用是否属实但至少倒逼模型给出可追溯的来源而不是空口白话。4.3 多轮对话把问题聊偏了给对话加隔离Chatflow的对话管理能力是双刃剑。好处是用户可以在一个会话里继续追问那第二条建议具体怎么落地坏处是如果用户在新对话里丢进来完全不同的素材旧素材的内容还在上下文里模型就会分不清到底要复盘哪一次对话输出的结论东一句西一句。我的解决方案是在开始节点加一个**重置话题开关**并且提示词里写死一句话请仅分析用户在当前消息中提供的复盘素材字段内容忽略之前所有对话历史中的素材信息。事实上这一步也只防了大部分真遇到连续多轮复盘一个复杂case时我宁可建议用户直接开一个新会话把每一次复盘用独立会话作为使用规范写进团队文档里。4.4 钱和速度复盘类任务怎么能跑得又稳又省复盘任务天然耗token知识检索有开销、一次归因要读几千字素材、还要输出长报告。我跑了一阵子之后看账单才发现单个复杂case的复盘成本比想象中高不少。控制手段有三个知识检索的精准召回优先Dify检索API有retriever_top_k参数我调小到3召回太多只会增加上下文垃圾不如精准。分级模型策略清洗和摘要用轻量模型只有最终归因用强模型前面已经提到。缓存历史结论对重复出现的case类型比如同一类退款纠纷代码节点先查历史复盘库如果相同问题已经复盘过优先返回历史结论而不是重新推理。我实测下来这类缓存能省掉大概三成的调用量。5. Hindsight还能往哪里延伸这个项目做出来之后我第一个想法是只做客服会话复盘但用着用着发现它完全可以变成一套通用的回顾分析处理框架。只要把输入素材换一换提示词里的领域词改一改它就能胜任很多别的复盘场景项目周报复盘把一周的提交记录、会议纪要和issue列表丢进去生成项目健康度报告标记阻塞点。用户反馈洞察把应用商店评论、问卷回执汇总起来让它做主题聚类和趋势分析比人肉翻几百条评论强得多。故障事后分析Server故障后把时间线日志、工单记录拼起来生成事故归因和规避清单相当于给SRE团队配了半个助理。销售过程复盘把销售跟进记录导入分析丢单原因、总结赢单模式沉淀成团队话术库。Dify本身支持API调用和Webhook我在Hindsight的入口挂了个自动化触发器每天晚上自动把当天的工单导出文件推进工作流生成日报式的复盘摘要推送到团队协作群里。这个自动化我挺推荐反正数据都在每天花那点token钱换来的是一整个团队都能共享的集体记忆。6. 一点经验顺便写给自己如果你也想做类似的项目我的建议是别一上来就追求全自动、覆盖所有复盘场景。先用最简单的方式把一个具体场景跑通——比如只做客服复盘只处理粘贴文本只输出一份Markdown报告。跑通之后再去加知识库、加自动化、加多轮追问你会发现每一步都有明确的改进方向模型效果也是能感知地变好。Hindsight这个项目做得不算复杂但对我来说很有意义它验证了一件事后端见之明这东西虽然名字带后价值却应该在先——在问题还没被拖大之前就通过结构化的回顾给出预警。用Dify把这些逻辑沉淀成应用整个团队的复盘质量都上了一个台阶。下一阶段我打算给它加上简单的评分机制让每次复盘结论直接映射到动作项跟踪争取把复完了就完了的毛病也治一治。
做AI应用这几年我越来越觉得真正值钱的功能往往不是那些看起来很酷的而是藏在日常流程里、能帮人省下大量重复劳动的东西。hindsight这个词本义是后见之明说白了就是我们常说的复盘——事情结束之后回头看把当时的决策、执行、结果重新捋一遍找到改进点。听起来简单但真要做起来大多数团队的复盘都是靠人肉翻聊天记录、手动整理会议纪要又慢又漏。所以我用Dify平台做了个叫Hindsight的复盘智能体项目把散落在对话、文档、工单里的信息收拢起来交给大模型做归因分析和结论沉淀最后输出一份结构化的复盘报告。Dify是目前很常用的开源LLM应用开发平台工作流编排、知识库、模型统一管理这些能力开箱即用我把项目落地过程中踩过的坑、想清楚的逻辑、实际配出来的方案全部分享出来供正在做类似复盘类Agent、知识库应用的开发者参考。1. hindsight到底在解决什么问题1.1 复盘的难点不在回头看而在看得全很多人以为复盘就是把聊天记录翻一遍、把文档读一遍然后写个总结。但实际做过就知道真正的难点在于信息是散的。拿我一个真实的场景举例一个客服团队一个月能处理上千条用户咨询分布在聊天工具、工单系统、邮件里。人肉去翻这些记录两三个小时只够看几十条而且看的时候注意力早就涣散了很容易漏掉关键转折点。复盘的核心其实是归因——这单用户为什么会不满是流程堵了还是话术没到位这个问题是偶发还是必然这些归因信息分散在不同渠道里单靠人去记必然丢三落四。而大模型天然擅长做信息聚合和因果推断所以复盘这个场景非常适合做成AI应用。1.2 Hindsight的定位做团队的第二大脑我给Hindsight设了一个很朴素的定位它不是聊天机器人不是一个什么都能答的助手而是一个只做复盘的专用工具。输入是一堆原始素材——对话记录、问题描述、处理结果、用户反馈输出是一份复盘结论——原因分类、关键节点、改进建议、风险预警。这样的定位有个好处功能边界清晰提示词和工作流都好设计不会变成干啥啥不行的大杂烩。我见过太多AI项目死在不专注上今天想让它写文案明天想让它查数据最后提示词互相打架效果稀烂。Hindsight从一开始就咬死复盘这一个点反而做出来的东西真的有人天天用。1.3 为什么选Dify而不是从零搭一套系统说实话我自己也能用Python写一套API、接大模型、做个简单的前端页面但那样做的话80%的时间都会耗在非核心的事情上处理模型API的切换、写知识库检索逻辑、做可视化调试、配权限管理。用Dify的好处在于工作流可视化编排复盘流程里的每一个环节都能在画布上直接拖拽搭建调试的时候一眼就能看到哪一步的输出出了问题。知识库和RAG开箱即用Hindsight需要查阅历史复盘记录和业务手册Dify的知识库直接支持文档导入、向量化、检索召回省掉一大块开发量。模型统一管理切换不同大模型只需要在后台配置不用改代码。我实测过用不同模型跑同一条复盘流程效果差异确实明显能方便地做对比选型。部署简单Dify开源版可以Docker一键起数据完全在自己手里没有平台绑定焦虑。现在想一想如果从零搭光一个提示词调优就得花掉我两个礼拜的业余时间而Dify把这一层的调试体验做得相当顺手我能把精力集中在复盘逻辑本身。2. 一个复盘智能体需要哪些核心素材与能力2.1 素材层散落的信息如何统一收口复盘智能体的原材料是过去发生了什么但这些过去形态各异。我归纳下来主要有三类素材类型常见来源原始形态需要做的处理对话记录在线客服、社群群聊json、csv、txt清洗、脱敏、按会话分组结构化数据工单系统、ERPcsv、excel、数据库导出字段映射、关键指标提取非结构化文档复盘纪要、周报、邮件docx、pdf、md分段、摘要、归档我在Hindsight里做了一层素材预处理不直接让大模型处理原始导出文件而是先通过脚本把这些内容转换成统一的文本格式。比如客服对话记录我会按会话编号时间戳发言人内容的格式转成纯文本工单数据则转成问题描述处理人耗时结果。这样做的原因是大模型能处理的数据量有限提前结构化能省下大量token而且减少无关噪音对判断的干扰。2.2 知识层让大模型查得到再答得准复盘不是凭空造结论它需要参考业务背景。比如判断某个客诉是不是已知问题得先查历史工单和知识库文档看是不是老毛病又犯了。这类能力靠的是RAG检索增强生成在Dify里体现为知识库功能。我建了两个知识库一个是业务手册库放产品说明、流程规范、话术模板另一个是历史复盘库把每次复盘产出归档进去。第二个知识库尤其关键因为模型看过历史复盘后就能识别出这个问题在三个月前就出现过这类关联结论的参考价值完全不同。这里有个容易踩的坑知识库的切片粒度直接决定检索质量。我试过把整个文档做成一个大切片结果检索时经常召回一段无关的引言也试过切成几十字的小片段结果语义被割裂模型找不到完整上下文。Dify里知识库切片可以自定义长度我最后调成500字左右一段、重叠30-50字效果比较稳定。2.3 流程层从材料到结论的完整链路Hindsight的工作流我设计成五个阶段收集接收用户提交的原始素材支持文本粘贴或上传文件。清洗用代码节点做格式化和脱敏过滤掉无信息量的内容比如哈哈哈哈收到这类纯闲聊。检索根据素材内容去两个知识库做向量检索取出业务背景和历史先例。归因大模型综合原始素材、知识库背景、历史先例输出结构化的复盘结论。沉淀把本次复盘结果写回历史复盘库作为下一次复盘的先例。前两步是把饭煮熟第三步是备好佐料第四步才是真正炒菜第五步则是给下次做饭攒菜谱。整个流程的核心在第四步但前几步做不好第四步输出必然变形。3. 手把手实操在Dify上把Hindsight搭出来3.1 环境准备与项目初始化我用的是Dify社区版Docker部署一套命令就能跑起来。需要注意的是服务端环境最好单独准备一台2核4G以上的机器因为Dify本身要跑API服务、Worker、向量数据库等多个容器资源太紧张会导致推理速度明显变慢。部署完成后进入Dify控制台的第一步是创建应用。这里有个类型选择的讲究Hindsight需要和用户进行多轮交互比如用户补充素材、追问复盘细节所以我选了Chatflow对话流而不是Workflow工作流。两者的区别很直接Workflow适合一次性的批处理任务比如传一个文件进去出来一份报告Chatflow则自带对话管理能力可以维持多轮上下文适合交互式场景。3.2 知识库搭建把复盘素材变成可检索的资产在Dify左侧菜单进入知识库我分别建了业务手册和历史复盘两个知识库。业务手册库导入的是团队已有的规范文档。导入前我做了三件事把pdf转成文字版mdDify对md的支持最干净、删掉封面目录等垃圾页、统一用标题-正文的格式。切片参数我选的是自动分段Dify会按语义段落切分段落长度设500字符分段标识符留默认。历史复盘库比较特殊它最初是空库靠Hindsight自己喂大。每次复盘结束时我通过一个HTTP请求节点调用Dify的知识库API把本次复盘报告作为新文档写入这个库。刚开始库是空的检索不到东西但用了大概两周之后库里有几十条历史复盘再跑新案例时模型会自动匹配类似的坑之前踩过吗效果一下子就出来了。这里有个体验上的提醒知识库从零积累需要时间别指望第一天就有用。想快速验证效果的话可以先手动导入一些过去的复盘纪要当种子数据。3.3 编排核心工作流我把Hindsight拆成了这几个节点Dify的Chatflow画布左上方是节点面板搭建逻辑是从左往右拉连接线。我的核心工作流节点顺序如下开始节点定义变量conversation_text用户粘贴的对话内容。这一步要勾选用户输入这样前端才会有输入框让用户填内容。代码节点执行数据清洗脚本把原始文本按会话编号、时间戳、发言人、内容的格式解析成标准文本。我在Dify的代码编辑器里写了段Python按换行切分每一条记录过滤掉包含收到/哈哈哈/在吗这类词的纯水消息输出标准化的字符串。知识检索节点接两个知识库检索query用清洗后的文本截取前500字。Dify支持一次检索多个知识库这个API建议设3-5分数阈值设0.3——太低会把无关内容也召回太高又容易漏掉有用信息。LLM节点这个节点是归因核心系统提示词里明确写你是复盘分析师把清洗后的素材和检索结果拼进上下文让模型按固定格式输出。变量聚合节点把模型输出转成固定变量方便下一步展示。直接回复节点把复盘报告以Markdown形式回复给用户。这里面最容易出错的是代码节点的输入输出变量绑定。Dify里代码节点必须声明输入变量名和起始代码输出也必须在代码里定义成可被后续节点引用的变量。我一开始没声明输出变量导致后面的LLM节点死活取不到清洗后的内容后来在代码节点右上角看了半天文档才弄明白。大家搭的时候留意一下这个细节。3.4 提示词设计复盘Agent的灵魂在一套固定模板里模型能不能给出高质量的复盘80%取决于提示词。Hindsight的LLM节点提示词我打磨了很多版最终稳定在这个结构你是资深复盘分析师。你的任务是基于给定的原始对话记录和知识库背景输出一份复盘报告。 报告必须包含四个部分 1. 事实摘要用3-5句话概括发生了什么只陈述客观事实不推断动机。 2. 问题归因列出导致问题出现的直接原因和根本原因每条原因标注证据编号引用素材中的原文片段。 3. 关键节点找出对话中改变走向的关键转折点说明如果在那一步采取不同处理结果会有什么不同。 4. 行动建议给出3条可执行、可验证的改进建议每条注明建议依据。 约束 - 不要猜测素材中没有出现的细节。 - 如果某部分证据不足直接在对应段落写证据不足需要补充严禁编造。 - 输出使用中文用Markdown格式条目清晰。这套提示词有几个关键设计分四段强制结构没有模板的话模型容易写成一团浆糊。分段之后每部分都能单独检查质量。证据编号约束这是用来对抗幻觉的。我要求模型每条归因必须引用原文片段引用不出来就说明这条结论没有依据宁可不要。明确证据不足选项给模型一个安全出口免得它硬着头皮编造。实测下来加了这句之后模型看不懂但强答的概率显著下降。3.5 模型选型不同场景我用两种模型Dify后台可以配置多家模型服务商。我试过用同一个Hindsight工作流跑不同模型结论是总结归因类任务强推理模型明显优于普通对话模型。对于需要深度归因的分析任务处理复杂客诉、项目复盘我用的是推理能力更强的模型虽然单次调用token成本高一截但结论的可信度高很多少花时间返工整体反而是省的。对于简单场景例行周报、会话摘要用轻量模型就够了速度快、成本低。这里额外提一句Dify的模型管理里有个模型能力开关可以限制某个模型只用于特定后端调用避免误用。建议把强模型只分配到LLM节点其他辅助节点比如分类、摘要都用轻量模型。4. 复盘类Agent最常翻的4个车我全踩过了4.1 上下文窗口爆了拆成分批处理汇总真实业务里的对话记录经常超长一次客服会话可能有几十轮粘贴进去直接超过模型上下文窗口。更麻烦的是Dify的知识检索结果也会占用上下文空间一旦超限要么报错、要么模型只看了部分内容就开答结论自然歪。我的解法是在代码节点增加分批处理逻辑如果清洗后的文本超过8000字就按对话时间切成多个批次每批单独让LLM做一次本轮摘要最后再让模型基于所有批次摘要做总分析。这其实是经典的MapReduce思路损失一点点细节但换来了稳定性和可控成本。如果素材实在太多我还会在开始节点加一个用户选项只复盘最近N轮对话让用户自己决定范围。4.2 模型脑补不属于素材的事实用证据约束事后抽查还有一个坑是幻觉。有一次我拿一份真实的客户退款纠纷素材去测模型在问题归因里写了一条客户是因为在社交媒体上看到了负面评价才选择退款但实际上素材里根本没有提到社交媒体纯粹是模型根据刻板印象脑补出来的。如果不是我熟悉这个案例这条假信息就会被当成真问题写进复盘报告误导团队决策。解决思路除了刚才提示词里的证据编号约束我还加了一道代码校验LLM节点输出的每条归因都要在代码逻辑里检查是否包含证据xxx的字段标记没有标记的部分直接丢弃并提示该结论缺少证据已移除。虽然代码层面没法真正验证引用是否属实但至少倒逼模型给出可追溯的来源而不是空口白话。4.3 多轮对话把问题聊偏了给对话加隔离Chatflow的对话管理能力是双刃剑。好处是用户可以在一个会话里继续追问那第二条建议具体怎么落地坏处是如果用户在新对话里丢进来完全不同的素材旧素材的内容还在上下文里模型就会分不清到底要复盘哪一次对话输出的结论东一句西一句。我的解决方案是在开始节点加一个**重置话题开关**并且提示词里写死一句话请仅分析用户在当前消息中提供的复盘素材字段内容忽略之前所有对话历史中的素材信息。事实上这一步也只防了大部分真遇到连续多轮复盘一个复杂case时我宁可建议用户直接开一个新会话把每一次复盘用独立会话作为使用规范写进团队文档里。4.4 钱和速度复盘类任务怎么能跑得又稳又省复盘任务天然耗token知识检索有开销、一次归因要读几千字素材、还要输出长报告。我跑了一阵子之后看账单才发现单个复杂case的复盘成本比想象中高不少。控制手段有三个知识检索的精准召回优先Dify检索API有retriever_top_k参数我调小到3召回太多只会增加上下文垃圾不如精准。分级模型策略清洗和摘要用轻量模型只有最终归因用强模型前面已经提到。缓存历史结论对重复出现的case类型比如同一类退款纠纷代码节点先查历史复盘库如果相同问题已经复盘过优先返回历史结论而不是重新推理。我实测下来这类缓存能省掉大概三成的调用量。5. Hindsight还能往哪里延伸这个项目做出来之后我第一个想法是只做客服会话复盘但用着用着发现它完全可以变成一套通用的回顾分析处理框架。只要把输入素材换一换提示词里的领域词改一改它就能胜任很多别的复盘场景项目周报复盘把一周的提交记录、会议纪要和issue列表丢进去生成项目健康度报告标记阻塞点。用户反馈洞察把应用商店评论、问卷回执汇总起来让它做主题聚类和趋势分析比人肉翻几百条评论强得多。故障事后分析Server故障后把时间线日志、工单记录拼起来生成事故归因和规避清单相当于给SRE团队配了半个助理。销售过程复盘把销售跟进记录导入分析丢单原因、总结赢单模式沉淀成团队话术库。Dify本身支持API调用和Webhook我在Hindsight的入口挂了个自动化触发器每天晚上自动把当天的工单导出文件推进工作流生成日报式的复盘摘要推送到团队协作群里。这个自动化我挺推荐反正数据都在每天花那点token钱换来的是一整个团队都能共享的集体记忆。6. 一点经验顺便写给自己如果你也想做类似的项目我的建议是别一上来就追求全自动、覆盖所有复盘场景。先用最简单的方式把一个具体场景跑通——比如只做客服复盘只处理粘贴文本只输出一份Markdown报告。跑通之后再去加知识库、加自动化、加多轮追问你会发现每一步都有明确的改进方向模型效果也是能感知地变好。Hindsight这个项目做得不算复杂但对我来说很有意义它验证了一件事后端见之明这东西虽然名字带后价值却应该在先——在问题还没被拖大之前就通过结构化的回顾给出预警。用Dify把这些逻辑沉淀成应用整个团队的复盘质量都上了一个台阶。下一阶段我打算给它加上简单的评分机制让每次复盘结论直接映射到动作项跟踪争取把复完了就完了的毛病也治一治。
