Prompt 工程是把模糊意图翻译成可执行、可验证指令的方法。它不是“写一句神奇咒语让 AI 变聪明”，而是像需求分析一样，把目标拆成模型能执行的任务、输入、约束和验收标准。

导读：你可以把这篇当成 Prompt 工程实践流程来用。本文不提供“万能提示词”，而是给一套可复用方法：先判断任务类型，再写上下文和约束，最后用验证标准检查输出是否可用。

如果你主要在 Claude Code 或 Claude API 场景里使用 Prompt，可以结合 Claude 教程专题 和 Claude Code 完全指南 一起看，先明确工具、API 和工作流边界。

先判断：你需要 Prompt，还是需要更好的输入？

很多人以为 AI 回答差是 Prompt 不够高级，其实常见原因是输入缺失。

问题表现真正原因优先修复
AI 输出很泛没有场景和目标读者补充使用场景、读者、输出用途
AI 胡编事实没给来源或证据提供 官方来源 / reference
输出格式不稳定没有结构约束明确 JSON、表格、步骤或字数
代码不能运行没给项目上下文提供文件路径、依赖、错误日志
反复改不好任务太大拆成小任务，逐步 verify

一个好的 Prompt 不一定长，但必须回答四个问题：

  1. 你是谁：模型扮演什么角色；
  2. 要做什么：具体任务；
  3. 输入是什么：上下文、数据、代码、来源；
  4. 怎么验收：格式、质量标准、不能做什么。

Prompt 的基础公式

我最常用的公式是：

1
角色 + 任务 + 上下文 + 约束 + 输出格式 + 验收标准

示例：

1
2
3
4
5
6
你是一个 Python 后端开发。
任务：为 FastAPI 项目写一个用户注册接口。
上下文：项目使用 SQLAlchemy，用户表已有 email/password_hash 字段。
约束：不要写数据库迁移；不要返回明文密码；错误用 HTTPException。
输出格式：只返回代码块。
验收标准：包含输入校验、重复邮箱判断、密码哈希。

这比“帮我写个注册接口”稳定得多，因为模型知道边界，也知道什么算完成。

零样本提示：适合简单任务

零样本提示就是不给例子，直接说明任务。它适合范围明确、格式清楚的任务。

推荐写法

1
2
3
4
5
6
7
8
把下面这段中文技术说明改写成面向初学者的版本。
要求：
1. 保留核心概念；
2. 删除营销语；
3. 每段不超过 80 字；
4. 输出 Markdown。

原文：...

不推荐写法

1
帮我润色一下。

“润色”没有标准。是更专业、更口语、更短、更适合 SEO，还是更适合产品页？模型只能猜。

少样本提示：适合风格和格式要求高的任务

如果你想控制风格，给一个例子比写十条形容词更有效。

1
2
3
4
5
6
把产品描述改成电商列表页短文案，每条不超过 20 个词。

输入：Built with a powerful 1500W motor, this blender crushes ice, frozen fruit, and tough greens in seconds.
输出：1500W motor, crushes ice and fruit in seconds.

现在处理：This espresso machine features a 15-bar pump and PID temperature control for consistent extraction.

例子的作用不是“让 AI 模仿句子”，而是让它看到：保留哪些信息、删掉哪些信息、长度控制到什么程度。

结构化输出：让结果可以被程序使用

如果 Prompt 用在 API 或自动化流程里，输出格式必须稳定。

JSON 输出示例

1
2
3
4
5
6
7
8
9
10
11
分析下面网页标题，判断是否适合 SEO。
只输出 JSON，不要解释。

Schema:
{
  "score": number,
  "issues": string[],
  "rewrite": string
}

标题：...

表格输出示例

1
2
3
4
5
审查下面代码，按表格输出：

| 严重程度 | 问题 | 证据 | 修复建议 |

只列确定存在的问题，不要猜测。

结构化输出的好处是：后续可以直接解析、排序、保存，而不是每次人工复制。

思维链和分步推理：不要要求它“想得越多越好”

复杂任务需要分步，但不是所有任务都要模型输出长推理。更好的方式是让它输出“检查过程”和“结论”，不要要求无边界地展开内心推理。

推荐：

1
2
3
4
5
6
分析下面函数的 bug。
按以下结构输出：
1. 输入假设
2. 可能失败的路径
3. 最小修复方案
4. 一个测试用例

不推荐：

1
一步一步详细展示你的所有思考过程。

前者能让结果可验证，后者容易变成长篇废话。

Prompt 调试 流程

当输出不满意时，不要立刻整段重写。按这个顺序调：

  1. 检查输入是否缺信息：有没有文件、数据、目标读者、来源；
  2. 检查任务是否太大：能不能拆成 2-3 步；
  3. 检查格式是否明确：是否指定 Markdown、JSON、表格；
  4. 给反例：指出哪里不对，让它按新标准重做；
  5. 加验收标准：让它自己检查输出是否满足。

示例纠正：

1
2
不对。你把“consistent extraction”删掉了，但这是核心卖点。
请保留这个信息，并重新输出 3 个不超过 20 个词的版本。

比起“再写好一点”，这种反馈更容易让模型修正。

实战模板：代码审查

1
2
3
4
5
6
7
8
9
10
11
你是资深代码审查者。
任务：审查下面 diff 是否存在正确性 bug。
范围：只关注会导致运行错误、数据错误、安全风险的问题。
不要评价命名、格式或个人风格。

输出表格：
| 严重程度 | 位置 | 问题 | 为什么是问题 | 修复建议 |

如果没有确定问题，输出：未发现确定性 bug。

代码：...

这个模板的关键是“只关注确定性 bug”。否则模型会给很多风格建议，反而降低审查效率。

实战模板：技术文章改写

1
2
3
4
5
6
7
8
9
10
你是技术博客编辑。
任务：把下面文章改成更符合 People-first content 的教程。
要求：
1. 首段说明适合谁、不适合谁；
2. 保留可执行步骤；
3. 增加验证方式和常见失败排查；
4. 涉及第三方事实时标出需要 官方来源 的位置；
5. 不要用泛泛总结凑字数。

文章：...

这个模板适合修复低价值内容，因为它不是简单扩写，而是补“场景、边界、验证、来源”。

实战模板：错误排查

1
2
3
4
5
6
7
8
9
10
11
12
13
14
我遇到了这个错误：
[粘贴完整错误]

上下文：
- 操作系统：
- 运行命令：
- 相关文件：
- 最近改动：

请输出：
1. 最可能原因（按概率排序）
2. 每个原因的验证命令
3. 最小修复步骤
4. 如果修复失败，下一步看什么日志

错误排查类 Prompt 的重点是“验证命令”。没有验证命令，AI 只是猜。

实战模板：对比选型

1
2
3
4
5
6
7
8
9
10
11
12
13
比较方案 A 和方案 B。
我的约束：
- 预算：每月不超过 100 美元
- 团队：1 人维护
- 技术栈：Next.js + SQLite
- 优先级：稳定性 > 成本 > 功能

输出：
1. 决策表
2. 各自风险
3. 迁移成本
4. 最终建议
5. 什么时候应该重新评估

选型类 Prompt 必须给约束。没有约束的“哪个好”没有意义。

Prompt 质量检查表

写完 Prompt 后，用这张 checklist 自查：

检查项合格标准
任务明确一个 Prompt 只解决一个主要任务
输入充分给了必要上下文、文件、数据或来源
约束清楚写明不能做什么、优先级是什么
格式稳定指定 Markdown / JSON / 表格 / 代码块
可验证有成功标准、测试方式或检查清单
可迭代输出不好时能指出具体问题

如果其中两项不合格，先改 Prompt，不要怪模型。

官方参考与 资料来源

Prompt 写法没有唯一标准，但不同平台有自己的最佳实践。建议优先看官方文档：

核验规则：System Prompt、工具调用、JSON 输出、上下文缓存等能力会随模型和 API 更新变化，涉及生产系统时应以 官方文档 和自己的小样本测试为准。

FAQ

Prompt 越长越好吗？

不是。Prompt 应该足够明确，但不应该把无关背景都塞进去。长 Prompt 如果没有结构，反而会增加模型忽略重点的概率。

要不要保存自己的 Prompt 模板？

要。尤其是代码审查、错误排查、内容改写、数据抽取这类重复任务。模板能减少每次重新描述任务的成本。

为什么同一个 Prompt 每次输出不同？

可能是模型参数、上下文、输入细节或随机性导致。生产场景应固定输出格式、降低自由度，并增加自动校验。

Prompt 工程会被 Agent 取代吗？

不会完全取代。Agent 只是能执行更多步骤，但每一步仍需要清楚的目标、边界和验证标准。

总结

Prompt 工程的本质是：把模糊意图翻译成可执行、可验证的指令。

最好的 Prompt 不是最长的，而是让模型知道：任务是什么、输入是什么、边界在哪里、输出怎么验收。只要坚持“上下文 + 约束 + 格式 + 验证”这四件事，大多数 AI 协作质量都会明显提升。