用 DeepSeek 做工作复盘与问题归因：从复述经过到找到根因

工作出了问题，很多复盘会从“当时发生了什么”开始，最后又回到“以后注意一点”。这样的记录看似完整，却很难改变下一次的做法。复盘真正要回答的是：结果和预期差在哪里，差距为什么出现，哪些因素可以被改变，接下来谁在什么时间做什么动作。

清华大学关于 DeepSeek 职场应用的资料反复强调任务拆分、材料准备、场景复用和持续优化。用在复盘上，就是先把聊天式的回忆整理成事实材料，再让模型帮助分类和追问，最后由团队确认根因与行动。DeepSeek 可以提高整理速度，但不能替团队替换责任判断。

复盘材料最好包括目标、计划、实际结果、关键时间点、相关数据、已采取措施和未解决问题。资料不足时，要求模型明确列出缺口，不要让它根据常见经验补出一个听起来合理的原因。

复盘一开始就追问“是谁的问题”，很容易让参与者进入防御状态，也会让真正的流程缺陷被个人解释遮住。可以先让 DeepSeek 按时间顺序整理事件：原定动作是什么，实际动作是什么，哪个节点出现偏差，偏差当时是否被发现，之后采取了什么处理。

事实清单要把数据和观点分开。例如“周三下午交付”是时间事实，“客户因此不满意”可能是反馈或判断，“因为某同事疏忽所以延期”则是待验证的归因。让模型为每条内容标记事实、当事人描述、外部反馈和待核验判断，复盘会议会更容易围绕证据展开。

也要记录没有发生的事情。例如原本应该有审批，但没有留下审批记录；原本应该在正式使用前做回归测试，但测试清单没有覆盖该场景。缺失的动作本身也是事实，不能只记录已经发生的错误。

“项目延期”是结果或现象，不是根因；“需求变更很多”是影响因素，也还不够具体。更好的问题是：哪些需求在什么时间变更，变更是否经过确认，变更后有没有重新估算，哪个环节没有吸收这些变化。根因分析要把模糊的抱怨推进到可以验证的描述。

可以让 DeepSeek 对每个问题输出四列：现象、直接原因、深层原因、需要验证的证据。比如测试缺陷进入线上，直接原因可能是回归用例遗漏，深层原因可能是需求没有形成可测试的验收标准，证据则包括需求版本、测试清单和发布记录。

每个根因都要满足一个条件：它能指导新的行动。如果结论只是“沟通不够”“重视程度不足”，团队很难据此改变流程。可以继续追问：什么信息没有被同步，应该由谁在什么时候确认，怎样留下可检查的记录。

连续追问“为什么”适合把一个线索往深处推进，但如果只沿着一条线追问，容易漏掉并行原因。一个交付问题可能同时与人员熟悉度、流程标准、工具限制和外部变化有关。可以先用四个维度铺开，再针对证据最充分的方向继续追问。

人员维度关注能力、信息理解、协作和工作负荷；流程维度关注标准、交接、审批和检查点；工具维度关注系统能力、数据质量、权限和使用成本；环境维度关注政策、市场、资源和时间压力。这个分类不是为了把问题放进固定格子，而是提醒团队不要只盯着某个当事人。

让 DeepSeek 输出可能原因时，要同时要求它说明证据、影响范围和验证方法。没有材料支持的内容应标记为假设，不能因为模型说得流畅就当成最终结论。

复盘结论的价值，最后要落在行动上。每项行动应写清楚要改变什么、由谁负责、何时完成、如何验收，以及没有达到目标时怎么升级。比如“加强沟通”太抽象，可以改成“从下个迭代开始，需求变更必须在任务看板中记录影响范围，由产品负责人在开发开始前确认”。

DeepSeek 可以把根因和行动做成对应表，帮助团队检查是否出现“根因说 A，措施却解决 B”的错位。还可以让它为行动补充最小可行版本、潜在阻力和验证指标。最终的负责人和截止时间必须由团队确认，不能由模型替人分配责任。

行动不宜一次列得过多。优先处理影响大、可控性高、可以快速验证的措施。复杂改进可以拆成试运行、观察和扩大范围三步，避免复盘结束后只留下一个没人维护的大项目。

可以这样组织提示语：请基于提供的会议记录、任务记录和数据，先按时间线还原事实；再区分现象、直接原因、深层原因和待验证假设；从人员、流程、工具、环境四个维度检查遗漏；最后输出行动清单，并为每项行动填写负责人、完成时间、验证指标和升级条件。

还要明确要求模型不补造人名、日期、数字和责任结论；无法确定的地方标记为待确认；引用依据时保留原材料编号。这样做会让结果少一点“完整感”，却更适合进入正式复盘。

如果是敏感的绩效或人员问题，应先脱敏，只提供完成分析所需的内容。涉及纪律、合规和责任认定的事项，不应由模型单独生成结论。

复盘会结束后，行动清单要进入日常任务系统或项目看板。下次检查时，不只看动作是否完成，还要看验证指标是否变化。如果动作做了但问题仍然存在，可能是根因判断不准确，也可能是措施没有真正改变关键环节。

可以让 DeepSeek 对比复盘前后的数据、异常记录和反馈，生成“已改善、部分改善、没有改善、无法判断”四类状态。对于无法判断的事项，要求它说明还缺什么数据，而不是强行给出好坏结论。

当某类问题反复出现时，应把复盘结果转成 SOP、检查表或培训材料。这样一次故障才会变成组织经验，而不是每次都重新讨论同一个问题。

复盘任务可以固定为四段：事实材料、问题定义、归因方法、行动与验证。要求模型先整理后判断，并保留原始依据和不确定信息。

输出建议包含：目标与实际结果、关键时间线、问题清单、根因假设、证据缺口、改进动作、负责人、截止时间、验证指标和复盘日期。

复盘的目的不是生成一份措辞严厉的报告，而是让下一次工作少走同样的弯路。模型可以帮助整理和追问，团队仍要负责事实确认、责任判断和行动承诺。