S32：Golden Path：标准化、灵活性与平台锁定

内容类型：预习教材（不代表已完成）
日期：2026-12-24
阶段：P2 · AI Systems Engineering 90
总路线：Day 122 / 360
周次：W5 · AI Platform Engineering & Golden Path
节奏：周四案例与连接
状态：教材已备；学习未完成
标签：golden-path、standardization、escape-hatch、lock-in、onboarding

一句话定义

Golden path 是平台为常见用例提供的受支持默认路径：它减少重复选择与隐性风险，但必须保留明确的适用边界和可治理的逃生通道。

学习目标

1. 能区分 golden path、模板、强制标准和平台 API，不把它们混为同一件事。
2. 能比较一个团队手工接入与平台化接入在时间、认知负担、证据和长期维护上的差异。
3. 理解标准化收益来自消除无价值差异，而不是消灭所有架构选择。
4. 能设计第二个用例接入时的默认项、可配置项和例外审批项。

核心知识

• Golden path 应提供“从需求到可观测运行”的连贯体验，通常包含仓库模板、用例 manifest、身份与 secret 接入、模型/工具目录、遥测、发布方式和责任人，而不只是脚手架代码。
• Paved road 强调平台持续维护的路径；template 只是创建时复制的起点；standard 是必须满足的约束；API 是能力接口。模板生成后若与平台脱钩，升级与证据仍会碎片化。
• 平台化的收益可以看成 接入节省 + 维护节省 + 风险降低 - 平台学习与约束成本。第一用例常看不出收益，第二、第三个用例的重复模式才检验抽象是否成立。
• Escape hatch 不是绕过治理，而是声明为何默认路径不适用、由谁承担维护、怎样提供等价控制以及何时回归主路。
• 锁定有多种：供应商 API 锁定、内部平台语义锁定、数据格式锁定、运维知识锁定。自建抽象层也会制造锁定，不能只把外部依赖叫作锁定。

机制与推导

比较两条接入路径：

手工路径：选框架→自建鉴权→自定义日志→自写发布→自行排障
Golden path：声明 use case→模板/目录解析→默认策略→标准遥测→受支持发布

可用一个简化决策式讨论标准化：

[ V_{platform}=R\times(S_{build}+S_{operate})+R_{risk}-C_{platform}-C_{constraint} ]

其中 (R) 是可复用次数。若只有一个高度特殊的用例，R 很小，平台抽象可能不值得；若十个团队都重复处理身份、遥测和发布，复用价值增加。这个式子不是财务预测，而是迫使讨论者显式说明假设。

第二用例接入是一种架构探针：若每个字段都要例外，说明第一用例被误写成平台；若第二用例只需声明业务差异，公共能力可能抽取得当。标准化应固定身份、证据、安全下限等跨用例不变量，而允许模型、检索、工具与 SLO 在边界内变化。

最小练习或观察步骤

1. 选择“AML 调查助手”为第一用例、“支付争议摘要”为第二用例，列出共同能力与真正不同的业务语义。
2. 分别写一条手工接入流程和 golden path 流程，标出每一步 owner、等待时间类别和产生的证据。
3. 将 manifest 字段分为默认、必填、可选和例外四类；每类写出为什么。
4. 设计一个 escape-hatch 记录：原因、风险、等价控制、owner、复查日期，而非一个 skip=true。
5. 选择一项平台升级，推演模板复制式与集中能力式的升级传播差异。
6. 只产出案例与问题，不要求搭建 Backstage 或 Kubernetes。

常见误区与边界

• 把“点击一次创建仓库”当作完整 golden path，忽略运行、观测、升级和退役。
• 为了统一而把所有业务 SLO、数据保留期和人工审批规则写死。
• 用大量必填字段把认知负担从编码转移到表单，没有真正降低复杂度。
• 把 escape hatch 设成永久例外且无人负责，形成第二套暗平台。
• 只计算首次接入速度，不计算升级、事件响应、审计与退出成本。
• 本日不评选具体平台产品；重点是识别默认路径的价值、边界与责任。

系统 / 金融 / Web3 场景连接

金融 AI 用例常共享身份、案件数据访问、审计、人工升级和模型调用，但欺诈、AML、客服对证据和时效要求不同。Golden path 可固定数据分级、调用追踪和审批接口，却不应把所有风险规则统一成一个阈值。Web3 场景中，观察链上数据的只读 Agent 可走默认路径；构造或广播交易需要钱包域特有的签名、nonce、simulation 与最终确认，这应成为受支持扩展而不是随意绕过平台。

自检问题

1. 模板、标准、API 与 golden path 分别解决什么问题？
2. 第二个用例为什么比第一个更能检验平台抽象？
3. 哪些差异值得标准化，哪些差异属于业务本身？
4. 一个合格 escape hatch 至少要记录什么？

专业课程对齐

• 阅读 Backstage 官方文档 中 Software Templates、Catalog 与 TechDocs 的入口，具体观察模板如何连接 owner、组件目录与持续文档，而不是只生成文件。
• 阅读 Full Stack Deep Learning 2022 中 infrastructure、deployment 和 continual learning 的讲次目录，将端到端生命周期映射成 golden path 应覆盖的几个阶段。
• 阅读 Stanford CS329S 的系统设计课程结构，重点回看 requirements、data、deployment、monitoring 之间的联系，用于判断哪些默认项属于跨用例不变量。

深入学习提示

先以第二用例作为反例，再读平台材料。深入时不要统计功能数量，而要统计用户仍需作出的高认知选择、例外会破坏哪些证据链、升级由谁传播。可以画“默认路径/受支持扩展/例外路径”三车道图；若每条路都没有 owner 和退出条件，图再漂亮也不能说明平台能力。

学后填写区

• 选择的两个用例：
• 可复用能力与业务差异：
• 默认项 / 可配置项 / 例外项：
• 一个锁定风险及退出思路：
• 尚未理解的问题：