Prompt 工程不是"魔法咒语学"。它是一种把任务讲清楚的能力——本质和你跟同事讲需求时讲得清楚不清楚没差别，只不过对面这个"同事"在某些维度更敏感（对结构、对示例、对上下文），在另一些维度更迟钝（不会自己反问、对领域黑话毫无知觉）。本章让你不是去背 100 句"完美 prompt 模板"，而是建立一套底层心法。

3.1 一个反直觉：把模型当实习生，而不是当神

坏 prompt：写一个爬虫
好 prompt：
  目标：爬取 https://example.com 上分页列表的标题。
  输入：起始 URL（list 页第 1 页）。
  输出：写入 items.jsonl，每行一个 {url, title}。
  约束：使用 httpx + selectolax，遵守 robots.txt，限速 1 req/s。
  错误处理：403 跳过该页，其他状态码重试 3 次。

差别不在字数，而在让模型知道边界。模型是个"特别想被使用的实习生"——你给的信息越具体，它越不会瞎发挥。

3.2 五元素清单

每次写 prompt 默念一遍：

元素 作用 常被漏掉导致
目标（Goal） 一句话说清产出是什么 跑题、答非所问
输入（Input） 模型能拿到什么数据 自己编数据幻觉
输出（Output） 形式、格式、字段名 你要 csv 它给你 md
约束（Constraints） 不能做什么、用什么库 库不一致、风格漂移
示例（Examples） 1-2 条"输入→输出"样板 边界情况误判

后两个最容易被偷懒省掉，也是新手与熟手 prompt 之间最大的差距来源。

3.3 三种情境，三种写法

3.3.1 一次性任务（最常见）

任务：把下面 SQL 解释给非技术同事听。

SQL:
EXPLAIN ANALYZE
SELECT region, sum(revenue)
FROM orders
WHERE created_at > '2026-01-01'
GROUP BY region;

输出要求：
- 一句话主旨
- 三到五条要点
- 最后一句给一个最关键的"为什么慢"的提醒
- 不超过 150 字

要点：明确形式 + 字数上限 + 受众。能压字数比讲道理有用。

3.3.2 多轮对话（持续协作）

不要每次都从头复述任务。给一个 role + standing rules 系统 prompt，把规则固定下来：

SYSTEM:
你是我团队的资深 Python reviewer。
- 不写新代码，只做 review
- 指出问题时给文件:行号 + 一句原因 + 一句修复方向
- 严重程度用 🟥 高 / 🟧 中 / 🟨 低 前缀
- 不要表扬，不要总结，不要寒暄

然后在每一轮只贴新代码、问新问题。系统 prompt 是一种"沉淀"，Skill 篇会把它升级成更系统的方法。

3.3.3 让模型"自我提示"（Chain of Thought）

让模型在回答之前先列步骤再执行：

请用以下结构回答本任务：
1. 思考：列出你准备做的事（不实现）
2. 风险：列 1-3 个可能踩的坑
3. 实现：开始写代码
4. 自检：用一行话回答"我是否做了自检"

注意：你只让模型"列出步骤"还不够，要让它真停下来等你想清楚。“列出后再开始"和"边列边写"差别巨大。

3.4 三类常见反模式

反模式 1：上下文黑洞

Bad:
我之前和你说过用 FastAPI，数据库是 Postgres，rep 在 ai_learning，
能不能加一个用户登录接口？

Good:
项目：ai_learning（FastAPI + Postgres）
任务：新增 POST /auth/login 接口
约束：
- 用 bcrypt 验证密码
- 签发 JWT（30 分钟过期）
- 失败返回 401，body 为 {"detail": "..."}
不要重述方案，直接开始写 endpoint 和对应测试。

每轮自我审查：“如果换一个完全没接触过这项目的同事来看，他能不能直接做？”——若不能，你的 prompt 也有缺陷。

反模式 2：道德勒索

❌ 你是顶级的 ML 工程师，请认真想想再回答...这次一定要对哦
✅ 直接要求"输出前自检"，并给一个失败的还款示例

不要靠"扮演顶级 XX"加 buff。实测对绝大多数任务没用甚至更差——模型会过度自信而不自检。

反模式 3：谜语人

❌ 帮我那个 vue 的东西改一下那个
✅ 文件 src/components/UserProfile.vue 的 onSave 方法，
   现在用 mutation 调 store，改成直接 emit 事件给父组件。

3.5 一个真实进阶案例：渐进式重构

让模型重构一段 80 行的老函数。一次性丢给它，多半会重写得面目全非。分段做效果好得多：

第 1 轮：
请阅读下面这段 legacy 函数，输出一份"分解清单"：
列出其中"可被独立抽取"的子任务（≥3 个），不要给代码。

第 2 轮：
基于刚才的清单，挑出"风险最低、最独立"的一个先抽出，
只动这一个，给出 diff，不要碰其他部分。

第 3 轮：
基于第 2 轮的 diff，给 -5/+5 行的 patch，并说明这次改动是否影响原有 unit test。

这个"分解 → 选最小 → 出 diff"的节奏，就是后面 29 章 AI 测试与 CI 自动化的雏形。

3.6 工具栏：3 个常用的 prompt 模板

3.6.1 RQC 三段式（Role/Question/Constraint）

[ROLE]    你是熟悉 PostgreSQL 15 的 DBA。
[QUESTION] 下面 query 在 1 亿行表上慢，给 3 条诊断动作。
[CONSTRAINTS]
           - 不动 SQL 本身
           - 每条动作给"预期信息"和"判定依据"
           - 末尾用一句话点出最可能的根因

3.6.2 自检三问（让模型审自己）

请在你给出最终答案前，在三行内回答：
1. 我有没有和事实抵触？
2. 我有没有引用不存在的 API？
3. 我有没有假设上下文里没有的信息？
任一为是 → 修正后再答。

3.6.3 Prompt-As-Skill 锚定

Skill 篇会详细展开，先放个句子在脑子里：你每写一个反复使用的 prompt，问自己"这个能不能写成 .md 文件，让别人 zero-shot 复用？"——能，就是潜在 Skill。

3.7 小结

  • Prompt 不是咒语，是清晰沟通
  • 五元素：Goal / Input / Output / Constraint / Example，后两个最关键
  • 不要扮演顶级 XX，要让模型停下来列出步骤再执行
  • 实战感来自"把一次性变成沉淀”——这是后面 Skill 篇的入口

下一篇：《04 上下文工程》——把 prompt 当一回事之外，把"模型能看到什么"当更大的事。

Summary: Prompt 五元素 + 自检三问 + 渐进节奏，把模型从玄学拉回工程。