业务建模与技术实现隔离的开发方法

主要论点：

AI Coding的时代，LLM最擅长的技术实现与分析，LLM在训练阶段就阅读过了人类几十年积攒下来的高质量代码库。关于如何写代码这件事情人类程序员只能望其项背，至少是输出速度上。
AI Coding的瓶颈我认为是将人类脑中的业务语言描述成LLM理解的语言，一旦LLM完整理解了业务技术实现上就不是问题
人脑中的想象翻译成LLM理解的语言中间存在一个巨大的鸿沟，由于语言的局限性人类理解和LLM理解没有对齐。现在有了LLM我们可以借助其对非结构化语言的理解帮我做成翻译的工作
需要利用业务建模的方法，将人脑中的业务描述利用结构化的业务模型来表达。而Ontology就是这样一套建模的方法论
一旦业务模型建立后LLM可以参考这套可以推理的业务模型进行技术实现，agent就拥有了一个全局视角不会迷失在充满细节的庞大的有限的上下文窗口中。
一句话：人类负责业务建模出一个LLM能够理解业务模型，LLM负责读取这个模型负责地下的技术实现

AI Coding 的瓶颈从来不是代码

——业务建模与技术实现隔离的开发方法

摘要：LLM 在「编码」上已经越过了人类程序员的经验广度与输出速度。真正的瓶颈在它的上游：把人类脑中的业务，翻译成机器能精确理解的形式。我主张的方法是——用本体（Ontology）做业务建模，把「业务语义层」和「技术实现层」切开。人类负责建模出 LLM 能理解的业务模型，LLM 负责读取模型、完成底下的一切技术实现。

全文三段递进：为什么必须切 → 怎么切 → 怎么落地。

一、为什么：瓶颈从「写代码」上移到了「说清楚业务」

1.1 前提：编码上，人类已无比较优势

第一个前提：LLM 的训练语料包含人类几十年公开积累的代码资产——主流框架源码、GitHub 工程实践、Stack Overflow 问答、RFC 与设计文档、issue 里的争论与妥协。

由此得出判断：一个程序员终身能精读的代码量，与公开代码语料不在同一个数量级。 这个差距不随个人努力缩小，它是「一个人一生」与「全行业几十年」的距离。

但经验广度不等于工程判断力，读过不等于理解正确。更具体的一层是：当需求足够清楚、足够精确，「写代码」的边际价值正在向模型转移。 语法记忆、API 用法、模式调用、跨语言转译、样板代码生产——这些曾占据我大量时间的工作，在输出速度上我已经无法相比。

1.2 证据：失败模式全部指向业务，不指向代码

换个角度，从失败模式切进去。

假设我让 AI 实现「订单取消后自动退款」：三十秒写完，代码风格漂亮，有单元测试，有事务边界，异常处理得体。然后我意识到——实际业务里，取消要客服审核；退款不是即时到账，走财务批次；已开票的订单不能直接取消，要先红冲。

它没有写错代码，它写错了业务。

这类失败归一下类，绝大多数落在四种：

凭空补全规则——模糊处不报错，用「最可能的解释」填上
边界条件猜错——金额取整、时区、幂等、并发
架构漂移——每追加一个需求都在旧结构上打补丁，几十轮后熵增到不可维护
上下文遗忘——改到第 30 个文件时，第 3 个文件定下的约定早滑出了窗口

共同点是：没有一种是「不会写代码」，全部是「不知道业务是什么」。

这和我熟悉的工程方法论拧着。代码规范、设计模式、单测覆盖率、CI/CD、Code Review，全都在为「实现质量」服务；而实现质量的成本正在快速塌陷，方法论的重心开始错位。

1.3 追问：为什么不直接「把需求说清楚」？

我试过用这个答案说服自己，站不住。从人脑到 LLM 有三道失真关口。

第一道，隐性知识说不出来。Polanyi 说：「我们知道的，多于我们能说出来的。」（We can know more than we can tell）

做了十年仓储的专家判断「这笔调拨要拦一下」，脑内闪过的是整套经验模式——供应商的历史交付稳定度、季节性、上次盘点差异——说出口的只有一句「这个不太对」。老工程师看代码说「这里味道不对」，追问哪里不对，他可能要想十分钟。

这些知识真实存在，但它是默会的，不在语言里。

第二道，自然语言本身多义。业务方说「客户」：销售想的是签约主体，财务想的是开票抬头，客服想的是联系人。一个词、三个对象，在需求文档里是同一行字。

第三道，LLM 的理解是概率性补全。这一条最关键，因为它与编译器形成了对照：

编译器和 LLM 对模糊输入的反应截然相反。编译器遇到歧义拒绝编译，把问题还给我；LLM 遇到歧义给出最可能的补全，把问题藏起来。

编译器逼我精确，LLM 纵容我模糊。而「最可能」是训练语料的统计偏好，不是我的业务真相。

于是：模糊的输入不会让 LLM 报错，只会让它自信地答错——答错的代码和答对的代码一样漂亮。往一个不确定的通道里灌更多信息，只会放大噪声。这就是「写更长的 prompt」解决不了问题的原因。

1.4 出路：让 LLM 做翻译，但译文必须结构化

另一面是，LLM 恰好是历史上最强的非结构化语言理解器：能读会议纪要、能追问、能推理、能从互相矛盾的口述里理出一致性假设。

所以分工是：让 LLM 承担「人类语言 → 结构化表达」的翻译。

译文形态是关键。我不接受更长的自然语言，要的是结构化的业务模型——自然语言产物有三个致命缺陷：

缺陷后果不可验证无法判断它到底理解了没有，只能读一遍、感觉「嗯，差不多」不可复用换一个会话、换一个模型，理解就丢了，下一个人得重新讲不可推理做不了一致性检查、影响分析、变更传播

三个缺陷，正好对应下一章「本体」的三个性质。

1.5 立论：六句话

LLM 最擅长技术实现与分析——它在训练阶段就读过了人类几十年积攒下来的高质量代码库，写代码这件事人类程序员只能望其项背，至少在输出速度上
AI Coding 的瓶颈，是把人类脑中的业务语言描述成 LLM 能理解的语言；一旦 LLM 完整理解了业务，技术实现上就不是问题
从「人脑中的想象」到「LLM 的理解」之间存在巨大鸿沟：语言的局限让两者无法天然对齐；而现在，我们可以借助 LLM 对非结构化语言的理解能力，让它来做这个翻译
需要用业务建模的方法，把脑中的业务描述用结构化的业务模型表达出来——Ontology 就是这样一套建模方法论
业务模型一旦建立，LLM 就可以参考这套可推理的模型做技术实现，agent 因此拥有全局视角，不会迷失在充满细节的、庞大而有限的上下文窗口里
一句话：人类负责业务建模出一个 LLM 能理解的业务模型，LLM 负责读取这个模型、完成底下的技术实现

二、怎么切：用一个能被推理的业务模型，分开业务语义层与实现层

2.1 本体：三个词，治三个病

「本体论」在哲学里是形而上学，在计算机科学里精确得多。我采用 1993 年 Tom Gruber 的定义：

本体是对某个概念体系的显式的、形式化的规范（An ontology is an explicit specification of a conceptualization）。

三个词，各治一个病：

性质工程含义治好的病显式 explicit 业务知识被明确写出来，而不是隐含在代码、文档或某个人的脑子里隐性知识无法传递形式化 formal 机器可读、可校验、可推理自然语言不可验证共享 shared 可作为人、LLM、系统三方共同的理解基础理解不对齐、不可复用

所以「用本体做业务建模」不是「画一张更漂亮的图」，而是：把业务知识变成一份显式的、机器可读的、可推理可校验的资产。

2.2 体系：从三模型到十一大模型

原则有了，还缺一套模型。我不重新发明，借用的是何明璐老师（「人月聊IT」）的本体建模规范，已在 GitHub 开源（https://github.com/sharptoolbox）。它综合 Palantir 的本体建模、经典本体论（OWL / OWL2 / SWRL / SHACL）、OOAD 与 DDD，演进到十一个模型。是一套值得好好研究的方法论。何明璐老师也是我最喜欢的架构师，大家可以去B站关注一下「人月聊IT」。

核心三个：

M1 对象模型——实体、属性、关系、约束。一条关键原则，也极易被违反：描述「业务对象」，而不是「数据库表」。

「订单」包含订单头 + 明细，是一个完整的业务概念；拆成两张表是实现阶段的持久化决策，归映射模型管。

违反这条，隔离立刻失效——模型里一旦出现表，就绑死在了某一种实现上。

M2 行为模型——领域行为，不是逐表 CRUD。「确认支付」「提交合同」「激活客户」是行为，INSERT/UPDATE 不是。每个行为声明四件事：原子性、前置后置条件、引用的规则、产生的事件。

M3 规则模型——跨对象、跨行为的业务决策。从 OWL 的简单约束（范围、非空），扩展到 SWRL / SHACL 级别的复合规则，如「合同的开票金额之和不得超过合同总额」。

完整十一模型（上限，不是入场券）：

编号模型核心职责层级 M1 对象模型实体、属性、关系、约束 L1 领域对象层 M2 行为模型领域原子行为、触发条件、前后置约束 L2 原子能力层 M3 规则模型跨对象/跨行为的业务决策规则 L3 解耦决策层 ME 事件模型业务事件、生产者/订阅者、事件链路 L3 解耦决策层 M4 场景模型跨对象事件协同的业务语义链 L4 编排协同层 M5 主体模型参与者、角色、权限边界横切层 M6 流程模型端到端协同流 + 审批流 L4 编排协同层 M7 查询统计与报表模型跨对象查询、统计分析、固定报表旁路层 MU UI 模型屏幕、界面元素、导航、调用链 L6 交互入口层 MM 对象-数据表映射模型对象到数据库表的持久化映射 L0 持久化映射层 MI 接口模型系统边界的接口契约 L5 集成边界层

注意 MM 和 MI 的位置：映射与接口被单独建模。这是「隔离」的制度化——对象模型不碰表，接口模型不碰行为执行，各自可以独立变更。整套理念六个词：正交分解、事件解耦、流程分离、读写分离、可追溯、可管控。

2.3 对齐：和 DDD、经典本体论、Palantir 的关系

不重复造轮子，几条路线的对应关系：

DDD——对象模型直接用聚合根 / 实体 / 值对象分类，聚合边界就是事务边界（订单 + 明细同聚合；订单 + 客户独立聚合，靠 ID 关联）
经典本体论——对象模型对应 OWL/OWL2 的实体-属性-关系-约束；规则模型把表达力从 OWL 的简单约束扩到 SWRL / SHACL 的复合规则
Palantir——对象 ≈ Object、行为 ≈ Action、规则 ≈ Function。它的核心主张是「规则和行为建模才是核心」：Ontology 不是数据资产目录，是可执行的业务语义层
SOA / EDA——事件模型用消息中间件解耦行为（订单「确认支付」后发 Order.PaymentConfirmed，库存模块自行订阅，两者无代码依赖）；场景模型是 SOA 服务编排的现代演绎

一句话：这套体系不是从零发明，是把几条既有路线收敛成大模型能直接读的格式。

2.4 形态：写成 YAML

模型需要一个 LLM 和人同时能读的物理形态。选 YAML：结构严格、人能读、能整块进上下文、diff 友好。

合同管理场景，我会这样写（节选）：

# ── M1 对象模型：描述业务对象，不描述表 ──
objects:
  - id: O_Contract
    name: 合同
    kind: AGGREGATE_ROOT            # DDD 分类：聚合根
    attributes:
      - { name: 合同编号, type: string, required: true, unique: true }
      - { name: 合同总额, type: Money, required: true, constraint: "> 0" }
    relations:
      - { to: O_ContractItem, type: COMPOSITION, cardinality: "1..*" }
      - { to: O_Customer,     type: ASSOCIATION, cardinality: "1" }
    stateMachine: [草拟, 审批中, 已生效, 履行中, 已完结, 已作废]

# ── M2 行为模型：领域行为，不是 CRUD ──
behaviors:
  - id: B_SubmitContract
    name: 提交合同审批
    target: O_Contract
    preconditions: [ "合同.状态 = 草拟", "合同.总额 > 0" ]
    effects:       [ "合同.状态 → 审批中" ]
    emits:         [ E_ContractSubmitted ]

# ── M3 规则模型：跨对象的业务决策 ──
rules:
  - id: R_InvoiceAmountMatch
    name: 开票金额不得超过合同总额
    when: "行为 = 开票登记"
    expression: "SUM(该合同下所有发票.金额) <= 合同.总额"
    violation: REJECT

复制成功

换成 prompt 里一句自然语言——「合同要能提交审批，前提是金额大于 0；开票不能超过合同总额」——人类工程师读完大概率会做出和我一致的实现，LLM 也会。

但「大概率」不是工程能接受的标准。

模型版本里，O_ContractItem 是不是聚合内子对象、超额时是 REJECT 还是 WARN、状态机有哪几个状态，全部显式：业务方能逐行评审，脚本能校验，模型上能跑图遍历。

这就是「可验证」与「听起来对」的差别。

2.5 收益：模型给 agent 全局视角

先承认物理约束：上下文窗口有限，工程代码库不是。

窗口做到 200K 还是 2M token，中等规模系统的代码量都远超它；注意力随上下文长度衰减也是已知现象（长上下文的「中间遗忘」）。更要命的是，代码是细节的海洋——翻开任何文件，都是 if/else、异常处理、字段名、框架注解，一层套一层，深不见底。

于是今天主流的 AI Coding 是这样工作的（策略 A）：

代码是唯一真相源。agent 在文件海洋里「读—猜—改」，每次理解都要重新打捞；理解是局部的、易失的、不可复用的。

隔离之后（策略 B）：

模型是真相源，代码是模型的投影。 agent 先读模型——几 KB 到几十 KB 的 YAML，能一次性完整进上下文——建立全局结构，再按需下钻到实现。

一个类比：模型之于代码，如同地图之于地表。 我不会走遍每条街来认识一座城市，也不该读完每个文件来理解一个业务系统。而现在的 AI，每次都在试图走遍全城。

策略 B 给出三个策略 A 给不了的能力：

一次性全局加载——几十 KB 模型占满上下文，agent 的视野从局部片段变成完整系统
静态一致性校验——模型上能跑 lint：「这个行为引用了不存在的规则」「这个界面调用了未定义的行为」。代码上做不到，只能靠测试覆盖度碰运气
变更影响分析——改一条规则会影响哪些行为、哪些流程、哪些界面？模型上是图遍历，代码里是考古

第三点是分水岭。能写新代码的 AI 到处都是；能在你改了三年、长了十万行的系统里安全改动一处逻辑的 AI，才是稀缺品。 后者要的不是更强的模型，是一个比代码更高的抽象层。

2.6 边界：模型必须技术实现无关

这是最容易做错的地方，也是「隔离」的字面含义。

我的规矩：本体模型里不出现技术实现——不写框架名、表结构、索引、接口协议、部署形态。

实现层信息从哪来？单独维护两份规范：

技术架构规范——开发框架、分层方式、数据库与语言选型，以及 AI 交互层（意图识别、流式输出、会话管理）
UI/UE 规范——统一界面风格，表单录入 / 查询 / 基础数据维护的布局约定

于是「模型 → 实现」变成多对多：

                     ┌──▶ 传统应用（Spring Boot + Postgres 单体）
                     ├──▶ 低代码平台（元数据驱动渲染）
   [ 本体模型 ]  ─────┼──▶ Skills 技能包（供 Agent 动态装配）
   业务语义层         ├──▶ MCP Server（供其他 Agent 调用）
                     └──▶ 数据分析 / 知识问答

复制成功

同一套模型可以落成传统应用、低代码配置、MCP Server，也可以只用来做知识问答。

反过来对企业更重要：已有数据库可逆向建模，源代码可逆向工程，非结构化文档可知识抽取——三条路径汇入同一套本体模型。这意味着躺在 Oracle 和十年前的 Java 代码里的存量业务知识，第一次有了被重新表达成「AI 可读资产」的通道。

2.7 分工：线画在哪

人该退到哪一层？

┌──────────────────────────────────────────────┐
│  业务世界（人的领域）                            │
│  业务专家 / 领域专家 / 需求分析                   │
│  说不清的隐性知识、经验判断、模糊的口述              │
└───────────────────┬──────────────────────────┘
                    │ ① 需求探索：LLM 追问、澄清、补全
                    ▼
┌──────────────────────────────────────────────┐
│  本体模型（人机共审的契约）                       │
│  YAML：对象 / 行为 / 规则 / 流程 / 权限 / 界面     │
│  ✅ 人类可读可评审    ✅ 机器可校验可推理           │
└───────────────────┬──────────────────────────┘
                    │ ② 技术实现：LLM 主导
                    ▼
┌──────────────────────────────────────────────┐
│  技术实现（机器的领域）                           │
│  框架、分层、表结构、接口、并发、测试                │
│  人类只做验收，不做逐行生产                        │
└──────────────────────────────────────────────┘

复制成功

这条线有一个漂亮的工程性质：线以上，正确性靠人的评审；线以下，正确性靠编译器和测试。 两侧各有验证手段，中间那份模型，是唯一需要严格对齐的接口。

命题第 6 条：人类负责业务建模出 LLM 能理解的业务模型，LLM 负责读取模型、完成底下的技术实现。

三、如何落地：四步流程、技术底座与几个反直觉

3.1 流程：四步

从零构建应用，固化成四步，每步可封装成独立 Skill，由 Agent 平台编排：

步骤输入输出主导 1. 需求探索原始需求文档 + 需求探索提示词完整软件需求规格说明书（交互式问答产出）人 + LLM 追问 2. 本体建模需求说明书 + 建模规范 YAML 本体模型（含一致性与交叉验证检查）人评审 + LLM 生成 3. 技术底座系统管理 + 流程引擎的需求可配置的技术底座平台 LLM + 架构师对齐 4. 应用生成模型 + 需求 + 架构规范 + UI 规范 + 开发指导书完整应用 LLM

第 3 步最容易做错，单独说。

3.2 底座：不能每次重新生成

每个系统都需要系统管理（用户 / 角色 / 权限）和流程引擎（流转 / 审批）。这两块每次都由 AI 重新生成，得到的不是效率，是重复的 bug 和永不收敛的形态。

做法：把底座做成元数据驱动 + 状态机 + 内置脚本的能力层（流程定义为 JSON 的「节点 + 连线」，运行时只维护当前节点和上下文变量），再让 AI 理解一件事：

不要重新生成底座，基于已有底座能力，实现本体模型里的业务功能。

要把这句话变成可执行的约束，需要一份《基于技术底座 + 本体模型的 AI 原生应用开发指导书》——它承载那些无法从模型和框架推导、只属于你组织的工程经验。何明璐老师的方案里，这一点我格外认同。

一句话：本体建模规范是灵魂，技术底座是骨骼，行业经验沉淀在提示词、指导书与开发规范里。

3.3 成本：换的不是工序，是成本结构

如果你读到这里是 CTO 或 CEO，请看最后一行。

传统成本曲线是需求 → 设计 → 开发 → 测试 → 上线，大头落在实现，返工成本随阶段指数上升。隔离之后：

传统模式模型隔离模式需求澄清需求文档，落定后基本不变建模，模型是活的、持续演进实现人力成本大头，随规模线性增长 LLM 完成，边际成本趋近于「重跑一次」变更找到代码 → 评估影响 → 改 → 测先改模型 → 图遍历影响面 → 重新投影实现资产沉淀代码（三年后是技术债）业务模型（五年后大概率仍成立）

今天写的 Spring Boot 代码，三年后大概率要重写；今天建的「客户 / 合同 / 审批 / 结算」这层业务语义，五年后大概率还是这个样子。 业务模型是生命周期最长的资产，代码不是。

所以我的判断：AI 时代的投资重点，不该是「让 AI 写更多代码」，而是「让 AI 能读懂你的业务」。 前者是买工具，后者是建资产。

这也是 Palantir 这类平台的估值逻辑——它的本体不是数据资产目录，是把对象、行为、规则组合成可执行的业务语义层，让数据集成、分析、推理和业务操作在同一模型里完成。

3.4 组织：程序员角色上移，不是消失

建模的人——业务架构师 / 领域专家 / 高级需求分析。这个角色过去被当成「文档写手」，模型隔离之后会成为交付链上最关键的一环
程序员做什么——从「逐行生产代码」上移到「设计约束、建设底座、编写架构规范、做验收」。一个不太客气的类比：从泥瓦匠变成建筑规范制定者，砖还要砌，砌法变了
反直觉的结论——AI 越强，建模能力越值钱。实现越便宜，瓶颈越集中在实现的上游。这和「人人都能写代码，所以架构师不值钱了」的流行叙事恰好相反

3.5 坑：五个

把建模做成「画更漂亮的 UML 图」。 模型只回答「系统要做什么」，没回答「对象之间什么关系、行为之间什么连锁反应、规则边界在哪」，它就还是二十年前的需求规格说明书。UML 用例图缺的正是可被大模型理解和执行的业务语义。
模型里混进实现细节。 一旦出现表名、框架名、接口路径，隔离就破了，模型退化成另一种技术文档，从此与实现一起腐烂。
一次性建十一模型的完整体系。 从 0 到 1 构建单系统，裁剪到 7 个就够（对象、行为、规则、主体、流程、查询统计、UI）：事件先用同步方法步骤替代，数据映射由对象模型直接生成，接口与场景模型暂不需要。完备性是上限，不是入场券。
把 prompt 当模型。 提示词里的自然语言业务描述，依旧不可验证、不可复用、不可推理。它和本体模型的区别不在格式，在能否被检查与推理。
指望模型自动与代码同步。 单向的「模型 → 代码」会随迭代漂移，需要双向：从代码逆向建模，定期核对一致性。这条不做，隔离三个月内名存实亡。

3.6 起步：两周验证

别一上来就重构整个研发流程。我会这么试：

第 1 周——挑一个中等复杂度、且不是最核心的业务域（比如「合同管理」而不是「订单主流程」），把对象、行为、规则写成 YAML。一两天的量
第 2 周——拿模型 + 技术架构规范，让 AI 生成这个域的完整实现。只评审模型，不逐行评审代码：实现偏离意图时，先问「模型里是不是没写清楚」，而不是直接改代码
第 3 周——做一次变更演练。丢一个新需求进去（如「开票金额可超合同总额，但需财务总监审批」），观察两件事：它在模型上怎么表达？影响面能不能在模型上直接回答？

一个比任何指标都准的判断标准：

需求变化时，你是先改模型，还是先改代码？稳定答「先改模型」，隔离就成立了。

结语

AI Coding 的瓶颈不在代码，在把业务说清楚——模糊的输入不会让 LLM 报错，只会让它自信地答错
出路不是更长的 prompt，是一份可验证、可复用、可推理的业务模型（本体）
分工就此划定：人类负责业务建模，LLM 负责读取模型、完成底下的一切技术实现

AI 时代的工程竞争，正在从「谁写得快」变成「谁说得清」。

参考

何明璐老师（「人月聊IT」）：本体建模规范（三模型 → 十一大模型）——2.2 / 2.3 / 3.1 / 3.2 节的模型体系与四步流程出自此规范。开源：https://github.com/sharptoolbox
Thomas R. Gruber, A Translation Approach to Portable Ontology Specifications, 1993 —— 2.1 节本体定义
Michael Polanyi, The Tacit Dimension, 1966 —— 1.3 节隐性知识
Palantir Foundry Ontology —— Object / Action / Function 的对应关系，见 2.3 节

关键词

AI Coding · Ontology（本体论）· 业务建模 · 业务与技术实现隔离 · 上下文窗口

posted @ 2026-09-20 16:53 BomberShell 阅读(13) 评论(0) 收藏举报

刷新页面返回顶部

沐风之境

业务建模与技术实现隔离的开发方法

AI Coding 的瓶颈从来不是代码

——业务建模与技术实现隔离的开发方法

一、为什么：瓶颈从「写代码」上移到了「说清楚业务」

1.1 前提：编码上，人类已无比较优势

1.2 证据：失败模式全部指向业务，不指向代码

1.3 追问：为什么不直接「把需求说清楚」？

1.4 出路：让 LLM 做翻译，但译文必须结构化

1.5 立论：六句话

二、怎么切：用一个能被推理的业务模型，分开业务语义层与实现层

2.1 本体：三个词，治三个病

2.2 体系：从三模型到十一大模型

2.3 对齐：和 DDD、经典本体论、Palantir 的关系

2.4 形态：写成 YAML

2.5 收益：模型给 agent 全局视角

2.6 边界：模型必须技术实现无关

2.7 分工：线画在哪

三、如何落地：四步流程、技术底座与几个反直觉

3.1 流程：四步

3.2 底座：不能每次重新生成

3.3 成本：换的不是工序，是成本结构

3.4 组织：程序员角色上移，不是消失

3.5 坑：五个

3.6 起步：两周验证

结语

参考

关键词

公告