说实话我第一次看到hindsight这个词蹦到我工作台旁边的时候第一反应是这不就是事后诸葛亮的英文版吗后来真把它当个项目名来用才发现这名字起得特别妙。hindsight 的意思是后见之明就是事情过后回头看才发现当时哪些判断是错的、哪些信号被漏掉了。而我要说的这个项目恰恰是把这个回头看的视角变成一套可复用的 AI 工作流基于 Dify 平台搭一个复盘助手让大模型帮你把杂乱的日志、周报、聊天记录整理成结构化的复盘结论。这个内容适合谁产品经理、软件工程师、运营、自媒体作者甚至只是每天写日记但坚持不下来的人。只要你手头有大量零散的过程记录又懒得自己一张张翻、一条条分析这个方案就能帮你把复盘这件事从玄学变成流水线。我自己从踩坑到跑通前后折腾了大概三个版本这篇文章直接把最终版的工作流、提示词、参数配置和排查方法完整拆开来讲你可以照着搭一套自己的。1. 项目概述hindsight 到底解决什么问题1.1 复盘这件事为什么总是做不下去复盘这个词职场里已经快被说烂了。什么每日复盘项目复盘OKR 复盘参加过不少但真正坚持下来的人没几个。我自己的体感是复盘最大的门槛不是方法而是时间和耐心。一天结束你想回忆今天到底做了什么、哪些决策值得反思脑子基本是一团浆糊。强行写复盘写出来的都是今天开会讨论了需求下午写代码遇到了 bug这类流水账完全没有见的成分。另一个问题是人的记忆是会被自己骗的。心理学上有个说法叫事后偏差事情发生之后再回头看你会不自觉地把结果写得比实际更合理、更连贯。自己手动复盘很容易变成给自己找理由的仪式。hindsight 这个项目想做的事情就是用 AI 当一面不带感情色彩的镜子把你丢进去的材料重新切一遍按事实、情绪、决策、得失几个维度展开逼你面对那些你下意识忽略掉的细节。所以这个项目的核心需求不是做一个AI 写日记工具而是做一个AI 复盘教练。它要有三个能力第一能接住各种乱七八糟的原始记录包括日记、周报、聊天记录、会议纪要第二能按照固定的复盘框架输出结构化结果而不是自由发挥的抒情散文第三能保持中立只依据事实说话不自作主张地给你灌鸡汤。1.2 为什么选 Dify 而不是自己写代码最开始我其实是想直接调大模型 API 写个脚本的用 Python 写一个命令行工具读文件调 API输出 Markdown。但写到一半就放弃了原因很简单日常的复盘输入不是规整的文件今天可能是一段语音转文字明天是飞书文档里的周报后天是微信群聊导出记录。这些来源需要不同的接入方式脚本写起来没完没了。然后我试了 LangChain 做编排发现它更适合开发者做复杂链路但对快速搭一个带界面、带知识库、能分享给同事用的工具来说工作量还是太大。那时候正好 Dify 已经比较成熟了可视化编排工作流、内置知识库、一键发布成 WebApp全都在同一个平台里解决。我把 Dify 当成一个流水线车间不需要自己造传送带只需要把各种处理节点拖进去接好再调几组参数就行。选 Dify 还有个很现实的原因模型可以随时换。复盘这种任务对推理质量要求不低但不同场景对延迟和成本的敏感度差很多。我自己平时会用两类模型一类是 DeepSeek 这种性价比高的处理日常日记另一类是 GPT-4o 或 Claude处理需要深度归纳的项目复盘。在 Dify 里换模型只是下拉框里改一下的事可维护性比改代码好太多了。2. 核心细节解析与实操要点2.1 工作流整体设计输入到输出的管线hindsight 的工作流本质上是一条材料处理管线。我不建议一上来就用一个巨大的提示词包办所有事那样输出质量很不稳定。我最后跑通的版本把流程拆成了四个阶段输入阶段接收文本或文件内容同时接收用户的复盘类型日复盘、周复盘、项目阶段复盘事实抽取阶段让模型先把材料里的客观事实单独拎出来区分发生了什么和当时我怎么想深度分析阶段基于抽取出来的事实按得失、决策质量、情绪状态、下一步行动四个维度展开分析结构化输出阶段把分析结果按固定模板组装成 Markdown 文档便于归档和后续整理每个阶段在 Dify 里就是一个节点节点和节点之间通过变量传递内容。我用的应用类型是 Chatflow而不是简单的 Workflow原因是复盘往往不是一次性任务——输出完第一轮结果后你很可能想追问一句第三个问题再说清楚一点或者当时那条决策如果不做会怎样。Chatflow 支持多轮对话复盘这个场景天然就是对话式的。2.2 提示词工程复盘 Prompt 这样写才有效提示词是整个项目里最值得花时间的部分。我前面几个版本输出差基本都是因为提示词写得太笼统模型不知道该用哪个视角来看待材料。我给 hindsight 设计的主提示词经过了三轮迭代最终版长这样你是我的复盘教练。我会给你一段原始记录请你严格按以下结构输出复盘结果不要省略任何小节 【事实回顾】按时间顺序列出关键事件只写客观事实不加入你的推断。 【情绪与状态】从记录中识别情绪波动点和精力峰值指出可能的原因标注证据。 【关键决策】找出我在记录中做过的3-5个重要选择分析当时做选择的依据是否充分。 【得失分析】分别列出做得好的2-3点和需要改进的2-3点每一点都给出下一步的具体动作。 【下一步行动】基于SMART原则写出3条可执行行动包含时间点和衡量标准。 硬性要求 1. 每条结论必须给出依据依据来自原文必要时引用原文短句。 2. 如果原文信息不足直接说明缺失了哪些信息不要编造。 3. 语气直接不要出现“很棒”“值得点赞”这类客套话。 4. 只基于这段记录分析不引入与记录无关的外部假设。这个 Prompt 的核心技巧就是给模型立了一个复盘教练的人设同时把输出强制拆成五个固定板块。板块化输出的好处是稳定模型知道每段该干什么不会跑偏。另外信息不足就直说这句话很关键它能让模型在材料单薄时不硬编结论这是复盘场景里最怕的事。如果你的复盘周期是按周或按月来还可以在此基础上加一个时间范围识别的变量。例如在开始节点设置一个date_range变量用户填2025-04-01 至 2025-04-07提示词里就加一句只分析时间范围内的内容超出范围的忽略。2.3 数据接入日记、周报、聊天记录怎么喂进去输入数据这个环节看起来简单实际坑最多。我一开始天真地以为直接把一整年的日记全粘贴进去就行结果模型输出直接崩溃原因后面会讲。正确的做法是先做一次粗筛选。我的输入方式分成三类第一类是纯文本粘贴。适合那种每天用笔记软件写日记的人。直接复制粘贴当天的记录几十行字模型处理完全没压力。这类输入最简单也是我最推荐的起步方式。第二类是文件上传。Dify 的 Chatflow 支持上传文件我把每周的周报存成 Markdown 或 txt 格式丢进去让它统一分析。注意文件不要太大。如果一份周报有几千字一次性分析反而会抓不住重点可以用 Dify 的知识库配合分段检索来解决这个下面单独说。第三类是聊天记录/会议纪要。这类材料最乱充满了碎片化信息、口语表达、无关的寒暄。我的做法是先让模型做一个信息压缩把聊天记录里涉及任务进展、决策点、阻塞问题的句子抽出来忽略寒暄和表情包描述。压缩完之后再进入复盘主流程。这个步骤我单独用了一个 LLM 节点前置在正式分析之前。3. 实操过程与核心环节实现3.1 环境准备部署 Dify 的两种路径Dify 的部署方式有两种我两种都试过可以给你一个非常直接的建议如果只是自己用直接用 Dify Cloud 的免费额度就行省去服务器维护的麻烦。如果涉及隐私数据——复盘这玩意儿其实挺私密的——建议还是自部署用 Docker Compose 拉一套 Dify 起来数据都在自己服务器上。自部署的硬件门槛不高一台 2C4G 的云服务器就能跑起来。官方的 docker-compose.yml 里包含 API 服务、Worker、PostgreSQL、Redis、Weaviate 等组件第一次启动大概需要几台容器一起拉起。我第一次部署时卡在端口占用上后来把 80 端口改成 8080 就通了。Dify 的.env文件里可以改EXPOSE_NGINX_PORT和EXPOSE_NGINX_SSL_PORT这个值决定你最终访问的端口改完重启docker-compose里的nginx服务就行。部署完成检查三个东西页面能否打开、能否登录管理后台、模型供应商里能否看到你配置的模型。这三个都通过了环境就算就绪。3.2 创建应用并配置模型参数进入 Dify 控制台之后选择创建应用类型选 Chatflow名字就叫 hindsight 复盘助手。创建好之后第一件事不是写提示词而是先配置模型。模型选型我的建议是日常复盘用 DeepSeek-V3 或者 GPT-4o-mini这个量级的模型速度快、成本低处理一般的日记文本完全够。项目级深度复盘用 GPT-4o 或 Claude 3.5 Sonnet它们的归纳能力明显更强能从大段材料里找到有价值的因果链。参数方面temperature我给的是 0.2。复盘任务需要的是稳定和克制温度太高会让模型自己发挥输出一些花哨但不可信的推论。如果你发现输出太机械、像复读机可以调到 0.4 试一下但超过 0.5 我是不建议的——那已经不是复盘了是 AI 陪你脑补。还有一个容易忽略的参数是max_tokens也就是单次输出的最大长度。复盘模板有五段内容不少如果设得太短会被截断。我设的是 2000基本够用。如果你是给模型喂一个月的大记录复盘那可以再往上加到 4000。3.3 编排工作流节点逐一配置整个 Chatflow 我用了六个节点按照顺序分别是开始节点、输入预处理节点代码节点做文本清洗、事实抽取节点LLM、深度分析节点LLM、输出整理节点LLM、结束节点。这里有个设计心得为什么用三个 LLM 节点而不是一个因为复盘这个任务如果一步到位模型很容易在深度分析时把事实回顾的错误也一起带进来——前面的抽取错一点后面全跟着错。分成三个节点每一步都有明确的输入输出任一步出错你都可以在节点日志里定位到具体是哪一环。这种方式在 Dify 里叫多阶段文本处理代价是调用次数多了两倍但换来的是可调试性和输出质量的显著提升我认为完全值。第一个预处理节点用的是代码节点我写了一段简单的 Python作用是把输入文本里的多余空行、特殊符号、时间戳前缀清理掉。这段代码不长但非常实用import re def main(input_text: str) - str: # 清理多余空行 text re.sub(r\n{3,}, \n\n, input_text) # 去除行首尾空格 lines [line.strip() for line in text.splitlines()] text \n.join(lines) # 删除常见聊天表情占位符例如 [捂脸] [呲牙] text re.sub(r\[[^\]]{1,8}\], , text) return text这个节点的主要作用是降低后续 LLM 节点的噪声负担。如果你喂的是聊天记录里面可能有大量[捂脸][旺柴]这类表情占位符不清理的话模型会被带偏把注意力放在这些无关内容上。事实抽取节点和深度分析节点的配置核心就是各自填好我上面提到的主提示词的变体。事实抽取节点用事实抽取版提示词把输出约束成一条条并列的事实短句深度分析节点用分析版提示词只负责看事实列表不看原始材料。这样信息一步比一步纯粹模型更容易聚焦。3.4 测试与发布把复盘助手变成随叫随到的服务工作流编排完成之后先别急着发布。Dify 提供了页面里的调试功能在对话输入框里粘贴一段测试文本就能看到完整的节点执行过程包括每个 LLM 节点的输入输出和 token 消耗。这个过程一定要做我每次改提示词都要在调试里跑一遍观察中间输出是否符合预期。调试通过后点击左上角的发布按钮Dify 会生成两个东西一个是可直接访问的 WebApp 链接手机和电脑都能打开适合自己日常用另一个是 API 服务地址和 API Key如果你想把复盘能力接到飞书机器人、企业微信或者自己的脚本里直接调这个 API 就行。我现在的使用方式是把 WebApp 链接加到浏览器书签栏每天晚上睡觉前花五分钟把当天的工作日志粘贴进去然后拿着生成的复盘结果对照一下第二天计划。周末再把这五天的复盘结果放到一个新对话里让它生成周度趋势总结。4. 常见问题与排查技巧实录4.1 输出太泛泛像正确的废话这是第一个版本最常见的问题。现象是模型输出的得失分析全是提高沟通效率加强时间管理这种话听着没错但对你没有任何指导意义。我排查了日志发现模型确实看了原文但它在分析环节偷懒了用通用话术填充。解决办法有两个层面。第一个层面是提示词约束要求每条结论必须引用原文短句作为依据比如你说下午四点之前完成了三次无效沟通这里提到的无效沟通具体指什么。引用依据有三个好处逼着模型从具体事实出发防止泛泛而谈让你复查时有迹可循还能让输出看起来更像一个真实教练的追问。第二个层面是前置事实抽取环节加一个动作在抽取事实时要求模型把每个事实按照时间地点人物事件结果的格式展开。结构化的细节会让后边的分析有抓手模型分析时也更容易从事实里推导出有价值的东西。4.2 长文本输入被截断模型遗漏关键信息这个问题我踩得最狠。有一次我把一个季度的工作记录全塞进去大概两万多字模型输出直接泛化成了鸡汤跟原文相关的部分寥寥无几。原因很简单上下文窗口超限或者即便没超限模型在处理超长文本时的注意力也会失焦。我的方案是先砍后喂。在 Dify 里用知识库组件把长文按章节切块切块大小设置为 1000 字符左右重叠度为 200 字符。然后把用户输入作为检索请求通过知识库召回最相关的那几块进入后续分析。这样模型永远只看到和问题相关的一两段精度高了不少。如果你不想用知识库组件还有一个土办法把长文本按天或按周拆成多段多轮对话里每次只喂一段。缺点是比较费对话轮数但效果也很直接。反正记住一条原则长文本能拆就别整段丢给模型。4.3 输出格式不稳定张三李四各说各话我测试阶段发现同一个输入有时候模型输出五个板块齐全有时候只输出三个板块甚至会把下一步行动的内容并进得失分析里去。这其实是 LLM 的通病格式约束在复杂任务里容易丢失。我试过在提示词里加如果不按格式输出会被扣分这种威胁式语句效果一般。真正稳定下来的方案是把格式约束拆到代码里做后处理。我加了一个输出整理节点用 Dify 里的模板节点来组装最终 Markdown 文本。模板节点有点像 JSP 里的模板引擎你可以预先定义好整个输出框架然后把前面 LLM 节点输出的数据填进对应的占位符里。这样至少在组织排版这一层永远不会因为模型发挥失常而乱掉。如果你的复盘结果要进 Notion 或者飞书文档这个稳定格式能力很重要。4.4 知识库召回不到想用的内容如果你用了知识库方案大概率遇到过这种问题明明往知识库里传了一个月的日志问上个月有哪些拖延的迹象却召回不到相关内容。问题多半出在查询改写上。Dify 知识库的召回逻辑是向量相似度匹配而用户对话里的问法往往和文档原文的表达方式差别很大。我的解决思路是加一步检索查询改写节点在主流程进入知识库之前先用一个轻量 LLM 节点把用户的复盘需求改写成几个有效的检索关键词。例如上个月有哪些拖延的迹象改写成拖延、计划延迟、未完成、加班赶工、临时变更。这个技巧在信息检索领域叫 Query Rewriting放在 Dify 里就是一个节点的事但对召回归类的效果提升非常明显。如果你发现知识库总是弱智80% 是查询方式的问题不是知识库本身的问题。4.5 复盘助手变成了情绪垃圾桶怎么办还有一个有意思的问题而且是我用了两周之后才注意到的。很多时候日记里会有大量情绪倾诉比如我今天被气死了这个项目要完蛋了。AI 作为复盘教练如果跟着你一起抱怨那复盘就变成哭诉了。处理方式是在提示词里加一条非常明确的分工指令情绪表达部分只作为分析依据不作为回应重点。不要安慰我不要共情只做理性拆解。 我发现一个有趣的现象模型其实很擅长做情绪识别只要你引导它把情绪当成数据来分析它就能很好地完成从情绪陪伴到状态诊断的切换。这个设定让 hindsight 的输出有了独特的价值——它不是你的朋友它是你的教练。朋友会顺着你说教练只会指着你的盲区说。这也是hindsight这个词想表达的态度站在事后的位置看到的不是情绪是因果。5. 一些值得单独拿出来说的体会5.1 复盘频率和内容颗粒度我实测下来日复盘适合用很短的文本输入三五行就够重点记决策点和情绪波动。周复盘适合做汇总分析把一周的日复盘内容拼起来让模型输出趋势性和规律性判断。月复盘则可以对比四周的周复盘结果让模型尝试建立因果链。很多人问过我用什么频率最合适我的回答是宁可每天花两分钟记三行也不要每周憋一小时写长篇。hindsight 的基础是原始记录的质量AI 再强也没办法从一个空洞的今天还行里榨出真正的信息。这个项目给我的一个额外收获其实是养成了随手记录的习惯AI 跑出来的复盘结果只是副产品。5.2 关于模型迭代和平台更新的建议Dify 这个平台更新得挺快我写这篇文章的时候市面上已经有了很多新功能包括更完善的 Agent 节点、更细粒度的权限管理以及更丰富的工具插件。如果你照着本文的流程搭建发现某些界面和截图不太一样不用慌大概率是版本更新的正常迭代。你只需要抓住三个核心不变的东西工作流拆阶段的思路、提示词里设置复盘教练人设的方法、以及知识库做长文本切块的策略。功能按钮会变但这三件事不会变。5.3 这个项目后续还能怎么扩展hindsight 目前是我自己用的私密工具但它其实很容易扩展成团队用品。把 Dify 应用接入飞书机器人团队成员每天下班后在群里丢一段当日总结机器人自动跑完复盘然后把结果汇总到一张共享表格里。一个季度下来每个人的成长轨迹都看得清清楚楚。这对团队负责人来说价值比市面上大多数绩效工具都大因为它不评价只呈现事实和改进方向这对团队的信任基础有好处。我个人的下一步计划是想把语音输入也接进来毕竟每天打复盘文字还是有点麻烦。Dify 本身支持语音转文字插件后面我会把录音文件转文本 - 文本进复盘流程做成一条完整的链路。这个扩展如果做成了可能就真能做到一分钟完成一次高质量复盘了。最后再分享一条我自己的实操感受复盘的输出结果一定要隔几天再重新看一遍。hindsight 这个名字本来就是在提醒这件事——你当时没有的视角事后都会有。AI 帮你生成第一遍的复盘你隔一周再看一遍往往能发现第二遍的思考比第一遍更深。工具能做的是帮你把复盘的门槛降下来但真正让复盘产生价值的还是你这个回头看的动作本身。 用Dify打造AI复盘助手：从日志到结构化结论的自动化工作流
说实话我第一次看到hindsight这个词蹦到我工作台旁边的时候第一反应是这不就是事后诸葛亮的英文版吗后来真把它当个项目名来用才发现这名字起得特别妙。hindsight 的意思是后见之明就是事情过后回头看才发现当时哪些判断是错的、哪些信号被漏掉了。而我要说的这个项目恰恰是把这个回头看的视角变成一套可复用的 AI 工作流基于 Dify 平台搭一个复盘助手让大模型帮你把杂乱的日志、周报、聊天记录整理成结构化的复盘结论。这个内容适合谁产品经理、软件工程师、运营、自媒体作者甚至只是每天写日记但坚持不下来的人。只要你手头有大量零散的过程记录又懒得自己一张张翻、一条条分析这个方案就能帮你把复盘这件事从玄学变成流水线。我自己从踩坑到跑通前后折腾了大概三个版本这篇文章直接把最终版的工作流、提示词、参数配置和排查方法完整拆开来讲你可以照着搭一套自己的。1. 项目概述hindsight 到底解决什么问题1.1 复盘这件事为什么总是做不下去复盘这个词职场里已经快被说烂了。什么每日复盘项目复盘OKR 复盘参加过不少但真正坚持下来的人没几个。我自己的体感是复盘最大的门槛不是方法而是时间和耐心。一天结束你想回忆今天到底做了什么、哪些决策值得反思脑子基本是一团浆糊。强行写复盘写出来的都是今天开会讨论了需求下午写代码遇到了 bug这类流水账完全没有见的成分。另一个问题是人的记忆是会被自己骗的。心理学上有个说法叫事后偏差事情发生之后再回头看你会不自觉地把结果写得比实际更合理、更连贯。自己手动复盘很容易变成给自己找理由的仪式。hindsight 这个项目想做的事情就是用 AI 当一面不带感情色彩的镜子把你丢进去的材料重新切一遍按事实、情绪、决策、得失几个维度展开逼你面对那些你下意识忽略掉的细节。所以这个项目的核心需求不是做一个AI 写日记工具而是做一个AI 复盘教练。它要有三个能力第一能接住各种乱七八糟的原始记录包括日记、周报、聊天记录、会议纪要第二能按照固定的复盘框架输出结构化结果而不是自由发挥的抒情散文第三能保持中立只依据事实说话不自作主张地给你灌鸡汤。1.2 为什么选 Dify 而不是自己写代码最开始我其实是想直接调大模型 API 写个脚本的用 Python 写一个命令行工具读文件调 API输出 Markdown。但写到一半就放弃了原因很简单日常的复盘输入不是规整的文件今天可能是一段语音转文字明天是飞书文档里的周报后天是微信群聊导出记录。这些来源需要不同的接入方式脚本写起来没完没了。然后我试了 LangChain 做编排发现它更适合开发者做复杂链路但对快速搭一个带界面、带知识库、能分享给同事用的工具来说工作量还是太大。那时候正好 Dify 已经比较成熟了可视化编排工作流、内置知识库、一键发布成 WebApp全都在同一个平台里解决。我把 Dify 当成一个流水线车间不需要自己造传送带只需要把各种处理节点拖进去接好再调几组参数就行。选 Dify 还有个很现实的原因模型可以随时换。复盘这种任务对推理质量要求不低但不同场景对延迟和成本的敏感度差很多。我自己平时会用两类模型一类是 DeepSeek 这种性价比高的处理日常日记另一类是 GPT-4o 或 Claude处理需要深度归纳的项目复盘。在 Dify 里换模型只是下拉框里改一下的事可维护性比改代码好太多了。2. 核心细节解析与实操要点2.1 工作流整体设计输入到输出的管线hindsight 的工作流本质上是一条材料处理管线。我不建议一上来就用一个巨大的提示词包办所有事那样输出质量很不稳定。我最后跑通的版本把流程拆成了四个阶段输入阶段接收文本或文件内容同时接收用户的复盘类型日复盘、周复盘、项目阶段复盘事实抽取阶段让模型先把材料里的客观事实单独拎出来区分发生了什么和当时我怎么想深度分析阶段基于抽取出来的事实按得失、决策质量、情绪状态、下一步行动四个维度展开分析结构化输出阶段把分析结果按固定模板组装成 Markdown 文档便于归档和后续整理每个阶段在 Dify 里就是一个节点节点和节点之间通过变量传递内容。我用的应用类型是 Chatflow而不是简单的 Workflow原因是复盘往往不是一次性任务——输出完第一轮结果后你很可能想追问一句第三个问题再说清楚一点或者当时那条决策如果不做会怎样。Chatflow 支持多轮对话复盘这个场景天然就是对话式的。2.2 提示词工程复盘 Prompt 这样写才有效提示词是整个项目里最值得花时间的部分。我前面几个版本输出差基本都是因为提示词写得太笼统模型不知道该用哪个视角来看待材料。我给 hindsight 设计的主提示词经过了三轮迭代最终版长这样你是我的复盘教练。我会给你一段原始记录请你严格按以下结构输出复盘结果不要省略任何小节 【事实回顾】按时间顺序列出关键事件只写客观事实不加入你的推断。 【情绪与状态】从记录中识别情绪波动点和精力峰值指出可能的原因标注证据。 【关键决策】找出我在记录中做过的3-5个重要选择分析当时做选择的依据是否充分。 【得失分析】分别列出做得好的2-3点和需要改进的2-3点每一点都给出下一步的具体动作。 【下一步行动】基于SMART原则写出3条可执行行动包含时间点和衡量标准。 硬性要求 1. 每条结论必须给出依据依据来自原文必要时引用原文短句。 2. 如果原文信息不足直接说明缺失了哪些信息不要编造。 3. 语气直接不要出现“很棒”“值得点赞”这类客套话。 4. 只基于这段记录分析不引入与记录无关的外部假设。这个 Prompt 的核心技巧就是给模型立了一个复盘教练的人设同时把输出强制拆成五个固定板块。板块化输出的好处是稳定模型知道每段该干什么不会跑偏。另外信息不足就直说这句话很关键它能让模型在材料单薄时不硬编结论这是复盘场景里最怕的事。如果你的复盘周期是按周或按月来还可以在此基础上加一个时间范围识别的变量。例如在开始节点设置一个date_range变量用户填2025-04-01 至 2025-04-07提示词里就加一句只分析时间范围内的内容超出范围的忽略。2.3 数据接入日记、周报、聊天记录怎么喂进去输入数据这个环节看起来简单实际坑最多。我一开始天真地以为直接把一整年的日记全粘贴进去就行结果模型输出直接崩溃原因后面会讲。正确的做法是先做一次粗筛选。我的输入方式分成三类第一类是纯文本粘贴。适合那种每天用笔记软件写日记的人。直接复制粘贴当天的记录几十行字模型处理完全没压力。这类输入最简单也是我最推荐的起步方式。第二类是文件上传。Dify 的 Chatflow 支持上传文件我把每周的周报存成 Markdown 或 txt 格式丢进去让它统一分析。注意文件不要太大。如果一份周报有几千字一次性分析反而会抓不住重点可以用 Dify 的知识库配合分段检索来解决这个下面单独说。第三类是聊天记录/会议纪要。这类材料最乱充满了碎片化信息、口语表达、无关的寒暄。我的做法是先让模型做一个信息压缩把聊天记录里涉及任务进展、决策点、阻塞问题的句子抽出来忽略寒暄和表情包描述。压缩完之后再进入复盘主流程。这个步骤我单独用了一个 LLM 节点前置在正式分析之前。3. 实操过程与核心环节实现3.1 环境准备部署 Dify 的两种路径Dify 的部署方式有两种我两种都试过可以给你一个非常直接的建议如果只是自己用直接用 Dify Cloud 的免费额度就行省去服务器维护的麻烦。如果涉及隐私数据——复盘这玩意儿其实挺私密的——建议还是自部署用 Docker Compose 拉一套 Dify 起来数据都在自己服务器上。自部署的硬件门槛不高一台 2C4G 的云服务器就能跑起来。官方的 docker-compose.yml 里包含 API 服务、Worker、PostgreSQL、Redis、Weaviate 等组件第一次启动大概需要几台容器一起拉起。我第一次部署时卡在端口占用上后来把 80 端口改成 8080 就通了。Dify 的.env文件里可以改EXPOSE_NGINX_PORT和EXPOSE_NGINX_SSL_PORT这个值决定你最终访问的端口改完重启docker-compose里的nginx服务就行。部署完成检查三个东西页面能否打开、能否登录管理后台、模型供应商里能否看到你配置的模型。这三个都通过了环境就算就绪。3.2 创建应用并配置模型参数进入 Dify 控制台之后选择创建应用类型选 Chatflow名字就叫 hindsight 复盘助手。创建好之后第一件事不是写提示词而是先配置模型。模型选型我的建议是日常复盘用 DeepSeek-V3 或者 GPT-4o-mini这个量级的模型速度快、成本低处理一般的日记文本完全够。项目级深度复盘用 GPT-4o 或 Claude 3.5 Sonnet它们的归纳能力明显更强能从大段材料里找到有价值的因果链。参数方面temperature我给的是 0.2。复盘任务需要的是稳定和克制温度太高会让模型自己发挥输出一些花哨但不可信的推论。如果你发现输出太机械、像复读机可以调到 0.4 试一下但超过 0.5 我是不建议的——那已经不是复盘了是 AI 陪你脑补。还有一个容易忽略的参数是max_tokens也就是单次输出的最大长度。复盘模板有五段内容不少如果设得太短会被截断。我设的是 2000基本够用。如果你是给模型喂一个月的大记录复盘那可以再往上加到 4000。3.3 编排工作流节点逐一配置整个 Chatflow 我用了六个节点按照顺序分别是开始节点、输入预处理节点代码节点做文本清洗、事实抽取节点LLM、深度分析节点LLM、输出整理节点LLM、结束节点。这里有个设计心得为什么用三个 LLM 节点而不是一个因为复盘这个任务如果一步到位模型很容易在深度分析时把事实回顾的错误也一起带进来——前面的抽取错一点后面全跟着错。分成三个节点每一步都有明确的输入输出任一步出错你都可以在节点日志里定位到具体是哪一环。这种方式在 Dify 里叫多阶段文本处理代价是调用次数多了两倍但换来的是可调试性和输出质量的显著提升我认为完全值。第一个预处理节点用的是代码节点我写了一段简单的 Python作用是把输入文本里的多余空行、特殊符号、时间戳前缀清理掉。这段代码不长但非常实用import re def main(input_text: str) - str: # 清理多余空行 text re.sub(r\n{3,}, \n\n, input_text) # 去除行首尾空格 lines [line.strip() for line in text.splitlines()] text \n.join(lines) # 删除常见聊天表情占位符例如 [捂脸] [呲牙] text re.sub(r\[[^\]]{1,8}\], , text) return text这个节点的主要作用是降低后续 LLM 节点的噪声负担。如果你喂的是聊天记录里面可能有大量[捂脸][旺柴]这类表情占位符不清理的话模型会被带偏把注意力放在这些无关内容上。事实抽取节点和深度分析节点的配置核心就是各自填好我上面提到的主提示词的变体。事实抽取节点用事实抽取版提示词把输出约束成一条条并列的事实短句深度分析节点用分析版提示词只负责看事实列表不看原始材料。这样信息一步比一步纯粹模型更容易聚焦。3.4 测试与发布把复盘助手变成随叫随到的服务工作流编排完成之后先别急着发布。Dify 提供了页面里的调试功能在对话输入框里粘贴一段测试文本就能看到完整的节点执行过程包括每个 LLM 节点的输入输出和 token 消耗。这个过程一定要做我每次改提示词都要在调试里跑一遍观察中间输出是否符合预期。调试通过后点击左上角的发布按钮Dify 会生成两个东西一个是可直接访问的 WebApp 链接手机和电脑都能打开适合自己日常用另一个是 API 服务地址和 API Key如果你想把复盘能力接到飞书机器人、企业微信或者自己的脚本里直接调这个 API 就行。我现在的使用方式是把 WebApp 链接加到浏览器书签栏每天晚上睡觉前花五分钟把当天的工作日志粘贴进去然后拿着生成的复盘结果对照一下第二天计划。周末再把这五天的复盘结果放到一个新对话里让它生成周度趋势总结。4. 常见问题与排查技巧实录4.1 输出太泛泛像正确的废话这是第一个版本最常见的问题。现象是模型输出的得失分析全是提高沟通效率加强时间管理这种话听着没错但对你没有任何指导意义。我排查了日志发现模型确实看了原文但它在分析环节偷懒了用通用话术填充。解决办法有两个层面。第一个层面是提示词约束要求每条结论必须引用原文短句作为依据比如你说下午四点之前完成了三次无效沟通这里提到的无效沟通具体指什么。引用依据有三个好处逼着模型从具体事实出发防止泛泛而谈让你复查时有迹可循还能让输出看起来更像一个真实教练的追问。第二个层面是前置事实抽取环节加一个动作在抽取事实时要求模型把每个事实按照时间地点人物事件结果的格式展开。结构化的细节会让后边的分析有抓手模型分析时也更容易从事实里推导出有价值的东西。4.2 长文本输入被截断模型遗漏关键信息这个问题我踩得最狠。有一次我把一个季度的工作记录全塞进去大概两万多字模型输出直接泛化成了鸡汤跟原文相关的部分寥寥无几。原因很简单上下文窗口超限或者即便没超限模型在处理超长文本时的注意力也会失焦。我的方案是先砍后喂。在 Dify 里用知识库组件把长文按章节切块切块大小设置为 1000 字符左右重叠度为 200 字符。然后把用户输入作为检索请求通过知识库召回最相关的那几块进入后续分析。这样模型永远只看到和问题相关的一两段精度高了不少。如果你不想用知识库组件还有一个土办法把长文本按天或按周拆成多段多轮对话里每次只喂一段。缺点是比较费对话轮数但效果也很直接。反正记住一条原则长文本能拆就别整段丢给模型。4.3 输出格式不稳定张三李四各说各话我测试阶段发现同一个输入有时候模型输出五个板块齐全有时候只输出三个板块甚至会把下一步行动的内容并进得失分析里去。这其实是 LLM 的通病格式约束在复杂任务里容易丢失。我试过在提示词里加如果不按格式输出会被扣分这种威胁式语句效果一般。真正稳定下来的方案是把格式约束拆到代码里做后处理。我加了一个输出整理节点用 Dify 里的模板节点来组装最终 Markdown 文本。模板节点有点像 JSP 里的模板引擎你可以预先定义好整个输出框架然后把前面 LLM 节点输出的数据填进对应的占位符里。这样至少在组织排版这一层永远不会因为模型发挥失常而乱掉。如果你的复盘结果要进 Notion 或者飞书文档这个稳定格式能力很重要。4.4 知识库召回不到想用的内容如果你用了知识库方案大概率遇到过这种问题明明往知识库里传了一个月的日志问上个月有哪些拖延的迹象却召回不到相关内容。问题多半出在查询改写上。Dify 知识库的召回逻辑是向量相似度匹配而用户对话里的问法往往和文档原文的表达方式差别很大。我的解决思路是加一步检索查询改写节点在主流程进入知识库之前先用一个轻量 LLM 节点把用户的复盘需求改写成几个有效的检索关键词。例如上个月有哪些拖延的迹象改写成拖延、计划延迟、未完成、加班赶工、临时变更。这个技巧在信息检索领域叫 Query Rewriting放在 Dify 里就是一个节点的事但对召回归类的效果提升非常明显。如果你发现知识库总是弱智80% 是查询方式的问题不是知识库本身的问题。4.5 复盘助手变成了情绪垃圾桶怎么办还有一个有意思的问题而且是我用了两周之后才注意到的。很多时候日记里会有大量情绪倾诉比如我今天被气死了这个项目要完蛋了。AI 作为复盘教练如果跟着你一起抱怨那复盘就变成哭诉了。处理方式是在提示词里加一条非常明确的分工指令情绪表达部分只作为分析依据不作为回应重点。不要安慰我不要共情只做理性拆解。 我发现一个有趣的现象模型其实很擅长做情绪识别只要你引导它把情绪当成数据来分析它就能很好地完成从情绪陪伴到状态诊断的切换。这个设定让 hindsight 的输出有了独特的价值——它不是你的朋友它是你的教练。朋友会顺着你说教练只会指着你的盲区说。这也是hindsight这个词想表达的态度站在事后的位置看到的不是情绪是因果。5. 一些值得单独拿出来说的体会5.1 复盘频率和内容颗粒度我实测下来日复盘适合用很短的文本输入三五行就够重点记决策点和情绪波动。周复盘适合做汇总分析把一周的日复盘内容拼起来让模型输出趋势性和规律性判断。月复盘则可以对比四周的周复盘结果让模型尝试建立因果链。很多人问过我用什么频率最合适我的回答是宁可每天花两分钟记三行也不要每周憋一小时写长篇。hindsight 的基础是原始记录的质量AI 再强也没办法从一个空洞的今天还行里榨出真正的信息。这个项目给我的一个额外收获其实是养成了随手记录的习惯AI 跑出来的复盘结果只是副产品。5.2 关于模型迭代和平台更新的建议Dify 这个平台更新得挺快我写这篇文章的时候市面上已经有了很多新功能包括更完善的 Agent 节点、更细粒度的权限管理以及更丰富的工具插件。如果你照着本文的流程搭建发现某些界面和截图不太一样不用慌大概率是版本更新的正常迭代。你只需要抓住三个核心不变的东西工作流拆阶段的思路、提示词里设置复盘教练人设的方法、以及知识库做长文本切块的策略。功能按钮会变但这三件事不会变。5.3 这个项目后续还能怎么扩展hindsight 目前是我自己用的私密工具但它其实很容易扩展成团队用品。把 Dify 应用接入飞书机器人团队成员每天下班后在群里丢一段当日总结机器人自动跑完复盘然后把结果汇总到一张共享表格里。一个季度下来每个人的成长轨迹都看得清清楚楚。这对团队负责人来说价值比市面上大多数绩效工具都大因为它不评价只呈现事实和改进方向这对团队的信任基础有好处。我个人的下一步计划是想把语音输入也接进来毕竟每天打复盘文字还是有点麻烦。Dify 本身支持语音转文字插件后面我会把录音文件转文本 - 文本进复盘流程做成一条完整的链路。这个扩展如果做成了可能就真能做到一分钟完成一次高质量复盘了。最后再分享一条我自己的实操感受复盘的输出结果一定要隔几天再重新看一遍。hindsight 这个名字本来就是在提醒这件事——你当时没有的视角事后都会有。AI 帮你生成第一遍的复盘你隔一周再看一遍往往能发现第二遍的思考比第一遍更深。工具能做的是帮你把复盘的门槛降下来但真正让复盘产生价值的还是你这个回头看的动作本身。