企业官网建设流程全解析

执行驱动交付（七）：资产复利——为什么每一单都要让下一单更便宜？

执行驱动交付（EDD）：AI 项目交付方法论 · 完结篇 7/8
基于 1 个真实交付项目与内部实战实验实测（2026-08）

📖 摘要：EDD 的终局不是交付流程，是资产复利：每一单结束，客户拿走应用，我们拿走复用资产——skill、黄金集、知识库、部署包。变强的不是模型（LLM 权重固定），是资产库。本文讲跨客户复用的三层沉淀、隔离机制、可运行资产体系（载体/账本/契约/基线）、人机分工（判断在人、执行在 AI），以及 EDD 适合什么、不适合什么。

📌本文要解决的核心痛点

• 项目做完就完，做下一单还是从零开始——经验一点没攒下？
• 客户特定内容（政策/规则/字段）不小心进了通用库，污染下一个项目？
• 沉淀的「资产」没有契约、没有基线，下次根本不敢用？
• 本文讲资产复利：项目是本金，沉淀是利率——每一单都在让下一单更便宜。

场景

两个团队，同样做了 10 个 AI 项目。

团队 A：每个项目从零开始。做完交付，代码留档，经验留在个人脑子里。第 11 个项目来，团队 A 的报价和工时和第 1 个差不多——因为第 1 个和第 11 个之间，没有复用，只有记忆。

团队 B（EDD）：每个项目结束，客户拿走应用，团队拿走复用资产：检索调优结论、企微部署包、黄金集用例、平台 skill。第 11 个项目来，直接复用第 3 个项目的骨架，结合新客户重新实例化——报价可以更低、交付可以更快、质量反而更稳。

差别不在能力，在沉淀率。团队 A 沉淀率 0%，做 100 个和做 1 个一样；团队 B 每个项目都是本金，复利在攒。

结论

变强的不是模型（LLM 权重固定），是资产库。强度 ≈ 项目数 × 沉淀率 × 资产复用率——沉淀率是 0%，做 100 个和做 1 个一样。项目是本金，沉淀是利率。

这一条是整个系列的落点：TR0 定方向、执行循环跑起来、活文档攒约束、TR4 收口——全部动作的终点，是把「这一个项目」变成「下一个项目的起点」。

推导链：为什么「模式复用 + 实例化」而不是「内容搬移」

跨客户复用最大的坑：把客户 A 的内容直接搬给客户 B。

沉淀分三层，处理方式完全不同：

隔离机制：客户特定的内容（政策、规则、字段、边界值）留在项目内 TR2 和边界卡，项目结束归档，不污染通用库。进 skill/知识库的必须是被验证的「模式」——「故障诊断类应用要三库分流」是模式；「这家客户的告警级别定义」是内容，内容不能出项目。

抽象时机：单客户是踩坑，多客户共性才是定理。通用库每条模式 = N 个客户验证过的共性。正因为客户不同，才需要「模式复用 + 实例化」，而不是「内容搬移」。

实践动作：可运行资产体系（简版）

沉淀不能是「文档躺文件夹」——资产必须可运行、有契约、有基线。四件套：

① 载体四档（按成熟度升级）： Snippet（临时工具，不入资产体系）→ 子工作流（资产最小载体）→ 发布为工具 → 插件 ——每次升级需更多证据（多项目验证/形态稳定） ② 资产账本（生命周期管理——找不到=不存在）： 身份（名称/版本/来源项目）/ 契约（入参出参 Schema + 错误契约 {error_code, error_message, retryable}）/ 质量（回归基线状态）/ 环境（兼容平台版本）/ 在用情况（哪些项目在调——唯一真相源） ③ 契约双轨（机器辅助强制 TR2）： 平台校验（运行时强校验）+ 文档备份（TR2 平台资产依赖 字段：身份/调用方式/入参出参映射/环境前提/变更责任） ——两者不一致以平台运行为准，反向更新文档 ④ 黄金集联动：资产 + 回归基线 = 原子对（固化同固、变更 同变）——资产基线是组件级黄金集，覆盖契约各入参出参 路径（正常+边界+异常）

资产体系的运转，一张图看全：

载体随证据升级，账本管全生命周期，复用必须过黄金集——资产不是「文档躺文件夹」，是「可运行 + 有契约 + 有基线」。

复用路径：新项目 TR0/TR1 从通用库提取模式 → 结合当前客户锚点重新实例化 →复用前用黄金集跑回归，100% 通过才交付。担心「模式是别的客户的特点」——正因为客户不同，才要回归验证，不是直接信任。

人机分工：判断与决定权在人，设计与执行在 AI

这套体系里人和 AI 的分工一句话：AI 管怎么做到（实现层），人管什么叫做到（标准层）。

• AI 全包（实现层）：选型列候选方向+跑样本实验；执行循环生成 DSL/导入/冒烟；约束提炼（带来源标注）；用例生成/执行/断言；跑六属性测试+报告初稿
• 人必须管（标准层）：边界拍板 + 成功标准定稿；介入纪律 A/B 的判断（报错纠什么方向/偏离改哪条约束）；用例集基线化确认；三态判定 + 客户签字；客户沟通

人的介入是「看结果、做判断、拍板」——一次几分钟，但每轮都有。判断活全甩掉，TR4 会面对「AI 觉得全对、客户一看全错」的应用。AI 的设计能力来自四个来源：平台层经验（skill）、方法论层（EDD 框架）、当前项目约束（边界卡/真相源/选型实测）、试错收敛——经验决定起点质量，试错决定终点质量。

反例实证：内容搬移的教训

一个项目，客户是制造业，知识库里有「设备告警级别」的客户特定定义。项目结束归档时，这段定义没有留在项目内，被一起提炼进了通用 skill 的「告警处理」模式里。

下一个项目是医疗行业——客户看到 skill 里的「告警级别三级定义」，直接照搬。两个行业的告警语义完全不同，上线后分级全错，排查两天才发现根在「客户特定内容进了通用库」。模式库里的每条内容，都要能回答「它属于哪一层」——回答不了，就是污染。

边界与盲区（完结篇的诚实声明）

这套方法论的可信度，取决于它承认没覆盖什么：

• 验证基础：EDD 完整流程跑过 1 个真实交付项目 + 内部实战实验（网络设备故障诊断助手）；配重校准闭环、资产账本规模化、跨多客户复用的抽象时机——这些目前是「推断待验证」，等更多项目回填
• 适合：AI 应用交付（知识库问答/智能体/自动化流程）、一人公司或小团队、需求边界模糊的项目、能积累资产的项目
• 不适合：传统确定性软件（需求可穷举时先设计后开发更高效）；合规强制前置设计文档的场景；客户完全甩手的项目（EDD 要求客户参与边界拍板和成功标准确认）
• 新领域冷启动：不是从零开始，是从 60% 开始——方法论层 + 测试能力平台无关保留，只缺平台操作经验，恰是试错最容易积累的层；四道防线（边界卡/MRT 极小化/介入纪律/TR3+TR4 闸门）保证「坑多但可控、学费有上限、学完归自己」
• 参数会过期：配重金额区间、熔断初值（max_steps=10/token_budget=8000）、证据门槛 N 值——基于 2026-08 实测，市场/平台变化后按校准闭环重拍

收尾（系列总结）

这个系列从「为什么先设计后开发翻车」讲到「资产复利」，八个环节是一条完整的链：TR0 定方向 → 配重定流程 → 执行循环跑起来 → 活文档攒约束 → 阻尼器防错误 → TR4 双面闸收口 → 资产复利让下一单更便宜。

EDD 一句话总结：拿需求做受控实验，每次交付同时产出两样东西——客户要的成果，和我们可复用的资产。成本由客户承担，资产归我们所有。

传统交付问「需求是什么」，EDD 问「痛点是什么、第一刀切哪、这单留下什么」。前者把项目当文档问题，后者把项目当实验问题——AI 项目是后者，而且每一单都在让下一单更便宜。

下一篇：执行驱动交付（八）：全流程操作手册——一张表，从项目启动跑到交付沉淀

📚 更多实战记录见我的博客：鱼日先生

💬讨论区：你做过 10 个一样的项目、第 11 个还是从零开始吗？你的「资产库」里有什么是真正可复用的？评论区聊聊你的沉淀率。

本文基于真实项目交付经验撰写（2026-08，1 个真实交付项目与内部实战实验）。文中数据均来自实测记录，方法论部分以「已验证 / 推断待验证」标注边界。