# AIelsen FDE Academy · W11 交付复盘与产品化沉淀

面向 FDE 的中文详细讲义 · v2 · 2026-09-08

## 1. 复盘的对象是决策与机制，不只是项目故事

项目完成后，最常见的复盘是列出做了多少功能、开了多少会议、解决多少问题。这些可以描述工作量，却不能说明下一次如何更好地交付。FDE 复盘应连接原始目标、当时证据、所作决定、实际结果和后续动作。

本周把 12 周材料分为客户专属资产、行业模板和产品通用改进，并验证迁移条件。复用不等于复制客户代码，更不等于把客户数据和策略改个名字后公开。

## 2. 五步复盘如何落到可检查的记录

先回到最初目标，避免用最终做成的事情倒过来修改目标；再按相同口径评估结果，区分已达、部分达到、未达和未验证；接着分析原因，查阅当时的证据与决定，不用事后全知视角责备个人；然后总结适用条件；最后形成具体改进动作。

| 步骤 | 应问的问题 | 应留下的记录 |
|---|---|---|
| 回看目标 | 为什么选这个切入点，哪些范围没做？ | 原始判断书与范围版本 |
| 核对结果 | 系统、采用、业务各证明了什么？ | 验收证据与未达项 |
| 解释原因 | 哪个假设错了，什么时候可以发现？ | 决策时间线与反例 |
| 提炼方法 | 在什么条件下值得复用？ | 方法说明与不适用边界 |
| 安排改进 | 谁修改哪项产物，如何检验？ | 责任、日期、测试与复查 |

一次有效复盘应能指出至少一个“当时合理但后来证伪”的判断。不是所有失败都来自疏忽，也不是所有成功都可归因于方案本身。保留不确定性，比写“加强沟通、持续优化”更有用。

## 3. 六类常见失败模式

以下是本课用于自检的失败模式，不是来自客户数量统计。每一类都要能对应早期信号和可执行修正。

| 失败模式 | 早期信号 | 修正动作 |
|---|---|---|
| 问题未定义就开发 | 目标只有“上 AI”，无实际任务 | 回放一次真实操作并冻结切入点 |
| 数据与语义被当作现成条件 | 同指标多套数字、身份无法解释 | 建立契约、对账和异常队列 |
| 演示通过替代评估 | 只有挑选过的成功样本 | 加入边界、对抗和留出任务 |
| 动作能力超过授权与运行准备 | 只有成功状态，没有未知与回查 | 限制动作，补确认、幂等和对账 |
| 系统交付但工作方式未改变 | 登录不少，仍手工重复操作 | 观察拒绝原因并调整工作嵌入 |
| 每个客户重新定制 | 客户 ID 写入核心，升级经常破坏 | 隔离租户扩展，检验通用接口 |

不要把这张表当作万能诊断。若项目失败来自采购取消、组织调整或外部政策变化，也应如实记录。能控制、能影响和只能观察的因素，要分别处理。

## 4. 资产分层：哪些能带到下一项交付

客户专属资产包含真实数据、内部策略、合同、权限映射和特定系统秘密，默认不进入公共模板。行业模板可以包含去掉客户身份后的对象模式、指标结构、任务与评估样例，但仍需检查权利与再识别风险。产品通用改进则是跨客户成立的能力，例如参数绑定确认、租户级工具策略或可扩展审计字段。

| 本项目产物 | 可能归属 | 复用前必须处理 |
|---|---|---|
| CRM 字段映射与真实会员 ID | 客户专属 | 留在受控项目，不放入公开包 |
| 会员/订单/活动对象结构 | 行业模板候选 | 参数化、合成示例、业务条件说明 |
| 发券金额与资格策略 | 通常客户专属或领域配置 | 不将私有经营策略宣称通用最优 |
| 确认与参数摘要绑定接口 | 产品改进候选 | 第二场景验证、兼容性与回归 |
| 审计字段扩展点 | 产品改进候选 | 删除身份信息，定义稳定契约 |
| 第三方 Skill | 依其许可与来源 | 保留出处、许可和修改说明 |

“匿名化”不是只删客户名字。结合行业、时间、门店规模和特定事故，仍可能识别客户。公开教材应使用独立合成数据和改编问题，不复现私有策略或内部组织细节。

## 5. 产品反馈要比“客户需要这个功能”更具体

一份可处理的产品反馈包括：原始问题、现有能力、复现步骤、影响范围、临时适配、候选通用接口、兼容风险和测试。第 8 周的确认绑定与第 9 周的客户审计字段，可以作为本课候选反馈。

```text
问题：确认状态只能表示 yes/no，无法绑定版本化动作参数。
现场影响：用户确认后人群或金额变化，执行端无法可靠检测。
租户适配：在客户扩展层保存 payload digest 与有效期。
通用提案：核心提供 confirmation record + validate hook。
兼容要求：现有只读工具不受影响；默认写动作仍需明确策略。
回归样本：改金额、换人群、过期、重放、跨租户、权限撤销。
```

出现第二个场景后再检验抽象：同一个接口能否用于标签、设备调度或文档发布？如果不得不加入大量零售专属字段，就可能还只是行业适配，而非稳定产品能力。

## 6. 私有知识如何转成团队知识

拒绝理由、争议记录和失败样本往往比“客户同意了”更有复用价值。记录“为什么这次不用向量检索”“为什么没有自动执行”“为什么撤回某个指标”，可以帮助下一位 FDE 避免重复试错。

建议知识条目包含：问题、上下文、曾尝试方案、选择理由、失败条件、证据位置、适用范围和维护者。敏感原始证据仍留在原有权限范围内，公共方法可以只引用受控记录 ID。不要把所有聊天记录直接复制到全员知识库。

## 7. 从零售迁移到其他行业

迁移到销售研究时，Member 可能变成 Account/Contact，活动建议变成带证据的客户研究与下一步行动；身份、来源时效、工具权限与结果评估仍可复用，但“30 天复购”和发券规则不能直接迁移。知识服务需要产品型号、文档版本和专业边界；供应链需要事件时序、资源约束和调度后果。

金融和医疗等场景还需要更严格的专业责任、数据与合规审查，不因本课在零售沙盘中通过测试就获得部署资格。迁移分析应写清可直接复用、需重配、需重做和不能承诺四类内容。

可将 [Airbus 案例](/academy/zh/cases/airbus/)与 [Morgan Stanley 案例](/academy/zh/cases/morgan/)按进场、需求、原型、变更、验收、沉淀六栏阅读。公开资料未披露某一栏时写“未披露”，不要为了填满图表编造实施细节。

## 8. 必做作业、思考与验收

**必做**：提交完整复盘、资产分层清单、两个产品反馈候选和一个跨行业迁移分析；准备答辩证据索引。至少有一项反馈包含复现步骤与回归测试，至少有一项资产被明确判定不应公开或不值得通用化。

**思考**：如果下一客户恰好提出一个看似类似、但权限和动作后果完全不同的需求，你如何判断复用是否真的减少成本，而不是把风险一起复制？

**进阶**：写一份面向新 FDE 的工程复盘，围绕具体错误、识别信号和修正方法，不披露客户身份，不用成功故事代替证据。

**验收要求**：复盘包含未达与反例；资产权利和敏感性已检查；模板有适用条件；产品提案可复现；迁移说明有不能复用的部分；改进动作有责任与验证方式。下一项目应能实际使用这些产物，而不只是阅读一段总结。