提示词工程

⚠️ 源单薄性声明 本仓没有一篇直接名为“prompt engineering guide”的正式本地条目。 本页主要依据 Claude Code 源码分析里对 system prompt 的拆解、output-styles.md 对 role / tone / output format 的说明、以及橙书里的实战对话例子，做边界清晰、不过度外推的整理。

一句话

提示词工程 / prompt engineering = 设计给 AI 的指令文本，让它更准确地理解你的意图并按预期输出。

它关心的是：
你这句话怎么说、先说什么、限制写到多细、要不要给范例、输出格式要不要指定。

和“上下文工程”“Harness”的边界

• 提示词工程：设计一条 prompt 或一段指令文本。
• 上下文工程：管理整个 session 的上下文空间。
• Harness：更大的一层，除了 prompt，还包括工具、权限、记忆、上下文管理、多 agent 组织。

可以这样记：

• prompt engineering = 局部表达
• context engineering = 全局编排
• harness = 整体运行脚手架

为什么重要

Claude Code 不是关键词搜索引擎，但“说得清楚”仍然极大影响结果质量。

橙书里一个很典型的例子是：

• 模糊说法：帮我优化一下这个页面的样式
• 明确说法：把标题的 font-size 从 16px 改成 18px，段落间距从 10px 改成 14px，只改这两处，不要动其他样式

模型没变，结果却完全不同。
区别就在于：后者把范围、约束、排除项说清楚了。

核心技术机制

1. 角色设定（role prompting）

output-styles.md 明确说明，系统 prompt 可以设定 role、tone 和 output format。
所以，“你现在是一位资深 TDD 工程师”“你现在扮演代码审查者”这类写法，本质上是在给模型一个工作视角。

2. 具体化任务边界

本地橙书总结得很实用：
指定文件、场景、技术选型、参考模式，比只说“大概要做什么”更有效。

例如：

• 说 做个登录功能 太宽
• 说 在 src/auth/ 下新增 Google OAuth，参考现有 GitHub 登录实现 更可执行

3. 给范本或 few-shot

“照着这个做”是很强的 prompt。
你项目里如果已经有一个写得对的范例，让 Claude 模仿它，常常比你口头描述十句更稳。

4. 分步执行或显式检查顺序

经典术语里这常被归到 CoT 一类，但在实际使用里，更可操作的写法是：

• 先读相关代码
• 再列方案
• 再实现
• 最后验证

这不是要求模型暴露所有内部思维，而是把行动顺序写明，减少它直接跳去错误执行。

5. 结构化输出

structured-outputs.md 明确支持 JSON Schema。
即使不走 SDK，普通对话里也可以用类似思路：

• 先列问题，再给建议
• 按“结论 / 证据 / 风险”输出
• 只返回 JSON

结构一旦明确，结果更容易检查，也更容易喂给后续流程。

6. 负向约束（negative prompting）

“不要动别的样式”“不要重构整个文件”“不要编造结果”这类约束非常重要。
它的价值不是增加能力，而是缩小模型的自由发挥空间。

最小可跑通例子

例子 1：模糊 prompt vs 清晰 prompt

帮我优化一下这个页面

vs

把标题的 font-size 从 16px 改成 18px，
把段落间距从 10px 改成 14px，
只改这两处，不要动其他样式。

第二种写法同时包含：

• 具体目标
• 可验证参数
• 明确边界
• 负向约束

例子 2：结构化评审 prompt

请审查这次改动。
先列问题，再给建议，最后给一个总体风险等级。
引用文件路径和行号；如果没有跑测试，要明确说没跑。

这类 prompt 同时做了两件事：

• 规定输出结构
• 规定真实性约束

常见误解

误解 1：写得越长越好

不对。
长 prompt 如果只是重复、绕弯、堆口号，只会让模型更难抓重点。

误解 2：提示词工程 = 上下文工程

不对。
本页优化的是“某次怎么说”；[[上下文工程]] 优化的是“整个会话里保留什么”。

误解 3：模型强了就不需要 prompt

也不对。
模型越强，越不需要花哨咒语；但边界、约束、输出格式、参考样例仍然很重要。

误解 4：提示词工程就是越狱技巧

不对。
本页讨论的是提升可控性和表达准确度，不是安全绕过。

与其他术语的关系

• [[上下文工程]]：本页是局部表达优化；它是全局上下文管理。
• [[CLAUDE.md]]：可视为“长期 prompt 层”，但它是会话启动时常驻的说明书。
• [[agent]]：agent 本质上也是一组角色与边界指令的封装。
• [[skill]]：skill 的描述和触发说明，本质上也是 prompt 设计的一部分。
• [[Harness]]：prompt 只是 harness 的一层，不是全部。

延伸阅读

• [[上下文工程]]
• [[CLAUDE.md]]
• raw/2026-04-18/claude-code-docs/output-styles.md
• raw/2026-04-18/claude-code-docs/agent-sdk/structured-outputs.md

needs_sources（明确待补）

• 独立的 prompt engineering 官方指南本地副本
• 更系统的反例：过度 prompt 如何让结果变僵
• 不同模型对同一 prompt 技巧的差异

---

🎬 3 个场景（读者最可能用到的情境）

场景 1 · 结构化指令（角色+任务+约束+格式）

HR 让 AI 写招聘文案。prompt： “角色=B 端 HR。任务=写一则 JD。约束=200 字内、避免套话、必须列 3 条硬性条件和 2 条加分项。格式=标题+正文+要求列表。” 结果比”帮我写个 JD”稳得多。

场景 2 · few-shot 给范例

散户让 AI 写持仓点评。直接说”写得短一点”无效；给它 2 段之前写得好的例子说”照这个风格”，立刻到位。范例比描述更有力。

场景 3 · CoT 引导分步

老师让 AI 解一道复杂应用题。prompt 里加一句”先列已知条件，再列未知，再写思路步骤，最后才给答案”。比一句”解答一下”少很多胡蒙。

⚖️ 和最像的邻居比

术语	本质区别	适用边界
提示词工程	单条指令的表达优化	一轮对话、一句指令
上下文工程	整个 session 的可见性设计	跨多轮、全局
角色设定（role prompt）	提示词工程的一种手法	需要固定工作视角时
越狱 prompt	安全绕过技巧（非本页范围）	和本页无关

🚫 反例（不该这么用）

反例 1 · 魔咒式 prompt（“你必须""极其专业""非常重要”堆满）

“你必须极其专业严谨认真仔细非常重要不能出错！“——这类修辞不会提高准确度，反而让模型更倾向于说套话。正确做法：把”必须”换成具体可验证的约束（“引用必须带文件路径和行号""没跑测试要明确说没跑”）。

反例 2 · 指令里没说”不要做什么”

写 500 字 prompt 全在说”做 ABC”，不说”不要 D 不要 E”。结果 AI 顺手把你没想让它碰的部分也重构了。正确做法：负向约束和正向约束一样重要，至少写 1-2 条明确禁区。

❓ 常见误解

• 误解 1：“prompt 越长越好” → 实际：长 prompt 如果只是重复、绕弯、堆口号，只会让模型更难抓重点；300 字清晰指令优于 2000 字口号。
• 误解 2：“模型强了就不需要 prompt” → 实际：模型越强越不需要花哨咒语，但”边界、约束、输出格式、参考样例”仍然必要。
• 误解 3：“提示词工程 = 上下文工程” → 实际：提示词工程优化”这一句怎么说”，上下文工程优化”整个 session 里保留什么”；一个局部、一个全局。

---

🧬 历史坐标（最早谁提 · 本质 · 分型 · git）

最早谁提

2020 年 Brown 等在 GPT-3 论文（arxiv:2005.14165）里提出 few-shot in-context learning，第一次把”只靠改写输入就能让模型做新任务”这件事写成实证研究；“prompt engineering” 作为社区术语随 2022 年 ChatGPT 公开后爆发，同年 Jason Wei 等的 Chain-of-Thought 论文（arxiv:2201.11903）把它从手艺推到可复现的方法论；DAIR.AI 的 Prompt Engineering Guide 是社区化的里程碑。

本质（一句话 · 20 字内）

怎么给 AI 下命令让它可靠产出。

分型 / 演化（2-4 行主线）

• 2020 few-shot / in-context learning → 2022 Chain-of-Thought（Wei）→ 2022 ReAct（Yao，思考+行动交替）→ 2023-2024 role-based / XML 结构化（Anthropic 风）
• 分叉一：学术派（CoT / Tree-of-Thought / self-consistency）
• 分叉二：工程派（role prompt + 结构化输出 + 负向约束，Anthropic Cookbook）
• 2024+ 开始被 context engineering 吸收为其中一层

代表 git / 文档

• Chain-of-Thought Prompting Elicits Reasoning in LLMs · Wei et al. 2022 · CoT 原文
• Prompt-Engineering-Guide · DAIR.AI · 社区级综合指南（含 CoT / ReAct / self-consistency）
• Anthropic Prompt Engineering 文档 · Anthropic · 工程派手册