Maintenance — 所有权 · 更新规则 · 晋升管道¶
最终更新: 2026-08 · owner: Youngjin · volatility: 低 ← 返回 index
L0 TL;DR: 定义让这份 playbook 不过时的结构。分离易变/稳定信息，为所有条目附上所有者·更新日·易变性，并通过门禁筛选 Slack 候选来晋升。本页面本身就是运营规则。
易变 / 稳定 分离¶
playbook 过时的原因是把易变信息与稳定信息混在一起。要在结构上隔离。
| 层 | 内容 | 放在哪里 | 更新周期 |
|---|---|---|---|
| 稳定层 | 原理·架构模式·sim-to-real 方法论·决策树 | 支柱正文 (L0/L1) | 很少 |
| 易变层 | 模型版本·GPU 价格/可用性·Preview→GA 转换·基准数值·区域 | 各条目的 <details> 折叠块或 Radar |
频繁（月~季度） |
规则: 易变信息必须隔离在折叠块/表中。不要把版本数字硬塞进正文（稳定层）。让更新时只需改动折叠块即可。
必需元数据¶
没有所有者的条目不予创建。 在每个页面·条目底部:
_owner: {名字} · 验证: {名字, 名字…} · updated: {YYYY-MM} · volatility: 高/中/低_
owner: 始终只有 1 人（责任单一化原则）。若未定则标为待定 ⚠️，作为债务保留（不隐藏）。验证（可选）: 参与一手来源验证（对照官方发布·论文原文·许可证）的人 —— 可多人，用逗号列出。与 owner 相同时可省略。updated: 最后实际复核的年月。绝对日期（禁止相对日期）。volatility: 高/中/低。决定 staleness1 周期。
✅ 全部页面 owner: Youngjin —— 支柱 P1~P5·index·radar（2026-07 指定）+ decisions·maintenance（2026-08 指定），owner 债务已清偿。
Staleness 规则¶
当 updated 超过基准月数时，在页面顶部挂上 ⏳ 需要复核 徽章。
| volatility | 复核周期 | 超过时 |
|---|---|---|
| 高 | 1 个月 | ⏳ 需要复核（模型版本·GPU·区域·基准） |
| 中 | 3 个月 | ⏳ 需要复核 |
| 低 | 6 个月 | ⏳ 需要复核（原理·树） |
易变性为'高'的条目(pillar-2/3/5, radar) 采用更短周期。尤其是 AgentCore 区域·功能、模型许可证、EC2 实例 GA 变化很快。
⚙️ 已自动化: 徽章不手动添加。CI(scripts/check_staleness.py) 在构建前自动注入，且每日 00:00 UTC cron 重新部署即使不推送也会刷新徽章。若页面的 updated/volatility 元数据缺失，构建会失败 —— 元数据就是契约。
纳入标准 (THE FILTER)¶
候选需满足以下4 项中至少 2 项才纳入正文。未达则仅以一句话放入 Radar。
- [ ] ⓐ 在 production 或实际客户部署中经过验证（仅有演示视频不足）
- [ ] ⓑ 可与 AWS 服务/基础设施具体映射
- [ ] ⓒ 有实际客户或 SA 问询过的记录
- [ ] ⓓ 已 GA 或有明确的 GA 路线图
Hype 警戒: 华丽的人形机器人演示会掩盖"成熟能力"。务必将"令人印象深刻的演示"与"可部署"分开标注。（例: Figure 03 "8 小时自主"=演示 vs Digit@GXO=已验证）
成熟度标签（每个条目必需）¶
🟢 GA / 🟡 Preview / 🔵 Research-only / ⚪ Hype（仅演示）
来源等级（附于每个主张）¶
[1] 官方文档/论文 > [2] AWS 内部验证 > [3] 厂商官方博客 > [4] 未经验证（Slack/传闻）
- 数值·基准要并列注明 日期 + 来源 + 测量条件。（例: "人形 82,000 FPS —— 4,096 环境·1×RTX 4090, NVIDIA, 2026"）
- 未经验证的信息要删除或明确标为
[4]。禁止像事实一样断言。
标准模板¶
晋升的条目按此格式编写。
### {条目名} {成熟度标签}
**L0 TL;DR**: （1~2 句，是什么、何时用）
**客户需求/问题**: （在什么情况下出现）
**解决方案概览**: （核心方法 + 来源等级）
**AWS 映射**: （具体服务）
**决策标准**: （何时用它/何时用替代 —— 明示条件）
**客户案例**: （若有。没有则"案例待定"）
**➡️ 后续行动**: （连接演示/研讨会/资产 —— 务必填写）
**🔗 相关资产**: （内部 skill/研讨会/deck 深链）
---
_owner: {名字} · 验证: {名字, 名字…} · updated: {YYYY-MM} · volatility: 高/低_
强制深度分层: L0 置于最顶。L2 deep-dive 用 <details> 折叠/链接分离，使正文简短。
- 高管页面（exec/exec-guide）原则: 禁止新的技术主张 —— 仅刊载 pillar/radar 验证判定的高管语言译文。
术语脚注惯例（持续）: 纳入或更新内容时，SA 难以立即理解的术语须在同一次变更中用 [^标签] 脚注一并处理 —— 已有标签则复用；新术语则在页面最底部 <!-- 용어 각주 --> 块中按"术语 — 1~2 句说明"格式追加。如有经验证的官方视频，在定义末尾附 🎥 链接（合并前通过 oEmbed2 响应核对标题·频道）。标记只放在正文首次出现处，禁止用于标题和 mermaid 块。标签是机械标识符，绝不翻译；四种语言完全一致地应用（标签·URL 相同）—— 详细规则见 i18n/glossary.md。
playbook 晋升管道¶
graph TD
S["Slack/博客/论文/演示<br>候选产生"] --> C["① 捕获<br>用指定频道 + 表情反应（例: 📌）收集候选<br>或用 GitHub 议题表单 '📌 Playbook 候选上报'（内置 THE FILTER 清单）"]
C --> F{"② 过滤<br>2.5 门禁（4 项中 2 项以上？）"}
F -- 未达 --> RD["Radar 页面一句话<br>（标签 + 为何待定 + 晋升条件）"]
F -- 通过 --> PR["③ 晋升 — 由负责的支柱 owner 用标准模板编入<br>· 附成熟度标签 + 来源等级<br>· 易变信息隔离到折叠块<br>· 填写 owner/验证者/updated"]
PR --> M["④ 通过创建前自检（下方）后合并"]角色¶
| 角色 | 职责 |
|---|---|
| 捕获负责人 | 监控频道，收集表情候选 |
| 验证负责人（可多人） | 流入条目的一手来源确认 —— 对照官方发布·论文原文·许可证。参与者记录在晋升议题和条目的 验证: 字段 |
| 支柱 owner | 门禁判定、晋升/Radar 决策、编写模板、更新 |
| playbook 管理员（Youngjin） | staleness 徽章、结构一致性、季度评审 |
创建前自检（每个页面合并前）¶
- [ ] 纳入的条目是否全部通过纳入标准 2 项以上？是否把未达者放进了正文？
- [ ] 所有条目是否都附了成熟度标签 + 来源等级？
- [ ] 所有条目是否都以"➡️ 后续行动"结尾？
- [ ] 是否把仅有演示的东西描述成可部署的样子？
- [ ] 是否把易变信息与稳定层混在了一起？
- [ ] 所有条目是否都有 owner/updated？
- [ ] 是否把未经验证的信息断言为事实？
只要有一项失败，就重写该页面。
已知技术债务（截至 2026-07）¶
- ~~全部条目 owner 未定~~ → 全部页面 owner: Youngjin 指定完成 —— P1~P5·index·radar（2026-07）、decisions·maintenance（2026-08）、playbook 管理员角色（2026-08）。owner·角色债务已全部清偿。
- ~~FAQ Top 10 为种子~~ → 扩展为 Top 20 并标注来源（2026-07）。剩余：获取 Slack 实际问询记录后按频率重新排序（index）。
- 内部资产深链未连接 —— 研讨会/deck/skill 链接处于"需确认 ⚠️"状态。
- 韩国客户案例不足 —— 大多为"案例待定"。韩国机器人企业为 NVIDIA 阵营，故 AWS 存在空白地带。
- 建议再确认部分 GitHub 发布年份 —— Isaac Sim 6.0.1(🟡 Preview/Early Developer Release —— 最新 GA 为 5.1.0)、Isaac Lab 2.3.2/3.0 标签年份。
- 单一来源数值再确认 —— Lotte 30%、DROID 回合数、部分厂商指标。
- Zensical 迁移待定 —— 构建栈（Material for MkDocs）的下一代。目前
mkdocs-static-i18n尚未被 Zensical 支持（Tier 2 待办），现在迁移会破坏 4 语言构建。迁移条件：Zensical 推出 static-i18n 支持（或原生多语言）+ 确认 strict 校验·韩文 slug 兼容。 在此之前页脚标注保持真实。
这份提示本身也是活文档¶
根据实际生成结果调整纳入标准·模板·支柱权重。主提示: physical-ai-playbook-master-prompt.md。
owner: Youngjin · updated: 2026-08 · volatility: 低（运营规则 —— 仅在规则变更时更新）