定义即内核：人与模型都换了，什么资产还能跑

AI编码只是表象，真正变化的是整个开发流程。腾讯工程团队的OK平台交出了一组亮眼数字：端到端AI交付需求，自动化率68%，51%的需求在两小时内完成。数字回答了"快"，但没有回答一个更锋利的问题——迁移到这套工作方式后，什么留在了组织里，什么随着人和模型一起离开。

作者用一个下午与上级梳理了这个问题，判据只有一句话：换人、换模型、换供应商，系统能否以接近的质量和速度继续运行？能，它属于组织；不能，它只是某人的手感、某一代模型、或对某家供应商的锁定。

没有边界的问题只是愿望

"我要研究一个行业需要什么软件"——这不是问题，是愿望。愿望没有停下来的地方，也没有办法被检查。

上级把问题拆成三层：问题本身是什么、谁在什么角度观察、边界在哪里（即领域）。前者被拆成三个可收敛的子问题：Agent时代行业需要什么软件（需求基线）、当前开源项目能提供什么且是否稳定可集成（供给面）、软件如何组件化（技术方法）。分开后，每个子问题都有收敛位置。

定义决定做什么、什么算对。写在wiki上没人执行的定义是负债；焊死在一套工具上的定义在工具更换后消失，同样不是资产。真正内核的判据是：载体更换后它依然在，并且能约束下一次运行。

契约式设计（Design by Contract）由Bertrand Meyer在1986年为Eiffel语言提出，核心是把前置条件、后置条件与不变量作为程序的一部分（可被运行时检查），而非文档中的提醒。前置条件规定调用方必须满足什么，后置条件规定被调用方必须保证什么，不变量则在整个生命周期中恒真。它与本文所说的"闸门"思想高度同构：检查不是写给模型的愿望，而是运行时执行的判定。在AI Agent场景中，传统契约的调用双方都是确定性的；而Agent引入了非确定性生成，因此契约的执行方必须外移——由模型之外的运行时来断言条件是否成立，模型本身不参与是否通过闸门的判断。

结构必须有，但写在提示词里的结构拦不住已发生的事

"没有形式，内容无处安放。没有身体，谈什么灵魂。"形式不是给文档盖章，而是内容需要一个结构来承载。大多数提示词只是一句线性描述，模型只能猜。上级要求把目标、上下文、条件与约束、输出格式、关键约定、注入位置、引用段落分开写就——目标可以有子目标，上下文按需加载，约束分层注入，流程中的检查点单独标记。提示词应当可折叠、可注入、充满变量，像代码里的循环或队列那样组织。

但真正的问题在后面：你在提示词里写"如果不过就澄清"，模型已经给出答案，它把这一步当作完成，继续往下走。你的句子从未获得执行机会。结构仍然需要，但写在提示词里的结构是软的。要让流程能停下来，检查必须坐在模型外面，成为运行时的一个原语、脚本中执行前后的强制检查点——不过就不能进入下一阶段。这和契约式设计是同一件事：前置条件、后置条件、不变量是系统的一部分，不是文档里的提醒。如果这些检查只活在一个产品里，换供应商时整套就消失。必须留下的是检查在找什么，而不是检查建在哪里。

同一条规则，放在两个地方，结果不同

高维数据可以当程序用，程序本身也是数据。字典、知识库、规格、规则看起来都是数据；结构足够好时，它们能驱动流程。写更少的固定步骤，写生成步骤的规则。

场景只需一种规则：缺了它就没有下一步。一个跨域请求需要五个维度，对方只给了两个。把"维度不全就停止"写进提示词，模型填完表单，当作已处理，继续。把同一条规则写成运行时提交前必须读取的记录：五个字段，缺三个，这一步不打开。前者指望模型服从，后者宣告条件不成立，下一步在流程中根本不存在。要让字典或规格充当程序，模型之外必须有东西去读它。模型可以是生成内容的机器，但闸门不读提示词里的愿望，闸门读记录。

本体描述世界，闸门检查这一次

本体描述这个领域包含什么，闸门检查这一次是否被允许。规格可以写"确认发货"，但这不意味着这一次发货可以走。闸门必须独立于本体。

对话最终被收拢为四个词：实体、关系、动作，加上上下文。本体中的动作是业务动词（检查库存、确认发货），描述这个世界里能发生什么；关系描述什么连接什么；上下文是这一次的场景。写下来就是规格，让人或模型有可能做对。闸门上的动作则是"这一次是否被允许"：字段是否完整、能否进入下一阶段。这一层不写进规格里指望被服从，它是执行时的检查。

演化被分成三级：某个领域规格长什么样是顶层，该形状下的具体内容是中层，某个具体实例是底层。越高越通用，越低越具体。内核只取"载体更换后仍能约束下一次运行"的那一层——规格的形状属于这一层，它决定有哪些槽位、什么算对。槽里的内容只在有人维护它时才算数；无人维护，内核就只剩形状。过期的内容可以完好无损地搬到下一个载体上，但下一次运行不再受它约束。检查在找什么、"什么算对"被执行——形状就是这个问题的边界和那句"什么算对"被写下来的方式。两边匹配时，它仍是同一层；检查在找的东西和"什么算对"不匹配，那是故障，不是多出来的一层。

通用方法加领域实体，才是能落进某个领域的东西。这不意味着每个行业都必须发明自己的方法，空模板不会自动变成行业结论。作者上级后来先转向制造业——这是一个决策：元方法先落地制造业，而不是先铺到所有行业。

本体（Ontology）源自哲学，在计算机与知识工程中指的是对某一领域内概念、属性及其关系的显式、形式化规格。它回答"这个领域里存在什么、能发生什么"，常见形式包括类、属性、实例、关系约束。与本体常并列的概念是知识图谱：知识图谱通常指以实体-关系-实体三元组构成的大规模事实集合，是本体的具体化实例。本文所说的四个词——实体、关系、动作加上下文——正是对本体最精简的工程化压缩。本体的价值在于让人与模型对同一领域形成共用词汇，它本身的真伪、覆盖是否完整，需要外部检验，这也解释了文中"闸门拦不住五个维度本来就是错的五个"这一判断。

错误一定会发生，笼子决定你敢不敢用

Agent无法避免错误，关键是公司敢不敢使用一个会犯错的Agent。给它一个笼子：入口有闸门，出口有检查，出错可回滚，重要决策点有人，越权时由人决定是否授权。前置检查也在笼子里：五个字段缺三个，这一步就不该开始；检查输入是否合法是必需的，不是跑完再看的。这个检查能拦住缺失字段，但拦不住下一节的情况——槽位填满了，问题依然没有唯一答案。

两件尚未解决的事

第一，形式化如何持续。结构、字典、知识库、规格，谁写、谁改、谁在过期前更新？太粗没用，太细会僵。形式化很昂贵，工具能降低成本，人仍然觉得麻烦，称之为形式主义。当一个人离开，从未写进系统的知识就断了。组织为什么要持续把东西写成结构？工具不降低意愿——系统已经可以很便宜，人仍然不用。无人维护，内核就只剩形状。

第二，如何发现结构本身是错的。回到那个请求：五个维度填满了，闸门放行，另一个人依然给不出唯一答案。闸门能拦住缺失字段，拦不住"这五个维度本来就是错的五个"，也拦不住知识库沿着错误地图运行。错误的内容被当作真的保存下来，用内核自己的尺子量仍然算数。所以"质量还在不在"不能由内核自己评分。模型读不懂过于复杂的结构，或上下文太长时表现变差，是今天的能力下限；这个方法还不能在所有场景运行，但那个下限不是方法的永久边界。

形式主义（formalism）一词在日常语境中常被当作贬义，指只走形式不走内容。但在软件工程与知识工程中，形式化是指把隐性知识写成可被机器读取、可被校验的结构，其成本主要来自三处：获取（谁把专家的手感写下来）、维护（规则过期前谁更新）、以及校验（怎么知道写下的规则是对的）。文中"太粗没用，太细会僵"正对应形式化的粒度权衡问题。当组织把形式化外包给工具时，成本可以降低，但意愿不会自动提升——这是组织知识管理中长期存在的激励错配，与本文"无人维护，内核就只剩形状"的判断一致。

你能带走的东西

模型会被替换，会变成普通商品，会开源；提示词技巧会迅速失去价格。只坐在wiki上的规则是负债，焊死在一个工具链或一个产品里的规则在载体更换后消失，也不是资产。

你能带走的是那一层——载体更换后它依然在，且仍能约束下一次运行。工具链、运行时、闸门建在哪个产品里，都是载体。质量还在不在，必须从内核无法篡改的外部结果来读：交出去的东西能不能用，接手的人能不能真的接住，出错时外面的人能不能看见。一个错误的内核可以完好无损地搬到下一个载体上，并用它自己的尺子觉得自己跑得不错——那仍然不是资产。

同样的检验适用于OK平台：68%的自动化率、51%的需求两小时内完成，回答的是"快"。快是一个外部数字，度量吞吐，不回答换新模型、新团队、新供应商之后，外部是否还能看到接近的质量。那个数字还没有。在它出现之前，这篇材料展示的是吞吐，不是资产。

作者最后说明：本文整理自一次内部对话，判断来自其上级；第四节中本体与闸门的关系、动作分为两层，是整理时的补充；把内核收拢为"仍能约束下一次运行的那一层"、内容只在有人维护时才算数、从外部结果读质量，是整理时划定的边界。这是一个方向，加上尚未完成的工程问题，不是完整答案。