AI 实战文档

Appearance

提示词设计 ​

核心原则 ​

跨平台官方文档在 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 分段。
  • 示例设计：覆盖正常样本、边界样本、反例样本。
  • 格式约束：能用结构化输出就不用"自然语言猜格式"。

高级推理模式 ​

Chain-of-Thought (CoT) ​

让模型显式输出推理步骤，提升复杂任务的正确率。

md
请按以下步骤思考：

1. 首先分析问题的核心要素
2. 列出可能的解决方案
3. 评估每个方案的优缺点
4. 选择最优方案并说明理由
5. 给出最终答案

问题：{input}

适用场景：数学推理、逻辑判断、复杂决策。

Self-Consistency ​

对同一问题生成多个推理路径，取多数答案。

md
请对这个问题进行 3 次独立思考，每次使用不同的推理路径。
最后比较三个答案，选择最一致的那个作为最终答案。

适用场景：需要高可靠性的判断任务。

Few-Shot with Reasoning ​

在示例中加入推理过程，而非仅输入输出对。

md
示例 1：
输入：小明有 5 个苹果，给了小红 2 个，又买了 3 个
思考：初始 5 个，给出 2 个剩 3 个，买入 3 个变成 6 个
输出：6 个苹果

现在请回答：
输入：{input}

Self-Reflection ​

让模型在输出前自我检查。

md
完成回答后，请进行自检：

1. 我是否完全回答了问题？
2. 我的推理是否有逻辑漏洞？
3. 我的结论是否有证据支持？

如有问题，请修正后重新输出。

Tool Use Pattern ​

明确工具调用的条件和格式。

md
当需要以下能力时，调用对应工具：

- 需要实时信息 → search(query)
- 需要计算 → calculate(expression)
- 需要查询数据库 → query_db(sql)

调用格式：{"tool": "name", "args": {...}}

反模式 ​

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

角色动作卡 ​

开发者 ​

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

产品经理 ​

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

开发者与产品经理交接件 ​

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

参考来源 ​