S30：最小 AI Use-Case Manifest
Use-case manifest 是应用团队向 AI 平台提交的最小声明，明确用例身份、所有者、数据用途、模型和工具依赖、运行边界及 SLO 意图，使平台能够解析而不是猜测。
内容类型：预习教材（不代表已完成）
日期：2026-12-22
阶段：P2 · AI Systems Engineering 90
总路线：Day 120 / 360
周次 / 节奏：W5 · 周二最小实现
状态：教材已备；学习未完成
主题：use-case manifest、owner、data/model/tool/SLO bindings
一句话定义
Use-case manifest 是应用团队向 AI 平台提交的最小声明，明确用例身份、所有者、数据用途、模型和工具依赖、运行边界及 SLO 意图，使平台能够解析而不是猜测。
学习目标
- 能定义一个简短 YAML/JSON manifest，覆盖 owner、data、model、tools、policy、SLO 与 evidence。
- 能区分声明式 desired state 与 runtime observed state。
- 能设计 schema version、引用、默认值和 validation error。
- 能避免把 secret、敏感正文和动态指标写入静态 manifest。
核心知识
Manifest 应声明“我想运行什么和受哪些约束”，而不是嵌入所有实现细节。Identity 字段包括 use-case id、version、owner、environment；data binding 说明数据产品/索引引用、purpose、classification 与 freshness 需求；model binding 引用 registry/bundle；tools 写允许能力和 scope；runtime 写并发、deadline 与降级意图；SLO 写用户可见目标；evidence 写 trace/eval/audit 需要的关联级别。
Owner 不应只有团队邮箱，还可区分 business、technical、data 与 risk owner，但本日保持简短。引用应使用逻辑名称+immutable version/digest，运行时 secret 通过 secret manager binding 注入，绝不写明文 token。Manifest 的 schema version 管理文档结构，use-case version 管理业务声明，两者不是同一版本。
Control plane 读取 manifest，验证必填与交叉约束，解析引用，生成 desired state；controller/reconciler 尝试让 runtime 达到该状态。Observed state 包含实际 bundle、endpoint、健康和最近错误，不应由用户手工写回 manifest。一次声明被接受只证明结构和平台规则满足，不证明业务用例正确。
机制与推导
可把解析流程表示为：
[ manifest\xrightarrow{schema\ validate}typed\ intent \xrightarrow{policy+reference\ resolve}desired\ state \xrightarrow{reconcile}observed\ state ]
Validation 分结构与交叉语义。例如有 write tool 时必须有 approval/compensation 声明；高敏数据不得绑定无允许地域的 provider；timeout 应小于上游 deadline。错误应有 path、code 和说明，如 tools[0].scope: UNKNOWN_SCOPE，不只返回 invalid。
SLO 是意图而非事实，例如 p95 TTFT target、成功任务率和成本上限；真实值属于 telemetry。Manifest version 改变应产生 diff，控制面可决定重新部署、仅更新策略或拒绝不兼容变更。
最小练习或观察步骤
- 选一个纯合成的“AML 案件摘要助手”，不接真实客户数据或外部写操作。
- 写不超过约 50 行 YAML/JSON，含 metadata、owners、data、model、tools、runtime、slo、evidence。
- 为所有 artifact 使用逻辑引用和 version；secret 只写
secretRef名称或完全省略。 - 写一个最小 validator 或纸面规则，制造 owner 缺失、未知 tool scope、timeout 冲突三个错误。
- 画 desired/observed 两栏，说明控制面接受后哪些运行事实仍未知。
- 改一个 tool scope，生成 manifest diff，并判断需要何种轻量复核。
常见误区与边界
- Manifest 变成数百行底层部署配置，失去用例意图。
- 把 API key、真实 prompt 输入或 PII 示例直接写入仓库。
latest引用所有模型和数据，无法解释实际组合。- 用户手工维护 observed health，造成声明和事实混杂。
- Schema 验证成功就宣称业务安全、质量合格或已经上线。
系统场景连接
多个金融 AI 用例若各自用文档/聊天约定 owner、模型、数据和权限，平台很难做统一目录、成本归属和事故路由。Manifest 提供共同语言：控制面解析绑定，runtime 执行，evidence plane 按 use-case/version 关联信号。它也为后续 policyEngine、agentRegistry 和 tco 的引导练习提供连接点。
自检问题
- Schema version 与 use-case version 各自管理什么？
- Desired state 和 observed state 为什么要分开？
- 哪些内容绝不能直接写入仓库 manifest？
- Manifest validation 成功后仍不能证明哪些事项？
专业课程对齐
- 阅读 Full Stack Deep Learning 2022 的 infrastructure 与 deployment 内容，提取一个用例从代码到服务需要声明的最小依赖与运行目标。
- 阅读 Stanford CS329S 的 requirements、system design 与 monitoring 主题，把 stakeholder 目标转译为 owner、data boundary 和可观察 SLO，而非只写技术字段。
- 阅读 MLflow 官方文档 的 model/artifact URI 与 registry 引用概念，比较逻辑 alias 和 immutable version 在 manifest 中的适用位置。
深入学习提示
先写一个真实用户问题和失败后联系人，再写字段。每个字段都问：谁提供、谁消费、是否静态、是否敏感、变化是否生成新版本。用三个非法 manifest 检查 error 是否可行动。最后追踪一条声明从 control plane 到 runtime，再从 evidence 返回 owner；若无法闭环，说明 manifest 仍缺少身份或关联，而不是需要继续增加所有平台细节。
学后填写区
- 我的合成用例与 owner：
- Manifest 主要字段：
- 三个 validation error：
- Desired / observed 差异：
- 一个需要后续平台决定的默认值：