FDE 项目怎么复盘？把一次客户交付沉淀成可复用的企业 AI 能力

项目复盘的目的，是让下一次交付有更好的起点。它不只是总结亮点，也不应成为追责会议。需要辨认哪些判断成立、哪些条件被忽略，以及哪些成果可以在明确权限下复用。

先回到原先的业务假设

对照立项时的任务、基线和预期，检查用户是否实际使用、完整处理时间是否变化、质量和维护成本是否可接受。若目标中途改变，应说明原因，不把不同范围的结果直接比较。

报告分清已证实、初步观察和未验证。小样本试点不能证明长期全部收益；如果只完成技术验证，也应如实记录，不能为了项目故事把它改写为全面转型成功。

从三个维度看问题

同一个失败可能涉及多个维度。资料准备不足导致开发延期，不应被简单归为工程慢；技术实现复杂，也不自动说明客户需求不合理。将事实与判断分开，有利于确定真正的改进。

四类资产分别处理

客户数据与专属规则、客户约定获得的成果、服务方已有通用组件、新产生的可复用方法，需要分别确认归属与使用范围。脱敏不自动等于可以跨客户使用。

能沉淀的内容可能包括接口设计经验、测试类型、错误排查顺序和估算方法，而不是原客户文件。将可复用部分提炼成独立模板后，还需验证它不依赖未公开材料。

失败样例怎样进入知识库

记录任务类型、触发条件、错误表现、根因、修复和复测，不必保留所有原始敏感文本。缺少依据的问题形成拒答样例，重复动作形成工具测试，资料冲突形成版本检查。

同时保留正常任务，避免修复一个问题后让系统对所有请求都拒答。测试集应反映代表工作，而不是只积累越来越偏的极端案例。

让改进有负责人和完成条件

复盘会应产生有限数量的优先事项。每项写明谁推进、何时验证、完成后改变什么。没有负责人和检查时间的建议，容易成为下一次会议再次出现的问题。

对于范围、估算和沟通失误，更新项目模板；对于反复技术缺陷，更新组件和测试；对于资料责任不清，调整客户准备要求。不同原因需要进入不同资产，而不是统一写“加强沟通”。

如何支持后续报价与交付

整理实际投入、依赖等待、返工和支持时间，使下一次估算更有依据。按任务和条件比较，不把一个顺利项目当成所有场景的标准工期。

复用还要计算适配和维护成本。共享组件只有在稳定边界、文档和责任明确时，才可能降低长期负担。复制代码而无人维护，可能只是在多个客户中复制缺陷。

什么时候适合公开成案例

取得相关授权，并确认客户名称、数据、指标口径和材料范围。未获授权时可以发布独立的通用方法或合成演示，但必须与真实客户案例区分。

对珞瑜来说，项目负责人应推动复盘，工程与领域顾问共同参与。经验最终要进入顾问质量机制与持续运营，才能形成一致的交付能力。