核心 GUIDE
Versioned Dependencies 与 Change Boundary
AI Behavior 依赖会独立变化的 Model、Prompt、Tool、Schema 与 Retrieval Source，因此 Production System 必须显式 Version Boundary。
核心心智模型
可复现 AI Outcome 是一整套 Versioned Stack 的函数：Model / Provider Behavior、Application Code、Prompt、Tool Contract、Retrieval Corpus、Policy 与 Runtime Configuration。
为什么重要
即使 Application Code 完全没改，Product 也可能 Regression。Provider 会更新 Model，Schema 会演化，Knowledge Source 会替换，Prompt 也会编辑。如果 Trace 与 Release Evidence 没有 Version Identifier，团队就无法判断哪个 Dependency 改了，也无法复现 User 真正看到的 Behavior。
01
让会变化的 Input 可识别、可测试
为 Prompt、Model Configuration、Tool Schema、Retrieval Index 与 Policy Artifact 分配 Stable Version 或 Content Hash，并把 Identifier 记录到 Trace 与 Evaluation Run。升级 Dependency 前执行 Targeted Compatibility / Regression Check；高风险 Upgrade 应预先设计 Rollback 或 Fallback，而不是出问题后才临时决定。
02
例子：Schema Update 破坏 Tool Call
Tool Provider 增加一个 Enum，同时 Model Update 开始选择这个新 Value；旧 Application Code 无法识别。Incident Trace 如果只写“Tool Validation Failed”就很难归因。记录 Model、Schema 与 App Version 后，团队可以复现精确 Combination，并选择 Patch、Pin 或 Rollback。
常见失败模式
- 只记录 Application Commit SHA，却忽略 External AI Dependency 独立变化。
- Prompt 或 Retrieval Data 改动没有 Reviewable Version Boundary。
- 一次同时升级多个 Major Dependency，导致 Attribution 消失。
工程启发
- 所有可能实质改变 Behavior 的 Dependency 都附上 Version Identifier。
- 可行时一次只改变一个 Major Boundary，并运行 Regression Evidence。
- 高风险 Dependency Upgrade 之前先设计 Rollback / Fallback。
关键结论
- 01Reproducibility 不只是 Code Versioning。
- 02Version Metadata 能把 Incident 转成可归因的 Change。
- 03Dependency Upgrade 应接受与 Code Release 一样的 Evidence Discipline。
阅读记录
这里只记录你真实做过的动作，不代表掌握、熟练或认证。
用于这些学习路径
这个 Concept 会在多个 canonical 学习路径中复用。