提示词设计

核心原则

跨平台官方文档在 2025-2026 的共识很一致：

指令要清晰且可执行
给上下文和边界条件
必要时给 few-shot 示例
强制输出结构，减少“格式随机”

Anthropic 文档明确强调：清晰直接、增加上下文、示例驱动、使用 XML 结构化标签与角色设定。Google Gemini 文档强调 few-shot 对输出格式和范围控制的重要性。OpenAI 文档强调“简洁明确 + 迭代评测”。

推荐模板

md

你是[角色]

任务目标：

- [目标 1]
- [目标 2]

输入：

- {input}

约束：

- 不要编造事实
- 不确定时明确说“不确定”并给出需要补充的信息
- 仅使用提供资料或工具返回结果

输出格式（JSON）：
{
"summary": "",
"confidence": 0,
"evidence": []
}

示例：
输入: ...
输出: ...

进阶技巧

角色分离：planner 负责拆解，executor 负责执行，critic 负责校验。
结构化上下文：把 instructions、context、examples、input 分段。
示例设计：覆盖正常样本、边界样本、反例样本。
格式约束：能用结构化输出就不用“自然语言猜格式”。

反模式

“帮我写得更好一点”这类模糊目标。
示例质量低于真实任务数据。
输出格式只写“尽量 JSON”。
提示词很长但没有优先级和约束层次。

角色动作卡

开发者

把提示词模板做成可版本化配置，避免散落在业务代码里。
强制输出 JSON Schema 或结构化协议，减少解析失败。
为每个提示词版本绑定离线评测结果与回滚标记。

产品经理

在需求里写清“成功回答”的定义，不只写功能描述。
维护正反例样本，确保提示词迭代围绕真实场景。
将高风险问题纳入验收项，例如误导性回答和越权内容。

开发者与产品经理交接件

提示词版本号与变更说明。
对应样本集与验收结果。
风险清单与禁答策略。

参考来源