- 介绍
- 先划定 use case 的边界
- 提示词，运维可行性比感性表达更重要
- 需要可靠性的流程，优先选择 structured output
- Safety 归根到底是产品决策
- 没有 Evaluation，就不要相信提示词
- 成本控制，归根到底是上下文纪律
- 生产环境检查清单
- 常见反模式
- 结语
- References
介绍
把 foundation model 接入生产环境，最难的从来不是第一次 API 调用。真正难的是，在真实流量、危险输入、不断变化的提示词、成本压力之下，仍然把它维持成一个可以理解的系统。Gemini 也不例外。API 本身很强，但真实的质量取决于提示词设计、structured output、safety 策略、evaluation 循环。
本文以 Gemini 官方文档为基准，梳理这些设计决策。
先划定 use case 的边界
在打磨提示词之前，必须先定义应用程序可以做什么、绝对不能做什么。
实务中有用的问题：
- 这个模型做的是摘要、抽取、分类，还是生成
- 结果应该是自由文本，还是结构化输出
- 约束响应的 source of truth 是什么
- 哪种失败更危险，是过度拒绝，还是自信满满的幻觉
这条边界一旦模糊，prompt tuning 很快就会变成迷信式的反复试错。
提示词，运维可行性比感性表达更重要
Gemini 的提示词越明确、范围越清晰、越可验证，就越好驾驭。好的提示词通常包含以下要素：
- 任务意图
- 输出格式
- 约束条件
- 必要时的示例
- 拒绝或不确定性的处理标准
实务中，通常把提示词拆分成如下几部分会更好：
- 稳定的系统或应用指令
- 任务相关的用户输入
- 必要时检索到的上下文
- 输出 schema 的预期
这样拆分之后，提示词的变更就不再是魔法，而是可以审查的变更。
需要可靠性的流程，优先选择 structured output
许多生产工作流并不需要漂亮的句子，需要的是可以验证并存储的稳定输出形态。
如果应用程序要抽取决策、标签、风险度、行动项，那么比起对自由文本做后处理，structured output 通常更安全。好的模式如下：
- 只定义应用程序真正需要的字段
- 让 schema 保持精简
- 在产生副作用之前先验证响应
后续自动化的依赖程度越高，就越应该避免模糊的自由文本。
Safety 归根到底是产品决策
Gemini 提供了 safety guidance 与可配置的选项，但任何平台设置都无法替代产品判断。团队最终必须自己决定：
- 应该拦截哪些内容
- 哪些内容可以带着警示放行
- 哪些内容要转交人工审核
也就是说，safety 设置不应是隐藏的默认值，而应作为产品策略的一部分被记录下来。
没有 Evaluation，就不要相信提示词
提示词的修改看起来太容易了，这恰恰是危险所在。哪怕是很小的措辞差异，也可能改变拒绝行为、结构化质量、tool 使用、token 消耗。
生产环境的评估循环至少需要包含：
- 固定的 benchmark 集合
- 期望输出，或基于 rubric 的评估标准
- safety 敏感的用例
- 成本与延迟的观测
如果团队只靠对话式测试来验证提示词，就很容易漏掉回归问题。
成本控制，归根到底是上下文纪律
模型成本往往是因为上下文不断被叠加而变大的。为了不让提示词变成垃圾桶，需要不断追问：
- 模型是否真的需要这全部上下文
- 是否可以先做摘要
- 能否拆成更小的调用
- 这一步是否真的需要最大的模型
比起一味使用更大的模型，上下文纪律与提示词质量往往更重要。
生产环境检查清单
- use case 边界已经文档化。
- 提示词把持续性指令与用户输入分离开。
- 在下游系统有依赖的地方使用 structured output。
- safety 设置与升级规则已经明确写出。
- 提示词的变更在发布前都经过 evaluation。
- 成本与延迟被作为产品指标持续观测。
常见反模式
只凭感觉反复调整提示词
提示词设计有创造性的一面，但生产环境的提示词工作仍然应该是可审查、可验证的。
在自动化流水线中直接使用自由文本
如果后续系统依赖稳定的字段，自由文本只会增加脆弱性。
只依赖 safety 默认值
平台层面的控制确实有帮助，但最终的安全行为仍然要由产品团队负责。
不经评估就发布提示词变更
这和不经测试就改动应用程序逻辑没有本质区别。
结语
生产环境中的 Gemini 系统，靠的不是华丽的演示，而是清晰的边界。明确定义任务，约束输出，明确 safety，对每一次重要的提示词变更做评估，并控制好上下文预算。做到这些，模型集成才会从一次实验变成一项产品能力。