03 Prompt：给 AI 装一本“任务交代手册”

你平时跟 AI 打交道，是不是经常遇到这种情况：你觉得需求说得很清楚了，它给出来的东西却南辕北辙。改了几版提示词，结果还是时好时坏。问题往往不在于 AI 笨，而是我们没把话说到点子上。

这篇文章聊的就是怎么把话说清楚，让模型真的听懂。

先说 Prompt 到底是什么

Prompt 就是你丢给大模型的输入，里面可以包含任务、背景、约束和输出格式。模型会根据你给的信息往后生成内容。如果你没交代清楚任务边界、需要什么信息、结果要什么形式，模型就只能自己猜。猜对了是运气，猜错了是常态。

所以提示词工程的核心就一件事：把该交代的条件交代清楚，而不是把字数堆上去。

怎么写好一条 Prompt

写好一条 Prompt，不看长度，看它有没有把任务说清楚。一个合格的 Prompt 通常要交代四件事：Role、Task、Context、Format。

要素	作用	例子
Role（角色）	告诉模型用哪个领域的知识和语气	“你是一位有 10 年经验的 Java 架构师”
Task（任务）	说明要完成什么	“请评审以下代码的性能问题”
Context（上下文）	补充相关背景	“当前线上 QPS 2000，响应时间超 500ms”
Format（格式）	规定输出长什么样	“输出 JSON，包含 bottleneck 和 solution 两个字段”

拿代码评审来说，差的 Prompt 只写“分析这段代码的性能问题，给出优化建议”。模型不知道要以什么视角评审，也拿不到负载情况和结果粒度。好的 Prompt 会给出角色、任务、背景和格式，模型据此确定分析重点，按指定粒度返回结果。

比喻：Role 就像你请师傅上门

你不会随便找个路人问“帮我看下这水管”。你会先找水电工，再告诉他“厨房下水慢，你帮我看看是不是堵了”，最后说“修完告诉我换了什么零件、花了多少钱”。Role 是找对人，Task 是说清事，Context 是交代背景，Format 是约定交付物。

顺序也有讲究

斯坦福大学的研究提过一个现象：模型对放在上下文中间位置的关键信息，利用效果往往更差，这就是常说的“Lost in the Middle”。开头和结尾的信息更容易被注意到。

所以角色定义和格式要求分别放在输入两端，可以减少关键约束被淹没的风险。但实际顺序还是得根据任务类型、模型和输入长度去试，没有万能模板。

别把 Prompt 写成说明书

“写清楚”不等于把所有资料都塞进去。无关信息会增加模型定位重点的难度，也会拉高延迟和成本。查个 API 用法、翻译一句话，一句话 Prompt 就够了。代码评审、方案设计这种复杂任务，用四要素框架把边界讲清楚就行，别把无关背景一股脑倒进去。

Prompt 需要反复调

提示词工程不是写完一版就完事。评测至少要覆盖正常、边缘和已知失败场景，再根据失败类型补充约束。每次只调一个变量，并保留测试结果，才能判断输出变化到底来自哪条规则。

最小评测可以这样做：选 10-30 条代表性输入，固定模型、Temperature、System Prompt 和检索材料，记录格式合规率、事实错误率、字段缺失率这些指标，单点修改，上线后保留失败样例定期回放。

常用技巧有哪些

角色扮演

角色设定用来约束模型的专业视角和表达方式。“你是一位专注于性能优化的 Java 架构师”比“你是 AI”多出了领域和任务倾向。但角色本身不能补足缺失的业务背景或输出格式。长对话中塞了大量无关内容后，早期角色设定的影响也会减弱，复杂任务要控制历史上下文，或者干脆开新会话重新交代。

思维链（CoT）

CoT 适合数学计算、逻辑推理、多步骤分析这些需要显式检查过程的任务。普通模型可以要求给出简要推理步骤，但 reasoning model 不一定暴露完整内部推理链。工程上更适合要求输出关键依据、检查步骤和最终结论。

最简单的用法就是加一句“请给出关键步骤后再回答”。复杂一点的可以用引导式 CoT，让模型回答前先检查几个问题，比如涉及哪些关键变量、变量之间什么关系、答案怎么验证。

比喻：CoT 就像让实习生写出解题过程

你让实习生算个数，他直接报答案，你没法判断他是真算对了还是蒙的。你让他把每一步写出来，他要是中途卡壳或者跳步，你一眼就能看出来。CoT 就是让模型把“草稿纸”摊开给你看。

但简单查询、翻译、格式转换就没必要用 CoT，硬加只会增加延迟。生产环境里优先输出依据和校验结果，减少冗长推理。

少样本学习

复杂任务或格式严格的任务，给 1-3 个示例通常比一大段文字说明更管用。示例直接告诉模型“输出应该长什么样”，比单纯说“请输出 JSON”直观得多。

示例要和真实任务同类型，能覆盖边缘情况，格式足够清楚。简单格式 1 个就够，复杂格式或多种边缘情况放 2-3 个。超过 3 个之后收益通常会下降，还多花 Token。

任务分解

复杂任务可以拆成多个输入、输出都能单独检查的子任务。某一步出错时能定位到对应步骤，不必重写整条任务链。

复杂场景怎么处理

长文本和减少幻觉

多份长文档进入同一上下文时，文档顺序和查询位置都会影响模型对材料的利用。可以先放文档材料，再在末尾给出 Query 和指令，让任务要求靠近上下文末端。更实用的办法是先引用再分析：让模型提取相关原文，再基于引用做判断，减少空口编结论的情况。

幻觉没法彻底消掉，只能降低概率。可以在 Prompt 里明确允许模型承认不知道，比如“如果对任何方面不确定，或者报告缺少必要信息，请直接说我没有足够的信息来评估这一点”。还可以多次采样，比较多次输出的关键字段，分歧大时再回到检索证据或 Schema 约束去排查。

结构化输出与降级策略

想让输出稳定，最好用 JSON Schema 或 XML Schema 直接定义结构。但不同格式各有麻烦：JSON 语法严格，字段缺失或类型不匹配解析容易失败；XML 层级清晰但内容会变长；YAML 对流式输出友好但缩进出问题很难排查。

实际项目里最好准备降级策略。解析失败时记录日志、触发重试，或者给默认值兜底。更完整的处理链路是：Schema 校验失败就记录原始响应和版本信息，字段缺失可重试一次并把期望类型反馈给模型，类型错误先校验再转换，枚举越界映射到 UNKNOWN 或走人工审核，重试仍失败则用兜底模板并统计失败率。

链式提示

链式提示就是把一个大任务拆成多条 Prompt，每条只处理一个子任务。多步骤分析、数据转换、合同审查、代码评审都适合这么做。设计时记住几条：任务拆小，前一步输出传给下一步，每一步只做一件事，哪一步出错就单独调哪一步。

比喻：链式提示就像流水线

一个人从头到尾组装一台手机，出了问题你都不知道是哪个环节的锅。拆成流水线之后，屏幕没装好就查屏幕工位，电池有问题就查电池工位。哪一步坏了修哪一步，不用整条线推倒重来。

链式提示最大的价值就是方便定位问题。如果最后邮件写得差，你能查出来是风险识别错了，还是沟通邮件生成错了，还是最后审查没做好。

提示词注入和越狱

先区分两个概念。Prompt Injection 关注的是应用指令和工具执行被操纵，攻击来源可能是用户输入，也可能是网页、邮件、文档、工具结果里的间接恶意指令。Jailbreak 通常以绕过模型安全策略为目标，让模型生成受限内容。两者有重叠，但不能只按输入来源划分。

Agent 场景风险更高，因为模型不只是聊天，还可能调工具、写文件、发邮件、改数据库。工具返回内容也属于不可信输入，同样要做注入防护。

防护一般从三层做。最底层是权限控制，代码执行环境要和宿主机隔离，API Key 和数据库权限尽量收窄，危险操作需要额外授权。中间一层是把 System Prompt 和 User Input 分开，用分隔符把不可信内容包起来。但分隔符只能帮模型区分边界，没法在安全层面阻止危险操作，带副作用的工具必须在代码层完成鉴权、参数校验、沙箱隔离和人工确认。高危操作应在执行前中断流程并请求审批。

比喻：分隔符是贴标签，不是上锁

你在一个盒子上贴“这不是炸弹”，标签能提醒别人注意，但如果里面真是炸弹，标签拦不住它。真正能拦住的是保险柜的锁、门口的安检和开柜需要两个人同时授权。Prompt 里的分隔符是标签，权限控制和沙箱才是锁和安检。

从 Prompt 到 Agent

单条 Prompt 只能约束当前输入。Agent 进行多轮推理、调用工具和读取记忆时，模型还会看到历史消息、工具结果和检索材料。Context Engineering 负责从这些可用信息中选择内容，组织进有限的上下文窗口。

一个真实的上下文窗口里通常包含系统提示词（角色、约束、输出格式）、工具上下文（可调用函数签名、上一步返回结果）、记忆上下文（短期对话历史、长期偏好检索）和外部知识（RAG 检索段落、数据库快照）。这些内容共同占用窗口空间，需要根据当前任务决定保留哪些、各留多长。

多 Agent 或多模块协作时，一个 Prompt 很难处理所有任务。提示词路由先识别请求类型，再选择对应的检索、分析或诊断链路。低置信度请求应进入追问或人工确认流程，像“删数据”这种高风险意图不能被当作普通问答处理。

工具设计别搞太复杂，几个原则够用：名称和描述要对 LLM 友好，语义清楚；工具只封装技术逻辑，不要把主观决策塞进去；一个工具只做一件事，保持原子性；权限别给多，能读就别给写，能查一张表就别给整个库。

用回归集维护 Prompt

先选一批真实样例，把当前 Prompt、模型版本、采样参数和工具定义一起固化成基线。每次修改只解决已经观察到的失败类型，同时检查旧样例有没有退化。结构化输出交给 Schema 校验，带副作用的工具交给权限与审批层，Prompt 只负责描述任务和决策规则。模型或 API 版本变化后要重新跑回归集，不能假设旧 Prompt 会保持同样表现。

总结

Prompt 的职责是把任务、必要背景、约束和输出格式表达清楚。角色设定、少样本示例、任务拆分、结构化输出和链式调用都是可选手段，用不用取决于任务复杂度、可接受成本和实际效果，不能靠堆叠技巧解决所有问题。

当系统开始检索信息、调用工具、维护多轮状态时，输出质量还取决于 Context、工具定义、权限和校验。用真实样例固定模型、参数和工具 Schema，持续跑回归集，才能判断一次 Prompt 调整是不是真的改善了结果，同时避免旧场景退化。

说到底，提示词工程不是玄学，也不是“咒语大全”。它更像是一种沟通训练：把话说清楚，把边界划明白，把验收标准定下来。你跟人协作时怎么交代任务，跟模型打交道时也差不多。