TOGAF 文档虽多，但它偏“规划视角”——告诉你“要做什么”，不直接告诉你业务系统里到底有哪些表、字段、动作、约束。53AI 的这篇文章（作者：人月聊IT）记录了一次完整尝试：把一套手机行业 TOGAF 架构规划（7 章约 70 万字、50 多份 Excel 附件），抽象成本体模型，再拿真实业务验证它能否撑起 LTC（线索到回款）端到端流程。

第一步是抽象：把规划文档归纳为四类——业务对象（名词）、业务行为（动词）、业务规则（约束）、业务场景（端到端流程），正好对应本体建模的四个核心元模型。作者把供应链、研发、制造、营销、售后、人力、财务、战略 8 大业务域逐个过了一遍，统计出 206 个业务对象、182 个业务行为、93 条业务规则，每个对象都对照 ERP/CRM/MES 的真实表字段列属性，并用五分类（主数据/事务/行为/规则/指标）打标。

第二步是建模：按《本体建模规范》写 Python 脚本把 22 份 Markdown 表格解析成 4 个 YAML（objects/behaviors/rules/scenarios），对象的跨域引用 100% 解析得上。文章如实记录了三个坑：属性误拆（“产品 SN/IMEI”这类含斜杠的属性被切碎）、ID 归一（带括号变体的对象引用连不上）、场景行为命中率（14 个场景 154 个步骤只精确命中 49 个，其余留待语义对齐）。

第三步是验证：按 LTC 流序逐对象走查——线索→商机→报价单→销售合同→销售订单→销售发货单→销售出库单→销售发票→客户应收→收款单，十个对象一气呵成，每一步都是“对象被行为读写、被规则校验”的确定事件。模型能撑住靠四件事：可追溯（对象/行为/规则互指）、口径一致（一个对象一个权威定义）、规则在前（约束挂在网上而非藏在代码里）、跨域能通（对象就是打通点）。

作者的经验结论值得抄下来：规划文档再厚，没有本体模型托底，落到系统里照样断链、扯皮、口径不齐——本体模型不是规划之外的东西，而是规划真正“落地”的那一层。这套 YAML 还能直接生成 485 节点、1087 条关系的知识图谱给业务评审用，行为与规则声明则等于给 Agent 提供了“能做什么、改什么、受什么约束”的可执行接口。