第十一章 复盘与资产沉淀
11.3 资产分层与产品反馈
承前：11.2 节的 F5"定制泥潭"警告过一种结局：项目一个接一个做，代码一遍接一遍重写。破局的钥匙是把项目产出当成"资产"来管理，而不是当成"交付物"来处理。这一节讲 FDE 的资产观：一个项目做完，你手里应该多出三类不同归属的资产——客户的、行业的、产品的；还应该多出一份写给产品团队的反馈，甚至一个补丁说明。最后讲资产分层里最微妙的一条纪律：什么时候该抽象，什么时候不该。
11.3.1 交付物 vs 资产：一字之差，两种职业生涯
先做概念区分。交付物是合同规定要给客户的东西：部署的系统、验收报告、文档。资产是能在未来项目里降低成本、提高成功率的东西：模板、checklist、脱敏后的数据模型、给产品的需求洞察。
两者的关键差异是复用性。交付物的价值在签收那一刻结算完毕；资产的价值在每一次复用时增殖。一个 FDE 做了 20 个项目，如果 20 个项目只留下 20 份验收报告，那他的第 21 个项目和第 1 个项目一样难。如果每个项目沉淀出哪怕两三个可复用资产，第 21 个项目的启动速度可能是第 1 个的三倍——这就是为什么有的前置部署团队能"越打越快"：不是人变聪明了，是脚下的资产层变厚了。
这个思维在行业里最成熟的表达就是 Palantir 模式：前置部署工程师在客户现场做的东西，一部分留在客户环境，一部分回流成产品组件（Gotham/Foundry 的很多模块最初都来自某个客户的现场需求），一部分变成行业模板。Airbus Skywise 就是这条回流管线的代表作——一个航司项目长出来的东西，最终变成服务整个航空业的数据平台（11.5 节展开全程案例）。
11.3.2 三层资产：归属、去向、脱敏纪律
复盘结束后，把《青禾优选项目复盘纪要》里的产出物逐条分类，装入三层：
资产三层图（青禾项目实例）
第 1 层：客户专属资产 第 2 层：行业模板 第 3 层：产品改进
归属：青禾（留在客户环境） 归属：你的公司 归属：产品团队
├─ 会员 ID 双轨映射逻辑 ├─ 零售复购语义层骨架 ├─ W8 确认策略
├─ 门店权限模型 │ （品类参数化） │ → 产品反馈工单
├─ 客户自评表定制版 ├─ 三个部门三个会员数 ├─ W9 审计字段
└─ runbook + 决策记录 │ 的数据诊断 checklist │ 扩展 → 补丁说明
└─ 灰度放量的节奏模板第 1 层：客户专属资产。 那些只有青禾才需要、离开青禾就没有意义的东西——新旧系统双轨会员 ID 的映射逻辑、按门店-区域两级权限的模型。它们留在青禾环境里，随项目移交。你能带走的是方法论：写一份《双轨 ID 治理五步法》的脱敏文档，不含任何青禾真实数据。
第 2 层：行业模板。 跨客户但限零售业的东西。比如语义层骨架：会员/商品/订单/门店四个核心实体的关系结构，在几乎所有会员制零售都成立；差别只在参数——品类复购周期、会员等级规则。所以沉淀动作是参数化：把青禾特定的数值抽成配置项，骨架开源给下一个零售客户直接套用。
第 3 层：产品改进。 只有产品改了才能解决的东西——青禾项目里最典型的两个，正是大纲指定的 W8 与 W9 的扩展：下一小节专讲。
三层各自有脱敏与参数化纪律。写第 2 层资产前跑一遍检查：客户名称、真实数字、内部系统代号、可识别的人名职务全部替换；表格里的数字除以一个系数或换成区间；截图一律重绘成示意图。一个实用标准：把文档发给客户法务审一遍不脸红，才算脱敏合格。这不是道德洁癖——保密条款（NDA）的违约成本是真实的，而且客户知道你连他的数据都保护不好时，也不会相信你保护下家的。
11.3.3 W8 确认策略扩展 → 产品反馈
现在走大纲指定的两条转化链。第一条：W8 的确认策略（验收口径书面确认、变更记录、签字机制）在青禾项目里救了指标漂移，但它当时的形态是你手工维护的一套文档纪律——每份确认单独起草，格式不统一，客户签字走邮件，存档靠你自己的文件夹。
复盘时你意识到：这是所有客户都会踩的坑，每个 FDE 都在重复发明这套机制。于是写了一份产品反馈工单，核心诉求三条：
- 产品内置"验收口径确认"对象：口径定义、版本号、干系人电子签字段产品化，而不是邮件附件；
- 指标变更自动生成对照表：新旧口径、提出人、生效日期，一行一条；
- 确认链与审计日志打通（W9 的 trace 体系）：口径变更可追溯，和数据处理一样可审计。
写工单的技巧：用失败故事开头，不用功能清单开头。第一段写"青禾项目 W7，指标口径在 3 周内变了 2 次而无人有记录，验收时被迫花 1 周重建归因链"——让 PM 一眼看到痛的成本，比"建议增加确认功能模块"有力十倍。第二段给方案，第三段给预估价值（"若产品化，每项目节省 3-5 人天，且消除指标纠纷风险"）。
这条工单如果被采纳，下一个客户项目里确认策略就是产品能力而不是个人纪律——这就是 FDE 对产品的杠杆：你比 PM 更早看到真实战场上什么武器缺弹药。
11.3.4 W9 审计字段扩展 → 补丁说明
第二条转化链更硬核：代码级回流。W9 客户审计时，你为了满足青禾财务经理的字段级追溯要求，在 Agent 底座的日志层打了一个补丁——给每次工具调用记录增加了"数据来源字段+转换规则"两个维度。这个补丁当时是项目内的私活：改了日志 schema、加了 trace 关联、跑通了审计抽查。
复盘分类时你判断：这不属于青禾（任何有审计需求的客户都要），也不属于零售行业模板（金融、医疗的审计需求同样存在），它属于产品。于是动作是把这个补丁整理成正式产出：
- 补丁说明文档：解决什么问题（字段级数据血缘缺失）、改动范围（哪些模块）、向后兼容性（老日志如何处理）、性能影响（日志量增加约 18%，实测）；
- 测试用例：把青禾审计抽查用的三类查询写成通用测试；
- 建议合入路径：是否需要 feature flag、默认开还是默认关。
提交给产品团队后可能有三种结局：合入主线（最好的情况，全公司客户受益）、作为可选插件（次好）、被拒并给出更好的产品级方案（也行——那你的补丁文档变成设计输入）。最坏的是你没提交——补丁死在青禾的环境里，下个客户重新踩一遍。
这条链路有一个行业级的历史注脚：Palantir 与 Airbus 的合作之所以能滚成 Skywise 平台，就是因为早期航司项目里的定制组件持续回流产品化。据 Palantir 投资者关系披露，双方的合作已多次延长并深化——每一次延展背后都是"客户现场需求→产品能力"的循环在转。个人层面的补丁说明，就是这个循环的最小单元。
11.3.5 私有知识转化：拒绝理由比同意更有价值
资产分层讲的是显性产出，这一小节讲私有知识——那些没写进任何文档、只存在于你脑子里和会议记录暗处的东西。
FDE 项目里最有价值的私有知识，往往不是客户同意了什么，而是客户拒绝了什么、质疑了什么。原因很直接：同意的东西进了 SOW、进了交付物，人人可见；拒绝的东西没有正式归档，但它编码着这个客户（以及这类客户）的真实约束和恐惧。举青禾项目里的三个例子：
- 门店店长拒绝"自动执行补货建议"——不是不信任准确率，是KPI 责任在人不在系统，出错要有人担责。这条拒绝揭示了零售一线的组织约束：任何自动化建议必须保留人工确认位，且确认动作要被记录为免责证据。
- 财务经理拒绝了"审计抽看 trace 全量导出"——导出格式对不上他们的合规系统。这条拒绝里藏着金融背景客户的真实审计工作流，后来直接启发了 11.3.4 那个补丁的字段设计。
- 增长副总裁在早期拒绝过"按门店个性化建议"——理由是"总部要保住品牌一致性"。这是一条战略级拒绝：揭示零售连锁总部-门店的权力结构，影响后续所有涉及放权的设计（第 8 章放权路径的分级设计正是从这里长出来的）。
转化方法：建一份《拒绝与质疑档案》，每条记录四栏——被拒绝的提案、拒绝理由（原话尽量保留）、拒绝人角色、由此推断的约束。每季度回看一次：某类拒绝在多个客户重复出现时，它就从"这个客户的怪癖"升级成"这类客户的普遍约束"，也就变成了第 2 层行业资产的输入。同样，方案讨论的会议记录里那些"绕开的路"（讨论了但没走的方案）也是同类资产——它们是你下次面对同类客户时的预判弹药。
一句话概括这一小节：**同意产出交付物，拒绝产出认知。**交付物给客户，认知归你。
11.3.6 第二个样本原则：何时抽象
最后处理分层纪律里最容易被热情冲垮的一条：出现第二个样本再沉淀抽象层。
道理：抽象是有成本的——错误的抽象比没有抽象更贵。你在青禾一个客户身上总结的"零售语义层骨架"，可能混入了青禾特有的假设（比如"会员等级只有三级"）；如果第一个客户就沉淀成强制模板，第二个客户（五级会员、线上为主）会被模板扭曲，你反而要先拆模板再适配。
所以纪律是：
抽象时机决策
样本数 = 1 → 记录为"案例笔记"（含完整上下文与假设清单）
样本数 = 2 → 对比两份笔记，找交集 → 交集部分才进"行业模板"
差异部分参数化 → 配置项 + 默认值说明
样本数 ≥ 3 → 模板升级为"默认路径"，偏离需要书面理由注意这条原则的另一面：它不阻止你在第一个项目时就写笔记——恰恰相反，第一个样本的记录质量决定第二个样本到来时你能不能快速做对比。所以正确理解是"第一个样本做详尽记录、克制抽象；第二个样本出现才提炼共性"。过度抽象（样本 1 就定模板）和过晚抽象（三个样本后还是各写各的）都要避免，前者成本更隐蔽、更常见。
11.3.7 要点总结
- 交付物在签收时结算，资产在每次复用时增殖；FDE 的成长速度取决于脚下的资产层厚度。
- 三层资产：客户专属（留环境、带走方法论）、行业模板（参数化+脱敏）、产品改进（反馈工单或补丁说明）——每份资产写之前先问归属。
- 脱敏合格标准：发给客户法务审一遍不脸红。
- W8 确认策略→产品反馈工单（用失败故事开头），W9 审计字段→补丁说明（含兼容性与测试）——现场需求产品化是 FDE 对产品的核心杠杆。
- 拒绝理由和未走的方案比同意更有价值：建《拒绝与质疑档案》，重复出现的拒绝升级为行业约束。
- 第二个样本原则：样本 1 记笔记不抽象，样本 2 提交集做参数化，样本 3 才成默认路径。
参考资料
- Palantir and Airbus Extend Strategic Collaboration — Palantir 投资者关系公告，现场定制经验产品化为 Skywise 平台并持续扩展的一手披露
- Morgan Stanley uses AI evals to shape the future of financial services — OpenAI 官方披露，客户现场反馈回流产品迭代（evals 驱动）的标杆案例
- Airbus launches Skywise – aviation's open data platform — Skywise 从单航司项目到行业平台的官方发布报道
- What Is Net Revenue Retention (NRR)? — 资产复用与客户留存经济性的量化背景