ONTOLOGY / AI × ONTOLOGY22 OCT 2026
AI 系统真正的资产，是一份说明书
做一个给自己用的 AI 系统做到第二个月，我才想明白一件事。
一个 AI 系统真正的资产，不是那几万行代码，而是一份说明书。
DEFINE 01 说明书定义 |
EXECUTE 02 程序照着做 |
EVOLVE 03 版本与血缘 |
这份说明书有个不太好懂的名字，叫「本体」。我自己的系统里，本体是两样东西拼起来的：
—一个 python 程序——照着说明书去数、去查、去报异常
说明书定义，程序执行。程序自己不定义任何东西：说明书怎么写，它就怎么数。
这篇把这句话拆开讲清楚。
ONTOLOGY / 01
一、说明书写什么
说明书只回答三个问题。
第一，有哪几样东西。 我的系统只认五样：要判断的事、读过的文章、书、判断、原始材料。不是五样里的，系统不管。
第二，每样东西在哪。 比如「书」放在书库那个目录里，「判断」一张一张放在判断卡目录里。说明书里一行字：这一样的料，从这个目录来。
第三，每样东西有哪几种状态。 比如一条判断，可以是「待回看」「站得住」「错了」「条件变了」；一篇文章，可以是「还没回看」「用过」「没用上」。
就这三样。怎么判断、怎么写文章，一律不写进来。 那是另一回事，归 AI 自己去想。
说明书是 md 格式，就是带几个井号和星号的纯文本。人能读，AI 也能读。 这一点后面会看到有多要紧。
ONTOLOGY / 02
二、程序做什么
程序只做三件事，都是「照着」：
照着数。 说明书说「书在这个目录」，程序就去那个目录数，数出来 86 本。它不判断哪本是书——说明书说是，它就数。
照着查。 说明书说「判断有回看日期」，程序每天看一眼：到期了没有？到期了，就把这条判断端到我面前，只问一句「当时写的那个作废条件，出现了没有？」
照着报异常。 说明书和实际对不上的地方，程序当场报出来。比如：说明书说开着的定时任务，实际没装；同一份材料被两处同时收了；说明书改过了，变更记录却没跟上。
注意这三件事都很笨。笨是故意的——程序要做的是「照着」，不是「想」。想的那一段，留给 AI。
ONTOLOGY / 03
三、一个今天的真例子
我系统里有一类东西叫「标的」，意思是「要判断的一件事」：一家公司的护城河，一个药的临床证据。
前两天体检报出来：标的 489 个。
我请两家不同公司的 AI 分别来审，两家都指出同一个问题：这 489 个里，有三百来个根本不是「要判断的事」——书库的副本和备份、写书的大纲、几套分析框架、变更日志，因为放在同一个大目录底下，被一起数了进去。
怎么改？
我没有改一行程序。 我只在说明书里，「标的从这个目录来」那一行后面，加了一句「跳过这几个子目录：书库副本、大纲、框架、日志」。
程序下次一跑，标的变成 204 个。
这就是「说明书定义、程序执行」的意思：改的是定义，定义只在一个地方；程序一个字不动，自然就对了。
反过来想：要是「什么算标的」写死在程序里，每次改定义都得改代码；改代码就可能改出新毛病；而且改完之后，除了写代码的人，没人说得清现在「标的」到底指什么。
ONTOLOGY / 04
四、为什么用说明书，不用数据库
做企业系统的人会问：对象、关系、状态，不是该放进数据库吗？
我的回答是：看你的东西本来是什么。
我系统里的东西，本来就是一份份文件——一本书是一个文件，一条判断是一个文件，一篇文章的评分是表格里的一行。把它们搬进数据库，多一层搬运、多一层对不上的可能，换来的好处我用不上。
用 md 说明书有三个实打实的好处：
—我自己能读。 我不写代码，但我打开说明书，看得懂系统里有什么、在哪、什么状态。数据库我就看不懂了。—AI 能读。 AI 干活之前读一遍说明书，就知道系统的边界在哪。这一点比给它看几万行代码管用得多。—改了马上生效，没有「迁移」这回事。 数据库改一次结构，历史数据要搬家；说明书改一行，程序下次跑就照新的来。
ONTOLOGY / 05
五、本体不住在模型里
这是我觉得最值钱的一点。
我的系统现在跑着好几个 AI 助手，背后是不同的模型。它们都在用这份说明书，没有一个住在里面。
本体是 md 加 python，不依赖任何一家的模型。哪天换了模型，换了执行它的那一层，说明书还在，程序还在，系统里有什么、在哪、什么状态，一样不丢。
今天有个现成的证明：我请两家完全不同公司的 AI 来审系统，它们拿同一份说明书，各自查出了真问题——一家找得深，一家证据扎实。说明书不认人，谁来都能用。
所以真正的资产是说明书，不是哪个模型，也不是哪段代码。
ONTOLOGY / 06
六、难的不是做出来，是往下长
一个朋友看完我的做法，提醒我：本体系统真正的难点不在「做出来」，在「演进」——定义改了一次又一次，怎么不乱。
他列了五根柱子：版本、权限、审计、血缘、和执行层解耦。我逐条对了一下，我的系统只缺其中两根：
一是版本号。 说明书每改一次定义，升一个版本号，再在变更记录里追加一行：改了什么、为什么、改前改后的数、改前的备份放在哪。只追加，不覆盖。程序会查：说明书改过了而记录没跟上，当场报出来。
这样任何一次改动，都能退回到「改前的样子」。
二是血缘——每样东西的料从哪来，只定义一次。
我系统原来有两张「料从哪来」的表：本体那边一张，查资料那边一张。两张表各写各的，就各漏各的。前两天审计查出来的毛病，一大半是这种：本体数的和查资料收的，对不上。
今天我把它收成一处：料从哪来，只写在说明书里；本体和查资料都读这一份。 改之前先把新旧两种读法逐份对比，查资料收的 1577 份材料，一份不差，才切过去。
另外三根柱子，我判断不用投入：
—权限：我的系统只给我一个人用，它只对我说话。对内，AI 放开干；对外，一律走固定的程序。企业那套「每个对象都绑权限」，搬过来是给自己找麻烦。—审计：对外每发一次，程序都记一行账；AI 的每一步，本来就有记录。够了。
不是少做，是按自己的边界做对。 别人的好方子，得先对一对自己的病。
ONTOLOGY / 07
七、一句话
说明书定义「有什么」，程序照着数、照着查、照着报；AI 在说明书划好的地方里放开干活。
模型会换，代码会改，说明书留下来。