第 1 章 · Prompt 基本功（下）：表达与迭代

上半部分解决了「放什么内容」，本章解决「怎么表达、怎么推进」。
本章包含 4 个知识点： 5. 肯定式表达：说「要什么」而不是「不要什么」 6. 用示例锁定答案：Few-shot 7. 指定产出格式 8. 复述确认与迭代提问

知识点 5：肯定式表达

① 定位

上一章讲约束时，我们大量使用了「不要……」。本知识点要做一个重要修正：否定约束要用，但真正驱动产出的应该是肯定指令。 它解决的是「AI 知道不能做什么，却还是不知道该做什么」的困境。

② 是什么（What）

肯定式表达：用「要什么、做成什么样」来描述目标；把「不要什么」降级为辅助性的边界提示。

对比：

否定式（弱）	肯定式（强）
别写太长	控制在 200 字以内，分 3 段
不要用复杂写法	用最直白的 for 循环实现
别改别的文件	只修改 src/auth.ts
不要泛泛而谈	每个结论必须引用具体文件行号

注意右栏的区别：它们不是单纯把「不」字删掉，而是给出了一个明确、可执行的替代目标。「别写太长」只划定了禁区，「200 字、分 3 段」则给出了落点。

③ 怎么做（How）

每写一条「不要 X」，追问一句：「那我要的是什么？」 然后把答案补上：

「不要过度设计」→ 追问：那要多简？→「用最少的代码解决当前需求，不提前抽象」。
「不要用 any」→ 追问：类型怎么来？→「为该数据定义 interface，字段不确定时用 unknown 收窄」。
「回复别太官方」→ 追问：要什么语气？→「用第一人称、像同事间讲解，可以有口语」。

④ 为什么这么做（Why）

模型靠「正向信号」生成。 它的工作机制是朝目标「靠近」，而不是远离禁区。你告诉它「不要 A」，它的注意力反而被 A 占据（类似人类被告知「别想大象」），却没有得到该往哪走的坐标。
否定空间是无限的。 「不要长」没有说明多长合适；不写代码的方式有无穷多种，模型只能猜。而一个肯定目标把无限可能收敛成一个具体落点。
否定句容易被「部分遵守」。 模型可能避开了你点名的那一项，却用另一种同样糟糕的方式替代——因为它只知道那一格不能踩，不知道正确答案在哪。
连续否定会显著改变语气。 一串「不要、不许、别」会让模型进入过度保守模式，回答变得畏首畏尾、信息稀薄。

所以：禁区用来排雷，目标用来导航。 两者分工不同，但导航信息才是主角。

⑤ 这样做的好处

AI 有明确落点，一次命中率高，不必在禁区外盲目试探。
产出形态可控：长度、风格、结构都能按你给的正向标准生成。
减少「换汤不换药」：避免它只躲开你点名的问题，又犯个等价的新问题。
沟通语气更健康：以目标为中心，模型更积极、信息更足。
标准更可验证：「200 字、分 3 段」比「别太长」更容易客观检查。

⑥ 不这么做的问题 / 坏处

只否定不肯定 → AI 知道雷区却无处落脚，产出要么保守空洞，要么换个方式出错。
否定目标过多 → 模型注意力被多个负面词占据，风格畏缩、回答失焦。
以为说清了其实没有 → 「别太复杂」在你和模型心中的「复杂」标准完全不同。
该封堵的危险操作没封堵 → 这是另一个极端：在删除、提交等动作上只说目标不说禁令，风险敞口过大。

⑦ 举一反三：三个例子

例 1（基础）：控制代码风格

📌 场景：你让初级向 AI 写一个工具函数，不希望它炫技。

❌ 否定式：「别写得花里胡哨的，不要搞那些我看不懂的高级语法。」

✅ 肯定式：

text

请用最朴素、可读的方式实现这个函数：
- 优先使用基础语法（普通 for / if），避免链式高阶方法和一行流；
- 每个非显而易见的步骤加一行中文注释；
- 目标是让刚入门的同事也能逐行读懂。

🔍 讲解：否定式里「花里胡哨」「看不懂」是纯主观词，模型无从对齐。肯定式给了三条可执行标准：用什么语法、要不要注释、读者是谁。其中「让入门同事逐行读懂」是一个非常好用的可读性锚点——它把模糊的「朴素」转成了具体的受众能力。

例 2（进阶）：要求「精简」一个回答

📌 场景：AI 给了一大段解释，你想要更短，但直接说「短点」它可能删掉关键信息。

✅ 肯定式追问：

text

请把上面的回答压缩成“结论先行”的版本：
- 第 1 句直接给最终答案；
- 随后用不超过 3 个要点支撑，每点一句话；
- 保留必要的文件/函数名，删除铺垫和重复表述。

🔍 讲解：「短点」只给方向不给结构，模型无法判断哪些能删。这里用固定结构（1 句结论 + ≤3 要点）既保证短，又通过「保留文件/函数名」防止它把高信息密度的内容误删。这就是肯定式表达的高阶用法：不仅说「要短」，还说「短成什么结构、什么必须保留」。

例 3（挑战）：高风险场景需要正负搭配

📌 场景：让 AI 处理一批文件的批量重命名，既要它放手去做，又怕它动错范围。

✅ 正负搭配的 Prompt：

text

目标（肯定）：把 src/icons 下所有 .tsx 图标文件从 PascalCase 改为 kebab-case，
并同步更新项目内对它们的 import 路径。
边界（否定，显式封堵）：
- 不要改动 src 目录以外的任何文件；
- 不要修改文件内容，只改文件名与 import 路径字符串；
执行方式：先输出“重命名映射表 + 受影响文件清单”给我确认，
得到确认后再实际执行。

⑧ 练习题 ×2

练习 1（巩固型）

📝 题目：把这句改成肯定式——「给我讲一下这个模块，别讲那些没用的，也不要太啰嗦。」

💡 思路提示：你真正想要的结构是什么？「没用的」具体指哪类内容？长度和深度怎么用正向方式定义？

✅ 参考答案：

text

请按下面的结构讲解 src/payment 模块：
1. 先用一句话说明它的职责；
2. 再列出核心函数及其调用关系（只讲与“支付下单”主流程相关的，
   跳过日志、埋点等辅助逻辑）；
3. 总长度控制在 5 条要点以内，每条不超过两句话。

🔍 讲解：「没用的」被具体化为「跳过日志、埋点等辅助逻辑」，「别啰嗦」被结构化为「≤5 条、每条≤2 句」。用肯定结构定义内容，比两个否定词精确得多，也让模型知道该保留主流程信息。

练习 2（迁移型）

📝 题目：迁移到设计场景：你要 AI 设计一个「极简风格」的登录页，但「极简」太抽象。请用肯定式（可含少量边界）写 Prompt。

💡 思路提示：极简在布局、配色、元素数量上分别意味着什么可执行的规则？有哪些常见的「多余设计」要显式排除？

✅ 参考答案：

text

请设计一个极简登录页：
- 垂直居中，仅包含：Logo、邮箱输入框、密码输入框、登录按钮，共 4 个元素；
- 配色不超过 2 种主色，大量留白，输入框用细边框、无阴影；
- 不要加入轮播图、渐变背景、社交登录图标、装饰性插画；
请给出布局说明与关键样式，而不是直接堆砌花哨动效。

知识点 6：用示例锁定答案：Few-shot

① 定位

前面多次提到「给样例」，本知识点系统讲解这个性价比极高的技巧：与其费力描述，不如直接演示。 当语言难以精确传达风格、格式或判断规则时，示例是最硬的约束。

② 是什么（What）

Zero-shot（零示例）：只给指令，不给例子。「把这句话翻译成英文」。
Few-shot（少示例）：在指令后附上若干组「输入 → 期望输出」的范例，再给出真正要处理的输入。

Few-shot 的本质是：你不再用文字定义规则，而是用几个具体样本让模型自己归纳出规则。 它特别擅长传达三类难以言表的东西：

格式：输出要长什么样（结构、字段、标点）。
风格 / 语气：正式还是口语、热情还是克制。
分类 / 判断边界：什么算 A、什么算 B，尤其是边界模糊时。

③ 怎么做（How）

一个标准 Few-shot Prompt 的结构：

text

【任务说明】把用户反馈分类为：bug / 功能建议 / 表扬 / 其它。
【示例】
输入：点了登录按钮完全没反应
输出：bug

输入：要是能支持导出 PDF 就好了
输出：功能建议

输入：这次更新后快多了，赞！
输出：表扬

输入：你们公司在哪
输出：其它
【现在请处理】
输入：搜索的时候偶尔会闪退
输出：

写示例的要点：

2–5 个为宜：太少归纳不准，太多浪费窗口。
覆盖主要类别 / 情况：每一种输出类型至少给一个样本。
包含边界 / 易混例：刻意给一个容易判错的样本，帮模型划清边界。
格式高度一致：示例的输入输出写法要统一，模型会模仿这个格式。

④ 为什么这么做（Why）

示范比描述的信息带宽高。 一种微妙语气可能要几百字描述还不准，两个范例一摆，模型立刻对齐——它极擅长从样本中归纳模式。
示例同时定义了格式和规则。 模型不仅学到「怎么判」，还学到「用什么格式输出」，一步到位。
边界示例能校正默认倾向。 当某个分类在训练数据里很罕见、或两种类别极易混淆时，一个针对性样本的引导力远超文字说明。
示例降低了歧义。 文字规则总会有解释空间，具体样本把抽象规则锚定成确定的对应关系。
它利用了模型的核心能力。 「根据示例推断并应用」正是大模型最擅长的模式补全，几乎不需要额外训练。

但要注意：模型会把示例当真理。 如果你的示例本身有错、有偏见，或无意中泄露了某种无关规律（比如「所有 bug 样本都比较短」），模型可能学到错误规则。示例质量即规则质量。

⑤ 这样做的好处

格式高度稳定：输出严格对齐范例，便于程序解析或直接使用。
风格 / 语气精准：尤其适合「模仿口吻」「统一文风」类任务。
复杂判断更可靠：分类、抽取、打分等有模糊边界的任务，准确率明显提升。
减少解释成本：省去反复描述「我到底想要什么风格」。
结果可预期：在批量处理大量同类输入时，一致性远高于 zero-shot。

⑥ 不这么做的问题 / 坏处

只靠文字描述风格 → 模型按自己的默认理解发挥，十次有八次和你预期有偏差。
格式要求用嘴说不给样例 → 字段名、标点、结构总有出入，批量使用时很痛苦。
给了示例但覆盖不全 → 没出现过的类别模型只能硬猜，可能乱判。
示例自相矛盾或格式不一 → 模型无所适从，输出风格漂移。

⑦ 举一反三：三个例子

例 1（基础）：统一抽取格式

📌 场景：要从一堆杂乱的客服消息里抽出「订单号」和「问题类型」，输出要固定。

✅ Few-shot Prompt：

text

从每条客服消息中抽取订单号和问题类型，以 JSON 输出，字段为 order_id 与 type。
示例：
输入：我的订单 A20260901 没收到货
输出：{"order_id":"A20260901","type":"物流"}
输入：订单 B7788 付款失败了，扣了两次钱
输出：{"order_id":"B7788","type":"支付"}
输入：A0099 想退货
输出：{"order_id":"A0099","type":"售后"}

请处理：输入：订单 C1234 的发票抬头能改吗
输出：

🔍 讲解：示例同时锁定了输出格式（JSON、固定字段）和判断规则（不同措辞映射到物流/支付/售后）。第一条给最典型物流例建立基准，后两条扩展类型。真实处理时即使出现没见过的「发票」类诉求，模型也会在示例建立的框架内归纳（可能输出"其它"或"发票"）。若程序要消费这个结果，格式一致是关键，这正是 few-shot 最稳的场景。

例 2（进阶）：用示例传达语气与改写尺度

📌 场景：你要把生硬的系统通知改写成亲切但仍专业的话术，尺度很难用文字说清。

✅ Few-shot Prompt：

text

把生硬的系统通知改写成“亲切但专业”的用户话术。参考下面的尺度：

原文：您的操作已超时，请重新操作。
改写：操作超时啦，别担心，重新点一下就好～

原文：密码错误，请重新输入。
改写：密码好像不太对，再确认一下试试？

原文：库存不足，无法下单。
改写：这件商品暂时被抢光啦，暂时下不了单，可以看看其它款哦。

请改写：原文：您输入的手机号格式不正确。
改写：

🔍 讲解：语气的「度」几乎无法用文字精确定义——「亲切」容易过头变油腻，「专业」容易变生硬。三个示例让模型自行归纳出目标尺度：用语气词（啦、哦）、给安抚/替代建议、但保留核心信息、不夸张。最后一条「库存」还示范了「提供替代方案」的写法。这比写一长段「要亲切、但别太随意、还要……」有效得多。

例 3（挑战）：用边界示例纠正模型的默认偏见

📌 场景：你要判断 commit message 是否「规范」。模型的默认倾向可能是把「短」等同于「不规范」，但有些短消息其实是规范的。

✅ 含边界例的 Few-shot：

text

判断 commit message 是否规范（规范 = 含类型前缀 + 简明描述改动）。
示例：
输入：fix: 修复登录页输入框失焦报错        输出：规范
输入：更新了一堆东西                       输出：不规范
输入：feat                                 输出：不规范（只有类型没有描述）
输入：docs: 修正 README 拼写               输出：规范（短但要素齐全）

请判断：输入：fix: 修正按钮颜色
输出：

⑧ 练习题 ×2

练习 1（巩固型）

📝 题目：设计一个 Few-shot Prompt，把技术术语解释给「完全不懂技术的老人」听。至少给 3 个示例。

💡 思路提示：示例要示范「类比 + 去术语 + 亲切」的解释方式，挑哪几个术语能覆盖不同难度？

✅ 参考答案：

text

请把技术术语用“打比方”的方式解释给完全不懂电脑的老人听，不出现英文和术语。
示例：
输入：缓存
输出：就像把常用的东西放在手边的小桌上，不用每次都跑去储藏间拿，更快。
输入：病毒
输出：像会传染的坏毛病，会让电脑生病乱跑，所以要请“保安”（杀毒软件）看着。
输入：流量
输出：像家里水龙头放出来的水，用多少走多少，看视频就像开大水龙头，用得快。

请解释：输入：Wi-Fi
输出：

🔍 讲解：三个示例都用「就像……」的生活类比，并在「病毒」例中顺带处理了被引出的新概念（杀毒软件→保安），示范了如何不丢信息又去术语。挑选「缓存/病毒/流量」覆盖了抽象、危险、可计量三类概念，让模型归纳出统一的解释套路。

练习 2（迁移型）

📝 题目：迁移到代码审查：你想让模型给函数复杂度打「高/中/低」，但判断标准模糊。请用 Few-shot 给出示例，特别要包含「行数不多但其实很复杂」的边界例。

💡 思路提示：复杂度应该看什么（分支数、嵌套、职责数量），而不是只看行数？怎样设计一个短但高复杂度的样本来纠正偏见？

✅ 参考答案：

text

根据“分支/嵌套数量、是否承担多个职责”判断函数复杂度，而不是只看行数。
示例：
输入：一个 5 行、顺序执行 3 个简单语句的函数        输出：低
输入：两层 if 嵌套、含 3 个 for 循环的 30 行函数     输出：高
输入：8 行函数，但内含 6 个连续的三元/逻辑判断、
      混合了数据转换与网络请求两件事                 输出：高（短但职责多、判断密）
输入：单层 if/else、逻辑平铺的 15 行函数             输出：中

请判断：输入：10 行里有 4 层嵌套回调、还顺手改了全局变量
输出：

知识点 7：指定产出格式

① 定位

Few-shot 能锁定格式，但并非每次都要给样例——很多时候直接声明格式即可。本知识点讲解如何用格式约束让产出「拿来能用」，并为「让程序/其它工具消费 AI 结果」打下基础。

② 是什么（What）

产出格式指对回答形态的显式规定，包含不同层次：

层次	常见选择
载体	Markdown / 纯文本 / 代码块 / JSON / YAML / CSV / 表格
结构	分几部分、标题、字段、顺序
粒度	每部分多长、列表条数
包装	是否用代码块包裹、字段名、null 如何表示

格式约束和知识点 6 的区别：格式简单、无歧义时直接声明（「用 Markdown 表格，列为 X、Y」）；格式复杂或含判断尺度时才上示例。

③ 怎么做（How）

按需声明，并遵循几条稳妥写法：

给出载体 + 字段 + 顺序：

text

用 Markdown 表格输出，列依次为：文件名、问题、严重程度（高/中/低）、建议，
按严重程度从高到低排序。

要 JSON 给程序消费时，规定骨架：

text

只输出 JSON，不要任何额外解释或 markdown 代码块标记，结构为：
{"name": string, "tags": string[], "risk": "high"|"medium"|"low"}
缺失值用 null，不要省略字段。

固定枚举值：把可选值写死，防止模型自由发挥（如 risk 只能三选一）。
要求「只输出 X」：当结果要直接喂给程序时，明确禁止多余的前言后语。

④ 为什么这么做（Why）

自由格式 = 每次都要二次加工。 模型默认输出「完整、带解释」的自然语言段落，人读舒服，但当你要把结果汇总进表格、喂给脚本、贴进工单时，就得手工重新整理。
格式是最廉价的确定性来源。 声明字段和枚举几乎零成本，却能把「每次形态漂移」变成「稳定契约」。
下游工具依赖严格结构。 程序解析 JSON 时，一行多余的文字、一个被省略的字段都会导致解析失败；结构必须前置约束。
排序与空值规则防止隐性 bug。 不规定空结果时，模型可能输出自然语言而非空结构，下游判空逻辑直接失效。
固定结构也帮助模型自我组织。 当它知道要填哪几个字段，会更系统地逐项检查，漏项减少。

⑤ 这样做的好处

拿来即用：结果可直接贴进表格、文档或被程序解析。
批量处理一致性高：处理成百上千条输入时形态统一。
便于自动化串联：AI 的结构化输出能作为下一步脚本/命令的输入。
减少漏项：固定字段就是一份内置检查清单。
评审更高效：统一结构让你和团队能快速横向比较。

⑥ 不这么做的问题 / 坏处

输出散文式段落 → 每次手工提炼，规模化时极耗人力。
字段随意 / 枚举漂移 → 程序解析失败，或统计时同义不同名（高/high/严重）无法聚合。
夹杂解释性文字 → JSON 无法直接解析，需要额外清洗。
不规定空结果 → 下游拿到「没有发现问题」这样的字符串而非 []，判空出错。

⑦ 举一反三：三个例子

例 1（基础）：审查结果输出成表

📌 场景：让 AI 审查多个文件，你想把结果直接贴进项目文档。

✅ 格式声明：

text

请审查 src/api 下的文件，并将结果输出为 Markdown 表格，列依次为：
文件 | 行号 | 问题 | 严重程度 | 修复建议。
严重程度只能填 高/中/低；按严重程度降序排列；没有问题的文件不用列出。
表格之外不要加任何开场白或总结。

🔍 讲解：载体（Markdown 表格）、列顺序、枚举值、排序规则、空结果处理、是否加多余文字——六项一次说全。模型拿到后产出是一张可直接粘贴的表，而不是「我审查了以下文件，总体来说……」的散文。「没有问题的不列」是实用的空结果规则，避免表格被无意义行填满。

例 2（进阶）：输出严格 JSON 供脚本消费

📌 场景：你写脚本批量让 AI 判断依赖是否过期，结果要被 Node 脚本 JSON.parse。

✅ 格式声明：

text

分析下列依赖是否可能过期/有风险。只输出一个 JSON 数组，不要代码块标记、
不要任何解释文字。每个元素结构：
{
  "package": string,
  "current": string,
  "latest": string,
  "outdated": boolean,
  "risk": "high" | "medium" | "low"
}
无法确定 latest 时 latest 设为 null，risk 设为 "low"，但仍保留所有字段。

🔍 讲解：给程序消费时，约束要更严：禁止代码块和解释文字（否则 JSON.parse 直接失败）、布尔与枚举固定、显式规定无法确定时的兜底值且字段不省略。最后一条尤其重要——模型在信息不足时最容易删字段，这会让读取 item.latest 的代码崩溃。把「异常/未知情况的合法形态」也定义掉，是结构化输出可靠性的关键。

例 3（挑战）：同一内容要两种形态（人看 + 机读）

📌 场景：你既想要一段给同事看的自然语言总结，又想要一份机器可读的结构化数据。

✅ 分段格式声明：

text

请分两个明确分节输出，顺序如下：

## 总结（给团队阅读）
用 3-5 句话说明本次改动做了什么、影响范围、需要注意什么。

## 数据（给脚本读取）
在一个 ```json 代码块中输出，结构：
{"changed_files": string[], "breaking": boolean, "needs_review": boolean}
两节之外不要输出其它内容。

⑧ 练习题 ×2

练习 1（巩固型）

📝 题目：让 AI 从一段日志中统计错误，并输出可直接导入 Excel 的内容。请写出格式声明。

💡 思路提示：Excel 最友好的载体是什么？列怎么定？含逗号、换行的字段怎么办？无数据时输出什么？

✅ 参考答案：

text

请统计下面日志中的错误，输出为 CSV，列为：时间,错误类型,信息,出现次数。
要求：
- 第一行为表头；字段内含逗号时用双引号包裹，信息里的双引号用两个双引号转义；
- 按出现次数降序；
- 若没有任何错误，只输出一行：NO_ERRORS；
除此之外不要输出任何解释。

🔍 讲解：CSV 是 Excel 直开的最佳载体。关键细节是转义规则（含逗号加引号、引号双写），不说明时模型生成的 CSV 常会列错位。表头固定、排序固定保证可重复导入。空结果用一个哨兵行 NO_ERRORS 而不是自然语言，方便脚本判断。

练习 2（迁移型）

📝 题目：迁移到人力场景：让 AI 把一批简历筛选结果同时给「HR 看的结论」和「可入库的结构化记录」。请设计输出格式。

💡 思路提示：如何分区让人读与机读分离？入库记录需要哪些字段、枚举怎么固定？模型拿不准的字段如何兜底？

✅ 参考答案：

text

请按以下两节输出：

## HR 结论
每位候选人 2-3 句话：亮点、主要顾虑、建议（进入面试 / 备选 / 不通过）。

## 入库数据
在一个 JSON 数组代码块中，每位候选人一个对象：
{
  "name": string,
  "years_exp": number,
  "match_score": 0-100 的整数,
  "decision": "interview" | "hold" | "reject"
}
信息不足的字段：years_exp 用 null，match_score 仍给一个整数并基于已有信息评估，
不要省略字段。两节之外不要有其它内容。

🔍 讲解：沿用「分区隔离双受众」的思路，把主观结论与客观字段分开。枚举与分数区间写死，保证入库可聚合。「信息不足如何兜底」再次被显式定义（null + 保留字段），防止模型删字段导致入库失败。这类设计在任何「AI 结果既要给人看又要进系统」的业务里都通用。

知识点 8：复述确认与迭代提问

① 定位

这是 Prompt 基本功的收口知识点：即便前七条都做到了，仍可能因「理解不一致」或「一次想不清楚」出错。本知识点用复述对齐和渐进迭代为任务上最后一道保险，也直接衔接第 9 章工作流。

② 是什么（What）

复述确认（Restate）：动手前让 AI 用自己的话复述对目标、约束、范围的理解，你核对一致后再执行。
迭代提问（Iterate）：把大/模糊需求通过多轮「方案 → 反馈 → 细化 → 再确认」逐步逼近，而非一次要完美答案。

两者关系：复述是空间上对齐（确保理解同一件事），迭代是时间上逼近（让答案逐步变清楚）。

③ 怎么做（How）

复述确认的标准动作：

text

在写任何代码之前，请先复述你对这个任务的理解，包括：
1. 你认为的目标与最终产出；
2. 涉及 / 不涉及的文件范围；
3. 你计划的步骤顺序；
4. 你看到的风险或需要我澄清的点。
先不要动手，等我确认“理解一致”后你再开始。

迭代提问的节奏：

第 1 轮只让它出方案 / 大纲（不执行）；
你针对方案给反馈（补充、修正、划掉）；
让它细化被指出的部分，或复述修正后的方案；
一致后再授权执行；执行后用验收标准核对，不符合就继续下一轮。

④ 为什么这么做（Why）

语言天然有损。 你脑中的意图经过文字表达必然丢信息，模型再经一层解读又会偏移。复述是把这条「失真链」显式暴露出来的唯一低成本方式。
错误越早发现越便宜。 理解偏差在「复述阶段」纠正几乎零成本；等代码写完、甚至提交后才发现方向错了，返工时还可能污染上下文和历史。
人对复杂需求也常没想清楚。 很多需求你自己也是模糊的，看到 AI 的方案/复述才能意识到「我真正要的不是这个」。迭代给了需求「被想明白」的过程。
复述会逼模型形成计划。 要求它先讲步骤，等于强制它在行动前做规划，而不是拿到指令就冲动执行。
迭代维持上下文聚焦。 一次塞一个过大的目标，模型容易丢三落四；分轮推进让每一轮都聚焦当前子问题。

⑤ 这样做的好处

方向级错误在动手前清零，大幅减少「全白做」的返工。
双方共享同一份理解，后续协作更顺。
需求质量被反向提升：复述/方案常常帮你发现需求自身的漏洞。
执行更稳：模型带着明确计划动手，步骤更有条理。
风险点提前浮出：复述时它往往会主动提出你没考虑到的风险。

⑥ 不这么做的问题 / 坏处

理解偏差一路带到成品，做完才发现南辕北辙，代价最大。
需求没想清就执行 → 边做边改，上下文越滚越乱。
模型无计划冲动执行 → 顺序混乱、遗漏约束。
把迭代误当啰嗦而省略 → 在高难任务上追求「一次成」，结果反而更慢。

⑦ 举一反三：三个例子

例 1（基础）：先复述再修 bug

📌 场景：一个涉及多文件的 bug，你担心 AI 对「要修到什么程度」理解不一致。

✅ 要求复述：

text

现象与相关文件我已给出。请先不要改代码，先用一段话复述：
- 你理解的根因；
- 你打算改哪些文件、各改什么；
- 哪些是你明确不会动的。
等我回复“可以，按此执行”后你再动手。

🔍 讲解：把复述聚焦在「根因 + 改动清单 + 不碰清单」三项，正好覆盖方向、范围、边界。你只需对照这三项判断是否一致，成本很低却能拦住「根因判断错」或「范围扩大」两类最常见的方向级返工。设一个明确的授权口令（"可以，按此执行"）让停手边界清晰。

例 2（进阶）：模糊新需求，迭代三轮收敛

📌 场景：你想做个「数据导出」功能，但格式、范围、异步与否都没想清楚。

✅ 迭代安排：

text

第 1 轮（只讨论，不写码）：基于“用户要导出订单列表”，列出需要我拍板的关键
决策点（导出格式、字段范围、数据量大时同步还是异步、权限），并给每项的
推荐默认值与理由。

（我对这些点逐一选择后）
第 2 轮：根据我的选择，给出完整方案与接口/任务流设计，标出边界情况。

（我确认方案后）
第 3 轮：再开始实现，并按既定验收标准交付。

🔍 讲解：承认「需求没想清」，第 1 轮不要求方案有多完美，而是让 AI 反向列出决策点 + 推荐默认值——这是澄清模糊需求极高效的一招，你只需做选择题。第 2 轮把决定固化成设计，第 3 轮才执行。每一轮都比上一轮更具体，风险逐级下降。这比你硬着头皮写一份完整需求、再让 AI 一次做完要稳得多。

例 3（挑战）：复述发现需求本身自相矛盾

📌 场景：你要 AI「不改数据库结构」地实现一个「需要按新字段检索」的功能。

✅ 让复述暴露矛盾：

text

请先复述并评估这个任务的可行性，不要直接动手：
- 目标：支持按“客户等级”筛选订单；
- 约束：不允许改动数据库表结构、不允许全表扫描。
请指出这两个约束与目标之间是否存在冲突；若有，列出可调和的几种方案
（如复用已有字段、另建索引视图、离线标签表等）及各自代价，等我选择。

⑧ 练习题 ×2

练习 1（巩固型）

📝 题目：你要让 AI 做一次「把 REST 接口改造成 GraphQL」的大改动。请写一段动手前的复述确认 Prompt。

💡 思路提示：这么大的改动，复述里必须核对哪些项？哪些现有行为必须保持不变？你希望它额外承诺或提示什么？

✅ 参考答案：

text

这是一次较大的改造，写代码前请先复述并等我确认：
1. 你理解的改造目标与最终交付形态；
2. 现有 REST 接口的哪些对外行为/数据必须保持等价（字段、鉴权、错误码）；
3. 你计划的迁移步骤与顺序，以及是否需要新旧并存的过渡；
4. 你识别出的风险（N+1 查询、鉴权穿透、缓存）与需要我拍板的点。
在我明确回复“按此执行”之前，不要修改任何文件。

🔍 讲解：大改造的复述要覆盖目标、等价性承诺、迁移顺序、风险四块。特别强调「行为/数据等价」，因为接口形态改造最容易在字段、鉴权、错误语义上悄悄发生变化。要求「新旧过渡方案」是为了降低一次性切换的风险。复述清单本身就迫使 AI 做整体规划。

练习 2（迁移型）

📝 题目：迁移到活动策划：你让 AI 帮你策划一场线下技术沙龙，但你只有一个模糊想法。请设计迭代澄清的前两轮。

💡 思路提示：第 1 轮该让 AI 反问哪些关键决策点？你希望它带推荐默认值吗？第 2 轮如何把选择固化成可执行方案？

✅ 参考答案：

text

第 1 轮：我想办一场 50 人左右的线下前端技术沙龙，但还很模糊。
请先不要写完整策划，而是列出我需要拍板的决策点（预算区间、主题方向、
时长与议程结构、场地类型、招募渠道、是否需要赞助），每项给出一个
推荐默认值和理由。

（我做出选择后）
第 2 轮：根据我的选择，输出可执行方案：时间表（倒排到活动日）、
分工清单、预算明细、风险与备选（如到场率低、讲师临时缺席），
并标出还需要我确认的少数关键点。

🔍 讲解：和「数据导出」例同一套路：第 1 轮用「决策点 + 推荐默认值」把模糊想法转成选择题，第 2 轮再固化为带时间表、分工、预算、风险预案的可执行方案。活动策划的「风险与备选」对应工程里的「回滚方案」——任何不可逆/有变数的事都要在计划阶段准备 Plan B。

本章小结

知识点	一句话核心
5. 肯定式表达	禁区用来排雷，目标用来导航
6. Few-shot	用样本让模型自己归纳规则，示例质量即规则质量
7. 指定产出格式	把自由表达变成稳定契约，兼顾人读与机读
8. 复述与迭代	动手前对齐理解，过程中逐步逼近，收敛于执行

至此 Prompt 基本功（上、下）共 8 个知识点全部完成。从下一章起进入工具操作层：《TUI 基础操作与快捷键》。

第 1 章 · Prompt 基本功（下）：表达与迭代 ​

知识点 5：肯定式表达 ​

① 定位 ​

② 是什么（What） ​

③ 怎么做（How） ​

④ 为什么这么做（Why） ​

⑤ 这样做的好处 ​

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

⑦ 举一反三：三个例子 ​

例 1（基础）：控制代码风格 ​

例 2（进阶）：要求「精简」一个回答 ​

例 3（挑战）：高风险场景需要正负搭配 ​

⑧ 练习题 ×2 ​

练习 1（巩固型） ​

练习 2（迁移型） ​

知识点 6：用示例锁定答案：Few-shot ​

① 定位 ​

② 是什么（What） ​

③ 怎么做（How） ​

④ 为什么这么做（Why） ​

⑤ 这样做的好处 ​

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

⑦ 举一反三：三个例子 ​

例 1（基础）：统一抽取格式 ​

例 2（进阶）：用示例传达语气与改写尺度 ​

例 3（挑战）：用边界示例纠正模型的默认偏见 ​

⑧ 练习题 ×2 ​

练习 1（巩固型） ​

练习 2（迁移型） ​

知识点 7：指定产出格式 ​

① 定位 ​

② 是什么（What） ​

③ 怎么做（How） ​

④ 为什么这么做（Why） ​

⑤ 这样做的好处 ​

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

⑦ 举一反三：三个例子 ​

例 1（基础）：审查结果输出成表 ​

例 2（进阶）：输出严格 JSON 供脚本消费 ​

例 3（挑战）：同一内容要两种形态（人看 + 机读） ​

⑧ 练习题 ×2 ​

练习 1（巩固型） ​

练习 2（迁移型） ​

知识点 8：复述确认与迭代提问 ​

① 定位 ​

② 是什么（What） ​

③ 怎么做（How） ​

④ 为什么这么做（Why） ​

⑤ 这样做的好处 ​

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

⑦ 举一反三：三个例子 ​

例 1（基础）：先复述再修 bug ​

例 2（进阶）：模糊新需求，迭代三轮收敛 ​

例 3（挑战）：复述发现需求本身自相矛盾 ​

⑧ 练习题 ×2 ​

练习 1（巩固型） ​

练习 2（迁移型） ​

本章小结 ​

第 1 章 · Prompt 基本功（下）：表达与迭代

知识点 5：肯定式表达

① 定位

② 是什么（What）

③ 怎么做（How）

④ 为什么这么做（Why）

⑤ 这样做的好处

⑥ 不这么做的问题 / 坏处

⑦ 举一反三：三个例子

例 1（基础）：控制代码风格

例 2（进阶）：要求「精简」一个回答

例 3（挑战）：高风险场景需要正负搭配

⑧ 练习题 ×2

练习 1（巩固型）

练习 2（迁移型）

知识点 6：用示例锁定答案：Few-shot

① 定位

② 是什么（What）

③ 怎么做（How）

④ 为什么这么做（Why）

⑤ 这样做的好处

⑥ 不这么做的问题 / 坏处

⑦ 举一反三：三个例子

例 1（基础）：统一抽取格式

例 2（进阶）：用示例传达语气与改写尺度

例 3（挑战）：用边界示例纠正模型的默认偏见

⑧ 练习题 ×2

练习 1（巩固型）

练习 2（迁移型）

知识点 7：指定产出格式

① 定位

② 是什么（What）

③ 怎么做（How）

④ 为什么这么做（Why）

⑤ 这样做的好处

⑥ 不这么做的问题 / 坏处

⑦ 举一反三：三个例子

例 1（基础）：审查结果输出成表

例 2（进阶）：输出严格 JSON 供脚本消费

例 3（挑战）：同一内容要两种形态（人看 + 机读）

⑧ 练习题 ×2

练习 1（巩固型）

练习 2（迁移型）

知识点 8：复述确认与迭代提问

① 定位

② 是什么（What）

③ 怎么做（How）

④ 为什么这么做（Why）

⑤ 这样做的好处

⑥ 不这么做的问题 / 坏处

⑦ 举一反三：三个例子

例 1（基础）：先复述再修 bug

例 2（进阶）：模糊新需求，迭代三轮收敛

例 3（挑战）：复述发现需求本身自相矛盾

⑧ 练习题 ×2

练习 1（巩固型）

练习 2（迁移型）

本章小结