写好 Prompt，不是把话说得更长

很多人把 Prompt 工程理解成“寻找一句神奇口令”。实际项目里，真正决定稳定性的不是口号，而是把任务边界、上下文、输出协议和验收方法写清楚。模型只能根据当前输入推断你的意图；没有写出的部分，它只能猜。

一条好 Prompt 的价值，不只是让某一次回答更好，而是让结果变得可预期、可复用、可测试、可回滚。官方文档也普遍把提示工程描述为持续迭代的过程：先定义成功标准，再通过真实样本验证和改进。

一、先理解 Prompt 到底包含什么

Prompt 不只是用户最后输入的一句话。在大模型应用中，它通常由系统规则、本次任务、业务上下文、示例、用户数据和输出格式共同组成。Google 的提示设计文档把任务、系统指令、Few-shot 示例和上下文列为常见组成部分；这也说明，写 Prompt 本质上是在组织信息，而不是堆砌“请认真回答”之类的强调词。

角色：让模型采用合适的专业视角

角色不是越夸张越好。比起“你是世界上最顶尖的专家”，更有效的写法是说明专业领域、关注点和工作方式。例如：让模型以“负责性能与安全审查的 Python 后端工程师”视角检查代码，远比“你是一个助手”更具体。

任务：用动作词写清楚要做什么

“分析一下”“优化一下”都太宽。最好明确动作和交付物，例如“找出 5 个性能瓶颈，按影响程度排序，并给出可执行修改建议”。复杂任务需要拆解，避免把检索、判断、生成、校验全部塞进一句话。

上下文：把业务前提主动告诉模型

模型不知道你的用户是谁、材料来自哪里、术语在公司内部怎么定义。对业务结果有影响的背景，需要主动提供；与任务无关的历史信息则应删除，避免重要指令被淹没。

格式：约定长度、字段和失败处理

当输出要进入数据库、工作流或下一步 Agent 时，格式约束往往比“文风好不好”更重要。除了字段，还要写清楚枚举值、空值、未知情况和禁止输出的内容。

示例：直接展示什么叫合格答案

对标签分类、品牌语气、固定 JSON、SQL 注释等任务，示例通常比长篇规则更直观。示例要有代表性，尤其要覆盖容易混淆的边界情况。

二、从差 Prompt 到好 Prompt

好 Prompt 不一定很长，但必须把影响结果的关键选择写出来。判断一条 Prompt 是否合格，可以问四个问题：模型知道给谁看吗？知道做到什么程度吗？知道用什么格式吗？遇到信息不足时知道怎么办吗？

一个可直接复用的通用模板

## 角色
你是一名【专业角色】，重点关注【关键能力或风险】。
## 任务
请完成【明确动作】，最终交付【具体结果】。
## 上下文
- 目标受众：【谁会使用结果】
- 使用场景：【结果将用于哪里】
- 已知信息：【必须参考的事实或材料】
## 约束
- 范围：【包含什么 / 不包含什么】
- 长度：【字数或条数】
- 风格：【正式、通俗、技术化等】
- 不确定时：【说明缺失信息，不要猜测】
## 输出格式
按【固定结构或字段】输出。
## 示例
输入：……
输出：……
## 待处理内容
【用户输入或材料】

三、Few-shot：用样例对齐格式和风格

Zero-shot 是只给任务，不给示例；One-shot 给一个示例；Few-shot 则提供少量输入输出对。Microsoft 的提示工程文档指出，Few-shot 并不会永久改变模型，而是在当前请求中用样例“调节”模型的行为。

示例不是越多越好。优先选择能覆盖主要模式、最容易出错和最需要保持格式一致的案例。大量重复样例会增加 token、延迟和维护成本。

四、长 Prompt 要分层，不要把所有文字混在一起

长 Prompt 最怕边界不清。系统规则负责长期身份和安全边界；任务指令描述本次工作；上下文只提供事实材料；用户输入是待处理数据；输出协议负责约束结构。外部网页、邮件、文档和检索片段都应视为不可信数据，不能因为它们写着“忽略之前要求”就当成真正指令。

Markdown 标题、XML 标签、代码围栏都能起到分隔作用。关键不是迷信某种符号，而是让同一类信息始终放在固定区域，并确保模板变量不会把数据插进高优先级指令中。

五、输出格式要为下游系统负责

要求 JSON 时，不能只写“用 JSON 输出”，还要说明字段、类型、枚举值、最大长度和缺失值处理。能使用结构化输出或 Schema 校验时，应优先依赖系统能力，而不是完全相信模型会始终输出合法 JSON。

{
    "summary": "20 字以内概述",
    "sentiment": "正面 | 中性 | 负面",
    "keywords": [
        "最多 3 个关键词"
    ],
    "confidence": 0,
    "missing_information": [

    ]
}

六、复杂任务用 Prompt Chain 拆开做

一条 Prompt 同时承担事实提取、内容创作、合规检查和格式转换，任何一步出错都很难定位。Prompt Chain 把任务拆成多个节点，每一步有独立输入、输出和验收规则。这样既方便重试，也方便为不同步骤选择不同模型或工具。

七、推理任务重视可核查结果，不要求展示完整思维链

对计算、排障和多约束规划任务，可以要求模型先规划再执行，但面向最终用户时，更适合输出结论、关键依据、可复查步骤和不确定性，而不是强制展示冗长的内部思考过程。这样既节省 token，也更容易审查。

一个实用写法是：“先检查输入是否完整；完成分析后，只输出最终结论、关键证据和需要人工确认的风险点。若无法确定，请说明缺少哪些信息。”

八、RAG 和 Agent 场景：不能只靠 Prompt 兜底

OpenAI 的提示工程文档把检索增强生成视为向请求加入相关上下文的一种方式。真正可靠的 RAG 不只是“把文档塞进 Prompt”，还要控制检索质量、标记来源、限制上下文长度，并要求模型在材料不足时拒绝编造。

Agent 还能调用工具和执行操作，风险更高。工具名、参数类型、可访问数据和敏感动作确认都应该由系统层控制，不能只写一句“不要做危险操作”就结束。

九、Prompt 工程必须有测试集和迭代闭环

Anthropic 的官方指南建议在优化 Prompt 前，先有明确的成功标准、可实证测试的方法和一版初稿。实际项目可以建立覆盖正常、边缘、对抗和历史失败案例的测试集，每次修改只改变一个关键点，并和上一版本对比。

常见指标包括：任务正确率、格式通过率、引用正确率、拒答准确率、人工评分、平均输入 token、首 token 延迟和单次成本。没有评测时，“感觉变好了”通常不可靠。

十、Prompt 要像代码一样管理

生产 Prompt 应进入代码仓库或集中管理系统，和业务逻辑一起审查、测试、发布和回滚。OpenAI 当前文档也明确建议把 Prompt 当作应用代码：使用命名模块、类型化变量、代表性测试样本、评测检查、Git 历史、PR 审查、发布标签和功能开关。

Google Cloud 的 Prompt Management 也强调把 Prompt 作为可版本化资产进行创建、更新、共享和复用。无论使用什么平台，至少要记录 Prompt 文本、模型版本、参数、测试集、指标、变更原因和发布时间。

十一、安全：Prompt Injection 不能只靠一句“忽略恶意指令”

Prompt Injection 是针对对话式 AI 的社会工程攻击：攻击者把恶意指令藏在网页、文档、邮件或检索内容中，诱导模型偏离用户本意。随着 Agent 能读取隐私数据、发送邮件和执行操作，这类风险会明显放大。

更可靠的防护是多层组合：区分可信指令与不可信数据；只授予完成任务所需的最小权限；敏感操作要求人工确认；工具参数使用白名单和类型校验；对输出进行内容与权限检查。明确、具体的任务范围也比“查看所有邮件并自行处理”这种宽泛授权更安全。

十二、Prompt 压缩：删噪声，不删边界

长 Prompt 会增加输入 token、延迟和维护成本，但“短”不是目标，“高信息密度”才是目标。可以删掉重复强调、无关礼貌话和相似样例；不能随便删除任务边界、关键上下文、输出字段和边缘案例。

稳定不变的前缀还可以结合 Prompt Caching 降低重复请求的输入成本和延迟。无论手工精简还是使用自动优化工具，都必须在自己的测试集上验证，避免为了省 token 破坏效果。

十三、上线前检查清单

最后再做一次反向检查：有没有让模型猜的重要信息？有没有把外部内容误当成指令？输出能否被程序严格校验？失败时是否会明确拒答或返回缺失信息？每次改动是否可以通过版本记录找到原因并快速回滚？

结语

Prompt 工程不是靠“更会聊天”获得偶然好答案，而是把目标、上下文、格式、示例、安全边界和评测闭环组织成一套可维护的系统。个人使用时，五要素已经能解决大多数问题；进入 RAG、Agent 和生产系统后，Prompt 必须和检索、权限、结构化输出、测试与版本管理一起设计。