结论：提示词是系统的核心配置，却常被当作"随手改的字符串"。没有版本、没有评审、没有回滚，一次线上事故你连"当时用的哪版提示词"都说不清。

一、把提示词当代码管理

• 纳入版本控制，每次改动可 diff、可回滚、可追溯。

• 改动走评审：提示词的修改常常比代码更能影响行为，却没经过任何审查。

• 与发布记录关联：某个版本对应哪套提示词，必须可查。

二、结构化而非一坨文本

把提示词拆成可组合的片段（角色、规则、示例、输出格式），按需拼装，避免一个巨型字符串里改一处影响整体。这与 Skill 的模块化是同一思路。

三、环境分离与灰度

开发/测试/生产的提示词分开，变更先灰度再全量。提示词改动的风险不低于代码，却常常直接改线上。

四、回归保障

每次提示词变更都要跑针对性的回归集（呼应 Evals）。没有回归，改一句"优化措辞"可能悄悄破坏某类场景。

五、可观测与归因

线上日志要记录本次请求用的是哪版提示词/配置，否则出问题无法归因到具体变更。

六、常见误区

• 提示词写死在代码里、无版本；直接改线上；无评审无回归；巨型提示词难维护；改了不知道影响谁。

七、检查单

• [ ] 提示词纳入版本控制，可 diff、可回滚

• [ ] 变更走评审流程

• [ ] 提示词结构化、可组合，非巨型字符串

• [ ] 开发/测试/生产环境分离

• [ ] 变更先灰度后全量

• [ ] 每次变更跑回归集

• [ ] 线上日志记录所用版本，可归因

• [ ] 有明确的回滚预案