最近我在Dify上搭了一个叫 hindsight 的应用名字取自英文里的“后见之明”说白了就是大家常说的“事后诸葛亮”。这个项目的出发点很朴素把复盘这件事做成一条可复用、可流程化的工作流让AI带着你一步步回看发生了什么、为什么会这样、下次怎么改。用Dify来做是因为它不需要你从零写前后端代码也不用自己折腾Prompt调度那一大堆底层的逻辑可视化拖几个节点就能跑起来对想把想法快速验证的人特别友好。这个应用适合的人群其实挺广的。备考的学生可以拿它做错题复盘产品经理可以拿它做版本总结创业者可以拿它回顾一次失败的谈判甚至普通上班族每天写工作日志、周末做周总结都能用上。它解决的核心问题不是“帮你预测未来”而是“帮你看清已经发生过的事”——并且把看清之后得出的结论真正转化成下一步行动。我这段时间实际跑下来最大的感受是复盘这事有框架和没框架效率差着一个数量级。下面我把这个项目的设计思路、在Dify上一步步搭建的完整过程以及踩过的坑都拆开讲清楚希望能给你一些可以直接抄作业的参考。1. 项目缘起与整体设计1.1 为什么做“复盘”而不是“预测”hindsight 这个项目一开始的灵感来自我对周围人复盘方式的一个观察。大多数人不是不愿意复盘而是“复盘”这个词听着宏大真坐下来面对电脑时完全不知道从哪里下手。最常见的状态就是想起哪说哪完全碎片化。今天聊到结果不好明天才想起过程有问题后天又想到当时其实有个机会没抓住。信息散落在脑子各个角落串不起来。情绪化严重。写复盘写成了检讨书满屏都是“我太粗心了”“我太着急了”“我真不应该”。情绪宣泄完了问题到底出在哪个环节说不清楚。没有闭环。复盘完列了一堆“下次注意”“以后要改”然后把文档一关下次该怎么样还怎么样。复盘的产出没有真正进入行动清单等于白做。这些问题背后有一个共通的原因复盘是一种典型的“后见之明”行为——事情发生之后回过头去重新审视当时的决策路径。但人脑的后见之明天然会受到情绪、记忆偏差、自我防御机制的影响几乎不可能做到客观。所以我在想如果让AI来扮演一个“中立复盘教练”用一套固定的结构化框架来带着用户走完整个回顾过程是不是就能把这个偏差压到最小于是 hindsight 这个项目就定了方向不做预测不做分析报告生成器只做一件事——帮用户把一件已经发生的事从事实还原到行动转化走完一个完整的闭环。1.2 为什么选 Dify 而不是直接写代码我之前也试过很多种落地方式。最早是直接在系统里写一个Prompt复制到任意AI对话框里用但那样没任何集成输出的内容也全靠模型临场发挥格式不稳定。后来也想过去翻各种Agent框架但那些方案针对我这种场景来说太重了又是向量存储又是工具调用光基础设施就要折腾好几天。最后选了Dify原因很直接可视化编排。hindsight 的核心流程是固定的五段式非常适合还原成工作流节点。Dify里就通过拖拽节点、连连线来搭建整个流程我能很直观地看到“事实还原→结果评估→原因分析→经验提取→行动清单”每一步的走向。组件开箱即用。LLM节点、知识检索节点、模板节点、条件分支节点全都内置好了。我不用写任何代码只需要填Prompt和配置参数。输出标准。工作流允许我把每一步产出的结构化内容汇总到一个模板里最终生成一份格式统一的复盘报告这比纯对话输出来得整齐多了。后期可扩展。以后万一想加入历史复盘记录检索Dify自带的知识库直接把文档导进去就能实现向量召回不用另外搭一套检索系统。当然用Dify也有它的代价最大的代价就是你得接受平台自己的一套节点逻辑稍微复杂一些的跳转、循环得靠变通实现。但对于hindsight这种线性流程它刚好卡在“顺手”和“可控”的最佳平衡点上。1.3 整体架构五段式闭环工作流hindsight 的整体结构简单画一下就是这样输入事件描述 → 事实还原 → 结果评估 → 原因分析 → 经验提取 → 行动清单 → 输出完整报告整个流程是一个严格的串联工作流前一个节点的输出会成为后一个节点的输入。为什么我不把它做成一个大的LLM节点一步到位生成报告有两个原因。第一拆开后每一步输出都更稳定。如果让模型一口气从“复盘事件”生成到“行动计划”它在早期阶段就可能会把推论参数混进事实里到最后所有内容糊成一团。分步骤逼迫模型先处理完“事实是什么”再处理“为什么”再处理“怎么做”每一层的逻辑都清晰可控。第二用户可干预。在工作流里理论上你可以在每一步之间加一个确认节点让用户看到事实还原结果之后再决定要不要让AI继续往下走。虽然我现在这个版本没做人工确认但这个架构本身保留了扩展空间以后想往“人机协同复盘”方向走改动不会伤筋动骨。这个设计思路决定了hindsight的上限它不是一把刀而是一条流水线。你往这头放进去一件发生过的事那头出来的是一个带着行动建议的复盘报告。2. 核心能力拆解hindsight 到底在解决什么2.1 五维复盘框架为什么这么设计我在设计hindsight的核心能力时参考了管理学和心理学里对“复盘”这件事的通用拆法结合实践中比较好用的模型最终定下五个维度这五个维度也是整个工作流的五个核心节点维度解决的问题输出内容示例事实还原发生了什么按时间线梳理的事件经过、关键行为、参与对象结果评估做得好不好与预期目标对比、差距分析、可量化的结论原因分析为什么会这样直接原因、根本原因、外部因素与内部因素经验提取从中能学到什么可复用的方法论、必须避免的错误清单行动转化下一步做什么SMART原则的改进计划、时间节点、优先级这个顺序有严格的逻辑关系。先客观后主观先把“发生了什么”定性清楚才允许模型进行评价先结果后原因先搞清差距再追根溯源先过去后未来先提炼教训最后才谈行动方案。如果顺序反了让模型一上来就评价它很容易把“评价”写到“事实”里去到最后用户拿到的是AI脑补的剧情而不是自己的真实经历。举一个具体的例子。假设输入的事件描述是“期中考试数学考砸了比平时模考低了30分丢分主要在后三到大题但在考场上我一直觉得这些题不难。”事实还原环节会要求模型先剥离“考砸了”这个判断写下“实际得分比模考低30分”“后三道大题未完成或失分”“做题时主观感知难度较低”这样的事实。结果评估环节对比“目标分数”与“实际分数”的差距。原因分析环节就会把“主观认为不难”和“实际失分严重”这两个矛盾摆在一起引导用户思考是不是存在过度自信、时间分配失误或者审题偏差。经验提取和行动转化则落在“下一次考试前增加模拟限时训练”这类具体的动作上。这个框架的好处是不管用户丢进来的是工作项目、感情问题还是健身计划模型都能套用同一套逻辑拆解不跑偏。2.2 提示词设计给 AI 立人设、定规矩hindsight 的提示词是整个应用里最核心的部分我调了很多版才稳定下来。总结起来有三个要点。第一角色设定不能是“老师”也不能是“领导”。我试过让AI扮演“严格的导师”结果输出的内容充满了说教感用户本来就想复盘结果被AI教育一通体验很差。最好用的角色是“复盘教练”——它不做对错审判只负责提问、汇总、引导思考。我在提示词里明确写着你的目标是帮用户理清思路而不是评价用户的对错。第二必须要求结论绑证据。这是防止AI输出“正确的废话”的关键。所谓“正确的废话”就是“复盘后我发现需要更加努力”“要注意时间管理”“下次要更细心”这类每个字都对但没有任何用的结论。在提示词里我加了这条硬约束每一个结论必须对应事件描述中出现过的具体细节禁止给出空泛评价。第三输出格式要结构化。每个节点输出的内容都指定了小节名、数量比如“原因分析最多列出3条每条原因必须包含对应的事实证据”这样后面聚合的时候格式才不会乱。下面这份是我目前在“原因分析”节点用的Prompt基本思路可供参考你是一名经验丰富的复盘教练正在帮用户分析某次事件产生的原因。 用户提供的事件描述如下 {{事件描述}} 基于已经完成的事实还原与结果评估结果请分析 1. 直接原因哪些行为或决策直接促成了当前结果 2. 根本原因哪些深层因素习惯、流程、认知偏差导致了直接原因 3. 分类限制只能使用事件描述中出现的细节作为分析依据禁止补充推测性信息。 输出格式 ## 直接原因 - ... ## 根本原因 - ... ## 分析说明 - 用一至两句话说明从直接原因导向根本原因的逻辑链条。因为我在工作流里把事件描述作为节点变量传进去了所以这份Prompt能准确拿到原始输入。这里没有用复杂的技巧核心就是“限制信息来源限制输出格式”。2.3 要不要上知识库什么时候上hindsight 早期版本没有知识库纯粹靠单次输入的Prompt进行分析跑通了之后我才意识到一个问题这套系统每次复盘都是“失忆”的。今天复盘跟昨天复盘完全没关系用户上个月踩过的坑这个月很可能根本不会在分析中被提到。后来我加了一层知识库专门存放用户以往的历史复盘报告。每次完成一次复盘我会把最终报告手动存进Dify知识库一起存入的还有事件摘要和行动清单。下次用户再提交同类事件时工作流里的“知识检索”节点就会从历史报告里召回相似的事件记录把相关内容注入到“原因分析”和“经验提取”两个节点的Prompt里。加入知识库之后效果提升非常明显。比如你在“考试复盘”里提到“这次又没时间做最后一道大题”知识库能召回上次复盘里已经写下的“考试时间分配策略需要调整”AI就会用这段历史作为交叉参考而不是再从零推导一遍。不过知识库不是必需的。如果你只是拿hindsight偶尔用一用完全可以先不上知识库只保留一个纯工作流版本。等到你发现自己已经积累了七八篇复盘报告之后再考虑把知识库加上去是性价比最高的路径。3. 实操过程在 Dify 上一步步搭出 hindsight3.1 准备阶段部署与环境配置在Dify上手搭建前先把前提条件准备好。第一你需要一个能访问Dify控制台的账号。如果是本地部署参考官方文档用Docker Compose启动即可如果想省事直接用云端版。注册体验方面云端版会更快一些。第二配置模型供应商。在控制台左侧菜单找到“设置-模型供应商”选择你打算用的模型。hindsight 对模型的推理能力有一定要求因为要看穿事件之间的逻辑关系建议选支持工具调用的主流模型。配置方式是在对应渠道的API Key填进去测试一下连通性就行。模型选择上我想多说一句。复盘场景对模型的要求是“中文理解能力强”和“指令遵循稳定”。有些超大参数模型虽然什么都能聊但输出风格比较发散不适合流程化复盘反过来一些偏轻量的模型响应快但多步推理能力稍微弱一些。我自己用下来在Dify上配置了中文支持较好的模型温度参数设置在0.3左右效果最稳定。3.2 创建应用与第一步输入设计准备工作就绪后在Dify首页点“创建应用”应用类型选择“工作流”而不是对话机器人。这一步是我踩过的小坑之一。我最初用的是“对话型应用”以为多轮交互更方便。但对话型应用的核心是自由对话用户可以直接打断、追问流程控制力弱我需要的其实是“点一下输入跑一条流水线”的确定性过程所以“工作流”类型才是正解。应用创建好之后第一件事是配置开始节点的输入字段。我设置的字段如下event_description必填多行文本用户对事件的完整描述想写多细写多细。review_goal可选下拉选择复盘目标比如“改进流程”“缓解情绪”“寻找机会”这个字段会直接注入到结果评估节点的Prompt里。attach_files可选文件如果用户有聊天记录、报表、错题本照片等可以上传附件供模型参考。有人问事件描述用多行文本框用户会不会写得过于零散我在实际使用中发现零散反而更好。hindsight 的“事实还原”节点本来就会帮用户把碎片整理成时间线所以这里不要求用户写得规整重点是让用户不要有“写不好就不想写”的心理压力。开始节点配置完成后往下面拖第一个LLM节点命名为“step1_fact_restore”输入绑定 event_description。节点输出选择结构化格式字段先定义成简单文本后续方便多个LLM之间传值。3.3 编排五段式核心节点接下来是整个工作流的主体部分。我在画布上依次拖出四个LLM节点和一个模板转换节点连线方式是一条直线串联。第一个LLM节点事实还原输入是开始节点的 event_description 和 attach_files。这里的Prompt任务是提取事实、过滤判断、按时间线排列。输出字段名我定义为 facts_text。这个节点最重要的是Prompt里的一句话“注意区分用户陈述中的客观事实和主观评价只提取可以验证的动作、时间、数字、对话内容把评价类语句放到后面的结果评估阶段再处理。”第二个LLM节点结果评估输入是 facts_text 和 review_goal。Prompt任务是基于事实还原结果判断实际结果与预期目标的匹配度定位偏差发生在哪个环节。输出字段 result_eval_text。第三个LLM节点原因分析输入是 event_description、facts_text、result_eval_text也就是把事实和评估都喂进来进行归因。这一步也是我前面提到“结论必须绑证据”的主要执行点。输出字段 reason_text。第四个LLM节点经验提取与行动清单输入是前面所有步骤的输出再加上一个约束优先输出可落地的动作每个动作必须包含执行人、时间、验收标准。这个节点我单独加了温度参数调低到0.2因为它需要的是精准而非发散。输出字段 action_text。模板转换节点组装最终报告由于前几个节点输出的都是文本片段最后用模板转换节点把它们按固定的Markdown格式拼成一份完整报告。模板里可以写死一级标题和段落顺序再把各节点输出变量插入到对应位置。结束节点结束节点选择“返回文本内容”变量引用模板节点的输出。这一整条串联线就通了。有些读者可能会问为什么不在一个LLM节点里一次性输出完整报告硬要拆成四段我在前面说过用拆分方式是为了每步可控、格式稳定。但如果你觉得四个LLM节点成本太高也可以合并成两个节点第一个节点做“事实还原结果评估”第二个节点做“原因分析行动清单”中间用模板拼接一下。两种方案我都跑过完整版输出质量更高合并版响应更快按需取舍。3.4 测试与调优的真实过程工作流搭好之后我用一条真实事件做了测试。事件描述是“上周和一个重要客户聊方案聊到一半我发现对方脸色不对但我没停下来确认还是继续把PPT讲完了。结果对方拒绝签约说觉得我们不够重视。”跑出来的结果让我既满意又意外。满意的是事实还原阶段准确识别出“对方脸色不对”“没停下来确认”“继续讲完PPT”“拒绝签约”这几个关键行为而且没有把“对方觉得我们不重视”这句用户的主观推测当成事实。意外的是原因分析阶段它调取了知识库里一篇历史复盘中提到的“销售拜访中非语言信号处理”的相关内容给出的建议比单纯基于本次事件的推理更具体。但第一次测试也暴露了一些问题。最明显的是原因分析输出太长把三条原因每个都展开写了一大段整个复盘报告读起来像论文摘要不够精简。我的解决办法是在Prompt尾部增加一条硬性格式要求“总字数不得超过350字每条原因限制在50字以内使用短句。” 加完之后输出立刻清爽了不少。温度的调整同样是在测试中完成的。第一次测试我把节点参数保持默认值原因分析里出现了“可能”“也许”这类弱动词整段内容的确定性不足。后来我把原因分析节点的temperature调到0.3情况好了很多。建议你第一次设置时不要追求完美先跑通再拿三到五条真实历史事件连续测试逐条观察问题出在哪个环节再针对性微调那个节点的Prompt效率最高。4. 进阶玩法让 hindsight 真正融入你的工作流4.1 场景扩展一考试错题与备考复盘hindsight 基础版跑通后我做的第一个场景扩展是考试错题复盘。毕竟对很多学生党来说“考试考砸了”是最需要复盘的高频场景。这里的改动其实很小主要是在开始节点加了一个“考试科目”下拉字段同时在结果评估节点的Prompt里加入一句“如果本次复盘涉及考试请额外分析知识点掌握程度、考场时间分配、心理状态三个维度。”效果比较明显。比如用户输入一次数学模考失利最终报告里就会多出一块“错因归类”是知识点盲区、粗心漏看条件、还是时间不足导致的大题空白。原因分析会基于历史记录指出这个用户连续三次都在同一个章节失分行动清单则会要求“接下来一周每天21点前完成15分钟针对数列压轴题的限时训练周六自测一次”。这类场景一旦模板成型用户只需要换一套Prompt就能把hindsight从职场复盘工具改造成学习复盘工具。4.2 场景扩展二项目结项复盘第二个场景是项目结项复盘这个场景对输入结构化要求更高一些。我在开始节点额外加了几个字段项目周期、团队人数、原定目标。项目复盘和考试复盘最大的区别在于它需要关注“人和人之间的协作”以及“流程设计”。所以在经验提取节点的Prompt里我专门加了一条分别从“个人执行”“团队协作”“流程机制”三个层面给出经验缺一不可。这样一来产出的报告就会覆盖到沟通成本高、需求变更频繁这类流程性问题而不只是某个人的成败。很多项目复盘工具都会面临一个困境复盘完了文档躺在云盘里吃灰。hindsight 的行动清单节点就是为对抗这个困境设计的。它强制要求每个行动计划都有“负责人截止时间验收标准”这些数据也可以直接导出做成项目待办。4.3 从单次工作流变成长期可沉淀的系统用多了之后我越来越觉得hindsight 真正最值钱的地方不只是“复盘这一次”而是长期积累形成的“个人经验数据库”。我的做法是每做完一次复盘就把生成出的最终报告转成文本存进Dify知识库标题写清楚“日期事件类型一句话概括”。知识库分片大小我习惯设置为500个字符左右检索模式用混合检索。等存了20篇以上你再回头看基本就是一本属于自己的“决策错题集”了。在这个基础上还有一种玩法周总复盘。每周日把这一周所有复盘报告的标题和结论聚合起来另外用一条简化版的工作流跑一遍让AI归纳出本周反复出现的三类问题作为下周的行动重点。我现在保持了每两周跑一次周总复盘的习惯它对工作的指导作用比单次复盘强得多。提醒一下知识库不是越早加越好。很多人一上来就折腾知识库结果发现检索质量不精准又花时间去调非常劝退。正确路径是先跑通标准工作流收集到足够的原始复盘再加知识库做引用。5. 常见问题与避坑指南5.1 输出“正确的废话”怎么办这是hindsight所有使用方式里最容易踩的坑。现象是报告里全是“要提高自己的沟通能力”“加强时间管理意识”这类放之四海而皆准的话没有一条真正指向用户自己的问题。我排查过的原因主要有三个一是事件描述给得太模糊模型没借口从细节里找证据只能泛泛而谈二是Prompt里没强调“每条结论必须引用事件细节”三是知识库检索到了很多相关但空泛的历史总结模型混淆了信息来源。解决办法首先在事件描述框里提示用户“写得越具体越好包括时间、数字、对话内容”其次在原因分析和经验提取两个节点的Prompt里强制加一句话——“只用事件描述中出现过的细节作为证据禁止无证据推断”最后检查知识库里的历史文档如果旧报告本身就是一堆空话那得先清理掉否则模型会被反复带偏。5.2 模型输出太长或格式混乱工作流模式下模型输出格式不稳定通常是因为节点Prompt里没有给出强约束。我自己的经验是不管哪个节点只要输出字段要求超过一个段落都要在后半部分加一个“输出格式要求”区里面写清楚各级标题用什么符号、每条限制多少字、总共不超过多少字。比如原因分析节点我直接限制总字数不超过350字每条原因不超过50字。加上之后输出基本就没再乱过。5.3 节点串联之后变量传参报错Dify工作流里A节点的输出作为B节点的输入有时候会报“变量不存在”之类的错新手容易一头雾水。这类问题绝大多数是先后顺序搞错了B节点的Output变量还没有定义好就先去引用它。解决方法是严格按节点执行顺序创建每写完一个节点保存并确认它的输出字段已经生成再去做下一个节点的变量引用。5.4 常见问题速查表现象可能原因解决办法报告内容泛泛而谈事件描述太简略、Prompt缺少证据约束提示用户补充细节原因分析节点Prompt增加“结论必须对应事实”输出跑题或格式错乱节点Prompt没给输出模板在Prompt末尾写明输出结构、字数限制、标题符号知识库引用了无关历史分段粒度太粗或检索阈值太低将知识库分段调小提高检索相关性阈值检查历史文档标题是否清晰流程执行太慢、token消耗大LLM节点过多、输出长度没限制合并部分节点限制每个节点的输出字数降低温度参数直接调用Dify API超时单次请求耗时长、节点排队调短首步Prompt长度对大事件拆分成多次复盘最后再分享一个执行层面的小技巧多轮调优之后我自己用得最多的其实是hindsight里一个最朴素的设计每次生成完整报告之前先让工作流单独输出一份“事实还原摘要”我花30秒扫一遍。这一步看起来多了次人工确认实际效果是让后面的原因分析靠谱了一大截。因为当模型把“事实”和“评价”分开时用户本人也会抵抗住那种不由自主的自我辩护更容易平心静气地接受AI的分析结果。hindsight这个名字起得确实贴切。它不能预判未来也没办法替你重做决策但它能逼着你把已经走过的路重新走一遍看清楚每一步为什么踩空。这个项目的价值不在生成报告那一刻的惊艳而在一个月之后你翻到旧报告开始执行行动计划的时候。别想着第一次就做到完美先把最小闭环跑通把一次复盘做扎实再慢慢加知识库、换场景模板。对我个人来说这是今年在Dify上做过的性价比最高、用起来最顺手的一个工作流。
