hindsight这个词字面意思是后见之明说白了就是我们常说的事后复盘。工作里我们总说如果当时那样做就好了但真到下次遇到类似场景大概率还是踩同一个坑。我用Dify搭了一个叫hindsight的小应用专门做这件事——把零散的项目记录、日报周报甚至聊天记录丢进去让它帮你沉淀出一份能指导下一步行动的复盘报告而不是单纯的情绪宣泄或流水账。如果你手里有一堆业务日志却不知道怎么提炼价值或者团队每次复盘都流于形式这篇内容应该对你有用。我会把整个设计思路、Dify平台的关键玩法、提示词写法、工作流编排细节以及我踩过的坑全部展开讲一遍。不绕弯子直接进入正题。1. hindsight应用到底在解决什么问题1.1 后见之明的本质从记录到决策的跨越后见之明在认知科学里其实有个很经典的定位人类擅长事后解释但并不擅长事前预测。这中间缺的不是信息而是结构化的反思机制。我们每天产生大量工作记录、会议纪要、客户反馈但绝大多数都停留在记录阶段没有进入思考阶段。hindsight这个应用的核心思路就是用大模型把记录自动转化为反思。它做的事情是三件把分散的事实数据时间、事件、结果提取出来在事实之上叠加分析框架目标对比、原因归因、可执行建议最终输出一个能进入下次决策的复盘结论我在做这个应用之前其实也试过直接用ChatGPT粘贴一段项目总结让它点评。效果凑合但有两个问题很致命一是上下文窗口有限长日志根本塞不进去二是提示词里没有领域知识做锚点AI给出来的反馈永远是那种提升沟通效率、加强项目管理的万金油。hindsight应用真正解决的就是这两个痛点。1.2 为什么选Dify而不直接写代码我有一段时间是直接用LangChain FastAPI自己撸这类应用的。功能确实灵活但每次加一个功能点就要改代码、重新部署、处理API密钥维护成本相当高。后来换成Dify是因为它在这类数据进、报告出的AI应用上基本覆盖了我90%的日常需求而且改配置比改代码快得多。Dify本质上是一个开源的大语言模型应用开发平台它把模型接入、提示词管理、知识库检索、工作流编排、日志追踪这些东西都做成了可视化模块。你不需要写一行代码就能把一个调用LLM的这个流程从零散脚本变成产品级应用。而且它的沙箱环境和版本管理机制让我敢在线上直接调提示词改坏了马上回滚。还有一个很实际的原因Dify支持结构化输出和变量传递。这意味着我可以设计一个输入表单让用户在界面里填项目周期、目标、关键事件这些字段会作为结构化变量进入提示词模板而不是让用户把一团乱麻的文字丢给AI自由发挥。这种可控性是直接调API很难实现的。1.3 这个应用适合哪些场景我在搭hindsight的过程中发现它适配的场景比我想象中广。个人层面你可以拿它做每日五条日志的深度复盘或者每周日把这一周的工作记录丢进去让它输出一份周反思。团队层面把项目周报、迭代记录、事故报告导入知识库然后让hindsight基于这些上下文生成项目阶段性复盘。我实际用得最多的场景是客户项目复盘。以前写项目复盘报告要从十几篇周报里翻事实、整理时间线、归纳原因一个人忙一个下午。现在我把周报文档扔给hindsight它自己会抽取关键事件、对比计划偏差、分析问题根因最后给我一版带时间线标记的复盘草稿我再做人工校正。效率提升不是一点点而是从无到有的质变。2. Dify平台的核心概念与部署准备2.1 Dify的四个核心模块先搞清楚再动手在开始搭hindsight之前我强烈建议你先花半小时熟悉Dify的界面和四个核心模块。它们是你所有应用的基础积木。模型供应商在这里配置大模型的API Key比如OpenAI、通义千问、DeepSeek、智谱等。hindsight这个应用对模型的要求不算极端但我会建议用推理能力较强的模型来做复盘分析具体理由后面讲。知识库用来上传和管理你的私有数据。hindsight把历史周报、项目文档放这里AI回答时会优先检索这些资料作为背景。知识库本质上是给LLM装了一个外挂记忆。应用真正面向用户的成品。Dify里应用分两大类对话助手Chatbot和文本生成Text Generator。hindsight我是用对话助手类型做的因为它需要多轮交互和上下文记忆。工作流这是Dify最值钱的部分。你可以像搭积木一样定义用户输入先走什么、检索什么、模型用什么提示词、最后怎么格式化输出。hindsight的整个复盘流程就是在工作流里编排出来的。提示如果你之前完全没用过Dify我的经验是先别急着看工作流的各种高级节点。先创建一个最简单的对话应用跑通模型接入-对话测试这个过程再逐步加复杂度。一上来就冲着工作流去很容易被节点之间的数据映射绕晕。2.2 部署方式与模型接入的取舍Dify的部署门槛很低官方文档提供了docker compose一条命令启动的方式本地机器有Docker环境就行。我用的是社区版部署在一个配置还算够用的Linux服务器上模型API因为成本考虑接的是国内模型的接口。这里有一个关键的取舍点值得多说两句。模型选择直接影响复盘质量尤其是复杂归因场景。我对比测试了三个模型效果模型事实抽取准确率归因深度中文报告可读性成本GPT-4o系列高深但偶尔过度脑补中上高DeepSeek系列高深逻辑结构好好低通义千问系列中上中偏保守好低最终我在hindsight的正式环境里用的是DeepSeek系模型主要原因是它在长文本理解归因深度中文表达这个三角上表现最均衡。价格还便宜复盘这种动不动就要处理几千字内容的场景成本优势非常明显。2.3 知识库准备先整理数据再谈效果hindsight这个应用要真正产生价值知识库绝不能空着。我在搭建初期犯过一个错误直接把几十篇杂乱无章的周报一股脑上传结果Dify的召回效果很差AI经常抽到不相关的背景内容反而不利于复盘。后来学乖了知识库的数据做了三步处理清理去掉周报里大量重复的流程描述和无关紧要的琐事保留目标、进度、阻塞、变更、结论这几类核心信息。分段Dify上传文档时会自动分段但我手动调整了分段大小让每一段聚焦一个项目或一个阶段提高召回精度。元数据标注给每个知识库文档加上标签比如项目A-2024Q3项目B-售前阶段这样在工作流里可以按元数据过滤检索范围避免无关项目的内容被召回。这一套准备下来hindsight的复盘质量有了质的提升。AI在输出分析时会引用知识库里真实发生的项目背景而不是凭空套用一个放之四海皆准的分析框架。2.4 工作流与变量把复盘逻辑结构化Dify工作流里最吸引我的是它把AI应用的逻辑从一句话提示词变成了可视化流程。hindsight的工作流我设计成了这样一条链路后面实操部分会展开讲用户通过前端表单提交复盘材料 - 系统自动判断材料是否为空 - 调用提示词模板结合知识库检索结果 - 大模型生成结构化复盘报告 - 输出给用户。这里最核心的概念是变量。Dify允许你在工作流里定义系统变量、用户变量和节点输出变量。hindsight的设计里我定义了项目名称、复盘周期、原始素材、重点方向这四个用户变量。这四个变量会通过模板字符串注入到后续的提示词节点中。比如提示词模板里写请针对{{项目名称}}在{{复盘周期}}内的表现进行复盘运行的时候Dify就会用真实输入替换模板占位符。这个机制的意义在于同一个hindsight应用面对不同项目、不同周期的复盘请求AI会生成完全匹配上下文的报告而不是一条提示词通吃所有场景。3. 构建hindsight复盘应用的核心设计3.1 应用类型选择Chatbot还是Text GeneratorDify里创建应用时第一个选择就是类型。hindsight从定位上我更推荐对话助手理由如下第一复盘本身是一个对话式探索的过程。你第一次生成的复盘报告可能不够深入你可能想追问关于客户投诉那条根因再展开一下或者帮我对比一下和上个季度的差异。对话助手天然支持这种多轮交互而Text Generator只能一次性生成。第二对话助手可以携带上下文记忆这在复盘的应用里太重要了。hindsight在会话中会保存用户上传的材料以及之前生成的复盘结果用户可以说基于刚才的复盘给我列五个下周要做的事AI完全能理解刚才的复盘指的是什么。第三对话助手类型的应用在Dify里配置起来并不复杂它一样可以嵌入工作流节点。我目前的hindsight版本就是对话入口 工作流处理 对话输出的混合结构。3.2 提示词工程复盘效果的分水岭我在调hindsight提示词的过程中有一个非常深的感受给AI的提示词决定了它是复读机还是分析师。一个平庸的复盘提示词大概是这样的你是一个项目管理专家请基于以下信息进行项目复盘给出改进建议。 这种提示词我一开始也用过效果非常平庸AI会输出项目总体进展顺利但在沟通方面仍有提升空间这种毫无信息量的话。后来我迭代了一版真正有效的提示词结构核心是五个层次角色定位不只说你是专家而是明确定义你是一位有十年交付经验的IT项目集经理擅长从事实中识别风险信号。思考框架明确要求AI按事实—偏差—根因—对策—行动五个步骤输出不允许跳步。约束条件禁止AI编造未出现在素材中的事实禁止使用加强提升这类无实义动词所有建议必须能落到具体负责人和时间节点。示例引用在提示词里给一个迷你复盘示例让AI模仿参考格式和深度。输出格式要求用Markdown输出包含标题、表格、加粗这样用户看起来清爽也方便后续复制到文档里。我下面会给出完整提示词模板但在这里想强调一点提示词不是写一次就完事了。我用Dify的日志与标注功能把每次用户提问和模型回答都记录下来每周翻一遍找出那些表现不好的case然后反向修改提示词。这比任何技巧都更有效因为你是在用真实数据迭代你的提示词。3.3 工作流设计从单次问答到流程化思考前面提到hindsight的工作流是为了让AI的思考过程可控。我的工作流具体包含这几个节点逐步拆开看开始节点接收四个用户变量的输入原始素材、项目名称、复盘周期、重点关注方向。这个节点本质上定义了用户与应用的接口协议。知识检索节点根据项目名称和复盘周期在知识库中检索相关背景文档返回top k条结果。这里我设置了TopK为5相似度阈值0.4太低了会召回一堆无关内容太高了又可能漏掉重要背景。问题理解节点这是工作流里的第一个LLM节点。它的任务不是直接生成复盘报告而是把用户提交的原始素材自动清洗成结构化的事实清单。这个中间步骤很关键它让AI在正式复盘之前先做一次信息压缩把一段2000字的流水账变成20条结构化事实。深度复盘节点第二个LLM节点接收事实清单、知识库检索结果和用户重点关注方向按照前面说的五步框架输出完整复盘报告。输出节点把复盘报告返回给前端对话界面。这套工作流和一句话调用LLM最大的区别在于它把一个大任务拆解成了两个小任务并且每个小任务都有不同的提示词。这符合大模型应用的一个核心认知LLM在专注处理单一任务时表现远好于同时处理多个复杂任务。3.4 知识库怎么和hindsight配合有些读者可能觉得hindsight就是一个提示词应用为什么非要绑定知识库我是这么看的没有知识库的hindsight就像一个失忆的分析师。它只能基于当前喂给它的一堆素材做局部复盘但它不知道这个项目上个阶段的复盘结论是什么这个客户的背景需求之前有没有人记录过。而这些问题恰恰是深度复盘的真正价值所在。举个例子用户提交本周的项目周报工作流里的知识检索节点会去知识库中找到该项目上周的周报以及该项目立项时的背景文档。然后深度复盘节点就会把本周进展和上周计划放在一起做偏差分析明确指出哪些任务是按计划推进的哪些产生了延误以及延误背后的原因对比。这个分析深度是单纯用一段文字让AI看着办绝对做不到的。知识库的使用也让hindsight具备了组织记忆的能力。随着数据积累同一个项目的复盘会越来越准因为AI能看到的历史背景越来越完整。3.5 输出格式设计让复盘报告真正可用复盘报告写出来没人看是复盘最大的失败。我设计hindsight的输出格式时遵循了一条原则报告要能让管理者在30秒内抓住核心让执行者在5分钟内找到自己的下一步动作。最终的输出格式是这样一个结构# {{项目名称}}复盘报告{{周期}} ## 一、总体结论 一两句话概括本期表现是达标、偏差还是严重风险 ## 二、关键事实与数据 表格事实描述、发生时间、影响程度 ## 三、目标偏差分析 表格原定目标、实际结果、偏差幅度、原因分类 ## 四、根因研判 按维度拆解流程问题/人员问题/外部因素 ## 五、经验沉淀 哪些做法下次继续哪些做法必须停止 ## 六、下一步行动S.M.A.R.T. 表格行动项、负责人、截止时间、成功标准你可能会问格式定这么死AI生成还能自然吗我的经验是复盘报告要的是效率和一致性不是文学性。固定的格式大大降低了阅读者的理解成本而且AI在输出时很容易遵循这种结构化的模板。如果你希望报告更生动可以在经验沉淀部分让AI用更口语化的方式总结这样既有结构又有温度。4. 实操过程从零搭建hindsight助手4.1 创建应用与基础配置进入Dify控制台在工作台页面点击创建空白应用。应用类型选择对话型应用应用名称我填的是hindsight-智能复盘助手描述信息里写清楚应用能力说明方便后续维护时分辨。创建完成后第一步是配置模型。左侧导航进入模型供应商填入对应API Key。我选择的是DeepSeek的API。有一点值得提醒Dify的模型参数里温度和Top P两个参数对复盘类应用的影响非常大。温度控制了回答的随机性。复盘报告需要稳定、可预测的输出所以我把温度设置成0.2几乎最保守的设置。这样保证同样的素材十次生成的报告差异很小。如果你希望复盘报告更有发散性可以适当调到0.4-0.5但我个人不建议更高因为发散出来的观点可能脱离事实。4.2 编写复盘提示词一份可直接抄的模板核心提示词我贴在这里已经去掉了所有无关内容你直接复制到Dify的指令栏就能用。这份模板是前面提到的五层结构的一次完整实践# 角色 你是一位拥有十年企业级IT项目交付经验的资深项目集经理同时精通组织过程改进。你擅长从项目事实中指出隐蔽的风险信号并用逻辑严谨的方式分析根因。 # 任务 基于用户提供的复盘素材以及知识库检索到的背景信息对{{项目名称}}在{{复盘周期}}内的表现进行一次结构化、深度的复盘。 # 思考步骤严格按顺序执行不允许跳步 1. 通读全部素材提取所有关键事实标注事实发生的时间线。 2. 将事实与既定目标做对比找出每一项偏差。 3. 对每个偏差进行根因分析区分内部流程问题、外部依赖问题、执行团队问题和偶发因素。 4. 根据根因提炼可复用的经验或必须修正的行为。 5. 将以上分析转化为可执行的行动建议行动必须能落实到负责人和时间点。 # 硬性约束 - 不得编造素材中不存在的事实或数据若素材缺失某项信息如实标注素材未提供。 - 禁止使用加强沟通提升效率优化流程等无实义动词作为行动建议每一项建议必须包含具体动作、负责角色和完成时限。 - 根因分析必须至少识别一层表层原因之下的深层原因如果原材料无法支撑深层归因必须明确说明归因的置信度有限。 - 重点关注用户指定的{{重点关注方向}}该方向的偏差分析要额外详细。 # 输出格式 严格按照以下Markdown结构输出报告 此处粘贴3.5小节的完整格式模板 # 示例参考 以下是一个缩写示例仅用于展示分析深度和行文风格 此处粘贴一段你自己写的高质量复盘示例 内容大约300字即可AI会模仿你的结构和语气这份提示词我用了很久实测下来效果非常稳。关于示例参考我建议你一定要给出来。大模型在模仿示例风格这件事上的能力超乎预期但前提是你给的示例本身质量要高。我自己写的那段示例花了两个小时打磨之后所有复盘报告的行文风格都稳定在了一个专业水准上。4.3 搭建工作流节点连接与变量映射详解在Dify的应用编排界面切换到工作流模式。我来按节点顺序讲配置要点。开始节点输入类型选择文本的四个变量。这里有个容易踩的坑你给变量设置用户可以在对话时填写选项时Dify会在前端对话界面自动生成一个表单。建议把原始素材设定为多行文本其他三个为单行文本。实际使用中用户可能会粘贴几千字的长文多行输入框不至于眼花。知识检索节点选择你准备好的知识库。查询变量我绑定的是项目名称这个字段这样检索内容会围绕当前复盘的特定项目展开。为了让检索更精确我在查询里拼了一段上下文项目复盘背景信息{项目名称}。这个技巧可以让向量检索更聚焦实测召回准确率提升不少。问题理解节点这是一个LLM节点模型选择DeepSeek温度同样是0.2。系统提示词我写的比较简短核心任务是把用户提交的原始素材整理为结构化事实清单每一条事实必须包含时间、事件、相关人/部门、影响结果。只做信息抽取和整理不要进行任何分析和评价。注意LLM节点里不需要像对话应用那样写长篇指令专注一个任务反而更出效果。这个节点的输出是一个文本变量我命名为facts。深度复盘节点这是整个工作流的核心模型选择DeepSeek温度0.2。系统提示词就是4.2节那份完整模板。不过有一个关键操作在上下文里要同时引用知识检索节点的输出和问题理解节点的输出。Dify的变量选择器里可以分别勾选知识库检索结果数组和facts变量。很多人在这一步会漏掉知识库的上下文接入导致复盘分析缺少组织记忆效果大打折扣。直接回复节点输出内容选择深度复盘节点的文本输出。设置节点暂存回复选项勾选根据我的输入内容回复。这样用户看到的回复就是工作流最后生成的那份结构化报告。注意工作流里的每个LLM节点响应时间都会累加。hindsight的整个流程如果知识检索比较慢用户可能要等几十秒才能看到报告。我的优化方案是在深度复盘节点里把问题理解节点输出的事实清单同时放到用户消息字段并把知识库检索的TopK值减小到3。这样能在损失很小精度的情况下明显缩短响应时间。用户体验优先吗在这里是。4.4 前端对话场景的用户使用方式应用发布之后用户会看到一个对话界面。hindsight的使用方式设计得很直接用户在对话框中按指定格式输入复盘需求比如项目名称电商中台迁移项目。复盘周期2024年8月。重点关注方向数据迁移质量与团队协作效率。原始素材以下是本周的项目周报……这里有一点值得特别注意Dify对话应用的表单变量是引导用户填还是靠提示词引导用户自己写这直接影响使用体验。我用的是后者——在工作流开始节点的描述里写清楚请按照以下格式输入然后在模型提示词里也重复了一遍格式要求。这对于非技术用户更友好因为他们在对话输入框里自然打字就行不用理解底层变量系统。用户提交后界面会先显示正在思考中然后逐步输出结构化的复盘报告。由于我设置了多轮对话用户还可以接着问再帮我展开讲讲数据迁移质量的根因。hindsight会结合工作流生成的结果和上下文记忆继续深入分析。4.5 测试与调优用什么标准判断效果好应用搭建完成后我用一批真实的历史周报做了三轮测试。第一轮测试的目标是事实准确性。我故意在素材里放了一些自相矛盾的信息比如第一周说进度正常第二周说延期三周然后检查AI的偏差分析是否抓到了这对矛盾。实测发现如果提示词中没有强调跨时间线对比AI大概率只看第二周的内容漏掉前后矛盾。于是我在思考步骤第2步里加了将事实与既定目标、历史背景做对比并补充了一句注意识别素材内部时间线上的矛盾。第二轮测试的目标是归因深度。我会审阅AI输出的根因分析看它是否停留在表面。比如项目延期的表层原因是第三方接口交付延迟深层原因可能是合同条款里没有约定交付时限的违约责任。如果AI只写了表层原因我会在硬性约束里增加更明确的要求并用示例参考来引导它挖掘更深。第三轮测试的目标是成本与速度。用DeepSeek模型时一次完整复盘大约消耗8000到12000个token成本控制在几分钱到一毛钱左右完全可以接受。响应速度在几秒到十几秒之间取决于原始素材的长度。调优最重要的手段是Dify的日志与标注功能。每次用户的提问和LLM输出都会被记录。我建议你每周留出固定时间把这一周内所有不满意的输出标记为负面案例分析是提示词问题、知识库召回问题还是素材本身质量问题然后分别去优化。这个反馈闭环比任何模型微调都及时有效。5. 常见问题与排查技巧实录5.1 复盘结果空洞、全是套话怎么办这是hindsight使用中最常见的问题。现象是AI输出了结构完整的报告但每条内容都像正确的废话。我的排查顺序是这样的先看知识库召回是否生效。如果知识检索节点的输出为空或者召回的文档和当前项目无关那么AI就只能靠通用知识硬写写出来的东西当然空。我会在工作流日志里点开知识检索节点检查召回结果片段。再看素材质量。如果用户提交的原始素材本身就是流水账没有目标、没有阻塞、没有数据AI巧妇难为无米之炊。我在应用描述和提示词里已经做了引导但有些用户还是会敷衍。这种情况下我会把复盘的结论写成素材信息密度不足以支撑深度复盘建议补充以下信息……而不是硬分析。最后检查提示词约束是否生效。如果你发现AI开始写加强协作、提升能力这类废话说明禁止使用无实义动词这条约束没起作用。这时我会把约束改成更具体的表述比如行动项必须是一个可执行的动作例如每周五下午与第三方接口负责人同步进度而不是一个抽象方向。5.2 大段素材超长处理报错或截断Dify的对话应用和LLM节点都有上下文长度限制。用户一次性粘贴几万字长文确实会出现超长报错或截断问题。我的处理方案是分两条路径。一是上游引导在应用描述里明确写了单次提交素材建议控制在5000字以内若素材较长请按周分批提交hindsight会合并多次复盘结果。这解决了大部分问题。二是工作流兜底在问题理解节点前面加了一个条件分支节点。判断用户输入的原始素材字符数是否小于4000如果小于走正常流程如果大于先让问题理解节点做一次提取事实清单的中间步骤只把事实清单传给后面的深度复盘节点从而绕过上下文长度限制。这一步实测能平滑支持2万字以内的长篇素材。5.3 多轮追问时AI失忆或答非所问对话应用的记忆机制默认开启但记忆容量有限。如果用户在第一轮上传了长素材又在第三轮追问一个和素材无关的新问题AI可能会混淆。我自己遇到过几次用户问这个行动项的负责人是谁AI却回答了一个素材里完全不存在的人名。这个问题的根源在于知识幻觉。对于复盘类的追问我的建议是在深度复盘节点的提示词末尾加上一条当用户追问本报告内容时只允许引用本次工作流中生成的事实清单和复盘结果不得生成素材中不存在的具体人名、数字和结论。若无法从上下文中找到答案请直接回复该信息在本次复盘中未提供。这条约束加上之后多轮追问的准确率提升非常明显。5.4 模型配置与部署中的隐藏坑部署Dify本身比较容易但有几个细节容易让人卡住。Docker部署时建议固定版本号不要直接用latest社区版更新频繁接口变动会导致配置突然失效。模型API这块最容易出问题的是供应商选择和模型名称的匹配。同一个API Key下可能有多种模型名称填错模型名称会报model not found。建议在Dify的设置页里先做一次连接测试确认能正常调用再进到应用里配置。另外提醒一句如果部署环境在国内Dify调用一些国外模型的API接口时可能会遇到连接超时或响应不稳定。我的处理方法是尽量接入国内可直接访问的模型服务一方面速度快另一方面也避免了网络层面的很多不确定性。技术选型上稳定比高级更重要。5.5 数据隐私与权限管理hindsight这个应用会涉及大量项目内部信息隐私安全必须提前想清楚。Dify社区版支持基础的权限管理你可以创建不同角色控制谁能访问后台、谁能使用应用。另外知识库文档的访问权限也是独立的建议对敏感项目单独建库不要所有项目共用一个知识库防止跨项目信息泄露。在模型调用的数据层面如果你使用的是云端模型API素材内容会经过模型服务商的处理。如果你对数据敏感度要求很高可以考虑Dify支持接入私有化部署的开源模型方案比如本地部署一个量化版的模型。代价是推理速度慢、硬件要求高但对那些完全不能出内网的数据来说这是唯一解。这里也想分享一个经验hindsight用了一两个月后我的知识库里沉淀了大量复盘报告和项目经验它已经不只是一个工具而逐渐变成了团队的过程资产库。员工流动、项目交接时新同事可以直接向hindsight提问这个项目之前遇到过哪些坑、当时的规避措施是什么它给出的答案比翻旧文档快得多也比问老同事靠谱得多——毕竟任何人的记忆都会衰减但知识库里的记录不会。最后关于hindsight应用我自己的迭代路线是下一步打算给它加一个风险雷达模块——通过持续喂入每周的项目状态数据让AI在复盘之外主动输出下周最值得关注的三条风险信号。个人或者团队用Dify做AI应用这件事真的不难难的是想清楚你要让AI在什么流程里、以什么标准、帮人做什么判断。hindsight这个名字说到底就是我们用技术把自己该做却经常偷懒不做的事后思考变成了一件自动化、标准化、可持续的事。先把复盘做起来它带来的变化可能比预期要大得多。