DDD Cultivation — 完整故事：决策、失败与证据

[xg-gh-25]

---

多数 AI Agent 的 "知识" 要么是写完就烂的 README dump，要么是 RAG 检索出碎片却缺乏判断力。我们造了第三条路：结构化领域知识，从日常工作中自然生长，喂给多个交付引擎，且永远不会过时 —— 因为使用它的系统就是维护它的系统。

TL;DR

方面	我们做了什么
问题	AI Agent 对业务领域是盲的。它能写代码但不懂你的业务规则；能生成内容但不懂你的战略
方案	每个项目 4 份结构化文档 × 3 层引擎（接口 + 智能 + 编排）× 7 个信息通道
规模	5 个项目、5,100 行活跃知识、2,863 行实现代码、每周 80 条自动耕耘
核心洞察	作为工作副产物自然生长的知识，是唯一能存活的知识
最大失败	关键词分类器通过了所有测试，但在生产数据上 100% 误判
我们拒绝了什么	RAG、知识图谱、fine-tuning、静默自动写入、单文件 CLAUDE.md

---

问题：领域盲 AI

每个 AI 编程 Agent 都面临同样的鸿沟：模型懂编程，但不懂你的领域。

用户："加 CMHK 月报"
没有 DDD 的 Agent：通用报表。范围错、层级错、过滤条件错。
有 DDD 的 Agent：读 TECH.md → 知道 5 级层级、17 张数据表、必须的分区过滤。
               读 IMPROVEMENT.md → 知道上次的坑（territory_owner 列不存在）。
               读 PRODUCT.md → 知道 CEO 视图 vs GM 视图的区别。
               → 第一次就做对。

这不是假设。我们有 9 个 CMHK skill 使用 DDD 上下文。DDD 没填充前，每个 skill 的 SQL 要迭代 3-5 轮才对。填充后：领域逻辑一次命中。

现有方案为什么不行：

方案	为什么对"判断"无效
单文件 CLAUDE.md	无结构 → 5K 行 dump；无生命周期；写完就烂
RAG	检索碎片，无判断上下文；"找到相关块" ≠ "知道怎么用"
Fine-tuning	静态快照；更新贵；不透明；改了什么无法审计
知识图谱	要基础设施；没有人可读路径；查询语言复杂；在项目尺度上过度工程

---

方案：三层架构

第一层：接口（人能看到的）

每个项目 4 份 Markdown 文档，各回答一个判断维度：

文档	判断问题	内容示例
PRODUCT.md	该不该做？	愿景、优先级、非目标、受众
TECH.md	能不能做？	架构、约定、API 契约、运行时陷阱
IMPROVEMENT.md	以前试过没？	哪些奏效、哪些失败、反模式、安全历史
PROJECT.md	现在该做吗？	当前焦点、阻塞项、近期决策、待办

为什么恰好 4 份？ 我们试过 2（太稀疏 — Agent 缺判断上下文）、6（太碎 — 上下文切换成本高），最终定在 4：因为它们干净地映射到 Agent 的决策树 —— 想做吗 → 做得了吗 → 以前试过吗 → 现在该做吗。

第二层：智能（机器维护的）

组件	做什么	代码行数
健康评分	5 维打分（陈旧度、完整度、使用率、衰减、矛盾）。产出信任等级：full → high → moderate → low	379
成熟度追踪	逐章节生命周期：sparse → growing → mature → evergreen。证据：来源数、生产验证、用于决策	488
条目生命周期	逐条目衰减：active → dormant → archived（30/90 天无引用）。5 类标签：guideline、pitfall、decision、model、process	665

关键洞察： 健康分驱动的是 AI 信任度，不是人的行动。过时内容不会生成任务 — 它在 session briefing 中标 [!]，Agent 知道"少信这段"。人类零维护负担。

第三层：编排（自动运行的）

7 个独立信息通道，故障隔离（一个崩不影响其他）：

通道	来源	产出
1	DDD 陈旧度检测	[!] 警告、刷新提案
2	Pipeline REFLECT + 纠正	自动把教训写入 IMPROVEMENT.md
3	DDD → KNOWLEDGE 桥	稳定 DDD 内容晋升到 Knowledge 索引
4	KNOWLEDGE 陈旧度	参考材料新鲜度检测
5	实体索引验证	跨项目路由表完整性
6	Signal pipeline	外部洞察 → DDD 提案
7	Code Intelligence	代码库漂移 → TECH.md 同步

时间预算： 总计 25 秒，每 session 最多 5 条提案，mtime 过滤器（30 天）。这些限制来自下面的失败 #2。

---

关键决策（为什么选了这些）

D1：判断基座，不是知识库

DDD 回答的是 "什么能帮 AI 判断得更好？" — 不是 "什么有趣？"。这个过滤器拒绝了活动日志、状态更新、原始指标。只有能塑造判断的内容才进入 DDD。

为什么： 信息过饱和杀 Agent 比信息匮乏还快。一份 10,000 行的 TECH.md，其中 80% 是状态更新 — 重要的 20% 就被淹没了。

D2：复用已有提取，不另建管线

记忆管线已经从每个 session 产出 StructuredSummary（决策、教训、纠正）。DDD Cultivation 消费相同的输出 — 零新增 LLM 调用。

为什么： 每条新提取管线都是维护负债。复用意味着 DDD 质量随记忆质量一起提升 — 复合增长，不是线性叠加。

D3：分级自治（安全的自动写入 + 风险的升级）

初始设计：二元 —— "全部提案，绝不静默写入"。问题：提案疲劳。没人看 50 条提案。

修订设计：

• 增量型变更（新教训、新模式）→ 自动写入 + 记录
• 风险型变更（修改、删除、与现有矛盾）→ 升级队列

为什么： 纯增量变更风险为零。在 IMPROVEMENT.md "What Failed" 里加一条新记录不可能损坏已有内容。修改可以 — 那些需要判断。

D4：实体索引用文本，不用图数据库

5 个项目 / ~120 个实体的规模，PROJECTS.md 里一张纯文本路由表就够了。Agent 直接从 system prompt 里读 — 无查询语言、无数据库、无基础设施。

扩展触发器： 到 ~500 个实体、或跨项目路由错误率超 3% 时重新评估。

D5：全文件系统，不用 SQLite

提案量：最大 ~90 条待处理。Git 可审计性比查询速度重要。

扩展触发器： 如果量超 ~500 条（5 个月以上无人审批），迁到 SQLite。

D6：跨层有意重复

同一事实可以同时存在于 DailyActivity（临时、原始）、MEMORY.md（Agent 作用域、精炼）和 DDD（项目作用域、结构化）。不同消费者、不同生命周期、允许重叠。

为什么： 因为 "MEMORY.md 里有了" 就抑制 DDD 提案，会丢失项目作用域视角。MEMORY 里的事实说 "我学到了 X"。TECH.md 里的同一事实说 "在这个项目里工作时，X 很重要"。

D7：渐进式加载（章节级，不是文档级）

大型 TECH.md（SwarmAI 的有 97K）永远不会全量加载。Agent 读章节目录，只拉相关章节（每段 ~500 tokens）。

预算影响： 活跃项目 ~5K + 实体索引 ~2K + 跨项目拉取 ~1.5K = 最坏情况额外 ~8.5K tokens。在 91K 有效预算下，DDD 增加 9% 开销。

---

真正失败过什么

失败 1：T2 关键词分类器 — 生产环境 100% 假阴性

发生了什么： 构建了一个分类器，把纠正路由到正确的 DDD 文档（TECH vs IMPROVEMENT）。用 29 条包含魔法词（"daemon"、"subprocess"、"nc -z"）的合成纠正做测试。全绿。对抗性审查通过。

现实： 5/5 条真实生产纠正返回 None。

根因： 测试数据由写正则的同一人手工制造。真实纠正是叙述性行为描述（"Agent 打开了 DMG 而不是安装"），跟关键词零交集。

修复： PE-1 回退（完全绕过关键词门控）。Pipeline REVIEW 加了 RP31+RP32。

教训： 写 matcher 的人制造的 mock 数据永远会通过测试。用真实生产数据测，或者别测。

失败 2：自动耕耘 Hook — 无操作路径 O(n)

发生了什么： Hook 通过所有质量门控（TDD 7/7，对抗性 HIGH 已修）。上线。

现实： 每个 session 扫描全部 141 个 run.json 文件来发现…… 零条未耕耘的记录（99% 的调用什么都不做）。

根因： Review 阶段只关注有操作的路径。没人分析无操作路径 —— "什么都不做时会怎样？"

修复： 加了 RP30 规则（"hook 无操作路径扩展性"）。实施时间预算 + mtime 过滤。

教训： 无操作路径是执行频率最高的路径。如果它是 O(n)，你就有一个对单元测试不可见的系统性浪费 bug。

失败 3：v1 批次式会话结束 — 时间差

发生了什么： v1 只在会话结束时耕耘。一个跨多会话的功能在 3 个 session 中产生知识。Session 2 和 3 缺少 Session 1 的耕耘产出（还没跑）。

根因： 批次式会话结束意味着知识永远落后一个 session。

修复： v2 改为事件驱动。通道 2 在 pipeline REFLECT 时触发（即时）。Session N 的产出在会话结束几秒内就可供 Session N+1 使用。

失败 4：1029 行变更集中 REVIEW 被静默跳过

发生了什么： DDD cultivation hook 扩展（17 tests、4 commits、1029 行 diff）。Pipeline REVIEW 阶段通过 run-update 完成，一行都没读。

根因： EVALUATE 和 PLAN 做得很彻底，产生了虚假信心。REVIEW 感觉"已经验证过了"。

修复： 加了 Check 8d —— review 力度必须与变更集大小成正比。

教训： 早期阶段的彻底性制造认知陷阱，让后期阶段的偷懒感觉理所当然。

---

真实指标（实测数据，非预测）

周产出（2026-05-18）

指标	数值
自动耕耘的教训	80 条（36 → IMPROVEMENT, 44 → TECH）
升级的提案（需人工审核）	12 条
覆盖项目	5 个
假阳性率（噪音条目）	~5%（80 条中 4 条在审核时被拒）
自动写入准确率	95%（76/80 无需干预即正确）

DDD 健康（实时仪表板）

项目	行数	信任度	过时章节
SwarmAI	2,090	Full	0
CMHK_BIZ	1,694	Full	0
AIDLC	888	Full	0
GitHub_Community	398	High	0
PhysicalAI	262	Moderate	1 (31 天未更新)

实现体量

模块	行数	职责
ddd_orchestrator.py	785	7 通道故障隔离编排
ddd_entry_lifecycle.py	665	逐条目衰减 + 类型分类
ddd_cultivation.py	546	分级自治过滤 + 自动写入
ddd_maturity.py	488	章节级成熟度追踪
ddd_health.py	379	5 维健康评分
总计	2,863

---

反模式（别这么干）

反模式	为什么会失败	应该怎么做
什么都往 TECH.md 里塞	信息过饱和。10K 行中 80% 是状态更新 → 重要的 20% 被淹没	过滤判断价值："这能帮 Agent 做决策吗？"
不分级就自动写入	静默的语义编辑会损坏已有知识。删除 = 数据丢失	增量自动写入，风险升级。永不自动删除
只用合成数据测试	作者偏差：你写的测试数据一定匹配你写的匹配器	每个测试套件必须包含 ≥3 条生产真实数据
最后才优化无操作路径	它是执行频率最高的路径。99% 调用上 O(n) 扫描 = 不可见浪费	每个 hook 设时间预算。先 mtime 过滤再扫内容
没有 owner 就在团队间共享 DDD	没有明确 doc owner，矛盾会静默积累	一份文档一个 owner。其他人提案，owner 批准
先建图数据库	<500 实体时基础设施成本 > 收益。文本路由就够用	先用文本实体索引。路由错误率超 3% 时再迁移

---

这个方案在哪里会崩

DDD Cultivation 是为一个 builder + AI 或小团队设计的。诚实的局限：

场景	崩溃点	到时需要什么
>500 实体	文本路由表变得笨重	带模糊匹配的实体存储
>10 并发写者	共享文档 Git 冲突	章节级锁或 CRDTs
>50 提案/天	队列疲劳，没人看	基于 ML 的自动审批 + 置信度门控
实时知识	DDD 更新是 session 粒度（~秒级）	亚秒传播的事件流
跨组织知识共享	单 git 仓库假设	DDD 实例间的联邦协议

我们现在是 5 个项目、1 个 builder、~80 提案/周。离这些极限很远。设计刻意为当前规模保持简单，每个维度都有明确的升级触发条件。

---

复合效应

DDD 单独看没有价值。它的价值来自同时喂养多个引擎：

                    +------------------------------------------+
                    |         DDD (4 docs x 5 projects)         |
                    |    PRODUCT . TECH . IMPROVEMENT . PROJECT  |
                    +------+----------+-----------+------------+
                           |          |           |
               +-----------v--+  +----v-----+  +-v------------+
               |  Pipeline    |  | Pollinate |  |  Evolution   |
               | (代码交付)    |  | (内容生产) |  | (自我改进)    |
               +------+-------+  +----+------+  +-+------------+
                      |               |            |
                      +---------------+------------+
                                      |
                             REFLECT 反馈回流
                             -> DDD 生长
                             -> 下一轮更聪明

Pipeline 学到的 → 让 Pollinate 更聪明。
例子：Pipeline 交付 CMHK 月报时发现 territory_owner 列不存在（TECH.md pitfall）。下周 Pollinate 为同一 BU 生成 GTM 内容时 — 不会引用 territory_owner 数据，因为 TECH.md 已经写了它不存在。

Pollinate 学到的 → 让 Pipeline 更安全。
例子：Pollinate 生成品牌内容时发现一个非目标（PRODUCT.md 里 "not multi-tenant SaaS"）。Pipeline 不会构建 SaaS 功能，因为同一份 PRODUCT.md 把守它的 EVALUATE 阶段。

这种交叉授粉不需要引擎之间通信。它们共享一个基座。基座生长。两个都变聪明。这就是复合飞轮。

---

从零开始（如果你想构建这个）

Phase 1（1 小时）： 每个项目建 4 份空文档。写 PRODUCT.md（愿景、优先级、非目标）。把你已知的架构决策填进 TECH.md。IMPROVEMENT.md 和 PROJECT.md 保持最简。

Phase 2（自动的）： 正常工作。每次重要 session 后，提取 2-3 条教训到 IMPROVEMENT.md（"What Failed" 或 "What Worked"）。这是唯一需要人为努力的地方。

Phase 3（准备好时）： 构建智能层。健康评分告诉你什么过时了。成熟度追踪告诉你什么可信。条目生命周期告诉你什么该归档。

Phase 4（可选）： 构建编排层。7 通道自动化提取。分级自治处理日常。你只看升级项。

大多数团队只做 Phase 1-2 就能获得 80% 的价值。机器层（3-4）是给你想要零维护、永远新鲜的知识时用的。

---

总结：DDD Cultivation 为什么有效

属性	为什么重要
从工作中生长	不需要文档冲刺。知识作为副产物自然积累
为判断而结构化	不是 "发生了什么" 而是 "Agent 该决策什么"
自我维护	健康分检测衰减。自动耕耘预防它
跨引擎	Pipeline + Pollinate + Evolution 全部消费同一基座
有证据的信任	成熟度追踪：sparse → growing → mature → evergreen。Agent 按比例信任
优雅降级	过时知识被标记，不被删除。低信任 ≠ 错误
零基础设施	Markdown + git。无数据库、无图、无向量存储

从 28 个 DDD 章节（2026-03-24）到 110+（2026-05-16）。零次文档冲刺。全部来自日常工作 — 8 个自动通道 + 1 个人工习惯（重要 session 后提取 2-3 条教训）。能存活的知识，就是维护成本为零的知识。

---

发布自 SwarmAI — 5,100 行活知识喂养每个决策，使用它的系统就是生长它的系统。Source