夜雨聆风今天，用AI生成代码已经不难。进入企业研发现场，更难回答的是：它凭什么在具体业务里写对？
8月21日至22日，第10届AI+研发数字峰会（AiDD）北京站举行。优锘科技CTO白靖受邀在主会场发表《AI原生产品研发和本体工程实践》主题演讲。他把问题落到企业研发中更棘手的一层：分散在系统、文档和个人经验里的业务知识，怎样成为AI可以读取和校验的规则。
白靖在演讲中给出一个公式：AI原生研发 = 本体（确定性边界）×智能体（概率性生产力）。本体负责组织企业知识、规则和执行边界，智能体负责生成与推理。有了这层配合，AI才有可能进入真实研发流程，参与需求、架构、代码和运行检查。
代码能生成，企业知识却没有自动跟上
大模型学习了大量公开知识，但每家企业都有自己的业务世界。同一个词，在不同组织里可能对应不同对象；同一个指标，在不同系统里可能采用不同口径；一条架构规约，也可能分别存在于制度文档、评审记录和架构师的经验中。
白靖把AI比作一名刚入职的员工。数据散在不同系统里，它很难看清全貌；业务对象被拆成表和字段，术语与指标又缺少统一解释，即使找到了数据，也未必能沿着真实业务关系继续判断。
模型越来越强，这些问题并不会自动消失。企业知识没有被组织起来，AI看到的仍然是一堆缺少名称、关系和边界的数据碎片。
本体要做的，是为这套业务世界“赋名”。它把客户、账户、应用、接口等对象定义出来，把对象之间的关系连起来，再补上业务语义、规则和动作。企业知识不再只写给人看，也可以被机器查询、计算和校验。
在白靖的框架里，本体与知识图谱并不是两套彼此割裂的能力。本体先定义业务对象及其属性，再将对象实例通过关系连接成图谱，进一步补充准确语义，以及动作的前置条件、权限和后果。知识图谱呈现企业中的对象及其关联，本体则为这张图规定统一的概念、语义和行动边界。
白靖把本体工程拆成四步：本体化（Object Type）、图谱化（Link Type）、语义化（Semantics）和行动化（Action Type）。前三步让机器知道“世界里有什么”，行动化把动作及其前置条件、权限和后果纳入模型，继续回答“谁在什么条件下可以做什么”。本体也由此从描述知识走向约束行动。
本体不只描述世界，还要说清如何行动
白靖用信用卡挂失冻结演示了这套建模方法。
在演示中，客户、卡片、账户和挂失记录等对象先被连接成业务网络。“信用卡账户冻结”也被作为知识管理：谁能操作、提交前要检查什么、成功后还要联动哪些系统，都写进同一个动作定义。
演示里有一个具体的工程取舍：账户状态等事务内变更需要保持原子性，失败时整体回滚；短信等外部通知则在事务提交后触发。短信发送失败，不能反过来撤销已经完成的挂失冻结。资金安全优先于通知成功率。
这类判断过去往往散落在代码、制度文件和资深员工的经验中。把它写进动作模型后，业务人员可以看懂定义，AI可以读取前置条件和执行边界，系统也能留下每次执行及拦截记录。规则需要调整时，团队面对的是一份可追踪的业务知识，而不是一段难以定位的隐含逻辑。
这个案例也为演讲后半段埋下了一个问题：如果业务办理可以被本体化，软件研发本身是不是也可以被看作一项业务？
如果把软件研发本身也当成一项业务
一项企业软件需求从提出到上线，要经过需求分析、架构设计、代码开发、测试验证和运行维护。过程中需要调用哪些存量能力，允许使用哪些技术组件，接口必须遵守什么安全策略，哪些数据需要分类、脱敏和受控传输，这些都是研发业务中的对象、关系和规则。
在白靖的框架中，本体可以与Vibe Coding、规范驱动开发配合使用。项目规约说明本次交付要做什么，本体为它补充可以跨项目复用的企业环境、知识和治理约束。
演讲选择了一个常见需求作演示：某企业原有客服系统只支持电话和线下网点，现在要新增移动App自助服务渠道，让用户提交服务申请并查询处理进度。
要完成这项需求，AI不能只看到一句需求描述。演示把业务需求、现有应用、数据约束、技术准入、治理规则和安全要求连接起来。不同研发Agent看到的不再是一句孤立需求，而是同一个企业环境。
架构设计Agent读取需求时，也会查询企业现有应用和接口。在演示设定中，统一认证和工单中心已经存在，方案据此复用这些能力，只新增移动端的渠道适配，没有另起一套用户和工单后台。治理本体规定分层方式，技术本体提供组件准入范围，安全本体给出接口和数据约束。方案就在企业现有系统和规则中完成取舍。
提交代码后，另一个Agent按照同一套知识核查实现：有没有绕过分层、引入准入范围之外的组件，或重复建设已有能力。检查范围随之超出通用代码风格，落到这家企业自己的规则。
白靖将这条链路概括为三个时刻：诞生（需求到架构）、落地（代码到验证）、保鲜（运行到回归）。方案生成时，安全红线和技术准入被带进设计；代码提交时，实现与设计接受校验；系统运行后，运行态Agent再通过对比设计本体，对未经审批的变化触发“架构漂移”告警。架构于是贯穿设计、实现和运行，不再只在评审会上出现一次。
演示还设置了一条明确限制：生成方案的Agent与负责合规检查的Agent在平台上分开，避免同一个Agent“既当运动员又当裁判”。AI负责规则的读取、流转和重复检查，人仍然负责价值判断，以及规则无法覆盖时的异常裁决。
先让一条规则进入研发流程
优锘正在把上述方法落实到AI原生企业架构治理平台中，让业务对象、架构规则和校验结果能够在需求、代码提交与运行检查之间流动。产品化的着力点，是让原本写在文档里的规则进入实际研发节点。
落地不必等到七类本体全部建完。白靖建议先选一个边界清楚、结果可验收的问题，例如把团队最头疼的10条架构规约改成机器可读规则，接入代码提交检查。先让第一条规则真正拦住一次违规，再逐步补全对象和关系。
除了生成速度，企业还要知道结果依据了什么、是否越过规则，出现偏差后能不能查清。
白靖最后留下了一句话：“让架构从墙上的图，变成代码里的基因。”这句话里的“代码里的基因”，是指规则不再等到评审会上才出现，而是在生成、提交和运行时持续起作用。
