1. 复盘这件事为什么需要专门做个工具去年年底我负责的一个项目在延期两周后终于上线。上线当天的庆功会上大家都在互相恭喜只有我一个人在翻聊天记录试图搞清楚“我们到底是在哪一天、因为什么决定把交付时间从周五改到下周三的”。答案是没人记得。周报里写的是“排期调整”会议纪要用词更体面——“基于当前进度评估”。但真实的原因早就淹没在十几条碎片消息和两场临时会议里了。那次之后我就动了念头能不能做一个叫“hindsight”的东西把所有工作痕迹定期收起来、消化掉然后在每周五晚上给我一份不带滤镜的回顾报告。不是那种 HR 爱看的“本周完成事项”而是“我们本周在哪些事上反复横跳、哪句话是真正引发方向变化的转折点、当时的假设现在是否还成立”。后来我搭出来了base 在 Dify 上。Dify 是个开源 LLM 应用开发平台工作流、知识库、模型管理这些能力开箱即用省了太多重复造轮子的时间。这篇文章就把 hindsight 从想法到落地的全过程写清楚包括数据怎么进、提示词怎么写、哪些地方坑了我一整天。想给自己的开发习惯、团队协作过程加一层“回看视角”的朋友可以直接照着搭一份。复盘反人性这件事我多说一句。人脑对“当时为什么要这么选”的记忆衰减速度远比想象中快而且会被后来发生的结果污染——项目成功了你会觉得当初的决定全是英明的项目失败了又会在事后把责任均匀地分配给每一个无关紧要的细节。 hindsight 要解决的其实不是“记录”问题是“对抗遗忘与自我美化”的问题。它不评判它只回放。这个工具适合谁独自维护多个项目的独立开发者、需要写周报又被各种信息淹没的职场人、以及带小团队但不太想靠“开会”推动信息同步的技术负责人。不适合谁指望它能替你思考的人。它的定位是镜子不是大脑。2. 从需求到架构hindsight 的四段式设计hindsight 的核心理念可以拆成四个阶段采集、归一、索引、输出。这四个词看起来简单但每一步展开都有很多细节。2.1 采集先解决“数据根本不在同一个地方”的难题要做复盘原料得先凑齐。但现实是你每天的信息散落在一堆互相之间没有 API 关系的系统里即时通讯软件、飞书文档、Git 提交记录、邮件、个人备忘录、甚至微信里随手发给自己的一句话。hindsight 采集层的第一原则是“能自动就自动不能自动就快捷录入”。我最终给每个输入源都配了一个 Dify 的入口工作群/聊天记录通过机器人把新消息转发到 Dify 的 HTTP 接口。文档与周报在 Dify 里的自定义工具中写了个简单的解析器把 Markdown 和纯文本拉平后入库。Git 提交通过 webhook 触发把 commit message 和改动的文件路径作为一条轻量记录送入。临时想法手机上的快捷指令点击一下调 Dify 的 API 追加一条语音转文字结果。这一层没有直接用 Dify 自带的文件上传来做因为多个来源的格式和语义差异太大。我在前置环节加了一个“轻量分类器”靠的是 Dify 工作流里的一个 LLM 节点判断这条输入是属于“决策记录”“进展同步”“闲聊”还是“问题描述”然后把标签一起写入存储。这一步相当关键到后面做检索时标签就是最粗粒度的筛子。2.2 归一所有记录必须变成同一种“事件”原始数据有长有短有正式有口水话直接扔进知识库检索时大概率会得到一堆结构混乱的碎片。hindsight 的做法是在入库前经过一次“事件归一化”把每条输入变成统一的事件结构字段包括时间、来源、角色、类型、内容、关联项目、关键实体。这个归一化本身就是一个 Dify 工作流。触发后依次执行模板解析、LLM 信息抽取、结构化输出校验、写入数据库。我曾经试过直接让 LLM 生成 JSON 塞进后端但提示词稍微飘一点 JSON 就会崩。后来改为在 Dify 里用“结构化输出”的功能来做要求模型严格按照 schema 返回配合类型约束把错误率降到了可接受范围。这里要提醒一句别依赖模型一次就生成完美结果归一化层必须加一个极端情况兜底——抽取失败时原样保留为“未分类”而不是丢弃。2.3 索引两种记忆配合使用hindsight 的“记忆”由两块组成事实性记忆放在数据库表里语义性记忆放进向量知识库。事实性记忆保证“某天某人说过某句话”能精确查到语义性记忆保证“跟云端部署相关的事情我们是怎么讨论的”这种模糊问题也能被召回。在 Dify 里我建了一个名为 hindsight-memory 的知识库分段策略上踩过不少坑后面会专门写一节。索引构建时对每一条事件同时写入摘要向量和原文向量这样既能做粗粒度主题聚类也能保住细节。2.4 输出没有主观倾向的“回顾报告”输出层才是 hindsight 真正与众不同的地方。每周五晚定时触发一个工作流先拉取本周全部事件然后做三件事按主题聚类、提取决策链、生成时间线回顾。最后产出一份报告包含本周到底是“推进了”还是“在原地转圈”以及有哪些被搁置的待办不该被遗忘。输出必须克制。我不允许报告里出现任何“本周团队高效协作”这类廉价赞美。在提示词里我把要求写得很死只列出事实、引用、以及事件之间的因果关系禁止评价性词汇如果一件事的因果链在数据里找不到依据就明确写“依据不足”。这听起来像在跟提示词较劲但对一份复盘工具来说可信度就是生命。3. 在 Dify 里落地 hindsight 的关键细节3.1 环境准备与模型选择hindsight 整体跑在自托管的 Dify 上。我之前也用过云版本但考虑到记录的内容涉及工作聊天和内部文档放在自己服务器上心里踏实些。Dify 的部署方式官方文档写得很清楚就是 Docker Compose 一把梭。我这里只强调三件事第一docker-compose.yaml里按需裁剪组件。只用工作流和知识库功能的话不需要装全所有中间件模块减少内存占用也降低故障面。第二模型接入。我用的是通过本地推理服务跑的 Qwen 系列模型OpenAI-compatible 接口在 Dify 里直接配上就行。主模型负责抽取、聚类、总结这类复杂任务轻量的分类和关键词提取我单独配了一个快速响应的小模型。混合配置的好处是省钱省时间代价是多维护一套模型配置。第三设置好日志保留策略。Dify 会记录工作流的运行日志但默认保留时间偏长跑一段时间存储会长得很快。我在运维层面加了定时清理任务只保留最近 30 天的日志。hindsight 的产出本身才是有价值的留档别让日志反过来变成新的负担。3.2 两条核心链路的配置思路hindsight 一共有两条核心流程写入链路和回顾链路我分别把它们做成两个独立的 Dify 应用。写入链路是一个基于 API 的流程可以简单叫做“事件入库”。流程大致是接收外部数据 - 格式判断 - 事件归一化 - 向量化 - 写入知识库和数据库。这里的关键不是某一个节点的参数多花哨而是每个环节之间要处理好容错。比如 LLM 抽取节点偶发超时工作流要有重试机制某个来源的字段缺失后续节点要能跳过而不是整条链路报红。回顾链路是一个以定时触发的流程叫“periodic-review”。流程是拉取时间范围 - 从知识库召回相关事件 - 聚类 - 生成决策时间线 - 渲染 Markdown 报告 - 推送到 TODO 或聊天机器人侧。时间范围的变量是从外部传入的这样既能跑周报也能跑月报不需要改流程本身。两条链路我在 Dify 里都做了多版本并存线下调试通过后再切流。这里尤其想说Dify 工作流编辑器里每个节点的输出都可以单独预览这个能力在排查链路问题时太重要了。实际开发时我基本是在一个节点看一个节点的输出确认数据形态正常才继续往下接。3.3 提示词打磨从“意识流”到“带约束的任务书”hindsight 的提示词经历了三个阶段。第一阶段是“想象中很行”。我写了一段很长的角色设定让它“像一位睿智的观察者深刻复盘”。结果是内容空洞充满了正确的废话连我自己都不想看第二遍。第二阶段是“结构化输出”。我把报告拆成“重要事件时间线”“话题聚合”“未决事项”“观点冲突检测”四个板块并在提示词里规定每个板块的输出格式。效果好了不少至少像份报告了。第三阶段是“约束与引用”。这一步拉开差距。我在提示词里加入了这样几条硬性规则所有结论必须引用至少一条原始事件引用格式为【事件ID】。禁止出现“高效”“显著”“积极”等评价性形容词。当多个事件之间无法建立因果链时必须输出“暂无足够依据”而不是强行推断。冲突检测只陈述两方观点和当时的信息背景不下“谁对谁错”的判断。就这么几行报告质量肉眼可见地上升。原因是 LLM 在没有约束时会倾向于生成“最顺滑的文本”而“最顺滑的文本”往往也是最平庸的。约束是在帮它跳过平庸直接回答现场。我还保留了一个永远不动的“底线提示词”如果这次运行的输入数据量不足 10 条报告里必须声明“本周记录不足以支撑回顾结论”。数据量太少时强行总结跟算命的没区别。4. 让回顾结果可信而不是“看起来专业”4.1 阻断幻觉所有结论必须带来源LLM 幻觉是 hindsight 这种工具的天敌。它的职业是从一堆真实记录里提炼结论一旦幻觉混进来整份报告的信用全面崩盘。我在工作流里加了一个独立的校验节点专门的职责就是“追溯所有结论的来源”。做法是要求生成报告时每个观点后面挂上对应事件的 ID校验节点逐条检查这些 ID 是否真的存在于索引库里同时检查正文里的引号内容是否能在对应事件原文里找到。找不到的就直接标红宁可让报告出现“存疑”也不能让它给出一个貌似自然的错误。这招不能百分百消除幻觉但能把它限制在可以人工修正的范围。而且回顾报告每周一次人工过一遍的时间成本是可控的。4.2 噪音过滤没有一个项目是被琐事害死的如果你把两周的聊天记录全部灌进去回顾结果大概率一团糟。聊天本身有大量寒暄、表情符号、中途插入的无关话题它们会在向量检索时严重干扰相关性。hindsight 的清洗分三道闸第一道在接入阶段。即时通讯的转发机器人只保留发在工作群且满足条件提到项目名、带有 TODO、包含“决定”“问题”“风险”等词的消息。第二道在归一化阶段。分类器会把“闲聊”标签直接过滤掉根本不让它进知识库。第三道在检索阶段。召回时按“事件类型”权重排序决策记录和问题描述权重最高进展同步次之未分类内容默认只在兜底时召回。我实测过不设权重和设权重的差距同一条查询召回的前 5 条里有效信息的比例差了很多。Dify 的知识库检索支持 metadata 过滤这也是我坚持把每个事件都打好标签的原因——混沌的数据无法被任何聪明的检索逻辑拯救。4.3 让人能随时干预复盘不是全自动的独角戏hindsight 从设计之初就没打算让“自动”取代“主动”。每周报告生成后我会花十分钟在原文里快速核对几条关键结论。遇到报告与记忆明显冲突的地方就直接在对话里给 hindsight 发一条更正记录它会把这个反馈吸收进下轮索引。实际上我在 Dify 里给它做了个“人工注释”的输入通道任何一条更正都会作为特殊类型事件入库并在后续回顾时优先展示。这不是什么复杂技术就是个带 reason 参数的追加接口但作用很大它让系统有了纠偏能力。不然跑三个月之后初始索引里一个早期噪声被放大成“重要观点”那种错误会顺着时间越滚越大直到彻底失真。这基本上就是 AI 项目里最典型的“带病运行”问题。5. 节奏、集成和后续演进5.1 复盘节奏怎么定才不招人烦刚开始我把生成报告的任务设在每周五下午四点原意是下班前让大家回顾一下。结果发现周五下午所有人都在赶进度根本没人认真看。后来改成周日晚上八点自己在家安安静静地翻反而效果好得多。工具本身没有时间偏好节奏要匹配使用者的生理曲线。每天还设了一个轻量的“每日回顾”流程只输出三条今天解决了什么、今天留下了什么悬而未决的问题、有什么值得明天第一眼处理的事。三条多一条都不要。一旦这个工具每天产出的内容超过可读阈值你就会开始无视它然后废弃它。一个复盘工具的天敌不是不智能而是刷屏。5.2 把日历和 TODO 接进来才完整纯粹基于聊天记录和文档的复盘有一个盲区它不知道“计划”长什么样。我后来把待办系统和日历事件也接入了 hindsight。方法是定期导出两者的摘要作为“计划事件”进库。这样在周报告里就能看到“计划做什么”和“实际发生了什么”的对照很多复盘结论只有在对齐这条线之后才真正有说服力。举个例子周一计划写某个模块的测试但整周相关记录里只有三次讨论、没有提交记录。报告会直接用事实告诉你“这个计划没有在执行层落地”而不是用“本周各方面平稳推进”来粉饰太平。说实话这种对照看起来挺扎心的但它有用。5.3 下一步从周报到个人维度目前 hindsight 还是围绕“项目”和“周”来运作的。下一步我想把它从“项目复盘”扩展到“个人时间复盘”——也就是不做事件索引而是做全天时间线的语义切片看看一周里时间到底花在了哪些语境上有多少次“切换上下文”其实是可以合并处理的。另一个想加的是“决策点反事实推演”挑一个已经做完的决策让 LLM 基于当时的数据和当前的结果列出“如果当时走另一条路可能会出现什么结果”。这个功能很危险容易生成民科式推演所以要等我觉得提示词足够克制了才敢放出来。6. 踩过的坑和现在的边界6.1 Dify 工作流里的变量传递变量命名是隐形坑在 Dify 里搭了多条链路之后最容易翻车的地方不是模型效果不好而是变量传递。不同节点的输出变量名一长串复制到另一个节点时手滑多一个空格、少一个括号流程就直接报错。尤其是嵌套条件分支时系统文档里的变量引用方式和实际习惯写法不一致排查起来相当耗时。我的建议是统一命名规范所有变量使用 snake_case全部小写每一步的“结构化输出”字段名保持一致写链路前先在草稿纸上把每个节点的 input/output 定义好再进编辑器。我在没规范前反复改提示词改得头大定下这些规则后就顺了。Dify 的编辑器本身不限制你但混乱是自己堆出来的。6.2 长期积累的原始数据会“越来越吵”hindsight 跑了两个月后索引库已经积累了上千条事件。问题开始出现一些早期事件里的过时结论始终占据较高的检索权重比如项目早期“技术方案 A 比 B 更适合”的观点会在后期讨论方案 C 时被反复召回导致报告始终带上一种“旧时代回声”。我后来加了一个“时间衰减”机制向量召回之后按事件的 timestamp 做一个加权处理近 30 天的事件权重提升超过 90 天的事件权重打折扣。这个机制用代码实现不复杂核心是在检索结果集上做一个重排序。没有它知识库越老越吵最终会让复盘变成对旧观点的回声模拟。6.3 别指望 AI 复盘完全中立最后必须交个底LLM 在当前阶段的文本生成几乎不可能做到绝对中立。即使我在提示词里加了一堆约束它依然会在语言的自然流畅性和观点倾向之间滑向后者。hindsight 提供的是一个有据可查的视角不是一台测谎仪。我的应对办法是把自己定位成“报告的质疑者”。每周看到报告第一件事不是看结论而是看它引用了哪些事件然后问自己这些事件是不是被断章取义了报告没引用哪些事件被忽略的事件里是不是藏着别的解释这个过程本身反而养成了更严苛的复盘习惯——工具没有替代思考它是在逼我思考。如果你也想搭一个类似的工具我给的建议是第一周先把“采集”做扎实没数据一切免谈第一版本报告写得难看没关系先把链路跑通提示词再烂都要设严格引用约束因为重建信任比重建功能难得多。hindsight 这个名字本身就在提醒我只有当你想回看的时候回看才有意义。这个工具只是把“想”这个动作的痛点消掉了至于回看之后做什么还是你自己的事。