提示工程
提示工程（Prompt Engineering）是把任务讲清楚的能力：你给模型的输入越清晰、越可验证，输出越稳定、越可复用。对百灵大模型同样适用。
这篇文档总结一套可落地的提示编写方法：从“目标与约束”出发，逐步补齐上下文、格式、示例与评测，让输出更可靠。
核心概念
| 维度 | 你要做什么 | 典型收益 |
|---|---|---|
| 目标 | 明确要完成的任务与成功标准 | 降低跑题、减少追问 |
| 约束 | 限制输出范围、语气、长度、禁止事项 | 更一致、更可控 |
| 上下文 | 提供必要材料（事实/规则/数据/代码片段）并标出边界 | 减少幻觉、提升准确性 |
| 结构 | 指定输出格式（列表/表格/JSON/步骤） | 便于解析与自动化 |
| 示例 | 给 1–5 个高质量输入输出示例（few-shot） | 稳定风格、减少偏差 |
| 验证 | 要求自检、给出引用/计算过程、或用结构化输出约束 | 提升可验证性 |
快速选择指南：
- 事实问答 / 代码 / 数学：目标明确 + 强约束 + 低采样（见
sampling.md） - 写作与创意：目标明确 + 风格约束 + 示例 + 适度采样
- 信息抽取 / 自动化：结构化输出优先（见
structured-outputs.md），必要时配合工具调用 - 长文档处理：边界标记 + 分段任务 + 可追踪的输出结构
一个通用提示模板（推荐）
你可以把提示拆成 5 个小块，按需取用（不需要每次都全写）：
- 任务（Task）：你要模型做什么
- 背景/材料（Context）：模型需要参考什么信息（用边界包起来）
- 要求（Constraints）：输出语言、口吻、长度、禁止事项、必须覆盖点
- 输出格式（Output format）：用明确可解析的结构（列表/表格/JSON）
- 示例（Examples）：给少量高质量示例（可选）
下面给一个“可直接复制”的示例。
你是一个严谨的助手。
【任务】
将用户给出的内容改写为适合对外发布的中文文案。
【背景材料（仅可使用下列内容，不要编造）】
<<<
（把原始资料粘贴在这里）
>>>
【要求】
- 语言：简体中文
- 风格：专业、简洁、无夸张宣传语
- 必须包含：产品定位、3 个核心卖点、1 段使用场景
- 禁止：引入未提供的功能/数据；使用“最强/第一”等绝对化表述
【输出格式】
用 Markdown 输出：
1) 标题
2) 三条卖点（列表）
3) 使用场景（1 段）角色与指令优先级（如何更“听话”）
多数对话式接口支持用不同角色组织消息（例如 system / developer / user / assistant）。优先级通常是：
system/developer（最高） > user > assistant（历史输出）。
实战建议：
- 把稳定不变的规则写在system/developer（例如输出语言、合规边界、格式约束）
- 把每次变化的输入写在 user（例如本次要处理的文本/问题）
- 避免把关键约束夹在长段上下文中；用条目列出
用“边界标记”防止上下文混淆
当你需要提供较长的参考材料（文档、日志、代码、合同条款），请用清晰的边界包裹，并告诉模型“只能在边界内引用/推断”。
推荐写法：
【参考资料】
<<<DOC
... 很长的资料 ...
DOC
>>>并配套约束：
- 仅基于 <<<DOC ... DOC>>> 中的信息回答
- 若资料不足以得出结论，输出：信息不足，并说明缺少什么这对降低“把提示当成指令/把指令当成资料”的混淆非常有效。
让输出可解析：结构化与格式约束
Markdown 结构（轻量、通用）
适合：总结、对比、方案评审、会议纪要。
【输出格式】
## 结论
（一句话）
## 依据
- ...
## 风险
- ...
## 下一步
1. ...JSON / Schema（强约束、适合生产）
适合：信息抽取、规则引擎输入、自动化流程。
优先使用结构化输出能力，详见：结构化输出。
Few-shot：用少量示例稳定风格与规则
当任务比较“像人类打分/分类/改写”，few-shot 往往能显著提升一致性。关键是：
- 示例要覆盖边界情况（容易误判的例子）
- 示例要短，避免把无关信息带进模式里
- 规则变化时，示例也要同步更新
示例（情绪分类）：
你是一个分类器，只能输出：正向 / 中性 / 负向。
【示例】
输入：这耳机音质很好，续航也够。
输出：正向
输入：还行吧，没有宣传的那么好。
输出：中性
输入：客服态度很差，再也不买了。
输出：负向
【现在开始】
输入：{用户评论}
输出：把复杂任务拆成“可验收”的步骤
模型在面对复杂需求时容易遗漏点。把任务拆成明确步骤，并要求逐项对照验收。
【任务】
根据需求文档写一份技术方案。
【步骤】
1) 先给出 5 条你对需求的关键理解（逐条引用原文片段）
2) 给出 2 套可选方案（各自优缺点、成本、风险）
3) 选出推荐方案，并给出实施计划（里程碑 + 回滚策略）
【验收标准】
- 必须覆盖：性能、可用性、监控告警、安全
- 不允许：引入需求文档之外的新目标自检与“信息不足”策略（减少幻觉）
在生产场景中，最重要的是可验证性。你可以要求模型：
- 先判断信息是否足够：不足就明确说缺什么
- 对关键结论给出依据：来自哪段材料、哪条规则或哪步计算
- 输出前自检：检查是否满足格式/必填字段/禁止事项
示例：
在回答前先做两步：
1) 判断资料是否足够；不足则输出“信息不足：缺少...”
2) 输出最终答案后，附上一个“自检清单”，逐项写“满足/不满足”代码示例：把提示工程用到 API 调用里
下面示例沿用你站内其它教程的 SDK 写法（base_url + api_key）。重点在 messages 的结构与提示内容本身。
Python
from openai import OpenAI
client = OpenAI(
base_url="https://api.ant-ling.com/v1/",
api_key="YOUR_API_KEY"
)
prompt = """你是一个严谨的中文助手。
【任务】
根据给定资料回答问题。
【资料（仅可使用下列内容，不要编造）】
<<<DOC
产品 A 支持离线模式；离线模式下只能查看已缓存数据。
产品 A 的数据缓存默认保留 7 天，可配置为 1-30 天。
DOC
>>>
【问题】
离线模式下能否查看新数据？缓存能保留多久？
【输出格式】
用两条要点回答，每条不超过 20 字。
"""
resp = client.chat.completions.create(
model="Ling-2.6-flash",
# 此处以“Ling-2.6-flash”调用为例，可按需调整为“Ling-2.6-1T”
messages=[{"role": "user", "content": prompt}],
temperature=0.2
)
print(resp.choices[0].message.content)常见问题与反模式
1. 提示太笼统
反例：
“帮我优化一下这段话。”
改进：
给出目标（受众/渠道/风格）、硬约束（长度/禁用词/必须覆盖点）与输出格式。
2. 把多个任务揉在一起
反例：
“先总结、再翻译、再提炼观点、最后给行动计划。”
改进：
拆成步骤并逐项输出，或分两次调用。
3. 上下文很长但没有边界
反例：
把文档直接粘贴，不说明哪些是资料、哪些是指令。
改进：
用 <<< >>> 包裹资料，并明确“仅可使用资料内容”。
4. 输出不可验收
反例：
没有格式、没有必填字段，结果难以解析与对比。
改进：
指定结构（表格/JSON/分段标题），并添加“自检清单”或 schema。
进一步阅读
- 采样：如何用 Temperature / Top-P / Top-K 控制创造性与确定性
- 结构化输出：用 JSON Schema 让输出严格可解析
- OpenAI 提示工程指南（方法论参考）