上线、运营与演进

上线清单

上一课把四个闭环连成了一个系统，这一课让它上线，并长期转下去。打开自动化之前，逐项核对一张清单。每一项都要能用命令或页面确认，不靠感觉：

1. 验收问题

   一页设计第 6 栏的问题，人和智能体都答对了。

2. Action

   每个 Action 都做过一次通过、一次失败的 --validate-only。

3. 工作流

   aidc app deploy --dry-run 没有解释不了的告警，test 通道预演过三种情形。

4. 通知

   aidc notify test 收到了；收件人都是本公司账号，不超过 5 个。

5. 权限

   批准类 Action 的 roles 与提交条件、一般访问和分享对象都核对过。

6. 数据

   绑定状态正常，看门狗已经就位。

7. 停用版

   一个只保留手动触发的版本已经发布过，运行手册写好了。

运行手册可以直接做成应用的一条 Skill，放在包里的 skills/{name}/SKILL.md。别人（或智能体）复制这个应用时，读到的是同一份手册。

采用度：有没有人真的信任它

自动化上线后，要问的不是「跑没跑」，而是「有没有被信任」。看四个指标：

aidc semantic observability summary procurement-watch --days 7
aidc semantic aggregate log.create-purchase-order --select '{"$count":"unordered"}'
aidc semantic aggregate log.approve-purchase-order --select '{"$count":"unordered"}'
aidc semantic observability events --app procurement-watch --kind feedback --status open

采纳率低，不一定是模型差。先看建议是不是来得太晚、太多，关口是不是设错了地方，再看反馈。使用与错误记录保留 180 天，反馈与操作长期保留，所以趋势可以看得比较久。采纳率稳定、改回率很低的自动化，才有理由升一级自主程度。

版本与破坏性变更

本体（Ontology）和应用各有版本。语义版本由 aidc semantic publish 发出，只增不减，定义没变不占号；应用版本是清单里的 version，改了任何东西都要升。核心模型的原则是：开放扩展，谨慎修改。

改名分步做：先加新名字，让调用方迁过去，再把旧属性标为 deprecated 或 experimental，定义或合并该状态后才删除。发布前用 aidc semantic define ontology/ --dry-run 看破坏性变更，用 aidc app registry 看哪些应用在读写它。工作流的 with 参数要与 Action 参数对应，部署时不匹配会被拦下。

成本、节奏与接下来学什么

成本靠按需。每个应用每月缺省 2000 计算分钟，用到 80% 就会有提示，用 aidc app usage 看；触发优先于定时，定时最密每 5 分钟，1 小时以内都会告警。没有人看、没有变化的时候，就不该有东西在跑。

1. 每周

   审提案：aidc semantic proposals --status OPEN。分支 35 天没有动静会转为 INACTIVE，再过 7 天删除，所以别让提案积压。再看反馈和自进化的提案。

2. 每月

   看计算分钟与被拦下的通知；对照采纳率，决定要不要提高自主程度。

3. 每季度

   换一批新的验收问题重测；复查 roles、分享与 Public 的设置。