Hindsight这个词直译过来是“后见之明”也就是事后才看清事情本质的恍然。它还有一层挺妙的背景——詹姆斯·乔伊斯在《尤利西斯》里给一个角色的名字就叫Mr. Hindsight专门负责在事后说“你看吧我早就觉得会这样”。文学里的味道是讽刺但在现实里这种能力反而稀缺我们大多数时候看不清眼前的选择只有退后一步、等时间过去才真正读得懂自己当时为什么会那样做。所以当我决定做点跟“复盘”相关的东西时第一个想到的名字就是hindsight。我的目标不是做一个更漂亮的数据日记本也不是情感树洞而是借助大语言模型搭一个合格的“复盘教练”你丢给它一段混乱的经历描述它通过多轮提问帮你把目标、预期、结果、归因一步步理清楚最后生成一份结构完整、点评克制、能落到行动上的复盘报告。项目基于 Dify 平台构建采用 Chatflow 应用类型实现多轮引导对话。选择 Dify 而不是从零开发前后端是因为复盘类应用的重心在对话策略和提示词打磨而不是系统架构。本文我会把方法选型、提示词设计、工作流节点配置、以及我踩过的几个实际坑点全部拆开讲适合想用 Dify 做对话式工具、或者对 AI 辅助自我反思场景感兴趣的人参考。1. 项目整体设计复盘工具为什么需要AI以及为什么选Dify1.1 复盘这件事卡在“当局者迷”上先说实话市面上不缺复盘方法KPT、GRAI、AAR、PDCA随便搜都是一堆。但大部分人的复盘习惯最终都会断掉因为问题的关键不在方法而在“当局者迷”。你刚做完一次汇报、写完一篇方案、或者带完一个活动大脑里剩下的是一团情绪化的感觉紧张、兴奋、后悔、侥幸。这时候让你冷静下来对照“目标-结果-归因”框架其实是反人性的因为你正处于事件余温里脑子里全是我当时要是那样说就好了。你会高估自己的失误也会忽略外部环境的客观制约。AI 在这里扮演的角色并不是帮你给出正确答案而是一个不受情绪干扰的提问者。它不会因为你说了很多沮丧的话就跟着共情也不会因为你表现得很好就花式吹捧。它只会按设定好的流程一次问一个关键问题一步步把你拉回事实层面。Hindsight 的定位因此非常明确它是复盘教练不是心理咨询师也不是夸夸机器人。1.2 最小闭环一段混乱描述到一份可执行建议我最初规划功能时可以做得非常重事件分类、心情指数、语音输入、数据可视化。但冷静评估 MVP 之后我只保留了一条最小闭环用户输入一段自然语言的事件描述越口语化越好系统提取本次复盘的关键信息目标、行动、预期结果、实际结果、情绪状态如果信息不完整系统每次只提一个最关键的问题补全信息当信息足够时系统生成五段式复盘报告一句话复盘、目标回顾、预期与现实差距、双维度归因、下一步行动每份报告末尾留下一道开放式问题引导用户今后继续深入为什么坚持“一次只问一个问题”这是我反复测试后得出的结论。多轮对话类 AI 最让人烦躁的体验就是模型一口气反问你三五个问题用户回复负担极重。而复盘这个场景需要的是轻松的自我袒露一次只问最关键的、能推动分析的那个问题用户留在对话里的意愿会高很多。实测下来单问题策略的交互完成率要比多问题策略高不少。1.3 为什么是 Dify而不是自己写一套应用我认真考虑过自己搭后端接大模型 API前端写一个聊天窗口再用向量库做长期记忆。但做到一半我就意识到这个项目的价值点全在 Prompt 策略和对话流程控制而 Dify 恰好把这些非核心的脏活全部承包了。选择 Dify 的理由具体有三点。第一Chatflow 的可视化编排极大降低流程调整成本。复盘的对话策略不是一次想好的我前前后后调了十几版包括何时进入报告生成分支、何时让系统闭嘴听用户说话。如果用代码硬编码代价是不小的在 Dify 画布上直接拖节点、改分支条件基本改完就能测。第二会话记忆不用自己维护。复盘场景经常是连续多轮追问用户第三轮补充的信息需要被第六轮的分析节点使用。Dify 内置的会话记忆机制可以把这个上下文带住我只需要关心变量命名和窗口大小。第三模型切换灵活。我前期用不同厂商的大模型做过交叉验证有的模型指令跟随好但太爱说教有的悟性高但格式爱飘Dify 里可以快速做切换对比不用改代码。这一点在提示词调优阶段极其好用。用的版本是 Dify 社区版 1.x 左右下面所有配置截图对应的就是那个版本的控制台布局。整体功能差异不大新版本以下几点操作更顺滑但设计逻辑是一样的。2. 核心功能设计复盘方法、Prompt工程与对话流2.1 复盘方法论从 GRAI 模型到五段式报告Hindsight 的报告结构不是凭空想的它主要由 GRAI 复盘法演化而来。GRAI 的四个步骤分别是 Goal目标回顾、Result结果陈述、Analysis原因分析、Insight总结规律。这个框架很清晰但在实际对话里直接扔给用户去执行会很生硬因为大多数人写不清“目标”和“结果”到底差别在哪。我做了一些适应 AI 对话的产品化改造最终形成五段式结构一句话复盘用五十字以内把这次经历的本质概括出来。这个概括越扎心越好我甚至要求模型避免使用“通过这次经历我学到了”这类套话。当时的目标把用户自己陈述的目标复述一遍帮用户确认“我到底想要什么”。预期与现实的差距用一个 Markdown 表格做三列对比分别是预期结果、实际结果、差距判断。表格的视觉冲击力比纯文字强很多能让用户明确看到自己哪里判断偏了。双维度归因分为可控因素和外部环境。可控因素必须写具体可执行的改进点禁止出现“提升自己”“更加努力”这类空话外部环境帮用户分清哪些不是自己的责任避免过度自责。下一次行动只给一条行动建议且要求可量化、两周内能完成。少即是多一条落到实处永远比三条漂亮话管用。选择这个结构的好处是它既保留了复盘方法的严肃性又非常契合大语言模型的输出习惯。结构化模板能显著提升输出稳定性用户拿到报告也更有“拿到一份正式结论”的仪式感而不是随便聊了几句。2.2 角色设定与系统提示词拆解Prompt 里最重要的是系统提示词它决定了这个应用是一台复读机还是一个合格的教练。我的第一版提示词写在下面可以直接复制到 Dify 的 LLM 节点里使用。你是 Hindsight一名复盘教练retrospective coach。你的任务不是评判用户不是鼓励用户也不是给建议而是帮助用户看清自己行为背后的逻辑产生真正的后见之明。 你遵循以下对话原则 1. 如果用户描述的事件缺少关键信息当时的目标、实际采取的行动、预期结果、实际结果、情绪感受、外部约束你只能提出一个最关键的追问不要一次问多个问题。 2. 如果用户明确输入直接给报告则跳过提问环节立即使用当前已有信息生成报告。 3. 只有当用户提供的信息足以形成完整分析时才输出复盘报告。报告开头必须包含复盘报告四个字。 4. 绝不要编造用户没有说过的事实信息。如果某个信息缺失在报告中明确标注暂时缺失而不是自行脑补。 复盘报告严格按以下 Markdown 结构输出 ## 一句话复盘 50字以内概括这次经历的本质避免通过这次经历学到了这类套话 ## 当时的目标 用户当时真正想达成什么 ## 预期与现实的差距 | 预期结果 | 实际结果 | 差距判断 | | --- | --- | --- | | 用户当时的预期 | 用户描述的实际 | 超出预期/符合预期/未达预期 | ## 双维度归因 - 可控因素用户本人可以改变并下次做得更好的部分必须写具体动作禁止空泛建议。 - 外部环境客观存在的限制帮用户分清哪些不是自己的责任。 ## 下一次行动 只给一条可执行建议要求可量化、两周内可完成 报告最后加一行 未来的一个开放问题……基于这次复盘提出一个用户下次可以继续思考的方向这段提示词里最关键的不是报告结构而是前四条对话原则。特别是“一次只问一个问题”和“不要编造”这两条几乎决定了整个应用体验的成败。举个例子如果用户只说了“今天面试被拒了”不再补充其他信息一个默认模式的模型可能一上来就安慰一番然后给出五条面试技巧但 Hindsight 要做的是先问“你面试前设定的目标是什么”或者“拿到结果时你的第一反应是什么”用追问把描述从情绪带到事实。2.3 Chatflow 的对话策略什么时候该问什么时候该停有了系统提示词还不够还需要在流程层面把它和用户的多轮回复衔接起来。我用的是 Chatflow 嵌套 LLM 节点加条件分支的方式。整体对话策略分三层第一层是信息提取。每次用户发言后先用一个 LLM 节点对用户输入做结构化抽取提取目标、行动、预期结果、实际结果、情绪五个字段。这个节点输出的是 JSON只把抽到的内容写进变量不做任何展示。第二层是完整性判断。进入条件分支节点对所有变量做空值检查。如果存在关键字段缺失就进入追问分支生成一个针对性的问题如果字段已经齐全就进入报告生成分支。第三层是报告输出。只有走到这里系统提示词里要求的 Markdown 五段式报告才会被真正执行。这个设计解决了一个经典难题多轮对话里模型经常忘记自己已经知道什么。通过把每次提取结果固化到变量里完整性判断由工作流逻辑负责而不是让模型自己“感觉”信息够不够极大的提升了触发准确度。3. 基于Dify的实操构建过程从建应用到跑通第一份报告3.1 创建Chatflow应用与基础参数在 Dify 控制台里“创建应用”时直接选“Chatflow”不要误选“工作流”。Chatflow 和 Workflow 的核心区别在于前者支持多轮会话与用户交互后者更偏后台的自动化流水线。复盘场景天然需要多轮追问所以必须选 Chatflow。创建完成后先配置模型。我这边用的是通用旗舰模型实测下来这类模型指令跟随能力比较强能够守住复杂模板。参数上温度建议调到 0.2 左右复盘报告追求稳定输出温度太高容易浪max tokens 给到 2000因为一份完整报告带表格是很容易突破 1000 token 的。其他参数保持默认即可。一个体验上的重点模型选型不要贪便宜。复盘这类任务对指令跟随要求很高尤其是“只问一个问题”“不要编造信息”这种反模型本能的要求小模型很容易破功。宁可 API 调用慢一点也别选一个管不住的模型。3.2 工作流节点编排与关键配置建成空应用后我按下面顺序把节点一个个拖到画布上逻辑非常线性开始节点只开启一个“对话用户输入”变量用户发什么就是什么。LLM 节点一信息提取把用户的最新一条输入和已有变量一起喂进去指示模型输出 JSON。这里的提示词不强求只要能抽出正确的字段即可。需要注意输出的 JSON 字段名和后面变量名完全一致不然代码节点解析时会有麻烦。条件分支节点信息判断逐个检查目标、预期结果两个核心字段是否为空。我实际调试中发现“目标”和“预期结果”是复盘中最常缺失的两项而情绪感受即使缺失也可以先出一个精简版报告所以条件里只卡这两个字段。LLM 节点二单条追问如果条件分支判定仍有缺失就把缺失字段对应的追问模板输出。这里要配合系统提示词的“一次只问一个”原则并且把追问模板写得像人话而不是“请输入您的目标”。LLM 节点三报告生成如果条件分支判定信息足够就用 2.2 节那段完整系统提示词生成报告。这段是核心节点所有其他节点的输出最终都会交给它汇总。代码节点兜底格式化因为模型偶尔会在报告前附加一两句废话我用一个简易代码节点把从“复盘报告”开始的内容切出来同时去掉多余的空白行。代码节点的内容很基础供参考我当时直接贴进去就能跑通def main(report: str) - dict: text report.strip() if 复盘报告 in text: text text[text.find(复盘报告):] return {clean_report: text}结束节点输出变量 clean_report作为回复内容返回给用户。整个画布串起来的路线就是用户输入先被抽取再被判断要么继续追问要么直接成报告。这套结构的优势是把“模型自由发挥”限制在最小的范围内所有关键决策都在工作流层做模型只负责“说人话”非常省心。3.3 调试实录我是怎么把搞砸的对话拉回来的第一次跑通时效果其实是不合格的。我把整个调试过程记录下来这段经验对初学者价值很大。最早版本我图省事把完整性判断也丢给了 LLM“请判断用户信息是否完整并生成报告或追问”。结果模型经常在信息明显缺失时强行输出报告然后在报告里把缺失字段用“暂无”搪塞过去。后来我把判断逻辑改到条件分支节点由代码和空值检测做硬控制情况立刻好转。一定要记住核心流程控制能用逻辑节点做的就别依赖模型自觉。第二次问题是输出格式飘逸。同一个事件换几次说法第一次报告还有表格第二次表格就变成了列表第三次干脆连“双维度归因”都改成“反思总结”。这属于指令跟随不稳定的典型表现。解决办法有两招一是把温度从 0.7 降到 0.2二是提示词里给出完整的 Markdown 模板和表头不给模型自由发挥的空间。两招一起用后格式稳定性明显不一样。第三次问题是模型总想当老好人。它在“一句话复盘”里写出来的是“整体表现良好只要注意沟通方式会更好”。这种没有痛点的复盘没有任何价值。我在提示词里专门加了禁词规则报告严禁出现“通过学习成长了”“整体表现良好”这类空洞的概括要求必须揭示一个用户没意识到的盲区。加完这条输出质量才算真正能看。4. 常见问题与排查技巧实录4.1 模型总是连环问问题怎么让它闭嘴这个是我被问得最多的一个问题也是实际测试中最常见的失败模式。明明提示词里写了“一次只问一个”模型还是会问“通过刚才的描述我想了解你当时的目标是什么另外你觉得导致这个结果最重要的原因是什么”一句话里塞两个问题。根治办法是两层配合。第一层是弱化“不要做某事”改成“必须做某事”在提示词里改成“你的每次回复只能包含一个问句如果你发现自己准备问第二个问题请立即停止”。正向描述比禁指令有效得多。第二层是流程兜底追问节点单独设一个 LLM 调用并把 max tokens 限制在 80 左右。token 一少模型想展开连环问也展不开只能老老实实问最核心的一个。4.2 长会话丢记忆前面说过的信息被遗忘用 Dify 做多轮对话最容易忽略的一点是“会话记忆”不会自动等于“关键信息记忆”。默认设置下模型看到的是近期几轮对话用户第五轮提到的预期结果到了第七轮可能已经滑出上下文窗口报告生成节点读取变量时就会拿到空值。我的解决方案分两步。第一步信息提取节点每次输出 JSON 后立刻写入对应的变量变量确保这个值不随对话轮次推移丢失。第二步在报告生成节点的系统提示词里把所有已知变量以结构化清单的形式再拼一遍相当于每次生成报告前先把“摘要”喂给模型。这样即使在长对话中途报告质量也稳定得多。4.3 报告生成时好时坏格式偶尔乱掉如果是对外发布的应用格式稳定性可以排在功能之前。我见过的典型问题是表格时有时无、标题从“## 一句话复盘”变成“一句话复盘”、或者表格列对不齐。不用太相信模型的自觉它今天心情不错格式就工整明天一个思路飘了你就得重新调。操作上最有效的是三层兜底。第一层是提示词给出完整模板并用小字说明不要改动任何标题文字第二层是把温度调到最低档最大限度减少输出随机性第三层就是 3.2 节那个代码节点从“复盘报告”处截断把模型多余的客套话全部剪掉。如果你要更进一步可以在代码节点里做关键词替换把“反思总结”统一归为“双维度归因”相当于小规模文本清洗。4.4 数据隐私复盘内容该不该交给云端大模型做复盘工具绕不开的一个担忧就是用户把心里最真实的经历和情绪交给第三方模型服务这需要认真对待也是任何真实场景应用都必须处理好的基础问题。我在项目里做了三层处理。第一提示词中主动引导用户脱敏开头就会提示“你可以把具体人名和公司名替换成同事A甲方”这不影响复盘效果又能减少数据敏感级别。第二在 Dify 平台配置模型 API 时关闭服务商的训练数据采集选项如果用的是私有化部署的模型则直接走内网调用这一步很多人会忽略建议在部署指南里明确标注清楚后再对外发布。第三用户会话数据只做短期存储不进入任何知识库与长期向量库确保每次对话都是一个独立闭环。复盘工具的本质是帮用户看清自己而不是把用户的历史积累下来做分析所以这里“用完即走”的取舍是合理的也是很多商业产品在隐私合规上最稳妥的做法。5. 结尾AI 在复盘里最值钱的是提问不是答案整个项目做下来我个人最大的体会是AI 在复盘场景里最值钱的能力不是生成结论而是生成好问题。结论是廉价的你随便问一个朋友也能得到“下次要多准备一下”这种建议而好问题是稀缺的它逼着你自己去面对那些模糊的、被你本能跳过的事实。Hindsight 这个名字现在在我眼里已经不是“事后聪明”的讽刺了而是一种朴素的方法论把自己变成那个在事后愿意真诚回头看看的人。AI 只是把回头这个过程变得不那么痛苦不那么自欺稍微有序一点。最后分享一个小技巧。如果你也打算在自己的复盘工具里加入持续反馈机制建议让每份报告末尾始终留一个开放式问题例如“如果三周后你重新遇到类似情况你希望自己做出的第一个动作是什么”。这个问题会悄悄留在用户的潜意识里让复盘的价值在报告生成之后的第三周才开始真正生效。别问我怎么知道的我是从一个用户反馈里看到的——他说他在一次重要谈判前想到的竟然是 Hindsight 上一次报告末尾的那个开放问题那一瞬间他确实“事后聪明”了一次。
基于Dify构建AI复盘教练：Chatflow多轮对话与提示词工程实践
Hindsight这个词直译过来是“后见之明”也就是事后才看清事情本质的恍然。它还有一层挺妙的背景——詹姆斯·乔伊斯在《尤利西斯》里给一个角色的名字就叫Mr. Hindsight专门负责在事后说“你看吧我早就觉得会这样”。文学里的味道是讽刺但在现实里这种能力反而稀缺我们大多数时候看不清眼前的选择只有退后一步、等时间过去才真正读得懂自己当时为什么会那样做。所以当我决定做点跟“复盘”相关的东西时第一个想到的名字就是hindsight。我的目标不是做一个更漂亮的数据日记本也不是情感树洞而是借助大语言模型搭一个合格的“复盘教练”你丢给它一段混乱的经历描述它通过多轮提问帮你把目标、预期、结果、归因一步步理清楚最后生成一份结构完整、点评克制、能落到行动上的复盘报告。项目基于 Dify 平台构建采用 Chatflow 应用类型实现多轮引导对话。选择 Dify 而不是从零开发前后端是因为复盘类应用的重心在对话策略和提示词打磨而不是系统架构。本文我会把方法选型、提示词设计、工作流节点配置、以及我踩过的几个实际坑点全部拆开讲适合想用 Dify 做对话式工具、或者对 AI 辅助自我反思场景感兴趣的人参考。1. 项目整体设计复盘工具为什么需要AI以及为什么选Dify1.1 复盘这件事卡在“当局者迷”上先说实话市面上不缺复盘方法KPT、GRAI、AAR、PDCA随便搜都是一堆。但大部分人的复盘习惯最终都会断掉因为问题的关键不在方法而在“当局者迷”。你刚做完一次汇报、写完一篇方案、或者带完一个活动大脑里剩下的是一团情绪化的感觉紧张、兴奋、后悔、侥幸。这时候让你冷静下来对照“目标-结果-归因”框架其实是反人性的因为你正处于事件余温里脑子里全是我当时要是那样说就好了。你会高估自己的失误也会忽略外部环境的客观制约。AI 在这里扮演的角色并不是帮你给出正确答案而是一个不受情绪干扰的提问者。它不会因为你说了很多沮丧的话就跟着共情也不会因为你表现得很好就花式吹捧。它只会按设定好的流程一次问一个关键问题一步步把你拉回事实层面。Hindsight 的定位因此非常明确它是复盘教练不是心理咨询师也不是夸夸机器人。1.2 最小闭环一段混乱描述到一份可执行建议我最初规划功能时可以做得非常重事件分类、心情指数、语音输入、数据可视化。但冷静评估 MVP 之后我只保留了一条最小闭环用户输入一段自然语言的事件描述越口语化越好系统提取本次复盘的关键信息目标、行动、预期结果、实际结果、情绪状态如果信息不完整系统每次只提一个最关键的问题补全信息当信息足够时系统生成五段式复盘报告一句话复盘、目标回顾、预期与现实差距、双维度归因、下一步行动每份报告末尾留下一道开放式问题引导用户今后继续深入为什么坚持“一次只问一个问题”这是我反复测试后得出的结论。多轮对话类 AI 最让人烦躁的体验就是模型一口气反问你三五个问题用户回复负担极重。而复盘这个场景需要的是轻松的自我袒露一次只问最关键的、能推动分析的那个问题用户留在对话里的意愿会高很多。实测下来单问题策略的交互完成率要比多问题策略高不少。1.3 为什么是 Dify而不是自己写一套应用我认真考虑过自己搭后端接大模型 API前端写一个聊天窗口再用向量库做长期记忆。但做到一半我就意识到这个项目的价值点全在 Prompt 策略和对话流程控制而 Dify 恰好把这些非核心的脏活全部承包了。选择 Dify 的理由具体有三点。第一Chatflow 的可视化编排极大降低流程调整成本。复盘的对话策略不是一次想好的我前前后后调了十几版包括何时进入报告生成分支、何时让系统闭嘴听用户说话。如果用代码硬编码代价是不小的在 Dify 画布上直接拖节点、改分支条件基本改完就能测。第二会话记忆不用自己维护。复盘场景经常是连续多轮追问用户第三轮补充的信息需要被第六轮的分析节点使用。Dify 内置的会话记忆机制可以把这个上下文带住我只需要关心变量命名和窗口大小。第三模型切换灵活。我前期用不同厂商的大模型做过交叉验证有的模型指令跟随好但太爱说教有的悟性高但格式爱飘Dify 里可以快速做切换对比不用改代码。这一点在提示词调优阶段极其好用。用的版本是 Dify 社区版 1.x 左右下面所有配置截图对应的就是那个版本的控制台布局。整体功能差异不大新版本以下几点操作更顺滑但设计逻辑是一样的。2. 核心功能设计复盘方法、Prompt工程与对话流2.1 复盘方法论从 GRAI 模型到五段式报告Hindsight 的报告结构不是凭空想的它主要由 GRAI 复盘法演化而来。GRAI 的四个步骤分别是 Goal目标回顾、Result结果陈述、Analysis原因分析、Insight总结规律。这个框架很清晰但在实际对话里直接扔给用户去执行会很生硬因为大多数人写不清“目标”和“结果”到底差别在哪。我做了一些适应 AI 对话的产品化改造最终形成五段式结构一句话复盘用五十字以内把这次经历的本质概括出来。这个概括越扎心越好我甚至要求模型避免使用“通过这次经历我学到了”这类套话。当时的目标把用户自己陈述的目标复述一遍帮用户确认“我到底想要什么”。预期与现实的差距用一个 Markdown 表格做三列对比分别是预期结果、实际结果、差距判断。表格的视觉冲击力比纯文字强很多能让用户明确看到自己哪里判断偏了。双维度归因分为可控因素和外部环境。可控因素必须写具体可执行的改进点禁止出现“提升自己”“更加努力”这类空话外部环境帮用户分清哪些不是自己的责任避免过度自责。下一次行动只给一条行动建议且要求可量化、两周内能完成。少即是多一条落到实处永远比三条漂亮话管用。选择这个结构的好处是它既保留了复盘方法的严肃性又非常契合大语言模型的输出习惯。结构化模板能显著提升输出稳定性用户拿到报告也更有“拿到一份正式结论”的仪式感而不是随便聊了几句。2.2 角色设定与系统提示词拆解Prompt 里最重要的是系统提示词它决定了这个应用是一台复读机还是一个合格的教练。我的第一版提示词写在下面可以直接复制到 Dify 的 LLM 节点里使用。你是 Hindsight一名复盘教练retrospective coach。你的任务不是评判用户不是鼓励用户也不是给建议而是帮助用户看清自己行为背后的逻辑产生真正的后见之明。 你遵循以下对话原则 1. 如果用户描述的事件缺少关键信息当时的目标、实际采取的行动、预期结果、实际结果、情绪感受、外部约束你只能提出一个最关键的追问不要一次问多个问题。 2. 如果用户明确输入直接给报告则跳过提问环节立即使用当前已有信息生成报告。 3. 只有当用户提供的信息足以形成完整分析时才输出复盘报告。报告开头必须包含复盘报告四个字。 4. 绝不要编造用户没有说过的事实信息。如果某个信息缺失在报告中明确标注暂时缺失而不是自行脑补。 复盘报告严格按以下 Markdown 结构输出 ## 一句话复盘 50字以内概括这次经历的本质避免通过这次经历学到了这类套话 ## 当时的目标 用户当时真正想达成什么 ## 预期与现实的差距 | 预期结果 | 实际结果 | 差距判断 | | --- | --- | --- | | 用户当时的预期 | 用户描述的实际 | 超出预期/符合预期/未达预期 | ## 双维度归因 - 可控因素用户本人可以改变并下次做得更好的部分必须写具体动作禁止空泛建议。 - 外部环境客观存在的限制帮用户分清哪些不是自己的责任。 ## 下一次行动 只给一条可执行建议要求可量化、两周内可完成 报告最后加一行 未来的一个开放问题……基于这次复盘提出一个用户下次可以继续思考的方向这段提示词里最关键的不是报告结构而是前四条对话原则。特别是“一次只问一个问题”和“不要编造”这两条几乎决定了整个应用体验的成败。举个例子如果用户只说了“今天面试被拒了”不再补充其他信息一个默认模式的模型可能一上来就安慰一番然后给出五条面试技巧但 Hindsight 要做的是先问“你面试前设定的目标是什么”或者“拿到结果时你的第一反应是什么”用追问把描述从情绪带到事实。2.3 Chatflow 的对话策略什么时候该问什么时候该停有了系统提示词还不够还需要在流程层面把它和用户的多轮回复衔接起来。我用的是 Chatflow 嵌套 LLM 节点加条件分支的方式。整体对话策略分三层第一层是信息提取。每次用户发言后先用一个 LLM 节点对用户输入做结构化抽取提取目标、行动、预期结果、实际结果、情绪五个字段。这个节点输出的是 JSON只把抽到的内容写进变量不做任何展示。第二层是完整性判断。进入条件分支节点对所有变量做空值检查。如果存在关键字段缺失就进入追问分支生成一个针对性的问题如果字段已经齐全就进入报告生成分支。第三层是报告输出。只有走到这里系统提示词里要求的 Markdown 五段式报告才会被真正执行。这个设计解决了一个经典难题多轮对话里模型经常忘记自己已经知道什么。通过把每次提取结果固化到变量里完整性判断由工作流逻辑负责而不是让模型自己“感觉”信息够不够极大的提升了触发准确度。3. 基于Dify的实操构建过程从建应用到跑通第一份报告3.1 创建Chatflow应用与基础参数在 Dify 控制台里“创建应用”时直接选“Chatflow”不要误选“工作流”。Chatflow 和 Workflow 的核心区别在于前者支持多轮会话与用户交互后者更偏后台的自动化流水线。复盘场景天然需要多轮追问所以必须选 Chatflow。创建完成后先配置模型。我这边用的是通用旗舰模型实测下来这类模型指令跟随能力比较强能够守住复杂模板。参数上温度建议调到 0.2 左右复盘报告追求稳定输出温度太高容易浪max tokens 给到 2000因为一份完整报告带表格是很容易突破 1000 token 的。其他参数保持默认即可。一个体验上的重点模型选型不要贪便宜。复盘这类任务对指令跟随要求很高尤其是“只问一个问题”“不要编造信息”这种反模型本能的要求小模型很容易破功。宁可 API 调用慢一点也别选一个管不住的模型。3.2 工作流节点编排与关键配置建成空应用后我按下面顺序把节点一个个拖到画布上逻辑非常线性开始节点只开启一个“对话用户输入”变量用户发什么就是什么。LLM 节点一信息提取把用户的最新一条输入和已有变量一起喂进去指示模型输出 JSON。这里的提示词不强求只要能抽出正确的字段即可。需要注意输出的 JSON 字段名和后面变量名完全一致不然代码节点解析时会有麻烦。条件分支节点信息判断逐个检查目标、预期结果两个核心字段是否为空。我实际调试中发现“目标”和“预期结果”是复盘中最常缺失的两项而情绪感受即使缺失也可以先出一个精简版报告所以条件里只卡这两个字段。LLM 节点二单条追问如果条件分支判定仍有缺失就把缺失字段对应的追问模板输出。这里要配合系统提示词的“一次只问一个”原则并且把追问模板写得像人话而不是“请输入您的目标”。LLM 节点三报告生成如果条件分支判定信息足够就用 2.2 节那段完整系统提示词生成报告。这段是核心节点所有其他节点的输出最终都会交给它汇总。代码节点兜底格式化因为模型偶尔会在报告前附加一两句废话我用一个简易代码节点把从“复盘报告”开始的内容切出来同时去掉多余的空白行。代码节点的内容很基础供参考我当时直接贴进去就能跑通def main(report: str) - dict: text report.strip() if 复盘报告 in text: text text[text.find(复盘报告):] return {clean_report: text}结束节点输出变量 clean_report作为回复内容返回给用户。整个画布串起来的路线就是用户输入先被抽取再被判断要么继续追问要么直接成报告。这套结构的优势是把“模型自由发挥”限制在最小的范围内所有关键决策都在工作流层做模型只负责“说人话”非常省心。3.3 调试实录我是怎么把搞砸的对话拉回来的第一次跑通时效果其实是不合格的。我把整个调试过程记录下来这段经验对初学者价值很大。最早版本我图省事把完整性判断也丢给了 LLM“请判断用户信息是否完整并生成报告或追问”。结果模型经常在信息明显缺失时强行输出报告然后在报告里把缺失字段用“暂无”搪塞过去。后来我把判断逻辑改到条件分支节点由代码和空值检测做硬控制情况立刻好转。一定要记住核心流程控制能用逻辑节点做的就别依赖模型自觉。第二次问题是输出格式飘逸。同一个事件换几次说法第一次报告还有表格第二次表格就变成了列表第三次干脆连“双维度归因”都改成“反思总结”。这属于指令跟随不稳定的典型表现。解决办法有两招一是把温度从 0.7 降到 0.2二是提示词里给出完整的 Markdown 模板和表头不给模型自由发挥的空间。两招一起用后格式稳定性明显不一样。第三次问题是模型总想当老好人。它在“一句话复盘”里写出来的是“整体表现良好只要注意沟通方式会更好”。这种没有痛点的复盘没有任何价值。我在提示词里专门加了禁词规则报告严禁出现“通过学习成长了”“整体表现良好”这类空洞的概括要求必须揭示一个用户没意识到的盲区。加完这条输出质量才算真正能看。4. 常见问题与排查技巧实录4.1 模型总是连环问问题怎么让它闭嘴这个是我被问得最多的一个问题也是实际测试中最常见的失败模式。明明提示词里写了“一次只问一个”模型还是会问“通过刚才的描述我想了解你当时的目标是什么另外你觉得导致这个结果最重要的原因是什么”一句话里塞两个问题。根治办法是两层配合。第一层是弱化“不要做某事”改成“必须做某事”在提示词里改成“你的每次回复只能包含一个问句如果你发现自己准备问第二个问题请立即停止”。正向描述比禁指令有效得多。第二层是流程兜底追问节点单独设一个 LLM 调用并把 max tokens 限制在 80 左右。token 一少模型想展开连环问也展不开只能老老实实问最核心的一个。4.2 长会话丢记忆前面说过的信息被遗忘用 Dify 做多轮对话最容易忽略的一点是“会话记忆”不会自动等于“关键信息记忆”。默认设置下模型看到的是近期几轮对话用户第五轮提到的预期结果到了第七轮可能已经滑出上下文窗口报告生成节点读取变量时就会拿到空值。我的解决方案分两步。第一步信息提取节点每次输出 JSON 后立刻写入对应的变量变量确保这个值不随对话轮次推移丢失。第二步在报告生成节点的系统提示词里把所有已知变量以结构化清单的形式再拼一遍相当于每次生成报告前先把“摘要”喂给模型。这样即使在长对话中途报告质量也稳定得多。4.3 报告生成时好时坏格式偶尔乱掉如果是对外发布的应用格式稳定性可以排在功能之前。我见过的典型问题是表格时有时无、标题从“## 一句话复盘”变成“一句话复盘”、或者表格列对不齐。不用太相信模型的自觉它今天心情不错格式就工整明天一个思路飘了你就得重新调。操作上最有效的是三层兜底。第一层是提示词给出完整模板并用小字说明不要改动任何标题文字第二层是把温度调到最低档最大限度减少输出随机性第三层就是 3.2 节那个代码节点从“复盘报告”处截断把模型多余的客套话全部剪掉。如果你要更进一步可以在代码节点里做关键词替换把“反思总结”统一归为“双维度归因”相当于小规模文本清洗。4.4 数据隐私复盘内容该不该交给云端大模型做复盘工具绕不开的一个担忧就是用户把心里最真实的经历和情绪交给第三方模型服务这需要认真对待也是任何真实场景应用都必须处理好的基础问题。我在项目里做了三层处理。第一提示词中主动引导用户脱敏开头就会提示“你可以把具体人名和公司名替换成同事A甲方”这不影响复盘效果又能减少数据敏感级别。第二在 Dify 平台配置模型 API 时关闭服务商的训练数据采集选项如果用的是私有化部署的模型则直接走内网调用这一步很多人会忽略建议在部署指南里明确标注清楚后再对外发布。第三用户会话数据只做短期存储不进入任何知识库与长期向量库确保每次对话都是一个独立闭环。复盘工具的本质是帮用户看清自己而不是把用户的历史积累下来做分析所以这里“用完即走”的取舍是合理的也是很多商业产品在隐私合规上最稳妥的做法。5. 结尾AI 在复盘里最值钱的是提问不是答案整个项目做下来我个人最大的体会是AI 在复盘场景里最值钱的能力不是生成结论而是生成好问题。结论是廉价的你随便问一个朋友也能得到“下次要多准备一下”这种建议而好问题是稀缺的它逼着你自己去面对那些模糊的、被你本能跳过的事实。Hindsight 这个名字现在在我眼里已经不是“事后聪明”的讽刺了而是一种朴素的方法论把自己变成那个在事后愿意真诚回头看看的人。AI 只是把回头这个过程变得不那么痛苦不那么自欺稍微有序一点。最后分享一个小技巧。如果你也打算在自己的复盘工具里加入持续反馈机制建议让每份报告末尾始终留一个开放式问题例如“如果三周后你重新遇到类似情况你希望自己做出的第一个动作是什么”。这个问题会悄悄留在用户的潜意识里让复盘的价值在报告生成之后的第三周才开始真正生效。别问我怎么知道的我是从一个用户反馈里看到的——他说他在一次重要谈判前想到的竟然是 Hindsight 上一次报告末尾的那个开放问题那一瞬间他确实“事后聪明”了一次。
