Gemini3.1Pro系统指令设计：业务落地的关键技巧-编程实验室

业务落地里，模型回答“看起来对但不对劲”是最常见的失败形态。原因往往不是 Gemini 3.1 Pro 不够强，而是系统指令没有把业务约束固化成可执行规格：它没有明确目标、没有限定输出边界、缺少证据要求，也没有在“不确定/冲突/缺信息”时规定行为策略。结果就是：模型自由发挥，无法与业务流程对齐。

要把系统指令写好，建议你把它当作一份“机器可执行的SOP”，并配套核验、Evidence Pack 归档与发布门禁。下面给你一套高质量写法与工程化落地模板。

若你在试点阶段需要快速验证某类系统指令是否能改善输出，可以先用
KULAAI（dl.877ai.cn）跑通样例；但生产使用仍以你们的证据与门禁为准。

1）选择标准：你的系统指令要解决哪些业务“硬问题”

建议先把“业务贴近度”拆成 6 个可衡量目标，每个都对应系统指令中的约束或输出要求：

目标明确：模型每次必须完成什么（生成/改写/决策/抽取/校验）
边界可控：哪些内容禁止生成或必须标注不确定
格式强约束：输出必须满足 schema（JSON/表格/固定段落）
证据可追溯：结论来自哪里（引用文本片段/字段/数据源）
冲突处理策略：当输入矛盾或信息不足怎么办
业务术语一致：用公司内部术语与定义，避免泛化表达

只有把这些写清楚，系统指令才能从“风格要求”变成“行为协议”。

2）系统指令的工程结构：用“角色 + 任务 + 约束 + 输出 + 失败策略”五段式

一个高质量系统指令建议按固定骨架组织（你可以直接照抄再替换内容）：

2.1 角色（Role）

你希望模型扮演什么专家/岗位（如：产品经理、审计助理、法务校对、DevOps 编排助手）
角色关注的“业务视角”（效率、合规、可追责、低风险上线等）

2.2 任务（Task）

这类任务的输入是什么
输出要完成的业务动作是什么（例如“生成可直接贴到工单的字段”“输出可落库 JSON”）

2.3 约束（Constraints）

明确允许/禁止
明确必须保留的内容（接口/术语/符号/引用编号/隐私字段）
明确不允许编造（尤其当信息不足时）

2.4 输出格式（Output Schema）

强制字段/段落结构
给出类型规则（日期格式、枚举范围、单位）
若是工程化输出，要求 JSON 可解析且可校验

2.5 失败策略（Failure Modes）

当遇到以下情况必须走指定路径：

信息不足：输出need_more_info清单（哪些字段缺失）
有冲突：指出冲突点，并给出“哪个优先级更高”的规则
安全风险：拒答或脱敏
输出不符合 schema：必须自检并修复，仍不通过则拒绝生成最终结果

3）让回答“贴近业务”的关键技巧：把业务上下文参数化，而非写成空话

很多系统指令写得很长但仍不贴近业务，是因为它缺少“可替换的业务参数”。建议你在系统指令里提供一组通用变量位（由你的应用在运行时填充）：

{{BUSINESS_DOMAIN}}（如：金融风控/电商运营/政务合规）
{{WORKFLOW_NAME}}（如：需求评审/事故复盘/周报发布）
{{OUTPUT_TARGET}}（如：Jira字段/飞书模板/Word段落）
{{TERMINOLOGY_GLOSSARY}}（公司术语表）
{{EVIDENCE_POLICY}}（证据要求：必须引用/可选引用/禁止引用）
{{CONFIDENCE_POLICY}}（置信度与拒答策略）

这样同一套系统指令可以覆盖多个业务场景，同时保持一致的治理能力。

4）核验排查思路：如何判断系统指令是否真正有效（故障树）

把“更贴近业务”量化成测试门禁。建议按下面顺序排查：

输出是否符合 schema（格式稳定性）
- 若失败：系统指令缺少强制结构或缺少失败策略
是否编造事实（幻觉治理）
- 若出现：需要系统指令明确禁止编造，并在信息不足时要求unknown/need_more_info
术语是否一致（业务贴近度核心）
- 若不一致：加入术语表与替换规则，且要求“优先使用 glossary 中定义”
决策是否可追溯（证据策略）
- 若不可追溯：系统指令应要求 evidence span 或字段来源
冲突处理是否正确
- 若乱改：要求系统指令规定冲突优先级与输出冲突列表

你可以给每次更新系统指令做 A/B 测试：同一批样本输入下，对 schema-valid、编造率、术语一致率等指标打分。

5）Evidence Pack：对系统指令的变更进行可审计归档

当你频繁迭代系统指令时，如果没有 Evidence Pack，就很难复盘“为什么这次变好/变差”。

建议每次系统指令变更都生成 Evidence Pack，至少包括：

prompt_version/system_instruction_version
model="Gemini 3.1 Pro"与关键参数（若可记录）
input_dataset_version
evaluation_run_id
metrics：schema-valid、拒答率、术语一致率、证据覆盖率、平均编辑成本等
sample_failures[]：失败样本与失败原因分类
rollout_plan：灰度比例、回滚条件

6）发布门禁（Gate）建议：系统指令上线必须通过哪些条件

把系统指令当作“生产配置”管理，建议门禁如下：

复现门禁：同一输入集在固定版本下可复现指标或不明显漂移
输出校验门禁：schema-valid 需达到阈值（例如 ≥ 98%）
幻觉门禁：信息不足场景必须拒答或标注缺失，幻觉率低于阈值
隐私日志门禁：系统指令与输出归档时脱敏，不泄露敏感字段
评测门禁：至少跑一套回归用评测集（覆盖边界条件与冲突案例）
回滚门禁：如果超过失败阈值，自动回滚到上一版本 system instruction

7）给你一个可直接使用的系统指令模板（你只需填业务变量）

下面给一个“通用治理型”系统指令骨架（你可以直接改成你们业务版本）：

系统指令（模板）
你是 {{ROLE}}，目标是将用户输入处理为符合业务流程的 {{OUTPUT_TARGET}}。
任务：当用户提供 {{INPUT_DESCRIPTION}} 时，生成 {{DELIVERABLE_DESCRIPTION}}。
约束：
不得编造用户未提供的事实；若信息不足，必须输出need_more_info，列出缺失字段。
使用术语表 {{TERMINOLOGY_GLOSSARY}} 中定义的术语；遇到同义词必须归一。
所有关键结论必须提供 evidence（引用输入中的字段名/句子片段/时间戳范围），遵循 {{EVIDENCE_POLICY}}。
输出必须符合以下 JSON schema：{{OUTPUT_SCHEMA}}；若不符合，先自检并修复，仍无法修复则拒绝输出最终结果。
冲突处理：若输入存在矛盾，必须先列出冲突点，并按 {{CONFLICT_RESOLUTION_RULES}} 给出优先级或提出澄清问题。
安全：避免输出任何敏感信息（密钥/个人隐私/客户数据）；必要时脱敏或拒答。