第 1 章 · Prompt 基本功（上）：核心认知

本章是全教程的地基。无论工具多强大，最终决定产出质量的，是你给 AI 的那句话。

本章包含 4 个知识点：

1. 什么是好 Prompt
2. Prompt 核心四要素
3. 给上下文的艺术
4. 单一任务原则

---

知识点 1：什么是好 Prompt

① 定位

这是全教程的第 1 个知识点，也是最重要的一个。它回答一个看似简单、实则决定一切的问题：怎样才算把话说好了？ 后续所有内容——四要素、上下文、单一任务、迭代提问——都是在拆解这个总问题。

② 是什么（What）

Prompt（提示词） 就是你发给 AI 的那段话。它既是「指令」，也是「输入数据」，还是「评分标准」——这三重身份同时存在。

一个好 Prompt 有四个可检验的特征，可以用四个词记住：

特征	含义	一句话检验方法
清晰（Clear）	没有歧义，任何人读都理解成同一件事	把这句话发给两个同事，他们会做同一件事吗？
具体（Specific）	有对象、有范围、有数量、有格式	AI 能不追问就直接动手吗？
可执行（Actionable）	任务在 AI 能力范围内，且步骤明确	AI 知道「第一步干什么」吗？
可验证（Verifiable）	事先定义了「做完、做对」的标准	产出回来后，你能立刻判断合不合格吗？

一个常见误解是：「写得越长越好」。长度不是质量指标，信息密度才是。一段 200 字但目标、约束、标准齐全的话，远胜于 2000 字的漫谈。另一个误解是：「AI 很聪明，说个大概它就懂了」。模型确实能「猜」，但它猜的是训练数据里最常见的答案，而不是你项目里那个特定答案——你不说，它只能赌。

③ 怎么做（How）

写 Prompt 时，按下面的顺序在脑子里（或草稿里）过一遍，最后再组织成自然语言：

1. 定目标：我到底要一个什么产出？（解释 / 代码 / 修改 / 方案 / 审查）
2. 定对象：针对哪个文件、函数、报错、需求？
3. 定约束：有什么不能动、必须遵守、需要考虑的？
4. 定标准：什么样算好？要不要附测试、跑命令、给格式？
5. 补背景：AI 还不知道哪些信息？（在知识点 3 详细展开）

这五步对应的就是后面要学的「四要素 + 上下文」。刚开始你可以真的列这 5 条；熟练之后会内化成直觉。

④ 为什么这么做（Why）

要理解为什么需要这四个特征，先要理解大语言模型（LLM）是怎么生成回答的：它在你给定的上下文基础上，逐词预测「最可能接下去的内容」。这个机制带来三个关键后果：

1. 你不给的信息，模型不会凭空拥有。 模型不知道你公司的代码规范、你这个函数昨天为什么这么改、你的报错截图长什么样。它只能基于「你提供的内容 + 训练数据的通用知识」来预测。
2. 模糊的输入 → 模型取「最大公约数」。 当你说「优化一下这个函数」，模型会按互联网上最常见的理解去做（往往是性能层面的微调），而你心里想的可能是「提高可读性」。歧义越大，模型越倾向于选最平庸、最不会错的答案。
3. 模型不会主动质疑目标，只会努力完成目标。 如果你没定义验收标准，它就自己假设一个，然后「认真地」交差。产出不合格时，它并没有错——是标准缺失。

所以「清晰、具体、可执行、可验证」本质上是在做一件事：把模型从「猜你想要什么」变成「执行你明确要的东西」。每补上一条信息，就消灭一类猜测，也就消灭一批返工。

⑤ 这样做的好处

• 一次到位率高：AI 不需要反问，你也不用来回补充，平均沟通轮次显著下降。
• 返工少：目标和标准前置，产出回来通常已接近可用，而不是「方向都错了」。
• 可控、可审查：有了明确标准，你能快速判断产出是否合格，而不是凭感觉「好像不太对」。
• 可复制、可沉淀：写清楚的 Prompt 能存进命令（Commands）、写进 AGENTS.md，变成团队和你自己的可复用资产（第 4、5 章会讲）。
• 省下隐性成本：AI 改错方向浪费的不只是时间，还有可能动了不该动的代码，后续排查更贵。

⑥ 不这么做的问题 / 坏处

• 答非所问：你要可读性，它给性能优化；你要方案，它直接改了代码。
• 反复拉扯：「不是这个意思」「我是说……」三五轮之后，上下文越来越乱，模型也越来越偏离。
• 过度或不足：没有范围约束时，模型可能顺手重构一大片（过度），也可能只改表面一行（不足）。
• 无法判断好坏：没标准时你只能凭感觉验收，容易放过「看起来合理但其实有坑」的答案。
• 危险操作：在模糊指令下让 AI 跑删除、迁移、提交等操作，它会「自信地」执行，代价由你承担。

⑦ 举一反三：三个例子

例 1（基础）：让 AI 解释一段代码

📌 场景：你打开一个不熟悉的项目，想让 AI 解释 src/parseToken.ts 是干什么的。

❌ 常见说法：「这个文件什么意思？」

✅ 好 Prompt：

请阅读 src/parseToken.ts，用中文向一个不熟悉本项目的中级开发者解释：
1. 这个文件整体负责什么；
2. 导出了哪些函数，各自的输入、输出和作用；
3. 用一段话描述 token 解析的完整流程。
解释中引用关键代码时请带上行号。

🔍 讲解：这个 Prompt 四个特征齐全——清晰（三件具体的事）、具体（指定文件、语言、受众水平）、可执行（AI 知道读文件后分三步回答）、可验证（你能对照着检查：有没有讲整体职责？有没有列函数？有没有流程描述？）。受众设定「不熟悉本项目的中级开发者」很关键：它决定了解释要补背景但不用科普编程基础。带上行号的要求让你能快速核对，防止 AI 空谈。

---

例 2（进阶）：让 AI 修复一个报错，但限制改动范围

📌 场景：测试报错 TypeError: Cannot read properties of undefined (reading 'id')，出现在 src/order.ts 第 42 行。你怀疑是某个订单数据缺字段，但你不希望 AI 大改。

❌ 常见说法：「报错了帮我看看 / 修一下这个 bug」

✅ 好 Prompt：

运行 npm test 可复现报错：TypeError: Cannot read properties of undefined
(reading 'id')，位置在 src/order.ts:42。

请按以下要求处理：
1. 先只定位根因，不要改代码，用中文说明 undefined 是从哪里来的；
2. 给出最小修复方案，只允许改动 src/order.ts，不要动其它文件；
3. 说明这个报错在什么输入下会触发，以及修复后如何验证；
4. 等我确认方案后你再动手改。

🔍 讲解：比例 1 多了两个进阶要素。第一是分阶段——「先定位、等确认、再修改」，这是防止 AI 一上来就乱改的关键手段（知识点 4 和第 9 章会深入）。第二是显式约束——「只允许改动 src/order.ts」，把爆炸半径锁死。注意它还给了复现方式（npm test）和完整报错原文 + 精确位置，AI 不用猜。「说明什么输入会触发 + 如何验证」则提前定义了验收标准：修完不是看到不报错就完事，而是要能说清触发条件和验证方法。如果把第 4 条去掉，AI 通常会直接改完并跑测试——在你信任它的场景下这没问题，但在陌生、高风险代码里，分阶段更稳妥。

例 3（挑战）：需求看似简单，但目标本身有歧义

📌 场景：你对 AI 说「这个接口太慢了，优化一下」，指的是 GET /api/search。陷阱在于：「慢」和「优化」都没有定义，而且性能问题可能根本不在代码。

❌ 直接说：「这个接口太慢了，优化一下」

✅ 好 Prompt：

GET /api/search 线上 p99 延迟约 1200ms，目标是降到 300ms 以内。

请先不要改代码，按下面顺序排查并汇报：
1. 用 profiling / 日志 / 慢查询等手段，定位耗时主要在哪一段
   （数据库、网络、循环计算、还是外部调用）；
2. 列出你考虑过的所有优化点，按「预期收益 / 改动风险 / 实现成本」
   做成表格排序；
3. 只推荐性价比最高的 1-2 个方案，说明各自的权衡；
4. 给出优化后如何用数据验证（对比同一指标），避免“感觉变快了”。

注意：不要通过加缓存来掩盖问题，除非你能说明缓存一致性如何保证。

🔍 讲解：它先把「慢」量化（p99 1200ms → 目标 300ms），把模糊感受变成可测量的目标；再强制 AI 先诊断后开药，因为性能优化最大的坑就是「在错误的地方优化」。让 AI 列出所有候选并按「收益/风险/成本」排序，是为了对抗模型「抓住第一个想到的方案就动手」的倾向。「不要用缓存掩盖，除非能保证一致性」是一条预防性否定约束——缓存是模型最爱的「万能优化」，却常引入脏数据。这个例子说明：当任务本身模糊时，第一步不是下指令，而是先把目标量化。

⑧ 练习题 ×2

练习 1（巩固型）

📝 题目：你想让 AI 给 src/utils/date.ts 里的时间函数补单元测试。请写一个符合四特征的 Prompt。

💡 思路提示：测哪些函数？用项目现有的什么测试框架？覆盖哪些情况（正常、边界、非法输入）？文件放哪、要不要改源码？

✅ 参考答案：

请为 src/utils/date.ts 中的所有导出函数补充单元测试，要求：
1. 使用项目现有的测试框架（先查看 package.json 确认，不要新装依赖）；
2. 测试文件放在同级的 __tests__ 目录，命名为 date.test.ts；
3. 每个函数至少覆盖：正常输入、边界值（月末、闰年、时区偏移）、
   非法输入三类；
4. 不要修改 src/utils/date.ts；若发现疑似 bug，单独列出告诉我，不要顺手改；
5. 完成后运行该测试文件，确保全部通过，并把结果贴给我。

🔍 讲解：框架与文件位置具体、不改源码是显式约束、三类用例是可验证标准、最后「运行并贴结果」形成闭环。特别注意第 4 条——补测试时 AI 很容易「好心」把它认为的 bug 一起修，让本次改动混入意料之外的变更，review 时极难发现。

练习 2（迁移型）

📝 题目：迁移到非编程场景：让 AI 把一篇 3000 字会议纪要压缩成可执行任务清单。请写出 Prompt。

💡 思路提示：读者是谁？每条任务要含哪些字段？哪些内容不该算任务？未拍板的事项怎么处理？信息缺失时怎么办？

✅ 参考答案：

下面是一份会议纪要（见附件）。请整理成可执行的任务清单，要求：
1. 每条任务包含：任务内容、负责人、截止时间、依赖项（没有写“无”）；
2. 用 Markdown 表格输出，按截止时间升序排列；
3. 只收录“明确决定要做”的事项；不同意见、未拍板议题单独放到
   “待确认”一节，不要混进任务表；
4. 信息缺失时填“未指定”，不要编造人名或日期；
5. 最后用 3 句话概括本次会议的核心结论。

知识点 2：Prompt 核心四要素

① 定位

知识点 1 给出了「好 Prompt 的四个检验特征」（结果标准），本知识点给出「写 Prompt 时必须放进去的四类内容」（组成结构）。前者是验收，后者是配方。后面知识点 3（上下文）是对四要素中「背景」的放大，知识点 4（单一任务）是对「任务」的约束。

② 是什么（What）

几乎所有可靠的 Prompt 都能拆成四个要素：

要素	回答的问题	缺失时的典型症状
角色与背景（Context）	你是谁 / 这是什么情况 / 在什么前提下？	回答太泛、不贴合项目、深度不对
任务目标（Task）	具体要我做什么、产出什么？	AI 自由发挥，方向跑偏
约束条件（Constraints）	有什么规则、边界、不能碰的东西？	改多了、用错方式、违反规范
验收标准（Criteria）	怎样算做完、做对？	无法判断质量，来回返工

记忆口诀：「背景—任务—约束—标准」（CTCC）。注意这四者不是要你写成四个小标题——它们是检查清单，可以自然地融进一段话。但在复杂任务里，显式分段（甚至用编号）反而更清晰。

③ 怎么做（How）

推荐的落地写法是「先填空，后润色」：

1. 先用关键词把四要素各写一行（哪怕是碎片）：
   • 背景：React18 + TS，这是个支付页，金额用分为单位
   • 任务：加一个“金额大写”展示
   • 约束：只改 PaymentAmount.tsx，不加依赖，中文大写
   • 标准：边界：0、整元、角分；跑 tsc + 相关测试
2. 检查每一行是否具体、是否有歧义。
3. 再把碎片组织成一段通顺的话，复杂任务保留编号。

一个四要素齐全的成品长这样：

【背景】这是 React18 + TypeScript 的支付页面，金额内部以“分”(整数)存储。
【任务】请在 src/components/PaymentAmount.tsx 中，为金额增加中文大写展示
       （如 10050 → 壹佰元伍角）。
【约束】只修改该文件，不引入新依赖；复用项目已有的格式工具（若有）；
       不要改动金额的数值计算逻辑。
【标准】覆盖 0、整元、有角有分三种情况；改完运行 npx tsc --noEmit 和
### ④ 为什么这么做（Why）

四要素并非人为规定的格式，它恰好对应了模型完成任务所需的四类信息缺口：

1. **背景决定「从哪个分布里采样」。** 同一个词在不同语境含义完全不同：`token` 在认证模块是凭证，在编译器课是词法单元，在计费里是用量单位。背景把模型的注意力「锚定」到正确的语境。
2. **任务决定「往哪个方向生成」。** 没有明确动词和产出物，模型只能猜你想要解释、代码还是方案。
3. **约束划定「可行域边界」。** 模型默认倾向于「给出完整、通用、可能改动较大」的答案，约束把它限制进你项目真实的规则（技术栈、目录、风险偏好）。
4. **标准提供「自我检查的靶子」。** 现代模型在生成后有一定自我校验能力，但它只能校验你给出的标准；没有标准，它就按自己的默认假设「宣布完成」。

四者环环相扣：背景让答案「对得上场景」，任务让它「做对的事」，约束让它「用对的方式」，标准让你「确认做对了」。

### ⑤ 这样做的好处

- **结构化降低遗漏**：照着四要素检查，几乎不会漏掉关键信息。
- **复杂任务也能稳住**：任务越大、要素越多，显式结构越能防止 AI 丢三落四。
- **便于协作与复用**：统一结构让别人（以及以后的你）一眼看懂这条 Prompt 的意图。
- **方便沉淀**：四要素清晰的 Prompt 最容易被改造成 Command 或写进 AGENTS.md。
- **提升一次通过率**：四类缺口同时补齐，返工通常从「方向级返工」降到「细节级微调」。

### ⑥ 不这么做的问题 / 坏处

- **缺背景** → 得到「正确的废话」：答案通用但不解决你这个项目的问题。
- **缺任务** → AI 在解释、建议、动手之间摇摆，产出形态不可控。
- **缺约束** → 最常见的后果是「过度发挥」：顺手加依赖、重构无关代码、引入项目不用的模式。
- **缺标准** → 交付了但你无法验收，隐藏 bug 容易蒙混过关。
- **四要素混成一团** → AI 可能把「约束」误读成「任务」，例如把「不要改 A 文件」理解为「重点处理 A 文件」。

### ⑦ 举一反三：三个例子

#### 例 1（基础）：给现有函数增加一个参数

📌 **场景**：`formatPrice(cents)` 目前不带货币符号，你想加可选参数控制是否显示 `¥`。

✅ **四要素齐全的 Prompt**：
```text
【背景】src/format.ts 的 formatPrice(cents: number) 目前返回不带符号的金额字符串，
全项目多处调用，金额单位为分。
【任务】为它增加一个可选参数 showSymbol（默认 false，保持现有行为），
为 true 时返回以 ¥ 开头的字符串。
【约束】默认行为必须完全不变，避免影响现有调用；用 TypeScript，更新该函数的
JSDoc；不要改动调用方。
【标准】npx tsc --noEmit 通过；补两种情况的测试（带符号 / 不带符号）并通过。

🔍 讲解：这是四要素最规整的应用。背景点明「多处调用、单位为分」，直接催生了两条关键约束——默认值设 false、不改调用方——它们保证这是一次向后兼容的改动。很多人写这类需求只说「加个货币符号」，AI 很可能默认开启符号，导致全项目显示变化。「默认行为不变」这条约束的价值就在这里。

例 2（进阶）：让 AI 做技术选型

📌 场景：项目需要一个状态管理方案，团队对体积敏感，且新人多。你希望 AI 给建议而不是直接装库。

✅ 四要素齐全的 Prompt：

【背景】React18 + TS 的中小型后台项目，包体积敏感，团队新人多、水平参差，
当前用 useState + props 传递，已出现 prop drilling。
【任务】对比 Redux Toolkit、Zustand、Jotai 三个方案，给出选型建议；
只产出分析报告，不要安装或修改任何依赖。
【约束】结合“包体积、学习曲线、调试体验、与现有代码迁移成本”四个维度；
不要单纯堆砌官网介绍，要给出明确推荐和理由。
【标准】输出一张对比表 + 明确的第一推荐 + 该推荐在本项目落地的 3 步迁移思路。

🔍 讲解：非编码类任务同样适用四要素。背景里「体积敏感、新人多、已有 prop drilling」三条，分别对应评判维度中的「包体积、学习曲线、迁移成本」——背景不是寒暄，它决定了评判标准的权重。约束中「不要堆砌官网介绍、要明确推荐」针对模型写选型时「各打五十大板、不下结论」的通病。标准把产出结构钉死（表 + 推荐 + 迁移思路），你拿到就能直接用于团队讨论。

例 3（挑战）：四要素之间会互相冲突

📌 场景：你要 AI「快速」给一个支付接口加重试，同时要求「绝不能重复扣款」。这两个要求天然冲突：重试越激进，重复扣款风险越高。

✅ 好 Prompt：

【背景】调用第三方支付下单接口偶发网络超时。支付场景对幂等要求极高，
重复请求可能造成重复扣款。
【任务】为该调用增加失败重试机制，同时保证同一业务订单绝不重复创建。
【约束】
1. 必须基于幂等键（用业务订单号作为 idempotency key），不能简单地无条件重发；
2. 仅对“网络超时 / 5xx”这类不确定结果重试，对明确的业务拒绝（4xx）不重试；
3. 重试次数与退避策略要可配置，并在日志中区分“首次/重试”。
【标准】
- 给出时序说明：超时、明确失败、成功但响应丢失三种情况下分别发生什么；
- 说明在最极端情况（服务端已扣款但响应丢失）下如何靠幂等键避免重复；
- 先给方案，等我确认后再写代码。

⑧ 练习题 ×2

练习 1（巩固型）

📝 题目：你想让 AI 把一个类组件改写成函数组件 + Hooks。请按四要素写 Prompt。

💡 思路提示：背景里有什么必须交代（组件规模、用了哪些生命周期、有无外部依赖）？约束里最关键的一条是什么（对外行为 / props 接口）？标准如何定义「改写成功」？

✅ 参考答案：

【背景】src/UserProfile.tsx 是一个约 150 行的类组件，使用了 componentDidMount
拉数据、componentDidUnmount 处理定时器，通过 props 接收 userId。
【任务】在不改文件位置和组件导出名的前提下，改写为函数组件，用 useState/
useEffect 及项目已有的数据请求方式实现等价逻辑。
【约束】对外 props 接口与渲染结果保持不变；不新增依赖；注意定时器在卸载时
清理、避免对已卸载组件 setState。
【标准】npx tsc --noEmit 通过；该组件现有测试全部通过；若没有测试，
请列出我应手动验证的交互点。

🔍 讲解：改写类任务最大的陷阱是「改写时顺手改了行为」，所以约束锁死「props 接口与渲染结果不变」。背景里点出两个生命周期，等于明确告诉 AI 要对应处理「副作用 + 清理」这两个最容易在 Hooks 改写中出 bug 的点。标准用「现有测试 + 手动验证清单」双保险，承认纯靠 tsc 无法保证行为等价。

练习 2（迁移型）

📝 题目：迁移到写作场景：你让 AI 以你的口吻写一篇技术博客，但担心它写得像「官方通稿」。请用四要素写 Prompt。

💡 思路提示：角色与背景里如何定义「你的口吻」？任务产出是什么？约束要限制哪些风格与结构？标准怎么判定「像你写的」？

✅ 参考答案：

【背景】我是一名有 5 年经验的前端工程师，博客读者是初中级前端。我的写作风格：
口语化、会讲踩坑过程、少用形容词、代码示例多于概念堆砌（附我以往两篇文章
见附件，请模仿其语气与结构）。
【任务】以“我是如何给项目做首屏性能优化的”为题，写一篇 1500 字左右的中文
技术博客。
【约束】用第一人称、按“遇到问题→排查→解决→复盘”的顺序写；不要写成
文档式的知识点罗列；不要夸大收益。
【标准】包含至少 2 段真实的踩坑/试错描述；关键结论配可运行或可对照的
示例；读起来应与附件文章的语气一致。

知识点 3：给上下文的艺术

① 定位

四要素中，「背景与上下文」是新手最容易省略、却最能拉开质量差距的一项。本知识点专门解决：该给哪些背景信息、给多少、怎么给。它与第 3 章（上下文管理）相呼应——那里讲用 @、会话等工具提供「文件级上下文」，这里讲你在 Prompt 文字里提供「情境级上下文」。

② 是什么（What）

上下文是帮助模型理解「为什么做、在什么前提下做、相关事实有哪些」的全部信息。常见的可给上下文分为六类：

类别	例子
项目事实	技术栈、目录约定、运行命令、环境
任务背景	为什么要做、用户遇到了什么、业务规则
相关代码	涉及的文件、函数、类型定义、调用关系
已有决策	之前试过什么、为什么放弃、已确定的方案
证据材料	报错原文、日志、截图、数据、性能指标
期望与偏好	风格、深度、输出格式、受众

关键不是「全都给」，而是 相关且充分：少了模型要猜，多了会稀释重点、浪费上下文窗口。

③ 怎么做（How）

判断「给不给」用三个问题筛选：

1. 这条信息会改变 AI 的做法吗？ 会 → 给；只是背景噪音 → 不给。
2. AI 自己能可靠获得吗？ 它能用工具读到文件、跑命令查到的，让它自己查（第 3 章）；只有你知道的（决策原因、线上现象、截图），必须你给。
3. 不给它会怎么猜？ 想象它缺这条时最可能的默认假设，如果那个假设危险，就必须给。

④ 为什么这么做（Why）

• 模型没有「现场感」。 你知道这个 bug 只在 Safari、只在凌晨批处理、只在升级了某个依赖后出现——这些信息不在代码里，模型无从得知，只能按最常见情形推断。
• 相关性决定注意力分配。 Transformer 对上下文里的信息一视同仁地分配注意力。塞入大量无关信息，会把真正关键的信号「淹没」，导致模型抓住无关细节。
• 上下文窗口是有限资源。 长对话中，无关信息会挤占空间，更早触发压缩（Compaction），可能丢失真正重要的早期内容。
• 结论会锚定推理。 人类会受「先入为主」影响，模型同样：你先说「我觉得是空指针」，它可能顺着你找空指针，而证据其实是并发问题。先给证据能减少这种误导。

所以「充分」是为了消灭危险猜测，「相关」是为了保护信号密度——两者要平衡。

⑤ 这样做的好处

• 诊断更准：模型基于完整证据，而不是仅凭一行报错空想。
• 少走弯路：把「已试过的方案」告诉它，避免它把你否决过的路再走一遍。
• 答案贴合实际：业务规则、环境特性进入上下文，产出可直接落地。
• 节省窗口与费用：只给相关信息，上下文更短，也更便宜。
• 可追溯：证据 + 结论分明，日后回看知道当时依据是什么。

⑥ 不这么做的问题 / 坏坏处

• 上下文不足 → 模型用通用假设填充，得到「看起来对、其实不适用」的答案。
• 上下文过载 → 关键信号被淹没，模型纠结无关细节，回答冗长失焦。
• 只给结论不给证据 → 模型顺着错误假设走，「一个敢说一个敢信」，越查越偏。
• 重复给同一信息 → 浪费窗口，还可能让模型误判其重要性。
• 把敏感信息给出去 → 密钥、用户隐私等一旦贴入对话有泄露风险，应当脱敏。

⑦ 举一反三：三个例子

例 1（基础）：交代「为什么要做」

📌 场景：你让 AI 给一个表单加「草稿自动保存」。如果只说功能，AI 不知道触发时机和冲突处理。

✅ 给足上下文的 Prompt：

背景：这个长表单有 30 多个字段，用户反馈填到一半意外关闭页面后内容全丢，
投诉集中在这里。需求是降低“意外丢失”的损失。
任务：实现草稿自动保存与恢复。
已知约束：多人可能在不同设备编辑同一表单；后端已有 /draft 接口可直接用。
请先给方案：说明保存时机（定时/失焦/字段变更防抖）、恢复时机、
以及多端编辑冲突如何处理，确认后我再让你写代码。

🔍 讲解：关键上下文是「30 个字段、意外关闭、投诉」——它解释了为什么做，直接影响方案选型：字段多意味着每次全量保存不划算，倾向防抖/增量；「不同设备」引出冲突处理。「后端已有接口」避免 AI 另设计一套存储。很多人只说「加自动保存」，AI 可能默认 localStorage 单端方案，根本不考虑多端冲突。

例 2（进阶）：提供「已试过什么」，避免重复劳动

📌 场景：一个偶发内存泄漏，你已经排查过一些方向。

✅ 好 Prompt：

现象：服务运行约 8 小时后内存持续上涨并 OOM，每天凌晨定时任务后更明显。
已确认：
- 用 heap snapshot 比对，怀疑与定时任务里创建的连接未释放有关；
- 已排除：全局缓存无限增长（已检查 key 数量稳定）、已排除明显的全局数组；
- 相关代码：jobs/nightly.ts、db/pool.ts（已用 @ 附上）。
请基于这些前提继续定位，不要重复我已经排除的方向。先给出你的验证步骤，
需要跑命令时先告诉我。

🔍 讲解：这份上下文的价值是节省一大轮排查。明确「已排除缓存、全局数组」让 AI 不浪费时间；给出「凌晨任务后更明显」这个时间相关性是高价值线索，直接把怀疑范围缩到定时任务。同时坦诚「怀疑与连接有关」但标注为怀疑而非结论，保留了让模型推翻它的空间。注意它还附上证据类型（heap snapshot），让 AI 知道已有材料，而不是凭空猜。

例 3（挑战）：上下文不是越多越好——主动做减法

📌 场景：你本想把整个报错上下文、自己猜的 5 个原因、公司背景全贴进去，结果信息又杂又长。

❌ 过载写法：贴上 300 行日志 + 大段公司介绍 + 「我猜可能是 A/B/C/D/E」。

✅ 精简后的 Prompt：

目标：定位下面这个偶发超时。
仅提供相关证据：
- 报错原文（凌晨 2:10-2:15 集中出现，约 20 次）：<贴 5-10 行关键日志，
  含时间戳与 traceId>；
- 该时段唯一的系统变化：2:00 开始跑批任务 batch-report；
- 我暂时没有结论，请你先根据证据判断方向，而不是在我给的猜测里选一个。

⑧ 练习题 ×2

练习 1（巩固型）

📝 题目：一个问题「只在生产、只在 iOS、只在弱网」出现，本地无法复现。请写一段向 AI 求助的上下文。

💡 思路提示：哪些是只有你知道、AI 无法自己查到的信息？证据和你的猜测该怎么安排顺序？

✅ 参考答案：

现象：某接口在生产环境的 iOS 设备、弱网下偶发请求挂起，Android 与 PC 正常，
本地无法复现。
证据（先于我的判断）：
- 抓包显示请求已发出，但长时间无响应也无超时，约占该条件下请求的 15%；
- 后端日志按 traceId 查不到对应请求到达记录；
- 最近一次相关改动：两周前把超时配置从 fetch 库迁移到了统一的 request 封装。
我暂时没有确定结论。请先列出可能的原因假设与各自的验证方法，
不要急着改代码。

🔍 讲解：「生产 / iOS / 弱网 / 后端无到达记录」都是 AI 无法自行获得、且会显著改变判断方向的信息，属于必须给的高价值上下文。把「统一 request 封装的迁移」作为时间相关线索给出。证据全部列在「我没有结论」之前，符合「证据先行」，避免锚定偏差。最后只要「假设 + 验证方法」，是因为不可复现的问题靠直接改代码往往是瞎试。

练习 2（迁移型）

📝 题目：迁移到数据分析场景：你让 AI 解释一份销售数据「为什么本月华东区下滑」，你手上有很多材料。请说明你会挑选哪些作为上下文、舍弃哪些。

💡 思路提示：用「会改变 AI 分析方向吗 / AI 能自己算吗 / 缺失时它会默认什么」三问筛选。

✅ 参考答案（筛选说明 + Prompt）：

纳入：
- 本月与上月华东区按周、按品类的销售明细（AI 可直接据此计算，不用猜）；
- 已知业务事件：华东某主力门店本月停业装修 12 天、竞品同期大促；
- 数据口径：统计是否含税、退货如何计。
舍弃：
- 全国其他区的全部原始数据（与华东归因弱相关，易稀释重点）；
- 公司组织架构、系统介绍（与本次分析无关）。

请基于所附数据，量化拆解华东区本月下滑的构成（多少来自门店停业、
多少可能与竞品促销相关、是否还有无法解释的部分），区分“数据能证明的”
和“仅为推测的”，不要把相关性直接写成因果。

知识点 4：单一任务原则

① 定位

本知识点约束四要素中的「任务」：一次只让 AI 做一件主要的事。它同时是第 9 章「任务拆解」工作流的 Prompt 层基础。学会它，能解决多指令混杂导致的丢任务、顺序错乱、上下文污染。

② 是什么（What）

单一任务原则：一条 Prompt 围绕一个清晰的主目标展开；当存在多个目标时，要么拆成多条依次发送，要么显式地给出编号、顺序与依赖，让 AI 逐段完成并在阶段间停下等确认。

需要区分两种「多任务」：

• 可并行的独立任务（如同时改两个不相关文件）——可以用子代理并行（第 9 章），但不要塞进一条线性指令让它随意处理。
• 有依赖的串行任务（如先重构再加功能）——必须显式分阶段，否则顺序一错就出 bug。

一句话：一条话里如果出现多个「然后」「顺便」「再」，就要警惕。

③ 怎么做（How）

1. 识别动词数量：数一下 Prompt 里的主要动作。超过一个核心动作，就考虑拆分。
2. 能拆则拆：把 A、B 两件事分成两条消息，做完 A、验收后再说 B。
3. 必须放一起时，显式分阶段：用编号写清步骤，并加上「每完成一步先停下，等我确认」。
4. 说明依赖与顺序：明确「先做 X，因为 Y 依赖 X」，防止模型跳步。

④ 为什么这么做（Why）

• 每多一个任务，出错率叠加。 模型要同时记住多个目标，遗漏其中一个的概率随任务数上升，尤其当后段任务依赖前段结果时，一处错连锁出错。
• 注意力被摊薄。 同一段上下文服务多个目标时，每个目标分配到的关注都减少。
• 验收无法分段。 多任务一次完成后，若结果有问题，难以定位是哪个环节出错，回滚也只能整体回退。
• 上下文污染。 任务 A 产生的中间改动，可能在做任务 B 时被误当成 B 的一部分继续扩大。
• 模型倾向「一口气做完」。 没有明确停顿点，它会连续执行全部动作，中途不给你干预机会——危险操作尤其可怕。

分阶段则把一个大的高风险决策，切成几个小的可审查节点，每个节点你都能喊停。

⑤ 这样做的好处

• 任务不丢、顺序不乱：一次一件，目标聚焦。
• 逐段验收、及时纠偏：错了只影响当前小步，返工成本低。
• 上下文更干净：每个任务的上下文互不干扰。
• 危险可控：阶段间的确认点就是人工闸门。
• 更易回滚：小步改动对应清晰的快照（Snapshots），出问题容易定位和撤销。

⑥ 不这么做的问题 / 坏处

• 任务被吞：列了 5 件事，它认真做了 3 件，你以为都完成了。
• 顺序颠倒：在旧结构上加了新功能，又按计划重构，新功能被重构冲掉。
• 范围蔓延：「顺便」不断叠加，改动从 1 个文件滚成十几个。
• 无法审查：一大坨改动里混着多种意图，review 和 git 历史都很痛苦。

⑦ 举一反三：三个例子

例 1（基础）：把「重构 + 加功能」拆开

📌 场景：你希望先把一个混乱的工具函数整理一下，再用它实现新的校验逻辑。

❌ 一条塞下：「把 validate.ts 重构得清晰一点，然后顺便用它加个手机号校验，再补点测试。」

✅ 拆开 / 分阶段的 Prompt：

第一阶段（本条只做这个）：重构 src/validate.ts 的内部结构，要求：
- 不改变任何现有导出函数的对外行为与签名；
- 不新增功能；完成后运行现有测试确认全部通过，然后停下等我验收。

（我验收通过后，会再单独让你加手机号校验和测试。）

🔍 讲解：重构和加功能是两类风险性质完全不同的改动，混在一起最大的问题是：一旦行为变了，你无法判断是重构引入的回归，还是新功能的问题。第一阶段用「不改签名、不加功能、跑测试、停下」四条把它锁成一次纯粹的等价重构。显式预告「之后再单独加功能」，让模型知道不要提前动手。这就是用顺序换可审查性。

例 2（进阶）：一条指令里三件事，显式编号 + 阶段闸门

📌 场景：有时确实需要在一条任务里安排多个步骤（如数据迁移），无法完全拆成独立消息。

✅ 分阶段 Prompt：

目标：把 users 表的 phone 字段拆分为 phone_country_code + phone_number。
请严格分三步，每完成一步停下，等我确认再继续：

步骤 1：只写迁移方案与回滚方案，不改任何东西，说明对线上数据的影响；
步骤 2：（我确认后）写迁移脚本，先在测试库跑并核对条数与抽样数据；
步骤 3：（再确认后）改应用代码读写逻辑，并保证迁移期间的兼容。
在任何一步，如果发现前面假设有问题，立即停下告诉我，不要自动往下走。

🔍 讲解：数据迁移是高风险操作，特点是强依赖顺序且不可逆，因此不适合简单拆成互不相干的消息，但必须保留显式闸门。三个步骤对应「方案 → 演练 → 上线」的经典节奏；第 2 步要求在测试库核对条数和抽样，是把「验证」做在真正动生产数据之前。最后一句「假设不成立立即停」给了模型一个中止规则，防止它为了完成任务而硬着头皮继续。

例 3（挑战）：看似一件事，其实藏着三个目标

📌 场景：你说「帮我看看这个 PR 有没有问题，顺便改了，然后提交」。这句话包含了「审查 → 修改 → 提交」三个动作和一次权限升级。

❌ 原说法：「看看这 PR 有没有问题，顺便改了然后提交。」

✅ 拆成两段：

第一阶段（只审查，不改、不提交）：审查当前分支相对 main 的改动，
列出问题清单，按严重程度排序，每条标注文件行号，并区分“必须改”和“建议改”。

（等我看过清单、确认哪些要改之后，第二阶段我再让你动手；
提交（commit/push）我会单独、明确地授权，不要自行提交。）

⑧ 练习题 ×2

练习 1（巩固型）

📝 题目：你想让 AI「升级依赖、修复升级带来的类型错误、跑一遍全量测试」。请改写成符合单一任务原则的安排。

💡 思路提示：这三步的依赖关系是什么？哪一步风险最高、需要你亲自确认？每个阶段的「停下点」设在哪？

✅ 参考答案：

请分三个阶段，每阶段完成后停下等我确认：

阶段 1：列出建议升级的依赖及版本范围，标注哪些是 major、可能有破坏性，
先不要安装；
阶段 2：（确认后）执行升级，然后修复因此产生的类型错误，只做让 tsc
通过所必需的最小修改，不要借机重构；
阶段 3：（再确认后）运行全量测试，把失败项整理汇报；若有失败，先分析
原因，不要为了让测试变绿而擅自改测试断言。

🔍 讲解：三步是严格串行的，每个阶段都设闸门。阶段 2 的「最小修改、不借机重构」防止在修类型错误时范围蔓延——这正是升级任务最常见的失控点。阶段 3 特别强调「不许改测试断言来凑绿」，因为模型面对失败测试时，有时会「修」测试而不是修代码。把这些行为边界提前写明，比事后发现再回滚便宜得多。

练习 2（迁移型）

📝 题目：迁移到日常办公：你想让 AI「整理邮箱、起草三封不同事项的回复、并把会议约到周五」。请按单一任务原则重新组织。

💡 思路提示：哪些任务彼此独立、可以分开授权？哪些动作属于「对外发出」、需要你最终拍板？如何避免 AI 直接把草稿发出去？

✅ 参考答案：

我们一项一项来，所有邮件都只生成草稿、绝不自动发送，发送前必须由我确认。

任务 1（先做）：读取并分类我的未读邮件，输出“需回复 / 仅需知悉 / 可忽略”
三类清单，先不要起草；
任务 2（我确认分类后）：针对“需回复”中的三封邮件，分别起草回复，
三封的事项与语气各自独立、不要互相套用；
任务 3：根据我邮件中的日程信息，给出周五可安排的时间段建议，
由我确认后再创建会议邀请，不要直接发出邀请。

🔍 讲解：迁移要点是识别「对外、不可逆」动作——发送邮件、发出邀请——并统一设为需要人工授权，正如编程里的 commit/push。先「分类」再「起草」，是因为分类错了草稿就白写，且模型可能对漏分的邮件根本不起草。三封回复要求彼此独立，防止模型把不同事项的措辞、甚至收件内容串台。整体仍是「一次一件、阶段闸门」的同一套思想。

---

本章小结

知识点	一句话核心
1. 什么是好 Prompt	清晰、具体、可执行、可验证；把「猜」变成「执行」
2. 核心四要素	背景—任务—约束—标准（CTCC），缺一有典型症状
3. 给上下文的艺术	相关且充分；证据先行，主动做减法
4. 单一任务原则	一次一件；审查、执行、提交分设闸门

下一章《Prompt 基本功（下）：表达与迭代》将进入：肯定式表达、Few-shot 示例、指定产出格式、复述确认与迭代提问等进阶技巧。

---