系统提示词上线注意事项

系统提示词（system prompt）不是「写得越长越聪明」，而是产品契约的一部分：它规定模型能做什么、不能做什么、工具怎么用、缺信息时怎么处理。上线前按清单过一遍，比上线后靠用户吐槽修补便宜得多。

英文对照：production system prompts。清理杂乱草稿可用本站 Prompt 清理工具。

上线前先写清「职责」

用一两句话定义角色，避免空洞形容词：

• 差：你是全能、友好、专业的助手。
• 更好：你是 sudoai 文档助手；只依据 CONTEXT 回答产品用法；不确定就说不知道并给出人工支持入口。

职责越清楚，越容易做回归测试，也越容易在评审里争论「该不该加这句话」。

必须写进系统提示的硬规则

建议单独成段，便于 diff：

1. 拒答 / 安全：哪些请求必须拒绝，拒绝时如何一句话说明。
2. 事实边界：只能用 CONTEXT / 工具结果；禁止编造链接、报价、法律结论。
3. 输出形态：纯文本 / Markdown / JSON；是否允许代码围栏。
4. 缺信息策略：反问一次、返回 UNKNOWN，还是降级给人工——三选一写死。
5. 工具约定：有哪些工具、何时调用、禁止伪造工具结果。

结构化输出场景可参考英文指南 JSON schema output prompts。

不要塞进系统提示的东西

• 每周都变的运营文案（放到用户侧或可配置 CONTENT 块）
• 整份百科式产品手册（改检索 / RAG，并做 上下文费用估算）
• 互相打架的「既要又要」形容词堆叠
• 未版本化的示例对话长篇粘贴

系统提示应短而稳；易变内容外置。

版本、评审与回滚

把提示词当配置：

• 命名：sys-docs-assistant-v12
• 每次变更附一行「为什么改」
• 与校验代码、工具 schema 同一 PR 或明确依赖版本
• 保留上一版，支持一键回滚

没有版本号的提示词，出事时无法回答「昨晚改过什么」。

上线检查清单（可复制）

• 角色与成功标准一句话可复述
• 拒答与缺信息策略有示例
• 工具列表与真实 API 一致
• 输出格式有最小合法样例
• 用 20 条真实/脱敏用例跑通（含应拒绝的）
• Token 粗估已做（Token 费用估算）
• 限流与重试预算与后端一致（见 rate limit playbook）
• 监控：拒答率、解析失败率、人均 Token、429 率
• 回滚路径演练过

灰度与观察

不要全量切换大改版：

1. 内网 / 员工流量先跑
2. 按租户或百分比灰度
3. 盯解析失败、人工接管、投诉标签
4. 达标再扩量；异常先回滚再分析

「感觉更好」不能替代指标。若你没有评测集，至少固定 20 条黄金问题，每次改提示词必跑。

常见翻车

• 上线后把销售口径偷偷写进系统提示，导致模型保证无法兑现的 SLA
• JSON 模式与 Markdown 说明并存，模型偶发加注释
• 工具增删了，提示词未改，模型继续「调用」旧工具名
• 为压 Token 删掉拒答句，安全回归失败（压缩请另循 减少 Prompt Token 的验证流程）

最小系统提示骨架

角色：…
能力边界：只做…；不做…
事实：仅使用 CONTEXT 与工具结果；禁止编造
缺信息：…
输出：…
工具：名称 / 何时用 / 禁止伪造结果
拒答：… → 固定短句

先骨架、再加必要示例；示例要短，且与生产校验一致。

系统提示词上线是工程变更。写清契约、版本化、小步灰度、指标盯盘——这比再写一段「请务必认真」有用得多。更多英文细节见 production system prompts；团队费用侧见 团队如何控制 LLM 成本。