第一次看到 hindsight 这个词，是在一次项目复盘会上。组里一个同事半开玩笑地说：如果 AI 能帮我们把过去几个月的聊天记录全部翻一遍，然后直接告诉我们“当时这里其实有更优解”，那该多省事。这个想法在我脑子里留了很久，最后就变成了我现在要说的这个项目——一个基于 Dify 平台搭建的复盘型 AI 助手，名字就叫 hindsight。
简单说，hindsight 不是一个普通聊天机器人，而是一个“回看过去的 AI”。它的核心能力是：把零散的历史对话、项目记录、学习笔记变成可以被 AI 吸收和检索的资产，然后你用自然语言提问，比如“我第一次接触向量数据库的时候，哪个理解是错的？”或者“上个月设计方案时，我们为什么排除了那套方案？”，它能结合历史记录给你一个有根据的复盘结论。这里重点说一下，“hindsight dify”这个组合其实非常有代表性：hindsight 代表的是产品的语义核，而 Dify 则是把语义落地成真实应用的骨架。如果你正在做个人知识管理、团队项目复盘、或者 AI 学习助手，这篇文章里讲的东西基本可以直接抄作业。
1. 项目到底是什么：hindsight 的定位与价值
1.1 为什么叫 hindsight：后见之明的价值
英文里有一句老话叫“hindsight is 20/20”，翻译过来就是“事后看，一切都清清楚楚”。我们的记忆天然会对过去的事情做美化，也会漏掉很多当时没注意的细节。复盘的意义，就是对抗这种记忆偏差。
hindsight 这个名字其实已经很直白地表达了这个项目的使命：让 AI 帮我们获得“后见之明”。它不是预测未来，也不是帮你做决策，它只做一件事——把你过去的对话、记录、决定，重新放到今天的时间点上去审视。
我做过一个小测试。把自己半年前学习 LangChain 时的笔记导入 hindsight，然后问它“我当时对 Agent 和 Chain 的理解有什么偏差？”它返回的内容让我有点吃惊：不仅指出了我当时把 Agent 简单等同于“调用工具”这个误区，还引用了我在笔记里几处具体的原文，说明我当时忽略了记忆模块的设计。这就是人力复盘很难做到的——重读自己的历史记录不难，难的是同时结合现在的认知水平去对照。
1.2 为什么选择 Dify 平台来落地
其实最早我想自己写代码来实现这个想法。用 LangChain 写一个检索链，把历史文档向量化，再封装一个问答接口，技术上并不复杂。但真正动手之后，我发现有几个问题被低估了：
第一是对话历史的管理。项目复盘往往涉及几十轮甚至上百轮对话，我的历史数据格式五花八门，有来自微信聊天导出的，有飞书文档，还有本地 Markdown 笔记。要自己做格式清洗、分段、入库，工作量远超过写一个问答链。
第二是应用的可调试性。复盘问答有一个特点：用户的问题往往是开放式、模糊的，需要反复调整提示词和检索参数才能得到理想结果。如果每次调优都要改代码重新部署，迭代效率太低。
第三是团队协作。hindsight 不是我一个人用的工具，团队其他成员也需要在 Web 界面里直接提问。我不想自己维护一套前后端代码。
Dify 在这三个问题上的优势非常明显。它是一个开源的大模型应用开发平台，提供可视化的工作流编排、知识库管理、提示词管理和完整的 Web App 界面。而且 Dify 原生支持把历史对话作为“记忆”注入上下文，也能通过 API 与其他系统对接。我可以用最少量的代码，把核心精力放在“复盘逻辑”本身，而不是基础设施。
选 Dify 还有一个实际考虑：它支持接入多种模型服务，包括 OpenAI、Azure OpenAI、本地部署的模型等。我们在实际项目中用的是团队已有的模型服务，Dify 只需要改一改 Provider 配置就可以切换，不用动业务逻辑。
2. 核心设计思路与整体架构拆解
2.1 复盘助手的信息流设计
hindsight 的整体信息流可以用一条线串起来：历史数据进入知识库，然后经过检索与 Prompt 组装，最终输出复盘结论。但这里有个容易被忽略的关键点——复盘问题和普通问答的信息需求完全不同。
举个例子。你问普通问答系统“什么是 RESTful API”，它只需要召回知识库里最相关的一段文档，生成解释即可。但复盘问题不一样，比如“我在设计鉴权方案时，是否考虑过 token 过期策略？”这个问题要求 AI 做三件事：第一，从历史对话里找到当时的讨论片段；第二，判断这些片段中是否包含了“token 过期策略”这个主题；第三，如果缺失，要结合当前知识库补充说明。所以 hindsight 的信息流是“先定位、再判断、后补充”的三段式。
在 Dify 里的实现方式是：知识库检索负责“定位”，LLM 的判断和推理负责“判断”，系统提示词里注入的“背景知识”负责“补充”。
具体来说，我把 Dify 的知识库分成两个库：
- 历史对话库：存放用户上传的聊天记录、会议纪要、笔记。分段时尽量保持“一个对话回合”或“一个主题块”为一个检索单元。
- 知识基础库：存放团队的技术文档、行业资料、教程，用于在复盘时提供背景补充。
两个库分开管理，可以在检索时设定不同的召回数量权重。历史对话库的权重更高，因为复盘的核心依据是“当时发生了什么”，而背景知识库只做辅助支撑。
2.2 技术方案选型：Agent 模式还是工作流模式
Dify 里支持两种主要的应用编排模式：Agent 模式和 Workflow 模式。我在做 hindsight 的过程中先后尝试了两种，踩了不少坑，这里详细说说。
第一版我直接用 Agent 模式。Dify Agent 可以配置多个 Tool，让大模型自主决定调用顺序和调用次数。理论上很灵活，但在实际测试中我发现一个问题：Agent 经常会在复盘场景里“过度检索”。比如用户问“我们当时为什么选择 PostgreSQL”，Agent 可能先调用知识库检索，再调用某个搜索工具，再尝试从对话历史里翻找，绕了一大圈之后，回答质量并没有明显提升，反而因为多轮工具调用浪费了不少 token 和响应时间。更麻烦的是，当 Agent 的自由度太高时，它偶尔会把历史库里不同项目的内容混在一起，给出完全离谱的复盘结论。
后来我改成了Workflow 模式 + 关键节点用 Agent的混合方式。Dify 的 Workflow 允许把流程固定下来，同时在一个节点里调用 LLM 做灵活处理。这样整个 hindsight 的执行路径是稳定的：
- 开始节点接收用户问题；
- 对问题做一次“复盘意图分析”，判断这个问题是针对历史对话、知识基础还是两者兼有；
- 按意图查询两个知识库，设置不同的 TopK；
- 把检索结果和历史对话摘要拼接成上下文；
- LLM 生成复盘回答；
- 结束节点输出。
这样既保留了确定性，又避免了纯 Workflow 死板到无法应对开放式问题。这也是我特别想强调的一个经验：不要迷信 Agent 的“全自动”，复盘类应用最重要的是可控性，先固定流程，再在流程节点里嵌入智能。
2.3 Prompt 框架设计：复盘提问的三层结构
hindsight 的 Prompt 是整个项目里调整次数最多、也最关键的部分。我最终总结出来一个复盘 Prompt 的三层结构，分享给大家。
第一层是角色设定层。我会告诉模型：你是一名复盘教练，你的任务不是直接给答案，而是帮助用户重新审视过去的对话和决策。你需要在回答中指出可能的盲点、不一致之处和改进空间。
第二层是思维引导层。模型需要按照一套固定框架来分析，我用的框架是“事实—影响—改进”。先陈述历史对话中的客观事实，再分析这些事实对后来的影响，最后结合现在的知识提出改进建议。这个框架的灵感来自经典的项目复盘方法，把它放进 Prompt 里，能有效防止模型一上来就输出泛泛而谈的建议。
第三层是约束层。包括：不得编造历史记录中没有出现的内容；引用历史记录时要标明出处关键词；如果检索到的内容与问题不相关，要明确告诉用户“未找到相关内容”，而不是强行回答。
这三层结构用 Dify 的提示词变量可以很方便地动态组装。尤其是“检索到的内容”这个变量，它由前面的知识库检索节点输出，我只需要在提示词里用 {{#context#}} 之类的变量引用即可。每次调 Prompt 只需要改 Dify 里的文本，不需要改动代码或重新部署，这个体验真的非常爽。
3. 实操落地：在 Dify 上搭建 hindsight 的关键步骤
3.1 环境准备与基础配置
我假设你已经部署好了 Dify，用的是社区版或云版都行。整个项目需要准备的东西不多：一个模型服务的 API Key（我用了 OpenAI 兼容接口，团队内部用 vLLM 部署的模型也试过，都没问题）、一批历史对话数据、一个干净的 Dify 应用。
首先在 Dify 里创建一个新的应用，类型选“工作流”。注意创建的时候，模型提供方要确认已经配置正确。在“设置—模型供应商”里填好 API Key 和 Base URL，不同的模型影响很大，后面调参的章节我会细说。
创建应用完成后，第一件事是进入“提示词编排”页面，把默认的“请开始你的工作流”之类的初始内容清空，按照你的模型能力编写一段项目级指令。比如我写的是：“你是一个帮助用户复盘过去对话和决策的 AI 助手。你的知识来源是两个知识库：历史对话库和知识基础库。回答时请遵循‘事实—影响—改进’框架。”
3.2 知识库搭建：把历史对话变成可检索的资产
这是整个项目里最繁琐但是最值得做的环节。Dify 的知识库目前支持多种数据源，包括上传文件、同步 Notion、网页 URL 等。最常用的还是直接上传文本或整段粘贴对话内容。
历史对话数据往往是杂乱的。我踩过几个坑，这里直接给出我的处理流程：
第一步，清洗数据。把对话里的时间戳、无关的表情包文字、系统通知等噪音去掉。注意不要过度清洗，保留说话人的身份标记非常重要。因为在复盘中你需要知道哪句话是谁说的，这会影响判断。
第二步，分段。Dify 知识库上传时可以选择分段方式，默认按字符数切分。但对话记录按固定字符切分会把上下文切断。我的做法是：用 Markdown 的二级标题把每段对话按“主题”划分，然后在 Dify 上传时设置分段标识符为“## ”，这样每一段就是一个完整的主题块，不会把两个人说的一句话拆成两半。
第三步，设置检索方式。Dify 知识库的检索方式我建议选“向量检索”。如果数据量比较小（比如 200 条以内），也可以考虑混合检索，不过实测对小文本来说向量检索已经够用，而且更稳。
在 Dify 的检索设置里，还有一个关键参数叫 TopK，初始建议设置为 4。这个参数决定了每次从知识库里召回多少个分段。复盘场景下我不建议调太高，因为召回的片段越多，上下文越容易被不相关信息污染。TopK 我最终稳定在 4 到 6 之间，具体调优在第 4 章详谈。
第四步，建立第二个知识库。也就是“知识基础库”，上传团队技术文档、行业报告等。这个库的分段可以稍微长一点，因为它的作用是供给背景知识，不需要像对话库那样精确到每个回合。
3.3 工作流/Agent 编排细节
创建完知识库之后，回到工作流编排页面。hindsight 的工作流我用的是这样的节点配置：
开始节点下面接了两个并行节点：第一个是“历史对话检索”，配置为查历史对话库；第二个是“知识基础检索”，配置为查知识基础库。并行执行的好处是响应时间更短，两个检索互不阻塞。
检索完之后，进入一个“人工提示”节点（LLM 节点）。在这里把系统提示词写进去，并把两个检索节点的输出变量引用进来。我习惯把历史检索结果放在前面，知识基础库的检索结果放在后面，中间用明确的标记隔开，方便模型理解数据来源的差异。
除了 LLM 主节点，我还额外加了一个“问题分析”节点，放在检索之前。这个节点的作用是让模型先判断用户问题属于三种类型中的哪一种：“历史复盘”“知识补充”还是“综合”。如果用户问“我们为什么选 MySQL 而不是 PostgreSQL”，问题分析节点输出“历史复盘”，那么工作流就只查询历史对话库，不查知识库，能省掉不少 token。
最后是结束节点。结束节点的输出格式我设置成 Markdown，并明确告诉模型按三级结构组织回答：核心结论、依据引用、改进建议。这样输出结果直接呈现给用户，不需要再做格式化。
3.4 通过 API 接入外部系统
如果只是想在 Dify 的网页对话里用，到这一步就结束了。但我的实际场景是：团队成员在用飞书机器人，我希望他们能在飞书里直接 @机器人 问复盘问题，所以需要把 Dify 应用暴露成 API，再通过飞书 webhook 调用。
Dify 的 API 调用方式很成熟。创建应用后，在“API 访问”页面可以拿到 API Key，然后调用工作流执行接口。我写了一个简单的 Python 脚本做这件事，核心代码大概长这样：
import requests DIFY_API_URL = "https://your-dify-instance/v1/workflows/run" API_KEY = "app-xxxxx" payload = { "inputs": { "query": "帮我复盘一下我们上个月讨论缓存方案的对话", "user": "feishu_001" }, "response_mode": "blocking", "user": "feishu_001" } headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json" } resp = requests.post(DIFY_API_URL, json=payload, headers=headers) result = resp.json() # 从返回结果里取最终输出 final_output = result.get("data", {}).get("outputs", {}) print(final_output)这段脚本里我调用了工作流的 run 接口，inputs 里传了两个参数：query 是用户的问题，user 是用户 ID。Dify 官方文档里支持通过 data 对象获取每个节点的输出，但这个版本我已经简化为只拿最终输出。实际接飞书时，只需要把这个脚本放到一个 FastAPI 服务里，再由飞书 webhook 转发即可。
4. 参数调优与效果打磨
4.1 检索召回参数：分段长度、TopK 与 Score 阈值
hindsight 的效果一半取决于 Prompt，另一半取决于检索参数。我把这三个参数的实际调优过程记录一下。
第一个是分段长度。Dify 知识库默认按字符切分，历史对话库我设置 max_tokens 为 800 左右，重叠字符为 80。这个数值不是拍脑袋定的，我测过几组不同长度：如果分段太短（比如 200），模型经常只看到对话的一小段，无法理解上下文语境，回答明显片面；如果太长（比如 2000），检索命中率高但召回片段里有大量噪音，模型容易受到无关信息干扰。800 到 1000 这个区间对对话类内容的体验比较平衡。
第二个是 TopK。这个参数我在做测试时逐步从 8 降到 4。原因很简单：复盘问题本身是模糊的，它不像精确查询那样只关心某一段。TopK 太高会导致模型在生成回答时把好几段不相关的内容强行“圆”在一起，幻觉比例上升。最终历史对话库的 TopK 设为 5，知识基础库的 TopK 设为 3，两个库合计召回的片段数保持在 8 段以内。
第三个是 Score 阈值。Dify 支持设置检索的最低相关度分数。我强烈建议打开这个开关，初始值设为 0.4 左右。这样如果用户问的问题和导入的历史数据完全不相关，模型会走“未找到相关内容”的反馈逻辑，而不是硬着头皮编一堆东西。你可以根据导出的日志调整这个值：如果太多问题被判定为“未找到”，就往下降；如果检索结果明显跑偏，就往上升。
4.2 模型选择与温度参数
模型选择对复盘质量的影响非常直接。我在 project 里试过同一个 Prompt 和同一套检索配置下跑不同模型，对比非常明显。
先说结论：7B 级别以下的小模型做复盘助手，效果几乎不可用。复盘类任务需要多步推理和长上下文整合，小模型在“事实—影响—改进”这个框架里经常丢步骤，或者把原因和结果搞混。我团队里有 vLLM 部署的 13B 模型和 70B 模型，实测 70B 在复盘质量上明显更稳，代价是单次回答延迟接近 8 秒，对比之下 13B 大概 4 秒。这不是一个可以用绝对标准来评判的选择，取决于你的场景：如果是团队内部低频使用，我推荐用更强模型保证质量；如果要高并发接入线上流程，只能接受小模型的折损。
温度参数方面，我最终设置为 0.3。复盘输出不应该有太多创造性发挥，它更接近分析任务。温度过高会导致模型在引用历史记录时“自由发挥”，给出一些看起来合理但实际不存在于原始记录里的细节。0.2 到 0.4 这个区间可以兼顾严谨性和叙述的自然度，你可以自己微调。
4.3 成本与性能平衡
成本是复盘类 AI 应用最容易失控的地方。我总结几个亲测有效的省钱方法。
第一，把工作流里的“问题分析”节点做成轻量级。我用的是小模型（比如 7B）来做意图判断，因为这个任务不需要推理深度，只需把问题分为几类就行。让大模型只在真正生成复盘回答时出场，成本差别非常明显。
第二，利用 Dify 的知识库召回命中判定，把不相关问题提前拦截。如果所有知识库召回分数都低于阈值，工作流直接输出提示语并结束，不再调用大模型。这个拦截逻辑放在工作流里很简单，却能把大量无效请求挡在 LLM 调用之外。
第三，设置历史对话的“保留窗口”。在 Dify 应用的记忆设置里，把最大记忆轮数设置为 20 轮。用户在一个会话里连续问很多问题时，不需要所有历史对话都进上下文。实际经验是 20 轮足够覆盖多数复盘追问场景，超过 20 轮的历史就让模型依赖知识库去查，而不是全部塞进上下文。
5. 常见问题与排查记录
5.1 历史对话太长，总是截断
这个问题在我本地测试时反复遇到。原因是 Dify 对输入 token 有上限，当历史对话库的分段长度设置太宽，或者召回条数太多时，LLM 节点输入会超出模型上下文限制。
排查方法：在 Dify 的日志里看 LLM 节点的输入和输出，确认到底断了哪里。我的解决思路有两个方向：一是降低分段长度和 TopK，让输入量降下来；二是升级到上下文更长的模型。两个方向我都试过，最终建议是优先降低 TopK，因为复盘问题筛选信息的优先级更高，不能靠“多喂片段”来硬撑质量。
5.2 回答太泛，没有复盘的洞察感
这是最影响用户信心的一个问题。模型回答看起来没错，但都是空话，比如“建议加强沟通”“建议做好规划”，说到底就是没有真正阅读历史对话。
这一般是 Prompt 问题，不是检索问题。你要在提示词里明确规定模型的输出形式，不能只靠口头说“要具体”，而是要给出具体的模板。我加了一句约束：“回答中的‘依据’部分必须引用历史对话中原话或关键词，并说明这段话出自哪一次讨论。”加了这句之后，模型的输出质量直接上了一个台阶。
还有个技巧：把历史对话库的 TopK 提高一点，比如到 6，同时把知识基础库的 TopK 设为 0。这样模型不得不从历史对话里找材料，而不是依赖背景知识库里的“常识”来回答。
5.3 知识库检索不到关键内容
如果你确定历史数据已经导入了，但检索不到，先检查分段。我之前一大段对话被按固定字符切碎，导致主题关键词被拆散。用“## ”作为分段标识符重新上传后，检索命中率明显上升。
另外，Dify 的向量检索结果和文本分词质量直接相关。中英文混合的对话里，如果关键词以英文缩写形式出现（比如 RAG、LLM），建议在上传数据时给这些缩写统一加上说明，或者用双语文档的形式转换后再上传。
5.4 上下文污染问题
这是 Workflow 模式特有的一种问题。前面并行检索的两个节点都会输出结果，但模型在生成时可能把历史对话库的某个片段和知识基础库的另一片段错误地组合在一起，导致回答张冠李戴。
解决这个问题我在工作流里加了一个“数据标记”步骤。具体做法是：在 LLM 节点的提示词里，明确告诉模型“以下内容来自历史对话库：xxx”“以下内容来自知识基础库：xxx”，并要求模型在回答中标注来源。这个单纯用提示词做标记的方法，比修改节点更简单直接。
我做了个小实验：同一段输入，不标注来源时约 15% 的回答会出现来源混淆，标注后几乎降到 0。强烈建议复盘类项目都加上这个标记。
6. 还能往哪里扩展：hindsight 的进阶玩法
hindsight 做到目前这个版本，其实已经可以满足日常复盘需求了。但它还有很多可以继续扩展的方向，我简单说几个自己尝试过或者正在计划中的玩法。
一个是定时复盘。用户的对话历史并不是一次性全量导入，而是持续增长的。可以在外部系统里写一个定时任务，每天把新增对话导出为文本，再通过 API 上传到 Dify 知识库。Dify 的知识库管理本身支持新增文档，我写了一个每天凌晨自动同步历史记录到知识库的脚本，这样 hindsight 就能一直保持“最新记忆”。
另一个是团队复盘的自动报告生成。目前 hindsight 是被动回答，用户问什么答什么。你可以换个思路：在工作流最后加一个节点，把一段时间内的检索结果输出成 Markdown 报告，固定送给团队群。我当时试过一次，让 hindsight 根据一周的工作群对话生成一份“本周关键决策盘点”，效果相当好，因为没有多余的修饰，全是引用的关键节点和对应的前因后果。
还有一个更有个性的扩展，是给 hindsight 加上基于情绪或关键词的自动标记。这种玩法需要你在上传历史数据前先做一道语义预处理器，比如用情感分析或者主题聚类，给每段对话打上标签。打上标签后，用户可以问“上个月哪次讨论里大家的意见分歧最大？”知识库检索加上标签过滤，回答会更精准。
不管怎么扩展，hindsight 的核心价值始终没变：它不是在帮你记忆东西，而是在帮你从过去里“看出”东西。技术工具永远是透明的，真正重要的是能不能在回看的过程中发现认知升级的机会。我做这个项目最大的收获，是发现很多问题在过去就已经有了答案，只是当时的自己没看见而已。而 AI 的进入，让我们不用再依赖“灵光一现”，后见之明开始变成一种可以主动获取的能力。
