写出清晰提示词：任务、上下文、约束与输出格式

前面的系列文章解决了“如何调用模型”以及“如何处理响应”的问题，但 API 调用成功不代表结果就可靠。同一个模型，面对一句含糊的要求，可能每次都采用不同的理解；把目标、背景、边界和交付格式说清楚，输出的稳定性通常会明显提高。本文只聚焦一个核心知识点：如何把提示词写成可执行的任务说明。

提示词不是越长越好

提示词可以理解为给模型的一份任务说明，而不是一段越详细越好的作文。高质量提示词的关键是减少歧义，让模型知道“要做什么、依据什么做、哪些事情不能做、结果怎样交付”。

一个实用的最小结构有四部分：

任务：用动词明确要求，例如“提取”“分类”“改写”或“比较”。
上下文：提供完成任务所需的材料、受众和背景，不要假定模型知道未写出的信息。
约束：说明范围、语言、长度、禁止事项以及不确定时的处理方式。
输出格式：明确字段、顺序、是否允许额外解释；如果程序要消费结果，最好使用结构化格式。

这四部分不要求必须使用固定标题，但分隔清楚通常更容易维护，也便于后续测试。提示词的目标不是替模型思考所有细节，而是把任务边界表达得足够明确。

先写验收标准，再写提示词

写提示词前，可以先用一句话回答：“什么样的结果算完成？”例如，客服工单分类的验收标准可以是：只能从给定的三个类别中选择一个，并返回类别和一句理由。这个标准比“请准确分类”更可检查。

还要提前决定缺少信息时怎么办。对于文章摘要，可以要求“仅根据输入内容总结，不补充原文没有的事实”；对于信息抽取，可以要求“找不到字段时返回 null”。这类规则能减少模型为了让答案完整而自行猜测。

另一个容易忽略的细节是受众。面向初学者的解释和面向工程师的排障报告，虽然主题相同，词汇、细节深度和格式都不同。把受众写进上下文，往往比添加大量形容词更有效。

最小可运行示例：把反馈归类

下面使用 OpenAI Python SDK 的 Responses API 演示一个分类任务。模型名称从环境变量读取，避免把供应商或部署信息硬编码到程序中；API 密钥也只从环境变量读取。运行前请根据所用服务商的官方文档配置对应的 SDK、模型名称和可选的基础 URL。

import os

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["OPENAI_API_KEY"],
    base_url=os.environ.get("OPENAI_BASE_URL"),
)

prompt = """
任务：将用户反馈归为一个类别，并给出一句不超过 30 字的理由。

可选类别：bug、feature_request、question。
判定规则：
- bug：用户报告现有功能不能正常工作。
- feature_request：用户提出新增或改进功能的建议。
- question：用户主要是在询问如何使用现有功能。

约束：只能选择一个类别；只能根据反馈原文判断；信息不足时仍选择最接近的类别。
输出格式：严格输出两行，不要添加 Markdown：
category: <类别>
reason: <理由>

用户反馈：导出的 CSV 文件打开后，中文都显示成乱码。
"""

response = client.responses.create(
    model=os.environ["AI_MODEL"],
    input=prompt,
)

print(response.output_text)

代码中的 prompt 先声明任务，再给出类别定义，接着写约束和格式，最后放入待处理文本。把待处理文本放在明确的标签或标题之后，是一种简单的边界标记方式；实际项目中还应注意对输入内容进行长度限制和敏感信息处理。

response.output_text 是 SDK 提供的便捷文本属性。不同 SDK 版本或兼容服务的响应细节可能不同，开发时应以当前服务商的官方文档为准，并在自己的环境中确认模型名称和返回结构。本文不把“看起来合理的输出”当作程序保证：如果后续代码需要解析字段，下一篇关于结构化输出的知识会更适合这个场景。

常见问题

只写角色，不写具体任务

“你是一名专家，请帮助我处理这段文字”没有说明处理动作和验收标准。角色设定可以补充语气和视角，但不能替代任务定义。优先写清动词、输入和输出，再考虑是否需要角色描述。

把多个目标塞进一个请求

同时要求模型总结、翻译、判断情绪并生成营销文案，失败时很难知道是哪一步出了问题。更稳妥的做法是拆成多个明确步骤，或者至少为每个步骤规定独立的输入和输出。拆分还便于单独测试和重试。

约束互相矛盾

例如要求“只输出 JSON”，又要求“先解释判断过程”。模型可能在两条要求之间摇摆。约束应当互相兼容；如果机器要解析，就去掉额外解释，若需要调试信息则单独记录，而不是混进最终结果。

提示词写得很长，却没有示例

长篇背景不一定能消除歧义。对复杂格式而言，一个输入和对应输出的示例通常比几段抽象描述更直观。示例应覆盖边界情况，并且不能与规则冲突。

以为提示词能保证事实正确

清晰的指令只能改善任务执行，不能自动提供最新知识，也不能杜绝错误。涉及事实的应用应提供可信上下文、限制回答范围，并在程序层增加校验或人工复核。不要因为输出格式整齐，就把它当作已验证的事实。

小结

清晰提示词的核心不是堆砌技巧，而是把任务写成可验收的说明：明确动作，补足必要上下文，声明边界和异常处理，再规定稳定的输出格式。开发时先用最小提示词跑通，再用真实样本测试失败案例；每次修改只改变一个关键因素，才能知道改动是否真的有效。下一步学习 Few-shot 示例和提示词模板时，也应继续遵守这个顺序：先定义任务，再决定如何组织提示词。

搜索时光笔记