从使用中变好

从使用里长出来

合并只是一次改动。本体（Ontology）要一直跟着业务长，靠的是一个循环：应用和智能体每天使用它，使用留下证据，证据变成提案，提案变成新的语义版本，新版本又被使用。

自进化 SDK 用 aidc evolve 提供证据与提案命令。evidence 汇总证据；suggest 用提供的材料起草提案，按公司计费。用户在应用里提出的改进也是证据。智能体处理语义类提案时，不能直接 apply，须转为本体分支提案。

aidc evolve evidence procurement-board
aidc evolve suggest procurement-board --file 采购口径.md --conversation 采购群.txt
aidc evolve proposals --status open
aidc evolve accept <提案 id>
# 智能体的语义类提案：转成定义文件，再走分支
aidc semantic branch create add-promise-synonym
aidc semantic branch modify add-promise-synonym ./ontology-change --dry-run
aidc semantic branch modify add-promise-synonym ./ontology-change
aidc semantic branch propose add-promise-synonym --title "补交期同义词" --trigger "采购员的说法匹配不到属性" --self-test "分支定义已包含同义词"

两种形状，今天并存

自进化的语义类提案只做加法，有五种操作：改说明（describe）、加同义词（synonyms）、加语义层属性（addColumn）、给枚举加值（addEnumValues）、加 Action（addAction）。开发者应用后自动发新语义版本。智能体直接应用会返回 branch_required，须转为分支提案。删属性、改类型、改主键不走语义补丁。

比如采购员总说「交期」，而属性上没有这个说法，智能体找不到。补一个同义词就够了：

{
  "target": "semantic",
  "title": "给到货日期补上业务说法",
  "rationale": "采购员总问「交期」「承诺交期」，属性上没有这些说法，智能体找不到",
  "patch": [
    { "op": "synonyms", "entity": "DeliveryPromise", "column": "promisedDate", "add": ["交期", "承诺交期"] }
  ]
}

把它存成 proposal.json，用 aidc evolve propose --spec proposal.json 提出。今天有两种形状可选：

说明、同义词等小改动可以先写自进化语义提案。智能体须把语义补丁转成定义文件，再走 branch create / modify / propose。新 Object Type、新 Link Type 和删除、改类型也走分支提案。review 由人审核；yolo 可由合格贡献者批准并自动合并。

评测问题集：改前问一遍，改后再问一遍

「改好了」的标准是业务问题能答出来，不是结构好看。做法是智能体自己维护一份问题清单。问题来自真实工作：采购员每周问的、管理者反复要的，不是从现有模型能答什么倒推出来。答不出的也留在里面，它们就是下一次的触发原因。

每个问题存成一条只读 SQL。DeliveryPromise 合并、数据流绑定之后，第一个问题可以这样查：

SELECT s."name" AS supplier, m."name" AS material, count(*) AS latePromises
FROM "DeliveryPromise" d
JOIN "purchaseOrder" p ON p."poNo" = d."poNo"
JOIN "supplier" s ON s."supplierId" = p."supplierId"
JOIN "material" m ON m."materialCode" = p."materialCode"
WHERE coalesce(d."receivedDate", current_date) > d."promisedDate"
GROUP BY 1, 2
ORDER BY 3 DESC

存成 questions/late-suppliers.sql，一条命令跑完，把结果存下来对比：

aidc semantic sql --file questions/late-suppliers.sql --csv > after.csv

• 提案前：把清单跑一遍，记下哪些答不出。这就是提案的触发原因和验收标准。
• 合并、绑数据之后：再跑一遍。答出来的写进提案记录；原来答得出的，不许变成答不出。
• 找人对照：让一个不熟悉模型的人试同一批问题。智能体答得出、人答不出，多半是名字、同义词或说明不清；人答得出、智能体答不出，多半是有业务知识只在人脑子里，没写进本体。

护栏：让错误便宜

智能体可以一直改，前提是每一次改都便宜、可查、能被拦住。常用的护栏有这几条：

试跑不写入，分支改动在合并前不影响 main。review 等人审核、合并；yolo 在有效批准和检查通过后自动合并。每次合并都有提案记录和语义版本，可用 aidc semantic releases 核查。安全策略改动仍须人批准。