如何用履约建模法给 AI 准备业务上下文
一句话先讲清楚
我用履约建模法，不是为了先画一套业务图，而是为了在构建软件之前，先把真实协作里的角色、承诺、交付、验收和异常整理成 AI 能理解的业务上下文。
这句话是核心。
30 秒版本
我后来发现，很多业务问题不是功能没做出来，而是上下文不稳定。人还能靠经验补齐，但 AI 不行。AI 如果拿不到稳定的角色、责任、交付和完成条件，它参与需求分析和方案设计时就会漂。所以我先用履约建模法把真实协作里的履约关系抽出来，变成 AI 可消费的上下文。再往后因为沟通成本太高，我又把这些隐性的关系继续显式建模，最后才进入软件实现。
1 分钟版本
我做这件事的出发点，其实不是先做页面或者接口，而是先解决 AI 怎么理解业务。因为在真实协作里，很多关键东西并不在代码里，也不在一份完整文档里，而是散落在人的经验、口头沟通和默认认知里。
比如谁对谁负责，承诺交付什么，什么叫完成，如果中间出了异常该怎么处理。这些东西对人来说已经很容易沟通失真，对 AI 来说问题更大，因为 AI 一旦没有稳定上下文，它参与需求分析、流程拆解和方案生成时就会不稳定。
所以我先引入履约建模法，把这些现实里的履约关系整理出来，先变成一套结构化业务上下文，供 AI 和人共同使用。后来我又发现，真正高的成本不是编码成本，而是沟通成本，所以我又进一步把这些关系显式建模。这样最后做软件时，系统承接的就不只是功能，而是一套已经被讲清楚的协作结构。
2 到 3 分钟版本
我理解履约建模法的价值，不是在传统意义上做一套很理论的业务建模，而是给 AI 准备业务上下文。
因为我观察到，真实生活里的很多问题表面上看是流程问题，实际上是履约关系不清楚。也就是说，谁对谁负责、要交付什么、什么时候算完成、异常怎么处理，这些关键语义往往没有被显式表达出来。很多时候它们存在于人的脑子里，靠沟通在传递。
这对人来说会带来大量沟通成本，对 AI 来说就更严重。因为 AI 如果拿不到稳定的业务上下文，它看起来可以回答很多问题，但实际上并没有真正进入业务语境。你让它参与需求分析、方案设计或者任务拆解，它会很容易漂。
所以我先用履约建模法，把真实协作里的关键关系抽出来。这里我最关心的不是页面和表，而是几个问题：有哪些角色，彼此之间有什么承诺，交付物是什么，验收标准是什么，状态怎么推进，异常怎么处理。等这些东西整理清楚以后，AI 才算真正拿到了业务上下文。
但做到这里我又发现，只是“梳理清楚”还不够，因为真实项目里最大的成本往往是沟通成本。大家在讨论同一件事时，对对象、动作、完成标准的理解并不一致，信息会在传递过程中不断失真。所以我后面就不是只做流程整理了，而是把这些履约关系进一步显式建模。
这样做的价值是，原来散落在人脑、口头和零散文档里的信息，被沉淀成统一模型了。AI 可以基于这个模型理解业务，人和人之间也能基于这个模型对齐，最后软件实现才有稳定基础。
所以如果总结一下，我做的不是“先建模再开发”这么简单，而是“先用履约建模法给 AI 建立业务上下文，再因为沟通成本问题，把上下文继续显式建模，最后才进入软件实现”。
如果面试官问“为什么是履约建模法”
因为它天然适合处理真实协作问题。很多业务系统真正复杂的地方，不在字段和流程节点，而在承诺关系、交付边界和异常处理上。履约建模法正好逼着我先把这些事情讲清楚，所以它很适合拿来做 AI 的业务上下文准备。
如果面试官问“这和普通需求分析有什么区别”
普通需求分析很多时候还是围绕功能清单，但我这里更关注的是协作结构本身。也就是说，不只是系统要有什么功能，而是现实世界里到底谁和谁之间存在什么履约关系，这些关系怎么被 AI 理解、怎么被系统承接。我觉得这个视角更接近真实问题。
如果面试官问“沟通成本具体指什么”
我的理解是，沟通成本不是开会多，而是同一件事在不同人脑子里不是同一个东西。比如谁负责、什么算交付完成、出了异常谁接手，这些如果没有被显式表达，就会反复确认、反复返工。我后面做显式建模，本质上是在降低这种理解偏差。
最后一句收尾
所以这件事对我来说，重点不是先做了一个模型，而是先把现实协作里的履约关系整理成 AI 可用的上下文，再把高沟通成本的问题变成统一模型，最后才去做软件。