SDD的终点是什么？我们找到了答案

SDD（Specification-Driven Development，规范驱动开发）的核心理念很简单：规范是源头，代码是规范的产物。

这个理念没有错。事实上，这是软件工程自诞生以来一直在追求的目标——从形式化方法到UML建模，从模型驱动架构到低代码平台，本质都是在回答同一个问题：如何让“设计”真正驱动“实现”？

当前主流的SDD工具（如GitHub Spec Kit、Amazon Kiro）给出的答案是：

规范 = Markdown文档

用户故事写清楚，验收条件列明白，再加上一些边界用例的描述——AI就能根据这份规范生成代码。

这确实比“一句话生成代码”（所谓的Vibe Coding）前进了一大步。规范作为中间层，让AI生成代码的过程变得可审查、可干预、可版本化。

但问题也随之而来：

第一，自然语言天然存在歧义。 “用户应该能够方便地查看订单状态”——什么是“方便”？不同的开发者、不同的AI会有不同的理解。

第二，规范不可执行、不可被机器直接验证。 Markdown文档是给人读的，不是给机器理解的。规范写没写对、写没写全，只能在代码生成后才能发现——到那时候，返工成本已经产生了。

第三，规范与代码之间的追溯关系要靠人工维护。 改了一个需求，对应修改哪些规范文档？重新生成代码后，之前的手动修改怎么保留？这些问题在当前的SDD工具中没有好答案。

第四，规范是割裂的。 需求规范、架构规范、接口规范、数据规范——它们是不同的文档，彼此之间的关联靠人工标注。当你修改一个数据实体时，很难知道会影响哪些需求、哪些接口。

这些问题意味着：当前的SDD（我们称之为L3级别）可以支撑中小型项目、原型验证、个人开发者的日常需求，但当面对企业级核心系统——需要运行10年、20年，需要几百人并行协作，业务规则盘根错节——这些工具就显得力不从心了。

不是SDD的理念错了，而是当前实现SDD的工具，把“规范”定义得太肤浅了。

如果我们真正贯彻SDD的理念——“规范是源头，代码是规范的产物”——那么，理想的“规范”应该长什么样？

我提出四个判断标准：

第一，无歧义。 规范不应该依赖自然语言的双向理解。它应该是形式化的、结构化的，不同的人、不同的机器读到的信息是一致的。

第二，可执行、可验证。 规范本身就应该能被机器理解和验证。在代码生成之前，我们就能确认规范是否一致、是否完整、是否有冲突。

第三，全贯通。 需求、业务、数据、应用、程序各层级的规范不应该是割裂的文档，而是一个联动的整体。改了一个业务规则，相应的数据规范、接口规范应该自动感知变化。

第四，可治理、可演进。 规范不是一次性产物，而是企业资产。它需要被版本管理、影响分析、资产复用——就像代码被管理一样，但比代码更上层、更稳定。

这四条标准，指向的不是Markdown文档，而是计算机科学中一个经典的概念：

本体（Ontology）。

本体是知识工程领域的核心概念，由Tom Gruber在1993年给出经典定义：“本体是对共享概念化的显式、形式化规范。”

翻译成白话：本体就是用一种机器可理解的方式，定义一组概念、概念之间的关系、以及概念上的约束规则。

在AI领域，本体是大模型理解世界的骨架。在语义网领域，本体是数据互操作的基础。在企业架构领域，本体应该是驱动整个软件工程的核心工件。

我们把这条路线称为ODD（Ontology-Driven Development，本体驱动开发）。

ODD不是对SDD的否定，而是对SDD的终极贯彻。 如果说当前的SDD是L3级别，那么ODD就是L4级别——在“规范驱动开发”的同一理念血脉上，提升了一个层级。

• L1到L4不是“替代关系”，而是演进关系。L3的工具在L4场景下不够用，但L4的工具可以向下兼容。

• 当前市场上的SDD工具停留在L3，而CBF直接跃升到L4。

• 用L3的工具去做L4的工作（企业核心系统），就是技术冒险——规范文档无法支撑10年演进所需的可治理性、可追溯性。

不是L3不好，而是L3的工具有它适用的边界。 这就好比你不会用Word去写操作系统——工具本身没问题，是用错了地方。

CBF正是ODD路线的完整实现：

GRAMM（通用参考架构元模型） ——这是ODD中的“元本体”。它定义了企业工程中所有需要的概念类型以及它们之间的关系规则。GRAMM符合国家标准，并且可以高度定制。

CBF Studio ——这是本体构建（企业建模）与治理平台。用户在上面创建的不是图画，而是活的、结构化的本体。所有产出（业务需求项、业务组件、业务流程、业务对象、实体、应用组件、应用程序等）都是本体的一部分，彼此贯通、联动。

CBF Staff ——这是基于本体的软件工程AI智能体。它基于预置工作流+大模型自规划，自动完成从目标（战略、诉求）到本体的转化，也支持从遗留系统中逆向提取本体。

ADML ——这是本体上的可视化编程语言。图灵完备，ADML程序可直接在虚机上仿真运行，也可生成Java、TypeScript等GPL代码。

这个体系的核心特征是：本体不是副产品，而是第一等公民。

所有工程活动——需求整理、架构设计、业务建模、系统建模、程序开发——都在同一个本体框架下进行。产出物不是松散的文档，而是统一、贯通、可执行的本体（企业模型）。

Odoo重生的意义就在于此。 23小时完成的不仅是“代码翻译”，而是从一个150万行遗留系统中逆向提取出完整的本体——3507条业务需求项、214个业务组件、152个业务对象、148个前端组件、198个后端组件——这些成果本身就是企业资产，可以持续复用、治理、演进。

为了帮助你更好地理解SDD和ODD的关系，可以回想一下编程语言的演进：

• 第一代：机器语言。程序员直接操作二进制，做什么都对，但只有机器能理解。

• 第二代：汇编语言。用助记符代替二进制，人类可以写了，但抽象程度低。

• 第三代：高级语言（C、Java、Python）。程序员不需要关心寄存器分配，可以专注于逻辑本身。

SDD和ODD的关系类似：

• L3 SDD（Markdown规范）：相当于“汇编语言”层面的规范驱动。规范是写出来了，但抽象程度低，规范与代码之间的鸿沟要靠人工（或简单的AI提示）跨越。

• L4 ODD（形式化本体）：相当于“高级语言”层面的规范驱动。规范本身就是可执行、可验证的，代码只是本体的“编译产物”。

不会有人用汇编语言去写企业级ERP系统。同样，用L3的规范文档去驱动企业核心系统的建设，也是不合适的。

不是说汇编不好——在特定场景下（如操作系统内核、嵌入式系统），汇编仍然是必要的。问题是：在需要大规模协作、长期演进、高可维护性的企业级系统中，我们需要更高层级的抽象工具。

ODD就是那个更高层级的抽象。

必须再三强调：我们不反对SDD。

GitHub Spec Kit和Amazon Kiro是有价值的工具。它们在中小型项目、原型验证、个人开发等场景下可以大幅提升效率。SDD理念的普及，也让更多人意识到“规范驱动”的重要性——这是我们乐于看到的。

我们反对的是两件事：

第一，用L3的工具去解决L4的问题。

企业核心系统的建设，不是“能不能跑起来”的问题，而是“10年后还能不能维护”的问题。用规范文档去驱动核心系统的建设和重构，把“能跑起来”当作成功的唯一标准，而忽略了可治理性、可追溯性、可传承性——这是技术冒险。

第二，用概念炒作掩盖工程本质。

当有人用SDD的概念向企业推销“不需要架构师”、“不用做业务建模”、“AI会搞定一切”的方案时，我们要追问：系统上线3年后，团队换了一拨人，还能维护吗？业务规则变化时，能快速分析影响范围吗？架构决策有据可查吗？

如果答案是否定的，那就是在冒险——把企业核心系统的命运，押注在“AI每次都能生成正确代码”的假设上。

作为决策者，你不需要理解ODD的所有技术细节。你只需要问自己三个问题：

第一，这个系统预期运行多久？

如果不超过2年，L3够了。如果需要运行10年以上，你需要L4——只有形式化的本体才能支撑长期的可维护性。

第二，有多少人会在这个系统上协作？

如果是一个小团队（5人以下），L3可以。如果是几十人、几百人并行开发，你需要L4——只有结构化的本体才能支持大规模并行协作而不失控。

第三，业务规则变动的频率和影响范围？

如果业务规则相对稳定，或者变化只影响局部，L3可以。如果业务规则频繁变化，且“牵一发而动全身”，你需要L4——只有贯通的本体才能实现自动化的影响分析。

如果三个问题中有一个让你犹豫，那你就需要ODD。

SDD的理念是对的：规范驱动代码。

但规范不应该只是Markdown文档。规范应该是形式化的、可执行的、全贯通的、可治理的本体。

这就是ODD——本体驱动开发。

如果说GitHub Spec Kit是SDD的“入门版”，那么ODD就是SDD的“终极版”。两者共享同一个理念血脉，但在工程深度上相差一个层级。

CBF走的就是ODD的路线。我们不是在做“文档驱动的AI编程”，我们在做本体驱动的企业工程。

PetClinic、Odoo、以及即将进行的银行核心系统重生验证，都是这条路线可行性的证明。

你的系统打算活多久？

如果只需要活6个月，用L3的SDD。

如果需要活20年，用L4的ODD。

这就是我们的答案。