在与 LLM 协作时，上下文工程（context engineering）的重要性持续上升，而提示词工程（prompt engineering）正是其中不可或缺的基础模块。
提示词工程指的是：如何把指令组织好，让模型产出更贴近目标。它涵盖你如何提问、如何规定风格、如何提供背景，以及如何约束模型行为。含糊一句与精心写就的提示，差别往往是「泛泛而谈」与「一次到位」——结构差的提示要靠多轮来回澄清意图，而工程化好的提示常常一轮就够。
下文先给出可立刻上手的基础习惯，再扩展到复杂项目里常用的进阶方法。
1.提示词工程在做什么
最朴素的理解：提示词工程就是在真正请求之前，改好你交给 LLM 的那段话。很多时候只是在查询里多塞一点信息——但难点在于：该塞哪些、不该塞哪些，这才是写出高效提示的关键。
核心技巧
以下习惯构成与模型有效互动的基础；持续使用，通常能立刻看到回答质量的变化。
明确、直接
现代模型对清晰、显式的指令响应很好。不要默认模型会「猜到你的意思」——请直接说出来。用简单句式说明要什么，避免歧义。
原则：让模型清楚看到你想要什么。要详尽输出就明说；要若干具体特性就逐条列出。Claude 等新一代模型尤其受益于明确指引。
示例（分析看板）
- 含糊：「做一个分析看板」
- 明确：「做一个分析看板。尽可能包含相关功能与交互，在基础版之上做全功能实现。」
后者明确要求「全面」与「超出最低限度」。
习惯要点：
- 开头用动作动词：写、分析、生成、创建……
- 少寒暄，尽快进入任务
- 说明输出里要包含什么，而不只描述「围绕什么主题做」
- 对深度、覆盖面有明确预期
交代背景与动机
解释为什么这样要求，有助于模型理解目标，从而给出更贴切的回答；对能推理用户意图的新模型尤其有效。
示例（版式偏好）
- 较弱：「绝对不要用项目符号」
- 较好：「我更希望用自然段落而不是条目，因为连贯文字更易读、更像对话；条目显得太正式，不符合我轻松学习的方式。」
后者让模型理解规则背后的原因，便于在相关版式选择上做出一致判断。
适合交代背景时：说明产出用途或读者；解释约束从何而来；说明结果将如何被使用；说明你正在解决什么问题。
具体
「具体」意味着用显式约束与要求组织指令——你越清楚描述要什么，结果往往越好。
示例（膳食计划）
- 含糊：「按地中海饮食做一份膳食计划」
- 具体：「为糖尿病前期管理设计地中海饮食方案：每日约 1800 大卡，侧重低升糖食物。列出早、午、晚各一餐及一份加餐，并给出完整营养分解。」
怎样算足够具体：写清约束（字数、版式、时间线）；相关情境（受众、目标）；期望结构（表格、列表、段落）；限制条件（饮食、预算、技术约束等）。
使用示例（one-shot / few-shot）
并非每次都需要示例，但在说明概念或示范格式时，示例往往比纯描述更有效。示例即 one-shot 或 few-shot，用「示范」代替长篇规则。
对现代模型的提醒：Claude 4.x 等高级模型会非常仔细地模仿示例里的细节。请保证示例体现你希望强化的行为，并弱化你不希望出现的模式。
示例（文章摘要）
与其只说「摘要这篇文章」，不如：
以下是我想要的摘要风格示例：
文章：[某篇 AI 监管报道的链接]摘要：欧盟通过全面 AI 法案，针对高风险系统；关键条款含透明度与人类监督要求，2026 年生效。
请用同样风格摘要这篇文章：[新文章链接]何时用示例：期望格式「展示比描述更容易」；需要固定语气或文体；任务涉及细微惯例；简单指令无法稳定复现结果。
技巧：先给一个示例；仍不满意再增加（few-shot）。
允许表达不确定
明确允许模型在信息不足时承认不知道，而不是编造，可降低幻觉、提高可信度。
示例：「分析这份财务数据并指出趋势。若数据不足以得出结论，请说明，不要臆测。」
2.进阶提示工程技巧
核心习惯能解决大量问题；若你在搭建智能体方案、处理复杂数据结构或需要多阶段拆解，下列进阶方法会更常用。
预填（Prefill）助手回复
预填指由你写出助手回复的开头，从而约束格式、语气或结构，对强制 JSON/XML 等结构、跳过「好的，这是您要的……」类开场尤其有效。
适用：需要结构化输出；想跳过寒暄；要保持特定人设或开篇方式。
示例（JSON）：对话接口里模型可能先说「这是您要的 JSON：{…}」。在 API 中可将上一轮助手内容设为 {，让模型从花括号后继续，更易得到纯 JSON。
聊天界面可用显式约束近似：「只输出合法 JSON，不要前言，并以左花括号开头。」
思维链（Chain of thought, CoT）
思维链要求模型在给出最终答案前逐步推理，适合需要结构化思考的复杂分析任务。
现代做法：Claude 提供 extended thinking（扩展思考） 等能力，在可用时往往优于手写 CoT；但若不可用，或你需要可审阅的透明推理，手写 CoT 仍有价值。
何时用手写 CoT：免费版等场景下没有扩展思考；需要可检查的推理过程；任务需多步分析；希望模型必须考虑若干因素。
常见三种写法：
- 基础 CoT：在指令末尾加「一步一步思考后再写」。
- 引导式 CoT：规定推理阶段顺序（先……再……最后……）。
- 结构化 CoT：用标签区分推理与终稿（如在
<thinking>中推理，在<email>中写邮件）。
扩展思考与显式 CoT 可互补，不必二选一。
控制输出格式
对现代模型可优先考虑：
-
说「要怎样」而不是只说「不要怎样」
- 与其说「不要用 Markdown」，不如说「正文用连贯段落写成散文」。
-
提示的版式风格会影响回答——若希望少用 Markdown，提示里也可减少 Markdown。
-
长篇版式要求可写进同一段说明（如报告只用段落与必要标题，列表仅在枚举离散项时使用等）。
提示链（Prompt chaining）
提示链无法在一次对话里完成，而是把复杂任务拆成多轮独立提示，上一步输出作为下一步输入。用延迟换准确率，每步任务更简单；通常用工作流或代码编排，也可手工分步提问。
示例（研究摘要）：先摘要论文（方法、发现、临床意义）→ 再让模型评审摘要的准确与完整并打分反馈 → 再据反馈改写。
适合：复杂需求需分步；需要多轮打磨；多阶段分析；中间校验有价值；单次提示结果不稳定。
代价：多次调用，延迟增加；复杂任务上准确率与可靠性常明显提升。
3.你可能听过的老技巧
部分在早期模型上流行的做法，对 Claude 等新一代模型不再必需，但在旧文档里仍会出现，特定场景也有用。
XML 标签划分结构
曾常用 XML 包裹大段材料以增强边界感；现代模型多数情况下用**清晰标题、空行、明示「以下数据用于……」**即可达到类似效果，开销更小。
仍可考虑 XML：极复杂、多类型内容混排；必须死死卡住边界；对接旧模型。
角色提示（Role prompting）
「你是一位理财顾问……」这类人设有时有效，但现代模型上过重的人设往往不必要，还可能限制发挥。
注意：不要过度收窄角色——「乐于助人的助手」常好过「只说术语、永不犯错的世界级专家」。
人设可能有用时：需要批量统一语气；产品需要固定人设；需要领域视角框定复杂问题。
替代：直接写清视角——「从风险承受力与长期增长潜力分析该组合」，常比硬套角色更有效。
4.综合示例
单独技巧之外，真正有效的是按需组合。提示工程的艺术不是堆砌全部技巧，而是为当前任务选对组合。
原文中的「多技巧合一」示例（修正首词笔误为 Extract）大意如下：从季报抽取关键财务指标并以 JSON 给出；说明数据将用于自动化处理故必须仅输出合法 JSON；给出字段结构示例；若某指标在文中不明确则用 null 而非猜测；要求以 { 开头——其中同时体现了：明确任务、交代动机、示例结构、不确定时勿编造、格式控制。
5.如何选择技巧
不必每段提示都用遍所有技巧。可参考：
- 请求是否足够清晰？否，则先改清晰度。
- 任务是否简单？是，则核心技巧（具体、明确、背景）通常足够。
- 是否需要固定格式？考虑示例或预填。
- 任务是否复杂？考虑拆分（提示链）。
- 是否需要逐步推理？优先扩展思考（若可用），否则 CoT。
需求 | 可考虑 |
固定输出格式 | 示例、预填、显式版式说明 |
逐步推理 | Claude 4.x 扩展思考，或思维链 |
复杂多阶段任务 | 提示链 |
可审阅的推理过程 | 带结构的思维链 |
抑制幻觉 | 允许在不确定时说「不知道」/用 null |
常见问题排查
现象 | 处理方向 |
回答太泛 | 提高具体度、加示例，或明确要求「超出基础版」 |
偏题或未理解意图 | 更明说真实目标，补充背景 |
格式不稳定 | few-shot 或预填控制开篇 |
任务太难、结果飘 | 拆成多段提示链，每段只做一件事 |
多余开场白 | 预填，或写明「跳过前言直接作答」 |
编造信息 | 明确允许承认数据不足 |
只给建议未改代码 | 动作用祈使句：「请直接修改该函数」而非「能否给点建议」 |
技巧：从简单提示起步，只在实测有效时再加复杂度。
常见误区
- 不要过度工程化：更长、更复杂的提示未必更好。
- 不要跳过基础：核心指令含糊时，进阶技巧救不了。
- 不要假设模型会读心：含糊就给误读空间。
- 不要一次叠满所有技巧：按问题选招。
- 不要忘记迭代：第一版很少完美，要测要改。
- 不要死守过时套路：XML、重人设等对现代模型往往不如「说清楚」优先。
6.长上下文与「好提示」长什么样
进阶提示会占用更多 token（示例、多轮、长说明），上下文管理本身也是一门课；详见 Anthropic 的 context engineering 博文。
Claude 4.x 等模型对长上下文的整体关注度已明显改善，有助于缓解历史上的「中间遗忘」问题；即便如此，把大任务拆成边界清晰的小任务仍有价值——往往不是因为装不下，而是单任务聚焦时质量更稳。
策略：长材料里把最关键信息放在开头或结尾；复杂任务评估是否应拆成多个子任务分别优化。
提示工程是技能，只能靠实测打磨。系统训练可参考 Anthropic 的 提示工程课程。快速自检可问：输出是否符合要求？是否一次成功？多次尝试格式是否一致？是否踩了上文误区？
7.结语
提示词工程本质是沟通：用模型最容易对齐意图的方式把话说清。先内化文首的核心习惯，再在遇到明确问题时叠加进阶手段。最好的提示不是最长或最炫，而是用最小结构稳定达成目标。
向上下文工程演进，并不会削弱提示工程——相反，精心写的每一条提示，都会进入更大的上下文（对话、附件、系统指令等），共同塑造最终行为。