今年我在折腾 Dify 的时候突然被一个英文单词戳中了hindsight。英文里有句老话叫 hindsight is 20/20翻译过来就是事后看什么都清楚说难听点叫马后炮说好听点叫后见之明。过去我一直觉得这是个贬义词直到我亲手把它做成了一款基于 Dify 的复盘 AI 应用名字就叫 hindsight。它的活很简单把项目记录、聊天记录、一段失败的经历丢进去它会像一个经历过一切的老师傅帮你把已经发生的事拆成事实、偏差、教训和下一次的行动清单。这篇文章就讲讲我为什么想做这么个东西、怎么从零用 Dify 搭起来、中间踩了哪些坑以及你完全可以照抄的配置思路。1. 为什么叫 hindsight把事后聪明从贬义变成生产力1.1 人人都是事后诸葛亮但没人把事后用好先说点虚的。你有没有过这种经历项目上线后出问题复盘会上所有人突然都变成了诸葛亮这个说当时我就觉得方案有问题那个说早该想到用户会这么操作。可下次做新项目同样的坑照样踩。问题出在哪出在事后思考这件事完全是散装、靠脑子的。洞察产生了但没被记录、没被结构化、更没被沉淀成下次可执行的检查项。我做 hindsight 的初衷就是把这种零散的事后聪明变成一条固定流水线。它不是让你对着失败自我检讨而是把一段原始材料扔进一个标准流程里产出一份结构化的复盘报告。说得直白一点别人复盘靠开会你复盘靠 AI 帮你拆解。1.2 这个应用到底解决什么问题我实际用下来hindsight 能覆盖三类典型场景这也是我推荐你先从这三个方向试的原因项目复盘把项目群里的关键对话、周报、上线记录扔进去让它找出目标与实际结果的偏差。对话分析客服聊天记录、销售沟通录音转的文字看看到底是哪句话让客户态度变了的。个人记录回看每天写几句日记式记录让 AI 帮你提炼今天有什么下次可以做得不一样。它适合谁适合已经在用或准备用 Dify 的开发者、做 AI 应用的产品经理以及所有被复盘走过场折磨过的职场人。如果你只是想要一个现成的一键复盘工具hindsight 的思路也值得你参考因为背后的提示词设计逻辑是通用的。2. 整体方案基于 Dify 的 hindsight 应用架构2.1 为什么选 Dify 而不是自己硬编码说实话第一版 hindsight 是我用 Python 脚本调大模型 API 写的当时觉得也就几百行代码的事。但做到后面就发现一个尴尬问题提示词改一版就要动代码对话历史要自己管想加一个抽取事实的中间步骤还得自己拼字符串。后来我把整个流程迁到了 Dify 上用 Workflow/Chatflow 而不是写代码原因有三可调试性好每个节点单独跑哪一步输出不对劲直接在面板上看得清清楚楚。改提示词不用发版Dify 里改完提示词保存就能生效产品同事也能上手调不用每次找我改代码。后续扩展方便接飞书机器人、接知识库、接外部 API都是画布上拉节点的事。hindsight 我选的是Chatflow聊天流而不是 Workflow。因为复盘这件事用户大概率会追问比如第二步你说的偏差具体指什么、能不能针对这个教训再给一个例子。Chatflow 天然支持多轮对话Workflow 更偏向一次性跑完拿结果。如果你确定只做单次分析用 Workflow 会更简单。2.2 核心流程五个节点把复盘拆成流水线整个 hindsight 的核心是一条五段式分析流水线。这个结构不是拍脑袋定的而是我从复盘方法论里搬出来的先搞清楚发生了什么再看和预期差多少然后想为什么会差最后给出下一次怎么办。节点作用对应变量开始Start接收用户输入的原始材料queryLLM 节点 1事实提取把原文变成结构化 JSONfactsLLM 节点 2偏差识别对比目标与结果gap_analysisLLM 节点 3教训提炼梳理原因与关键转折lessonsLLM 节点 4行动建议输出下次可执行清单actions结束End汇总四步结果拼装成报告最终回复为什么要把事实提取单独拆成一个节点而不是让后面的分析节点直接读原文这是我踩过坑之后才想明白的。直接让 AI 读原文做分析它经常会脑补出不存在的细节比如原文说用户流失严重它能自己编出可能是因为价格太高。但如果先强制它抽取事实字段再基于事实做分析虚构的概率会明显降低。流程拆开本质上是给 AI 设了一道不许乱编的栅栏。2.3 一个关键设计反事实推理hindsight 这个名字的真正含义落在第三个节点里反事实推理counterfactual。所谓反事实就是如果当时换一种做法结果会不会不一样。这是复盘里最有价值、也最容易扯淡的部分。我让 AI 在偏差分析之后专门生成 2 到 3 条如果当时……的假设但有一条硬性要求每条假设后面必须标注它是基于事实的推断还是纯粹猜测。这一步在提示词里写死后面我会把提示词模板贴出来。因为复盘可以大胆假设但不能把假设写成结论否则报告就变成 AI 编故事了。3. 关键实现提示词编排与节点配置3.1 事实提取节点的提示词模板先看第一个 LLM 节点。这个节点的输入是用户刚提交的原始记录输出是一段 JSON。我试过好几个版本最后稳定在这个提示词上你是一个严谨的信息抽取器。请阅读用户提供的复盘材料提取以下字段并只输出一个 JSON 对象不要输出任何解释文字。 字段要求 - background: 事件发生的背景一句话概括 - goal: 用户/当事人原本想达成的目标 - actions: 实际采取的关键行动最多列5项 - result: 实际发生的结果尽量引用原文关键词 - turning_points: 过程中影响事态走向的2-3个关键节点 规则 1. 所有字段必须基于原文不能推测。 2. 原文没有提到的信息字段置为 null。 3. actions 和 turning_points 保留原文短语不要改写。 材料内容 {{user_input}}几个细节为什么要这么写强调只能基于原文是为了防止后面分析跑偏保留原文短语是因为用户提供的复盘材料往往有口语细节AI 一旦改写就容易丢失情绪和关键措辞强制 JSON 输出是为了让 Dify 的下游节点能安全引用变量。3.2 分析与建议节点的提示词设计偏差识别节点接收的是facts变量提示词核心是让 AI 对比目标和结果之间的差距并按严重程度排列。这里我用了一个比较有效的技巧让 AI 先复述一遍目标和结果再做对比。先复述能让它真正读进去而不是随便生成一段漂亮话。经验提炼节点是 hindsight 的灵魂提示词关键词是归因和反事实基于事实清单和偏差分析结果请完成 1. 找出2-3个最可能导致偏差的原因每个原因必须引用事实清单中的具体内容作为证据。 2. 针对每个原因生成一条如果当时……的反事实假设。 3. 明确标注每条反事实假设是基于事实的推断还是推测。 4. 输出的教训要写成可复用的规则不要写成对个人的指责。最后行动建议节点更简单要求输出带时间范围、带责任人的动作列表。因为复盘报告如果只写下次要注意等于没写AI 得给出可执行、可检查的动作。3.3 参数配置模型、温度与上下文模型选择上hindsight 默认接的是推理能力较强的模型因为复盘任务本质上是逻辑分析不是简单问答。如果你的 Dify 里同时接了多种模型建议事实提取用便宜一点的轻量模型后面三个分析节点用强模型性价比最高。温度我统一调到 0.4 左右。太低接近 0输出太死板太高超过 0.7容易在推断环节放飞自我。让我比较直白地说0.4 是我试了二十几次之后的最稳值。上下文管理是一个差点坑死我的点。Chatflow 默认会把多轮对话历史全部传进去导致第一轮抽取的facts变量还好好的到了第三轮追问时模型开始盯着历史看把用户新的追问当成复盘材料的一部分。解决办法是在节点参数里显式设置history变量并且把事实提取节点固定只读取sys.query里最新输入的原始材料前面的历史不参与这一轮提取。4. 实操过程从零搭一个能跑的 hindsight4.1 环境准备Dify 部署与 Chatflow 创建假设你已经有一台能跑 Docker 的服务器这是最快的方式。第一次部署 Dify 大概十来分钟可以边喝咖啡边等git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d启动以后打开http://你的服务器IP第一次进来会让你设置管理员账号。然后进入应用列表新建应用选Chatflow名字就叫hindsight。进了编排界面左侧是节点面板右侧是画布。默认画布上已经有两个节点开始Start和结束End。我需要先到开始节点里把输入字段从默认的sys.query改成自定义的user_input原因前面说过我不想让多轮历史污染原始材料。改完以后开始节点下方会暴露一个名为user_input的变量后面所有节点都要从它身上拿数据。4.2 节点配置顺序与变量传递按顺序拖出四个 LLM 节点我把它们改名成fact_extract、gap_analysis、lesson_extract、action_plan方便排查问题。第一个节点配置如下模型选轻量模型上下文{{#start.user_input#}}提示词用上面 3.1 节里的模板输出变量命名facts输出格式JSON第二个节点gap_analysis上下文{{#fact_extract.facts#}}提示词3.2 节里的偏差识别提示词输出变量gap第三个节点lesson_extract上下文把{{#fact_extract.facts#}}和{{#gap_analysis.gap#}}拼接起来输出变量lessons第四个节点action_plan上下文接收facts、gap、lessons三份数据输出变量actions最后在结束节点里写一句话把四个变量打包返回【事实还原】 {{#fact_extract.facts#}} 【偏差分析】 {{#gap_analysis.gap#}} 【核心教训】 {{#lesson_extract.lessons#}} 【行动建议】 {{#action_plan.actions#}}4.3 实际案例跑一遍看看输出长什么样我拿一段一个朋友给我吐槽的本周项目翻车记录当测试材料原文大概是这样的周一开始开发一个优惠券功能周五要上线。周一产品说需求没问题周二我发现库存接口和优惠券系统对不上问了后端后端说周三才能改。周三又说联调环境挂了顺延到周四。周四终于联调完测试跑出一个严重 bug。周五硬着头皮上线当天晚上用户反馈领不到券转化率掉了 3%。跑完 hindsight输出大概长这个结构事实还原 - 背景五天期限的优惠券功能开发任务 - 目标周五正常上线并提升转化 - 关键转折接口对不上周二、联调环境故障周三、严重 bug周四、线上故障周五 - 结局上线当晚故障转化率下跌约 3% 偏差分析 - 目标与结果间严重偏差 - 最严重偏差技术风险没有被前置识别直到周二才发现接口问题 核心教训节选 - 接口依赖未在开发前确认属于基于事实的推断类教训 - 联调环境故障没有预案属于推测级假设 - 可复用规则任何涉及外部系统的功能开工前必须先核对接口契约 行动建议节选 - 下次项目开工第一天由后端列出所有依赖接口清单输出接口契约文档建议周五前完成 - 为联调环境故障预设备用环境切换方案建议下次项目启动前完成演练可以看到hindsight 没有把责任推给某个人而是把问题落到了流程节点和下次动作上。这就是我当初想达到的效果复盘不指责只转化。4.4 兜底技巧JSON 解析失败怎么办Dify 的 LLM 节点虽然能设定输出格式为 JSON但模型偶尔还是会抽风返回一段带注释的 JSON或者干脆把提示词里的规则也复述一遍。我的兜底方案是加一个代码节点Code放在fact_extract后面专门负责清洗返回内容。代码节点里我放了一段 Python做两件事从模型输出里找到{开头}结尾的子串然后用json.loads尝试解析解析失败了就丢出一个默认的facts空结构。代码如下import json, re def main(context: dict) - dict: raw str(context.get(raw_output, )) # 提取 JSON 子串 match re.search(r\{.*\}, raw, re.S) if match: try: data json.loads(match.group(0)) return {facts: data} except Exception: pass return {facts: { background: None, goal: None, actions: [], result: None, turning_points: [] }}这个节点看着简单但能在关键时刻保住整条流程不中断。复盘这种事最怕的就是用户把材料都交出来了流程却报错了。5. 常见问题与排查技巧实录5.1 AI 乱归因把臆测写成结论这是我用第一版 hindsight 时最常遇到的问题。模型为了输出深度分析会编造一条看似合理的因果链比如客户流失严重推测是因为竞品降价——原文里根本没提竞品。后来我在提示词里做了三重限制事实提取节点强制所有字段必须基于原文不能推测。偏差分析节点要求每个原因必须引用事实清单中的内容作为证据。反事实假设明确标注推断还是推测。三重限制加上去之后输出质量肉眼可见地提升。这里想提醒你一点不要指望一条提示词解决所有问题流程上的限制比提示词更可靠。5.2 中文材料的语气与情绪被 JSON 抽干把事实转成结构化 JSON 有一个损失口语里的情绪、语气、犹豫都没了。比如我其实很早就觉得有问题但当时没敢说转成turning_points之后变成了察觉问题但未提出。信息没丢但决策时的心理负担丢了。我的处理办法是在事实提取节点里加了一个字段contextual_hints专门用来保留原文中情绪化、模糊化的表述比如没敢说有点慌拖了很久。分析节点拿到这个字段后能感知到很多事实之外的信号。这个字段我是后来加的但它反而成了整个复盘报告里最有人情味的部分。5.3 上下文太长了后面的节点失忆当用户贴了一大段项目日志然后再追问两句Dify 会把整个对话历史传给后续节点导致三个问题响应变慢、Token 变贵、分析内容被历史稀释。我的解法是严格执行单轮分析模式开始节点只暴露user_input不引入history。四个分析节点全部只引用前序节点的输出变量不引用会话历史。如果想做多轮问答也是围绕已有的facts和gap变量继续问而不是重新分析原文。实际用下来这种一次性材料 结构化结果持久化的模式比让模型全程记住上下文要稳定得多。Dify 的变量机制刚好支持这个玩法你只需要在节点设置里手动引用变量别偷懒直接塞#sys.history#就行。5.4 复盘报告太长太啰嗦没人看第一版输出结果是一个大长串用户反馈看完第一段就不想看后面的了。后来我在结束节点里把报告拆成了两块上面是精炼版十五秒能看完下面按需展开查看详细版只在这个人想深究时才需要给。Dify 的 Chatflow 里可以直接用条件分支IF/ELSE节点做这个事根据用户是否点了详细复盘再拼接第二个长报告。这个改动不大但用户留存率高了很多。6. 扩展思路hindsight 还能怎么玩6.1 接机器人每周五自动做项目周复盘hindsight 现阶段最大的用法是我把它接到了一个自建的群机器人上。每周五下午机器人会把群里这一周的所有项目相关消息拉出来扔给 hindsight然后生成一份本周项目复盘简报自动发到群里。简报里不会点名道姓骂谁只会列出流程上的问题和下周行动项。如果你也想这么做可以在 Dify 上把应用发布为 API然后用一段简单的 webhook 代码把它接到飞书或者钉钉机器人上。核心代码不复杂大概就是收消息、调 Dify API、把返回内容发回群里import requests def handle_message(raw_text): resp requests.post( http://your-dify-api/chat-messages, json{ inputs: {user_input: raw_text}, query: 请对以上内容进行一次事后复盘, response_mode: blocking, user: weekly-bot } ) return resp.json().get(answer)6.2 把复盘结果回填知识库形成个人经验库这是一个我打算下一步做的方向。当前 hindsight 复盘完报告就飘散在对话流里了。更好的做法是加一个节点把每次产生的lessons写到 Dify 知识库里作为文档存储。这样一来等你要做下一个项目的时候可以把真正的经验翻出来看而不是靠记忆去回想。AI 帮我们把每一次后悔都变成了可以检索的资产这是后见之明这个题目里最值钱的部分。6.3 与语音转文字结合开完会直接出复盘如果你所在团队经常有复盘会议可以把语音转文字服务输出的会议纪要直接丢进 hindsight让它提炼会议中提到的偏差与教训。我试过几种转录服务效果都可以关键是喂进去的材料别太乱转录后的文本最好先做一次基础清洗比如去掉嗯那个之类的语气词hindsight 的分析质量会高一个档次。另外还有一个思路值得提一下不要把 hindsight 局限在失败复盘上。成功的事情也可以丢进去跑一遍。分析为什么成功、哪个动作起了决定性作用和复盘失败一样有价值。我目前也在收集成功场景的案例看看模型在这类输入下会不会给出更有建设性的输出。做这个应用的过程中我最大的体会是hindsight 这个名字起得有点反讽的意思因为传统的 hindsight 总是事后才明白而我想要的其实是把事后明白变成事前检查清单。Dify 只是工具真正难的是把复盘的逻辑想明白并落进提示词和流程里。如果你也在折腾类似的东西我建议别急着堆节点先把你要复盘的场景拆清楚事实是什么、目标是什么、偏差是什么、教训是什么、下次怎么做。拆清楚了剩下的就是用 Dify 把这些环节一个个串起来。最后再分享一个小技巧调好第一版以后找几个真实案例跑一遍然后盯着输出改提示词。别用自己编的完美案例调试因为真实材料里的模糊、噪声、情绪才是这个应用真正要处理的难题。