PromptWeave 架构设计系列

从 Prompt、模型和实验逐渐耦合的设计场景出发，理解版本、路由、fallback 与发布快照为什么必须分开又要一起验证。

适合需要管理多 Prompt、多模型或实验分流的 AI 应用开发者。

从第 1 课开始 →

最终会做出什么

最终能为一次模型调用划定配置边界，设计可审计、可验证、可恢复的发布链路。

01

先建立问题边界

从一次配置表失控的设计场景出发，理解 Prompt 系统究竟要管理什么。

2/2

1. 01 Prompt 不只是文本：先划清配置系统的边界 从 Prompt、模型和实验逐渐耦合的场景出发，判断系统应该拥有和不应该拥有的责任。 已发布
2. 02 PromptCode、ModelConfig 与路由：一次请求谁决定什么 区分调用方事实、Prompt 版本、模型配置和受限路由，建立一期直接执行的最小契约。 已发布

02

保护一次运行

继续同一场景，说明失败路径和执行记录为什么必须提前设计。

1/1

1. 03 主调用失败后，怎样进入一条可信的备用路径 用显式 fallback 和 runId 解决临时换模型不可解释、失败无法还原的问题。 已发布

03

把验证过的版本交付出去

用 A/B 全量切换场景说明发布、审批、加载核对与完整回滚。

1/1

1. 04 为什么发布和回滚必须以完整快照为单位 从 A/B 实验切换到 B 全量，推导不可变版本、环境指针、审批 hash 和完整回滚。 已发布

参考基线

这些资料用于支撑概念和术语。文章会使用自己的话解释，并用 Pi 重新实现 demo。

• project PromptWeave README
• architecture PromptWeave Architecture Contract