复杂 AI 系统为什么必须区分研发版与部署版？

当一个系统已经进入真实使用，继续直接在同一份环境里试验功能，会把“创新速度”变成“生产风险”。研发与部署分离，是复杂 AI 系统稳定演进的基础。

研发环境允许失败，部署环境必须可预测

研发阶段需要快速试错、替换模型、修改 Prompt 与 Skill；部署环境则承担真实任务，任何变化都需要明确版本、验证与回退。

变更必须经过迁移与回归

升级不是覆盖文件。需要检查数据结构、依赖、旧项目兼容、关键流程与失败样本，确认新版不会破坏已运行能力。

回滚不是“出事再说”

真正的部署设计应该在发布前就知道：失败时恢复哪个版本、哪些数据不能被覆盖、怎样验证恢复完成。

稳定与创新并不冲突

把 DEV / DEPLOY 分开后，研发可以更大胆，生产反而更稳定。边界清楚，团队才能长期迭代。

冻结版不是“永远不改”

DEPLOY 冻结的含义是任何改变都经过明确发布流程，而不是阻止升级。开发可以继续前进，但生产环境只接收已经通过回归和迁移检查的版本。

数据迁移比代码替换更危险

很多升级故障不是新代码本身，而是旧项目状态、字段和历史数据无法被新版理解。发布前应明确哪些数据需要迁移、哪些要备份、失败后能否恢复。

版本记录应该回答三个问题

这次改了什么、为什么改、出现问题怎样回退。对于 Agent 和工作流系统，还要记录模型、Prompt、Skill 和关键数据契约是否变化，否则后续很难复现一次“昨天还能跑”的结果。

发布流程需要留下可以被下一任维护者读懂的证据

每次正式发布至少保存版本号、变更清单、数据库或内容迁移说明、关键回归结果、部署时间和回滚版本。Agent 系统还应记录关键模型、Prompt、Skill、数据契约的变化。不要依赖某个人记得“上次为什么这样改”。当问题发生时，最重要的不是迅速再改一版，而是先知道生产环境究竟运行了什么、哪一次变更引入风险、恢复到哪个状态可以重新稳定工作。

格物的方法始终从真实问题开始：先看清，再结构化，再进入使用。