hindsight复盘工作流：用Dify把后见之明变成前见之用

hindsight这个词本身就很有意思——它自带一种自嘲的意味明明早该看清楚的事情非要等尘埃落定之后才恍然大悟。我前段时间做的这个hindsight项目核心就是想把这种“后知后觉”变成每天都能用的生产力。说白了hindsight不是预测工具它是一个“复盘工具”。它做的事情是把已经发生过的对话、告警、操作记录、项目过程全部拉出来让大模型帮你重新看一遍当时到底哪里出了问题、决定是怎么做的、如果重来一遍应该怎么改。而dify这个热词之所以能和hindsight绑在一起是因为我最终选择用dify作为落地底座把原本只停留在嘴巴上的“经验总结”变成了一条可配置、可复用、能接入业务系统的自动化工作流。这篇文章我打算聊得稍微细一点从设计思路、技术选型到完整的落地步骤、踩坑过程适合三类人看手里攒了一堆历史数据却不知道怎么提炼价值的开发者想在公司内部做复盘工具但又不想从零写一整套后端的管理者还有正在研究dify工作流、想找个真实场景练手的人。1. 项目到底要解决什么问题先把这个问题的边界说清楚。市面上做“预测”的工具很多但做“复盘”的工具反倒很少原因很朴素预测能带来故事感复盘却让人觉得是做事后功课。可对于一个团队来说真正决定长期战斗力的是复盘质量而不是谁喊得响。hindsight项目要解决的问题可以拆成三块。第一块是信息碎片化。一个项目从开始到结束会有需求文档、IM聊天记录、会议纪要、代码提交记录、线上告警、工单反馈等一堆来源完全不同的数据。这些数据平时躺在各自的系统里复盘的时候靠人肉去翻漏掉关键细节几乎是必然的。我做hindsight做的第一件事就是打通一个统一入口把散落在各处的信息先拽到一个地方。第二块是归因靠拍脑袋。传统复盘会变成“责任认定大会”大家倾向于找一个最容易被指责的人或团队来背锅而不是真正去找系统性原因。hindsight在设计原则上专门避开了这一点它会要求模型按照“时间线—事实—影响—假设验证—行动项”的顺序输出先说事实再提假设最后才谈责任人而且责任归属必须是流程上可以改变的点不能落到个人品质上。第三块是经验无法沉淀。复盘做完了结论写在文档里三个月后同样的问题换个姿势再出现一次谁也记不住当年总结过什么。hindsight里专门设计了一个知识库每次复盘产出的结论都会向量化存进去下次再遇到相似情况系统会主动把“上次的经验”拉到上下文里来提醒。这才是“hindsight”这名字的逻辑来源后见之明本身没有价值有价值的是把它沉淀成前见之用的能力。也有人问过我这项目能不能直接拿现成的商业工具来做为什么非得自己捏一个。我用过一阵子通用型团队复盘工具最大的感受是它们把“流程”做得很好但对“内容”几乎没有任何帮助还是要靠人自己去写。hindsight想拿掉的是最费时间的部分——从原始材料里梳理事实脉络、对齐多方说法、生成可验证的行动项。这恰好是通用工具做不到而大模型加dify工作流能做得不错的地方。2. 核心设计思路从“后见之明”到“前见之用”在动工之前我把hindsight整体流程画成了一条线性链路这条链路直接影响后面在dify里怎么搭节点。每一环都不能省因为每一环都在帮大模型做减负。2.1 五段式复盘链路我从一个比较成熟的复盘方法论里借了骨架把它改造成更适合LLM运行的版本整条链路分为五段数据接入与清洗把各种来源的原始记录转成统一的事件格式。事件至少要包含四要素发生时间、涉及对象、事实描述、信息来源。这一步决定了后面所有分析的准确性。时间线重建按时间顺序把离散事件串成一条故事线。时间线不是简单的列表排序而是要识别人工干预节点、关键决策点、异常拐点。影响面计算这一步的目的不是算经济损失而是梳理“影响半径”。发生了故障是只影响一个接口还是拖垮了一条业务线需求延期是只压了一个版本还是导致后续排期全部乱掉影响面越清楚复盘越不容易跑偏。根因假设生成与验证让模型基于时间线产出至少三个根因假设再去数据里找支持或反对假设的证据。这一步特别关键因为大多数不成熟的复盘都是跳到了“原因就是XXX”这一步压根没经过假设验证。行动项与经验沉淀把结论转成可执行的todo同时压成一句话“规则”写入知识库备用。行动项要满足smart原则不然写一百条也是白写。这段链路从天然就适合做成dify里的工作流因为dify的节点图能直观地看到每一段的数据流转哪个节点挂了、哪个环节耗时过长都一目了然。2.2 为什么一定用dify而不是自己写LangChain代码我在这个项目之前自己写过几个LangChain脚本说实话功能上完全能跑通但写到第三个版本就受不了了涉及多轮调试、参数调整、可视化追踪的时候纯代码方案的维护成本陡升。尤其是复盘这种需要反复调参、观察中间结果的场景每调一次prompt就要改代码再跑全流程效率太低了。换成dify之后体感上的差距非常明显。核心好处有三个。第一是工作流可视化。dify里可以用拖拽的方式把上面的五段链路搭出来每个节点单独调试输出结果直接在界面上看到。我在调“根因假设生成”这一步的时候把参数从temperature0.8调低到0.3前后的输出对比直接悬停在节点卡片上就能看到不用像LangChain那样每次print一堆日志。第二是知识库和引用机制是内置的。hindsight的第四段迭代需要用到历史复盘知识dify的知识库功能对中文长文档的分块、召回策略都做了优化还能在最终的回复里高亮引用来源。这对复盘结果的可信度帮助很大团队成员能看到哪句话是从哪份历史文档里带出来的。第三是API接入成本极低。hindsight的数据来源不只是对话还有监控系统的webhook、工单系统的回调这些在dify里都可以通过“接口触发”的方式直接进工作流不需要我额外写一个服务层。2.3 这个概念能扩展到哪些场景hindsight的方法论不限于技术故障复盘。我后来试过几类场景都跑得通客服客诉复盘把用户反馈、客服聊天记录、处理工单串起来找出服务流程中的系统性缺口。销售丢单复盘把客户沟通记录、跟进动作、价格方案汇总分析丢单究竟输在哪个环节。个人工作效率复盘把本周的待办清单、耗时统计、会议记录丢进去让模型帮忙找时间和注意力黑洞。代码评审复盘把PR讨论、review评论、修改记录喂进去识别团队评审流程里的无效环节。这些场景的共同点是历史数据都有但结构是乱的复盘需求都真实存在但没有人愿意每周花两小时去翻记录。hindsight把这两头直接对接上一句话就能生成一份相当完整的复盘初稿。3. 技术选型与基础环境我踩过的部署坑前面聊的是思路接下来落地。这一节先解决“跑起来”的问题把hindsight做成dify里一个能直接用的工作流。3.1 dify部署方式选择dify有两种常用的部署方式SaaS云端版和Docker Compose自托管版。我一开始图省事想直接用云端版后来发现如果要接入企业内部的知识库和监控告警还是自托管更合适尤其是在数据安全要求比较严的团队自托管几乎是唯一选择。自托管的具体操作我在自己机器上过了一遍记录下来供参考# 拉取dify官方docker编排文件 git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env # 按需修改.env里的配置把SECRET_KEY替换成自己的随机字符串 # 我习惯用openssl rand -base64 36生成一个 # 启动服务 docker compose up -d这里有个我踩过的小坑如果服务器内存不足8Gdocker compose起来之后会有几个容器反复重启。我一开始只给它分配了4G内存结果weaviate和api容器一直处于健康检查失败的状态。后来改到12G之后整个服务在几分钟内就稳定了。如果是个人学习用建议至少保证6G可用内存。启动起来之后打开浏览器访问服务器的IP加80端口用管理员账号登录第一步先在“设置—模型供应商”里配置好模型。hindsight的复盘任务对模型的推理能力要求比对话场景高很多我实测过几款主流模型效果从好到差大概是强推理模型通用大模型轻量模型。轻量模型生成的复盘结论经常停留在“需要加强沟通”“优化流程”这种正确的废话上完全没有复盘价值。3.2 模型与Embedding的配置心得hindsight项目里我会用两类模型一类是负责生成的高阶模型跑复盘正文另一类是负责文本向量化的embedding模型跑知识库检索。生成模型我选了推理能力强、上下文窗口大的一款不要只看综合榜单重点是看长文本理解和多跳推理能力。复盘材料经常包含几百条事件记录模型要在这些零散记录里找出隐含的因果关系没有多跳推理功底很难做好。embedding模型我选的是中文效果稳健的bge系列。知识库里存的全是中文复盘文档用通用英文embedding模型的话召回率会明显下降测出来的top3命中率比bge低了一截。如果打算正式投入生产建议把这两个配置单独抽出来。dify支持为不同应用设置不同的模型知识库检索用的embedding模型和工作流生成用的模型可以各自独立这样调参的时候不会互相干扰。3.3 目录、账号和数据源规划动手搭工作流之前先规划好dify里的资源结构不然后面会乱成一锅粥。按我的习惯分成三层一个“hindsight知识库”专门存历史复盘文档。一个“hindsight工作流”承载五段式复盘链路。一个“hindsight应用”对外暴露API供外部系统调用。账号体系上我用管理员账号创建了知识库同时给团队成员开了操作员权限。这里建议不要用管理员账号跑日常调用不然权限边界会很模糊尤其是将来要接企业微信、飞书机器人回调的时候单独建一个API专用的服务账号更稳妥。数据源规划方面我第一版先把ChatGPT导出的对话记录、企业微信的聊天记录备份、监控平台的告警历史当成三个核心数据源后面再加了GitLab的issue导出。每个数据源都需要做一层轻量清洗后面章节我会详细展开。4. 核心实操搭建hindsight复盘工作流环境准备好之后开始搭hindsight本体。这一节是整个项目操作密度最高的地方我会按实际搭建的顺序一步步写。4.1 准备知识库清洗历史复盘文档知识库是hindsight的长期记忆体。我第一批喂进去的是过去半年团队的所有复盘文档大约四十多份格式有md、docx、以及从wiki导出的html。dify自带文档解析能力但直接塞进去效果很一般原因在于原始文档里大量“会议纪要”“主观吐槽”和“结论”混在一起模型分不清哪些是有效经验。我提前做了一遍清洗手法很机械但效果立竿见影转成统一markdown格式去掉页眉页脚、目录、水印。把每个复盘按“背景—经过—根因—行动项”四个区块物理拆开。在文档头部加一段YAML元信息标注项目名称、日期、故障等级、涉及模块。--- project: order_service date: 2024-11-06 severity: P1 module: payment --- # 订单服务雪崩复盘 ## 背景 双十一大促流量为日常12倍支付网关依赖单点超时... ## 经过 ... ## 根因 ...清洗完之后把这些文档传进dify知识库分段方式我选的是“自定义分段”分隔符用\n\n##最大分段长度设800重叠区间设50。这套参数对复盘文档这种有明确小节标题的文本效果最好比默认的自动分段召回精度高不少。4.2 设计事件统一的输入格式hindsight工作流的入口是一段原始素材。为了让后续节点好处理我先在入口节点做了一次“事件抽取”把自然语言转成结构化JSON数组。如果你是在dify的工作流里做可以在开始节点定义一个input_text变量然后接一个大模型节点prompt如下你是hindsight事件抽取引擎。请从用户提供的原始素材中抽取所有事件输出JSON数组。 每个事件必须包含 - timestamp: ISO格式的时间戳无法判断则为null - actor: 动作发出者人/系统/外部依赖 - action: 具体动作描述尽量简要 - target: 动作的承受对象 - source: 这条信息的原始来源 - severity: 影响程度取值为[low, medium, high, critical] 要求 1. 只输出JSON数组不要输出额外说明。 2. 如果原文含明显猜测、传言在action前加[疑问]前缀。 3. 不要合并事件一个动作记录一条。这一步是整个hindsight的精髓也是我踩坑最多的地方。刚开始的版本没做事件抽取直接把原始文本丢给后面的分析节点结果模型经常被原文里冗长的口水话带偏。抽成事件JSON之后喂给后续节点的信息密度高了很多生成质量立刻上一个台阶。4.3 时间线重建节点的实现事件抽取完成之后进入时间线重建。这个节点做的事不是单纯排序而是找“转折点”。我用一个LLM节点专门做这件事输入是事件JSON数组输出是结构化时间线你是一名复盘分析师。给定以下事件列表请按时间顺序重建完整过程并识别出其中的关键节点。 输出格式为markdown表格列名是时间、事件描述、关键判断。 其中“关键判断”列专门标注 - DECISION人为决策点 - ANOMALY异常信号出现 - ESCALATE升级/告警触发 - FAILURE系统或人失败的点 - RECOVERY恢复点 请特别注意时间顺序中断、出现疑似因果关联的事件、以及“当时没有引起重视”的异常信号。输出示例时间事件描述关键判断14:02:11支付网关超时率开始超过1%ANOMALY14:05:33小A在群里问是否有支付报障DECISION14:12:47告警平台触发P2级别告警ESCALATE14:43:12订单服务线程池耗尽FAILURE15:20:00网关流量切换至备份通道RECOVERY时间线节点跑完之后建议先在调试面板里人工看一眼识别结果这个环节质量有问题的话后面全崩。4.4 影响面计算与根因假设生成影响面节点和根因假设节点是hindsight里两个分开的LLM节点但在业务上关系密切。我把影响面定义成三个维度用户影响多少人受影响、系统影响多少接口/服务/数据堆积、业务影响哪些核心指标出现异常。让模型逐维度打分并从事件里找依据基于上面的时间线评估本次事件的影响面。输出JSON { user_impact: {level: 高/中/低, evidence: [...], detail: ...}, system_impact: {level: 高/中/低, evidence: [...], detail: ...}, business_impact: {level: 高/中/低, evidence: [...], detail: ...} } 要求每个level都必须有evidence字段支撑不写无依据的定性结论。根因假设生成我用了dify的条件分支节点先让模型产出三个假设然后分别给每个假设找支持证据和反对证据。这一步是为了治“推理急刹车”把结论的形成过程暴露出来也方便人审的时候看出模型是不是在瞎猜。这个提示词可以供参考基于时间线事件给出本次事件的前三个候选根因假设。 对每个假设分别列出 - SUPPORT事件支持该假设的事件证据 - REFUTE事件反对该假设的事件证据 - VERIFY_STEP要验证该假设还需要哪些数据 - LIKELIHOOD可能性评分1-10 注意任何假设都必须有至少一条SUPPORT事件如果没有就删掉换一个新假设。三个假设之间不一定互相排斥我也遇到过模型给出来的三个假设说的是同一件事我会在prompt里加一句“假设之间必须有显著差异互为补充或竞争关系”生成质量会好很多。4.5 行动项生成与知识沉淀最后一段链路是把结论变成行动项同时沉淀知识。行动项必须带三样东西负责人、截止时间、验收标准。不然复盘报告发出去三天之后没人记得要干嘛。基于根因分析结论生成不超过5条行动项。每条行动项必须包含 - action: 要做什么动词开头 - owner: 负责人用占位符人名可留空 - due: 截止日期若没有明确日期则标记TBD - acceptance: 可验证的验收标准 - prevented_recurrence: 执行这条行动项的具体理由必须能明确指出它打断了根因链条的哪一环 请用markdown表格输出。行动项生成之后我再额外做一步让模型把本次复盘压成200字以内的“经验教训”然后写入知识库。在dify里这个可以通过HTTP请求节点调用知识库的创建文档接口也可以在导出后人工上传。我第一版是人工上传后来改成自动入库之后整个hindsight才真正跑通了“复盘—沉淀—复用”的闭环。5. 真实案例用hindsight复盘一次线上支付超时事故理论说了这么多放一段实际的运行记录更有说服力。有一天我把一段线上故障的群聊记录和监控告警摘要丢进hindsight原素材大概两千五百字乱糟糟的有闲聊、有告警、有技术讨论。5.1 事件抽取结果模型抽出了17条结构化事件我把几条关键的贴在下面[ {timestamp:2024-11-06T14:02:1108:00,actor:pay_gateway,action:超时率超过1%持续3分钟,target:payment,source:monitor_alarm,severity:medium}, {timestamp:2024-11-06T14:05:3308:00,actor:xiaoa,action:在运维群问大家有没有支付报障无人回复,target:team_group,source:chat_record,severity:low}, {timestamp:2024-11-06T14:21:4808:00,actor:pay_gateway,action:批量订单支付失败,target:trade_service,source:monitor_alarm,severity:critical} ]我特别注意到中间那条“小A问了一句无人回复”——原文里看起来像废话但抽成事件之后就很刺眼了从14:02出现异常信号到14:21开始大面积失败中间隔了19分钟没有任何人跟进。这其实就是复盘里最典型的“沉默期”。5.2 时间线与根因分析结果时间线重建比较顺利把整个故障分成了四个阶段信号出现期、沉默期、故障爆发期、恢复期。模型识别出的关键节点里最扎眼的两个一个是14:05的DECISION小A问询但未升级另一个是14:15的ANOMALY监控看板出现5xx比例爬坡曲线但无人盯屏。根因假设给出来三条告警阈值设置不合理单一超时率阈值过低触发了告警但被当成例行波动未引起重视SUPPORT证据是14:02的告警和后续无响应的对照。值班盯屏机制缺位故障爆发前监控看板已有明显爬坡但无人发现SUPPORT证据是14:15看板异常没人关注以及群里问询无人回复。网关线程池配置过小流量抬升后排队的请求打满线程池导致单点超时扩散成雪崩SUPPORT证据是进程线程池满的事件记录。三条假设里第一条和第二条其实高度相关都指向“人没有响应”第三条属于技术层面的次生因素。模型给第一条打了8分第二条打了7分第三条打了6分。这个判断跟我手动分析的结果基本一致很有参考价值。5.3 行动项落地的效果hindsight最后生成的行动项我挑两条来说行动项负责人截止时间验收标准调整支付网关超时率告警级别改为分级告警P2级以上必须电话确认小A11月10日在高流量时段触发时5分钟内收到升级通知建立监控看板值班制度明确盯屏时段和异常上报路径团队B11月12日下一轮大促期间任一异常信号15分钟内有人响应第一周执行完这些行动项后又跑了一次压力模拟同样流量下从异常信号出现到有人响应的时间从19分钟压缩到了6分钟。虽然这是叠加了流程优化和技术调整的结果但hindsight至少用一个多小时就给出了这份原本要花一下午才能整理的复盘初稿省下来的时间足够让团队专注在真正需要人工判断的地方。6. 使用过程中踩过的坑与排查思路讲了一堆顺利的情况其实项目推进过程中的问题一点都不少。我按自己踩到的顺序整理成一份问题记录每一条都是从真实操作里捞出来的。6.1 知识库召回为空或命中率低一开始hindsight生成的复盘经常“忘记”历史经验查了一下日志发现知识库召回结果为空。问题出在分段策略上。dify默认按固定字符数切分复盘文档里的小节标题都被切得七零八落embedding的时候找不到完整语义。排查思路就一句话先看召回日志再调分段策略最后换embedding模型。我可以分享一个诀窍在dify知识库的检索调试页面输入一个历史复盘里典型的“一句话经验”看top5返回的文档片段是否和这句话语义相近。如果不相近就把分段重叠区间调大或者在文档里为每段经验单独加一个小标题。还有一种情况是模型中文理解弱直接替换成bge系列embedding模型就行实测召回率能提升两成以上。6.2 上下文窗口不够用复盘材料一大时间一到二十分钟的故障素材可能就有三四千字加上事件抽取后的JSON、时间线表格、根因分析很容易把上下文窗口塞满。尤其是用非长上下文模型的时候到后面模型会开始“选择性遗忘”输出的结论质量断崖式下跌。我的解决方案是把长流程拆成两个工作流第一个工作流负责事件抽取和时间线重建输出结果保存为临时文件或写到中间变量第二个工作流只接收结构化结果再从知识库里检索历史经验最后生成复盘结论。这样每个工作流的输入都控制在模型能承受的范围内效果比硬塞上下文好很多。dify支持工作流之间通过API调用拆开之后还能各自独立调试、复用后面维护也轻松。6.3 模型生成“正确废话”复盘报告里最烦的话就是“加强沟通”“提升稳定性”“完善流程”。我在早期版本里收到过大量这种结论表面上看条理清楚实际执行价值为零。我在提示词里加了一条硬约束最终行动项禁止出现“加强”“提升”“完善”等无法量化的动词 每条行动项必须包含可观测的验收指标如果该步骤无法被一个机器人执行或检验说明它还不够具体需要改写。加了这个约束之后模型出来的行动项明显实在多了。另外我还在生成结论之后加了一个“批判自检节点”让模型用另一个视角审视自己刚才输出专门挑“空泛结论”的刺如果有不合格的就重新生成一遍。这个方法在我实测中能把结论质量拉高一截。6.4 dify工作流节点超时有一次接入了大批量历史数据dify的接口触发节点频繁超时。排查了一圈发现不是dify的问题而是我在开始节点里一次性塞入了整年的聊天记录LLM节点处理太慢。改法是把大批量数据拆成小批次每次调用只处理单周数据再把各批次结果合并。这样每个节点都在稳定耗时范围内超时问题彻底消失。做数据接入的时候建议提前设计好批次边界别等出问题了再拆。6.5 Agent调用工具混乱我还试过用dify的Agent模式做hindsight结果Agent在工作流里自由发挥一会调知识库一会调代码执行器节奏完全不可控。后面我把方案改成了纯工作流模式把大模型节点和工具节点的调用顺序固定死Agent的自由度只保留在节点内部的prompt里。复盘这种场景要的是确定性不是创造力这个取舍我在后文还会再聊一次。7. 效果评估怎么判断复盘做得好不好很多团队做完复盘评价方式就是“大家觉得行不行”这个标准太主观了。hindsight上线之后我设计了一套五个维度的评估量表每次跑完复盘先自测一遍再和人工评的对比校准。维度评估问题评分标准1-5事实准确性时间线、事件描述是否与原始记录一致5无不实细节事件能逐一溯源归因逻辑根因假设是否由证据支撑是否有逻辑跳变5每个假设都有独立事件链支撑行动项质量行动项是否具体、可执行、可验收5可以直接下发执行并跟踪验收经验价值结论是否能沉淀为复用经验避免同类问题5抽取出的经验不依赖特定场景也成立人本尺度复盘是否避免人身攻击和氛围甩锅5责任归因都在流程/机制可改动的范围内我拿一套历史复盘数据跑了一轮hindsight在事实准确性上得分是最高的因为事件抽取阶段做了结构化基本不会像人一样选择性记忆归因逻辑和行动项质量稍弱是人工修改最集中的地方经验价值一开始偏低后来知识库越喂越多这个维度分明显往上涨。这里也和纯人工复盘做个对比人工复盘的优势对隐性知识判断准了解团队历史能体会一些没写在文档里的上下文。人工复盘的劣势耗时、容易漏细节、归因时可能情绪化。hindsight的优势全量信息覆盖、复盘速度快、输出结构稳定、不会情绪化。hindsight的劣势对上下文理解依赖知识库质量遇到全新场景容易给出泛泛结论。我最终的做法是让人和系统叠着用hindsight先跑第一版完整复盘人工角色在它输出的框架下面改改补补。效率提升非常明显这一块我认为是复盘类工具最健康的落地姿势让人做判断题、让系统做信息梳理题而不是让系统替人做判断。8. 我实际操作下来的一些体会项目做到这个阶段回头看hindsight已经不只是一个dify工作流了它更像是一套帮助团队持续变强的机制。这里我聊点个人体会。第一复盘的瓶颈永远不在工具而在“愿不愿意面对事实”。hindsight能帮你把事实摊开能帮你快速生成假设但它替你做不了“承认自己当时判断有误”这一步。我用的办法是给复盘定一个基调不许谈对错只许谈“下一次能怎么改”凡是不指向下一次改进的话都删掉hindsight的prompt我也按照这个基调去设计反馈下来团队接受度明显高很多。第二结构化是复盘工具的灵魂。没有结构化大模型拿到几千字聊天记录就是一团浆糊结构化之后模型才能尽可能做到稳定输出。dify的工作流天然适合把“结构化”固化下来我甚至觉得这是它比纯Agent模式更适合复盘场景的根本原因。Agent模式适合探索性强、路径不确定的任务复盘恰恰是路径相对固定、更需要稳定输出的任务。第三知识库的质量决定了hindsight的天花板。一个复盘工具如果记忆体里全是空泛的总结它生成的建议只会更空泛。我会每隔两周回头检查知识库里的文档删掉那些没有行动项支撑的“总结”保证每条沉淀下来的经验都有对应的场景和验证办法。这个动作很重要却常常被忽略。最后这个项目后续扩展空间还挺大的。我目前在考虑加一步“趋势复盘”把每月复盘结果再汇总找出组织层面反复出现的模式还打算把它的输入从文本扩展到工单系统、监控平台的自动触发让复盘不必等到人想起来才做而是每次异常结束就自动生成一次。如果你正在做类似的事我特别建议你先把事件抽取和时间线这两步打磨扎实这两块是整个hindsight的地基地基扎稳了上面想怎么盖楼都可以。