复盘这事儿，核心应该是推动系统改进，而不是找人背锅。所以，一份好的复盘报告，需要把边界划清楚，用事实链条代替责任链条，把问题归因到流程、工具、协作这些系统层面的漏洞上，最后再配上能落到实处的SMART行动项。 先亮明一个核心观点：项目延期之后，最急需的是一份能让技术负责人愿意看、产品经理能执行、开发同学不反感的复盘报告。它的核心任务是把“为什么没按时交付”，转化成“下次怎么才能稳准快地落地”。 **复盘边界得先划清楚，哪些必须谈、哪些坚决不碰** 第一步，列清单。把这次延期涉及的具体交付物全部摆出来，比如大模型API接口v1.2、推理服务压测报告、客户联调文档这些。注意，只限已经写入合同或者PRD的条目。那些没有经过立项流程的需求变更、口头承诺的额外功能，一律不纳入复盘范围。 第二步，卡时间。复盘的时间窗口只锁定从需求评审通过那天，到原定上线日之间的执行过程。上线之后才发生的故障、客户临时加急的需求，一概不追溯。 第三步，定人。复盘参与人只包括实际承担关键路径任务的5个人：算法组长、后端主程、测试负责人、PM，还有交付接口人。市场、HR、法务这些角色就别来参会了，避免议题跑偏。 **用“事实链”代替“责任链”，重新描述问题** 第一个方法，按时间轴还原关键节点偏差。把每一个延迟环节都写成“客观动作 + 可验证数据”。举个例子：“7月12日，模型量化耗时32小时（预估16小时），原因是FP16转INT8时，3个算子没有对应的CUDA kernel，需要手动重写；7月15日，压测QPS卡在1200（目标3000），查出是GPU显存泄漏，根源在于TensorRT缓存没有释放。” 第二个方法，用对比表格呈现计划与实际。左边一列写“计划动作”，右边一列写“实际发生”，中间一列写“差异根源”——注意，这里写的是机制缺陷，不是人名。比如：“计划：7月5日前完成模型蒸馏→实际：7月10日完成→差异根源：蒸馏框架不支持动态batch size，需要等待开源社区补丁合并。” 第三个方法，让数据自己说话。把Jira任务关闭时间分布图、Git commit频次热力图、CI失败日志关键词统计表直接贴出来。图标题要写清楚“非结论性描述”，比如“7月第2周CI失败中，‘CUDA OOM’出现频次占总失败数67%”。 **归因要聚焦系统漏洞，避开人性判断** 把所有原因都按“流程层—工具层—协作层”来分类，每类只保留1到2个最高优先级的问题。比如流程层的问题可能是：“需求评审会没有强制要求算法组提供量化可行性评估报告。”工具层的问题可能是：“现有CI环境缺少GPU显存监控探针。”协作层的问题可能是：“算法与后端每日站会没有同步模型输入/输出tensor shape的变更。” 对每一个归因点，都必须附带可验证的改进行动项。比如针对“CI缺少GPU显存监控”这个问题，行动项可以写：“8月15日前，在Jenkins Pipeline中集成nvidia-smi -q -d MEMORY输出解析脚本，内存占用超过85%时自动中断构建，并推送企业微信告警。” 记住，像“沟通不畅”“责任心不足”“重视不够”这些根本无法落地的话，坚决不要出现。 **行动项必须满足SMART原则，责任人当场认领** 第一步，每个行动项都要用“动词 + 宾语 + 验收标准 + 截止日”这个结构来写。比如：“搭建模型量化兼容性检查清单（包含12个主流算子支持状态），由算法组长在8月8日前提交至Confluence，PM确认清单覆盖全部当前项目模型。” 第二步，责任人要现场口头确认。PM逐条朗读行动项，被指派人用“我负责，8月X日前完成”来回应。会议记录员实时录入飞书多维表格。 第三步，设置唯一的追踪入口。新建一个飞书多维表格，叫《阶跃AI复盘行动追踪》，字段包含“行动项原文”“责任人”“承诺完成日”“实际完成日”“验证人”，权限设为全员可看不可改。 这才是复盘的真谛。它不是审判，而是下一次成功的路线图。