1. 从“后见之明”到可复用的复盘工具先说清楚这件事的价值hindsight 这个词中文直译是“后见之明”。听起来像是马后炮但在项目管理、个人成长、团队协作里它其实是核武器级别的能力事情做完了回头拆解“当时为什么那么判断”“哪一步埋了雷”“下次怎么不踩”这一整套动作就是复盘。现实中绝大多数团队的复盘都是走形式开个会、说几句“下次注意”然后就没有然后了。我做过的很多项目里真正让复盘发挥作用的关键不是态度而是把复盘流程化、数据化。也就是说你不能靠脑子记不能靠口头聊要让每一次决策、每一个操作、每一轮反馈都沉淀成可检索的结构化记录。这个需求听起来很合理但落地时有个现实问题团队用的工具太散文档在飞书或 Notion、代码在 Git、需求在 Jira、聊天记录在 IM 里想串起来看一条完整链路得人工翻好几个系统。所以我把目光盯上了 Dify。Dify 是一个开源的 LLM 应用开发平台核心能力是把大模型的调用、知识库、工作流编排、Agent 会话管理封装成可视化积木。我的做法不是去开发一个独立的复盘系统而是基于 Dify 搭一个“AI 复盘助手”把分散的文本记录扔给它它按照我们预先定义的复盘框架自动生成结构化分析报告。整个应用跑起来之后团队复盘从“凭感觉”变成了“有依据”从“会后的口水话”变成了“归档可查的记录资产”。这篇文章会给你完整交代三件事第一为什么用 Dify 而不是直接用 ChatGPT 写 prompt第二这个 AI 复盘助手的数据结构和工作流是怎么设计的第三我在实际搭建和调优过程中踩过的坑以及最后稳定运行的配置参数。如果你正想把手头的复盘流程数字化或者想了解 Dify 工作流到底能编排到什么程度这篇值得看完。2. 复盘工作的痛点与 Dify 选型逻辑2.1 复盘为什么难落地三个真实场景我先描述三个我在不同团队里反复见到过的场景你感受一下有没有共鸣。第一个是项目结束后的复盘会。项目经理提前拉了一个共享文档里面写了四个标题做得好、做得不好、改进项、行动人。会上大家你一言我一语负责人把话记录进去散会之后就没人再看那份文档。下个季度遇到一模一样的问题再走一遍同样的流程。第二个是线上事故复盘。凌晨两点服务报警值班同学一顿操作恢复服务第二天写事故报告凭记忆回填时间线“大概 01:40 发现了问题02:10 回滚完成”。恢复过程里的真实操作记录其实在终端日志里但没人去导因为太麻烦。第三个是个人成长复盘。我发现大部分人有记周报的习惯但周报写的是“完成了什么”不是“当时为什么这么选结果怎么样”。写周报和真正做复盘是两回事。这三个场景的共同特征是信息散落、缺乏结构、靠人脑回忆、不可检索。你问我解决方案是不是一定要上 AI我会说 AI 不是重点结构化和自动化才是重点。Dify 在这里解决的是一个核心矛盾你不用写完整的前后端代码也能做出一个真正能用的内部工具把散落的信息变成结构化数据再用大模型抽取、归纳、输出结论。2.2 为什么选 Dify 而不是裸写 Prompt 或自研服务如果你只是试试玩把一段文字粘贴给 GPT 让它“生成复盘报告”这当然可以。但一旦进入真实工作流裸用 ChatGPT 会暴露三个问题。第一上下文管理完全失控。现实中的复盘材料可能是几十条聊天记录、十几个相关工单、几段日志单次对话根本塞不下你得在 prompt 里不断拼贴文本每次会话都要重新解释规则。第二输出格式不稳定。同一段 input今天给你表格明天给你列表你需要花大量时间整理。第三没有记忆和外部数据源的理解能力无法对接团队知识库和专有数据。如果选择自研服务用 FastAPI 包一个 OpenAI SDK 调用接口倒也不难但要做到生产可用需要自己处理 API key 管理、日志、用户权限、前端交互界面、会话历史存储、知识库向量化……这些工作加起来至少是两周工作量。Dify 把这些能力全部内置了而且它本身是开源项目可以本地部署。私密性要求高的公司完全能把它跑在内网数据不出网这一点对很多企业来说比什么都重要。我选 Dify 的最终理由可以压缩成一句话它把 LLM 应用的骨架——前端界面、工作流引擎、知识库检索、会话记忆、模型管理——都做好了我只需要往里面填充业务逻辑。以下整篇讲的复盘助手本质上就是一个 Dify 工作流应用。2.3 Dify 复盘答题的核心能力拆解这个基于 Dify 的复盘助手我给它取了内部代号叫 Hindsight。它要完成的任务可以拆成四个能力上下文聚合、关键问题提问、结构化输出、档案归档。前三者靠工作流编排完成归档靠平台自带的会话管理完成。Dify 提供两种应用形式Chatflow 和 Workflow。Chatflow 适合交互式场景可以多轮对话Workflow 面向无状态的自动化处理任务适合用 API 或定时任务调用。我做的是 Chatflow因为复盘不是一次性的而是一个持续对话过程团队成员作为提问方与 AI 一轮轮把事件拆清。在这个工作流里我设计了 5 个关键节点开始节点、知识检索节点、问题生成节点LLM、判断节点如果/否则、报告输出节点LLM 变量聚合。整个流程是这样的用户先输入一段原始文本或者选择某个历史事件编号Hindsight 先判断是否已有该事件的历史复盘记录如果有就加载历史数据如果没有就让用户补充信息。信息补充到一定程度后LLM 分析节点开始生成复盘报告。这份报告不是一篇记录流水账的文章而是按 GRAI 四步法输出的Goal 目标回顾、Result 结果陈述、Analysis 过程分析、Insight 经验总结。3. 从零搭建 Hindsight知识库与工作流设计3.1 知识库搭建把历史上的复盘档案变成大模型的参考语料整个应用的基座是知识库。Dify 的知识库本质上是一个 RAG 检索系统支持上传 PDF、Word、Markdown、TXT 等格式文档平台帮你做切分、向量化、入库。我在做 Hindsight 的时候第一步不是写 prompt而是把团队过去 18 个月的复盘记录全部整理成 Markdown 文件导进去。具体操作有几步。首先把每个项目的复盘记录写成统一格式我用的结构是# 项目名称 - 复盘时间 ## 目标回顾 当时的项目目标是什么量化指标是什么 ## 结果陈述 最终交付了什么数据和预期对比如何 ## 过程分析 哪些策略有效哪些环节拖延风险识别判断是否及时 ## 经验总结 沉淀下哪些可复用方法论有哪些坑需要记录写好后在 Dify 的知识库页面创建数据集选择“通用”场景把文件批量拖进去。切分模式我选的是“自定义”分段标识符设为\n##这样每个章节都会作为一个独立 chunk 进行处理最大分段长度设为 500 tokens。这个设置很关键如果不按章节切大模型检索时会把多段内容混在一个上下文里回答的条理性会明显变差。向量模型用的是text-embedding-ada-002这是默认选项里的老牌模型对中文长文本支持得足够好检索精度在大量实操里表现稳定。召回模式选择“向量召回”TopK 设为 4Score 阈值设为 0.35。为什么选向量召回而不是混合召回因为复盘文档结构高度一致没有太多关键词重叠的问题向量召回已经够用混合模式反而会引入一些噪声。3.2 工作流编排让对话按人类的复盘逻辑走知识库搭好之后重头戏是编排 Chatflow。我在 Dify 的画布上拖出了 5 类节点每个节点都对应复盘流程中的一个真实环节。第一个节点是开始节点这里定义了两个输入变量user_input用户输入文本和event_id事件编号可选。系统提示词在这里写好开场的引导语让用户明白“你要做什么需要提供什么信息”。第二个节点是如果/否则判断节点检查event_id是否为空。如果为空说明这是一次全新的复盘工作流走到“信息收集 LLM”节点如果不为空工作流优先走“历史档案检索”节点通过知识库检索把历史复盘记录拉出来作为上下文。“信息收集 LLM”节点的职责不是生成结论而是做一件事审查用户当前提供的材料列举出这次事件中缺失的关键信息然后用友好的语气向用户提问。比如用户说“上周线上服务挂了 20 分钟”Hindsight 会问这个事件发生在哪个项目当时的目标或预期是什么这个问题的直接原因是什么有没有监控告警这样一步一步把信息补全。这个步骤绕过了大模型“瞎编细节”的毛病也让复盘过程真正落在关键对照上。当收集到足够信息后最后一个“复盘报告 LLM”节点会执行核心生成逻辑。它接收到的是用户全部输入、知识库检索到的相关片段、以及一段固化的工作流 prompt。这段 prompt 里明确要求模型按以下层级输出报告## 一、目标回顾 描述原始设定的目标数据指标和预期效果。 ## 二、结果陈述 对比实际结果与预期目标列出偏差数据。 ## 三、过程分析 归纳导致偏差的关键事件、决策点、外部影响。 ## 四、经验总结 输出可复用的方法论并将其标签化如 #流程优化 / #风险评估 / #沟通协作。 ## 五、行动项 列出至少两个明确可执行的改进行动包含责任人和完成时间。3.3 提示词里的一个关键设计克制生成我在设计提示词时踩过一个大坑就是让模型生成太多、太全的内容。第一次跑通测试时Hindsight 输出了一篇 2000 字的长文文采很好但没有聚焦点。整个报告读下来行动项里写的全是“加强沟通”“完善流程”这种正确的废话。后来我把提示词里加了一段硬性约束如果输入材料中不存在某个环节的信息不要补充猜测直接标注“信息缺失”。每个部分不超过 100 字行动项必须包含可量化指标或者明确时间点。加了这个之后输出质量明显提升因为模型被强制放弃了“编圆”的倾向。复盘这份工作的核心是直面事实不是写一篇漂亮的汇报。有一个容易被忽略的细节是模型参数。在 LLM 节点右侧配置里Temperature我设成了 0.2Top P设成 0.3。复盘分析对创造性的要求极低对稳定性和事实遵循度的要求极高所以温度必须拉低。如果你的场景是创意头脑风暴的复盘那可以调到 0.7 以上但生产环境我不建议。4. 配置参数、部署步骤与真实运行效果4.1 Dify 平台部署与基础配置Dify 本身的部署不是这篇文章的重心但我还是要提一下基础环节。官方提供了 docker compose 方式一条指令就能把 API 服务、Worker、PostgreSQL、Redis、Weaviate或 Qdrant等中间件全部拉起来。我推荐生产环境把向量数据库换成 Qdrant不因为别的就因为 Qdrant 的 Docker 部署简单、文档清晰、中文生态好遇到问题好搜。Dify 默认可能用了 Weaviate如果你不想折腾保持默认也没问题。但如果你要处理的知识库文件数量超过 5000 个还是老老实实换成 Qdrant。部署完成后在“模型供应商”里配置你的 LLM API key。这里要说一句Dify 是支持接入多家模型商的不限于 OpenAI也支持各类兼容协议的服务。我当时用的是 OpenAI 的gpt-4o-mini原因很简单速度快、价格低、中文质量足够。复盘这种任务不需要gpt-4级别的推理深度mini完全够用。4.2 完整的工作流节点配置逐项拆解我突然意识到光讲宏观流程还不够你得知道每个节点里填入什么内容的细节。下面我把 Dify Chatflow 里几个关键节点逐个过一遍给出可以直接对照的配置方式。开始节点输入变量定义如下变量名类型必填说明user_input段落输入否用户最初输入的事件描述event_id单行文本否历史事件编号为空则新建复盘注意这两个都设为非必填是有意的因为用户可能第一轮只输入了 event_id或者只在文本框里写了一句“来讲一下上次上线出的事”具体内容还没铺开。如果都设必填用户第一步就会被卡住体验很差。如果/否则节点条件判断是不等于空字符串。Dify 的条件变量比较语法的坑是对字符串变量判空要用变量 而不是变量 null因为空值经过历史会话渲染后往往是个空字符串。这个细节在测试时很容易发现明明没填内容判断节点却没走进对应分支。信息收集 LLM 节点的系统提示词原版我放在下面你可以直接用你是一个经验丰富的项目复盘引导员。用户正在描述一次项目或事件。你的任务是判断所提供信息是否足以完成一次完整复盘。 完整复盘需要下列信息 1. 事件/项目名称和时间范围。 2. 初始设定的目标与量化指标。 3. 最终结果与目标的偏差。 4. 关键决策点或转折点。 5. 影响结果的因素或原因。 每次提问只提出当前信息里缺失的最重要的一个问题不要连续抛出一串问题。用户输入包含“不适用无法提供”时标记该项目为信息缺失不要追问。当五项信息均齐全或有标记缺失时回复消息时只输出“信息已齐全”。判读是否齐全的这一步千万别让模型直接进入写报告流程否则用户只是说了一个开头还没来得及补齐信息报告就已经开始自动补全了。信息收集节点之后我接了一个“如果/否则”判断节点条件是对 LLM 输出进行关键词匹配包含“信息已齐全”才进入报告生成节点否则回到自身的追问流程。这其实是 Dify 工作流里一个经典写法用 LLM 节点做状态判断再配合条件分支完成循环。很多人问我 Dify 支不支持循环原生支持有限但通过这种“判定 跳回”的方式就能实现有限次数的交互循环。我在这个应用里设置了最多追问 3 轮第 3 轮还没齐全就直接生成报告缺失项显示为“用户未提供”。4.3 运行效果一次真实的事件复盘输出直接给你看一个实际跑通的案例。某次项目上线后第二天用户反馈了一个数据问题我用 Hindsight 做了一次复盘。输入材料贴了一段当时在群里沟通的记录大约 300 字没有结构化信息。Hindsight 第一轮追问“这次数据问题是否关联到近期上线的 3.5 版本该版本上线前有没有做全量数据的回归验证”这是从知识库中检索到历史类似事件后结合目标分析提出的。我补了一句“上线前只做了抽样验证”。第二轮追问“抽样验证的样本量占总体数据的比例大概多少当时判定通过的依据是什么”到这一步我已经没法给出更精确的答复回复“信息缺失”。第三轮触发后系统进入生成报告流程。最终输出里“过程分析”是这样写的本次事件直接原因是上线前回归验证策略偏保守抽样占比不足导致一个边界条件未被覆盖。关键决策点是版本发布评审环节当时以“仅影响非核心数据”为由降低了验证标准。但该字段实际参与了核心页面渲染影响链路判断存在偏差。“经验总结”里给了三条其中一条是“任何上线前回归验证必须限定最低样本规模量化规则需同步写入发布检查单”。“行动项”用了表格输出列出了两个 action item都带上了具体的完成时限。这个报告的生成质量说实话已经超过了我见过的绝大多数人工写的复盘文档因为它直击要害不绕弯子。5. 知识库与工作流的进阶调优让答案更贴近业务5.1 把企业级复盘文档变成持续更新的知识库刚才我讲的是把历史复盘文档传进去作为静态语料。但真正用好 RAG你需要动态地持续喂数据。每完成一次新的复盘应该把生成的报告回写到知识库里这样下一次遇到类似事件时Hindsight 就能调取上一次的复盘结论作为参考。这个回写过程Dify 没有直接提供的可视化节点但有解决方案在报告生成 LLM 节点之后加一个 HTTP 请求节点调用 Dify 的文档更新接口把当前会话生成的复盘内容以 Markdown 格式 POST 到知识库里。HTTP 节点的参数设置要注意一下请求头里带上Authorization: Bearer {你的 API 密钥}请求体里要指定数据集 ID 和文档 ID。我当时在处理回写时踩了一个坑有多少次会话我就会回写多少个文档用户如果同一个事件复盘了两次知识库里就有两份类同材料检索时会互相干扰。后来我加了去重逻辑在回写之前先查询知识库是否存在同事件的文档存在就先更新再新增。也就是说文档的 ID 我直接用事件编号拼接例如retro-event-20250112这样每次回写都落在同一份文档上。5.2 团队知识库检索不到时如何优化召回效果用 RAG 应用最常见的通病就是知识库里明明有相关内容回答时却检索不出来。我在 Hindsight 上也碰到过表现为用户提到某一个内部系统名称比如“北极星指标平台”但知识库里存的是“指标中心”叫法不同导致向量相似度不够。解决思路不是改代码而是调整知识库的切分和索引方式。有两个有效手段。第一在知识库文档里加一段别名描述区把常用叫法、简称、英文名都列出来。比如文档开头加一行“本系统又称指标中心、NPS 平台、Metrics Hub”。这让向量化时相近的语义表达都能覆盖到。第二把召回模式从“向量召回”改为“混合召回”Dify 里可以直接打开关键词召回开关让 BM25 算法兜底专门负责精确匹配别名或简称。实测下在叫法不统一的环境里混合召回比纯向量召回命中率提升了不少。顺带说一下 Score 阈值怎么校准。阈值设高了会漏招设低了会引入噪声。我用的是人工验证法把 50 条测试问题跑一遍输出每条问题的召回结果及分数然后把低于 0.3 分的真实相关结果和高于 0.5 分的不相关结果各找十个看分布交叉区域取一个能把不该召回的分数挡在门外的值。对大多数中文复盘文档来说0.3 到 0.4 都是比较合理的初始取值。5.3 安全与权限配置复盘内容可能很敏感复盘数据在多数公司都是比较敏感的信息包含事故细节、人员失误、内部流程漏洞。如果你部署在公网 Docker 上没有做访问控制那等于把内部问题簿直接挂在公网上非常危险。我的建议是 Dify 应用创建之后在访问控制里禁用无鉴权访问改走 API 访问方式把密钥分发到对应团队个人聊天界面只对内部网络开放。如果是用 Docker Compose 部署在云服务器上还应该在安全组里把非必要端口全部关掉只留 Nginx 入口把/console/api/路径想办法用 IP 白名单保护起来。另外一个被很多人忽视的细节模型供应商的 API Key 保存在 Dify 的后台环境变量里千万不要提交到 Git 仓库也不要截图发到聊天群里。在 Dify 的管理后台可以使用密钥管理系统加密存储这是生产环境部署必须做的事。6. 常见问题与调参避坑实录6.1 知识库相关检索不准的 5 种典型原因我自己把知识库相关的问题归为几类直接给结论现象根因解决办法检索结果答非所问分段粒度太大上下文混合自定义切分按\n##分段每段不超过 500 token检索不到简称术语覆盖不足文档里加别名区开启混合召回检索超时向量集合过大且未分区按项目年份归档到不同数据集工作流里指定检索范围返回内容太碎TopK 过低上调到 5 或 6再配合重排模型部分文档被跳过没有索引原文档格式复杂预先把 PDF/DOCX 转成 Markdown删除多余表格嵌套第三类问题在团队文档库很大时特别常见。我处理的方式很粗暴把知识库按“年度 事件类型”拆成多个数据集然后在工作流里根据用户描述中的时间关键词动态选择数据集。用这种方式不仅减少了检索范围还提升了精度。6.2 工作流层面上下文清零与变量丢失我在测试 Chatflow 时遇到一个特别烦的问题用户在一轮对话里提供了事件背景但在下一轮追问时Hindsight 把上一轮的内容全忘了。原因排查下来是对话历史传给 LLM 节点的窗口太小Dify 在 Chatflow 默认环境下不主动把历史消息注入到非首轮调用的节点需要在 LLM 节点的高级设置里把“记忆”开关打开并限制窗口中可包含的历史消息数。但是这里有一个平衡问题历史消息开得太大token 消耗会指数级上升而且过多旧信息会让模型抓不住重点。我实测后用的是 10 条历史消息窗口已经能保证 Hindsight 记得用户在第五轮说的关键信息。还有一个相关问题是变量作用域。Dify 工作流里变量默认是单次执行内有效跨对话轮的持久化要用会话变量来实现。我在开始节点定义的event_id在用户第二轮修改后就容易变成空值。解决办法是把 event_id 的持久化存储改为conversation_var这样整个会话内它都不会丢失。这一点对于所有多轮对话类的 Dify 应用来说都是重要提醒。6.3 模型层面温度参数与输出质量的“跷跷板效应”最后聊一个大模型参数的问题。很多人做这类工具时习惯用默认参数也就是 Temperature 0.7 左右但复盘工具并不适合。我在测试中做了一个对照实验同一份输入一组用 Temperature 0.2一组用 0.8。温度高的那组输出里出现了两处幻觉偏差一处是“抽样覆盖率达到 95%”——这个数据用户根本没有提供过另一处是编造了一个“用户投诉量上涨 20%”的细节。温度低的那组虽然没有这些编造但措辞变得保守有时候会把“可能的原因”写得很犹豫。解决措辞保守的方法不是调高温度而是在系统提示词里加一句“基于已提供信息给出确定判断不要使用可能、也许等不确定表达。信息不足时标注信息缺失”。实测结果把温度保持在 0.2 至 0.3配合明确指令约束既避免了幻觉又维持了判断的主体语气。这个组合我后来复制到了好几个生产项目里效果一致。7. 实战过程复盘我自己踩过的三个大坑7.1 第一个坑过度追求自动化忽略了人的参与我设计第一版 Hindsight 时理想状态是用户输入一句话系统自动生成完整复盘报告。这个目标听起来很酷但实际遇到了一个致命问题如果输入信息不足以支撑分析模型就开始编。我一度想通过更复杂的提示词来解决让它“如果信息不足就默认某某场景”这完全是错误方向。最终方案是退回半自动模式工作流先把信息收集环节做成强制问答用户至少经过两轮澄清后才会进入报告生成。这个改动让我理解了核心问题AI 在复盘里的角色不是预言家而是结构化编码器。你负责诚实输入它负责把诚实输入变成高质量输出。任何试图让 AI 自己补全“缺失事实”的做法都是灾难。7.2 第二个坑报告模板写得太死结果输出干瘪第二个版本我把输出结构定得非常详细每个部分都有强制字段例如“责任人”“完成时间”“影响范围人数”。结果生成的报告确实结构整齐但内容非常僵硬。比如没有实际数据的时候就写“N/A”没有具体责任人的时候写“待定”这根本没法用。问题的根源是我把企业表格思维直接搬到了 AI 生成里。真实决策的过程不可能每一项都有明确负责人和时间点复盘的价值在于理解因果脉络不是填表。我最后重新设计了输出模板把硬性字段减少到 3 个目标、结果、行动项。过程和经验部分交给模型以段落形式自然描述。这是一个很典型的“越想结构化越会失去内容温度”的案例。7.3 第三个坑把回复放在工作流内导致请求超时我在做长复盘生成时遇到了请求超时问题。复盘报告生成节点使用的模型如果推理较慢加上知识库检索耗时整个工作流在同步模式下容易超过网关限制的时间。一开始我没意识到这一点直到用户在对话中频繁等不到结果。排查后发现超时不是模型单次调用慢而是整个 Chatflow 在当前线程里同步处理了“检索 生成 再生成”如果报告长总耗时就超了。最终调整方式把报告生成节点的输出改为流式返回同时在 Dify 的高级设置里单独调大请求超时时间。如果你也用 Dify 做类似的总结生成类工作流建议提前把这一步做了不要等到上线了被用户催。8. 这套方法还能往哪扩展复盘助手只是 hindsight 这个理念的一种落地形式。按照同样的架构你可以把复盘的对象换一下就能做出完全不同的工具。举几个我觉得有价值的思路。第一个思路是迭代开发复盘。把每个 Sprint 的提交记录、PR Review 评论、测试出出的 bug 清单汇总成输入项让 AI 每周自动生成一份迭代复盘。这个和项目复盘的区别在于它是持续性的不是等一个里程碑结束才做。我测试过用 GitHub API 拉数据配合 Dify 的定时触发效果比人写的周报可靠得多。第二个思路是客户投诉复盘。输入客户反馈文本Hindsight 自动归类问题根因比如是流程不畅、产品设计缺陷还是服务响应不及时并且给出历史上类似问题的处理记录。这个场景下知识库的价值极大因为客户问题有很强的重复性。第三个思路是个人每日复盘。你可以每天晚上给自己 30 分钟把一天的高光时刻和沮丧点丢给 Hindsight让它帮你提炼当天暴露出的决策偏好和行为模式。这个用法我没有给团队用但我自己一直坚持在跑每周再看一遍 AI 总结出来的行为模式确实能发现一些不自觉的惯性。9. 写在最后的一些嘱咐回到 hindsight 本身。这个词很妙它讲的不是“事后诸葛亮”而是把后视镜里的影像转化成下一次路况判断的经验。我觉得做这类 AI 应用的心态也是如此你不可能让机器替你记住所有事情但你完全可以让机器替你组织、检索和提炼。如果看这篇文章的你正准备用 Dify 搭类似的应用我最后再分享几个一定会用上的心得。第一知识库的整理时间一定要留足它占整个项目周期的一半都不夸张。第二工作流节点不要一次设计完美先跑通主链路再逐步加判断分支。第三把你的复盘报告模板开源给团队里的核心用户试用两周然后基于真实反馈反向去改提示词不要自己闷头调。我在用 Dify 做完这个应用之后有一个很深的感受AI 工具的价值高峰往往不在于它替你完成了什么而在于它倒逼你把原来一团浆糊的流程想清楚了。复盘之所以需要 AI 助推本质上是因为人类太容易被眼前的紧急事务推着走缺的就是一个结构性视角把事件摊开、对齐、分析。这套方法如果真能帮你养成复盘的肌肉记忆那它就是成功的。
