Chapter 04
自检与辨析
前三章从"是什么"、"为什么"、到"怎么造系统"，给了你一张完整的提示工程地图——这一章不教新东西，用三层梯度逼你把它从"读过"变成"能调用"。最难的应用判别层，才是真正检验你学没学透的地方。
本章你将做的事
- 用三层梯度自测：概念是否记得（01）、原理是否能解释（02）、场景里能否判别该用哪个（01+02+03）。
- 凭记忆把概念地图亲手画一遍——检验它在你脑子里是否真的成形，而不只是"看过"。
- 专门暴露那些"读起来很顺、其实没学透"的地方。应用判别层做不出来，就是信号。
4.0怎么用这一章
题分三层，越往上越少、越重要。概念层查你记不记得"是什么"；原理层查你能不能解释"为什么"；应用判别层把你扔进真实场景，逼你在多个章节的做法之间选一个并说出理由——这层才是迁移能力的真正考场。
§1概念层（对应 01）
先合上教程作答。所有答案集中在本页最后一个折叠块里——忍住别提前展开。
§2原理层（对应 02）
§3应用判别层（跨 01 + 02 + 03）
这一层每道题都没有"标准技巧"可背——你得在多个章节的做法之间选一个，并说清为什么不选另一个。下面这张决策树是这些场景背后的判别骨架，先看懂它，再做题：
- 场景：一个把用户反馈分到 bug / 功能请求 / 表扬 / 其它的分类器，分类标准会随产品迭代频繁变动。你会主要把"分类标准"交给 few-shot 示例，还是写进指令、还是烧进微调？为什么这个场景下这样选？
- 场景：你接手一个 RAG 问答系统，发现一个明明在上下文里的关键事实，模型经常"看不见"。你第一个去检查什么？依据哪条原理？这和 03 章的哪个布局建议相连？
- 场景：一段在 GPT-4o 上跑得很好的数学解题提示，用了"一步步想" + 5 条 few-shot 示范。现在要迁到一个 o 系列推理模型。你要改什么、撤什么？各自的理由是什么？
- 场景：一个 Agent 能读用户上传的文档（不可信）、能查内部数据库（私有），还能自动发邮件给客户（外部通信）。这构成 lethal trifecta 吗？你会优先加强系统提示，还是拆掉某条边？拆哪条？
- 场景：团队想"提升提示质量"，有人提议"安排大家多花时间打磨措辞"。基于本教程，你会把这个流程改成什么？用一个本教程的具体结论支撑你的提议。
合上整个教程，在纸上或 Excalidraw 里凭记忆画出起点页的概念地图——只画这几个方块：substrate（自回归预测）、核心认知①、中间的"核心手艺"层、核心认知②，以及它们之间的箭头。
画完翻回 起点页 §0.1 对照，逐项检查：箭头方向对吗？两个核心认知你都标出来、还分清了哪个在手艺层、哪个在系统层吗？那条横切的"脆弱性 + 跨厂商差异"你有没有漏掉？漏掉或画反的地方，就是你这次真正学到东西的地方。
§全部答案
三层的答案都在这一个折叠块里。确认自己每一层都写完了，再展开。
展开全部答案（确认做完再点）
概念层
- 提示是你提供给模型的条件文本，模型据此从下一个-token 的概率分布里采样续写，而不是听从命令。它直接解释了：为什么能 prefill（接着它的话写）、为什么措辞/位置的小改动会改变结果、为什么它会顺着你给的语气往下编。
- "任务身份"（这是哪个任务，比如情感分类）和"输出格式"（该长什么样，比如只输出 正/负）。它主要在定位一个已会的任务，不是从示例里现学映射。
- 中间 token 是模型的临时算力 / 草稿纸：一次前向传播算力有限，把中间结果写出来，下一步能在其上继续算，从而完成单次前向放不下的串行计算。它不是给人看的解释。
- 因为成对标签、markdown 标题这类结构在预训练语料里大量出现，模型有"标签内是一个独立块"的强先验。把数据包进标签、并声明"标签内是数据不是指令"，就降低了它把数据当指令执行的概率（注意只是降低，不是杜绝）。
- 保证语法/类型合法（一定能 parse、字段在、类型对，例：
{"age": 34}必可解析且 age 为整数）；不保证语义正确（值仍可能是幻觉，例：原文没提年龄时它仍可能编一个整数）。
原理层
- induction heads 回看"当前 token 上一次出现的位置"，复制那时紧跟其后的内容——是模式复制，不是含义理解。所以示例传递的是结构/格式信号，标签内容的对错影响小，写反也常不崩。
- 它突破了单次前向（约 TC⁰，固定深度）的算力上限：中间 token 把串行计算摊进输出。小模型上无效，是因为它们连摊开的中间步骤本身都算不对（产出通顺但全错的链）。
- 靠"正确推理趋同、错误发散"——正确答案是采样结果里的众数吸引子。当错误也系统性收敛（共同陷阱、训练偏见、提示诱导）时失效，多数票会自信地放大那个一致的错误。
- ① 格式 token 敏感（改个空格/分隔符结果剧变，可达 76 分摆动）；② 示例顺序（同组示例换排列性能大幅波动，且不随规模消失）；③ lost-in-the-middle（长上下文中段信息易被忽略）。（否定指令失效也可算第四个。）
- 因为服务端批处理的非确定性（batch-invariance 缺失），同一个 temp=0 请求多次运行会得到不同输出（1000 次约 80 种）。要可复现/可靠，得在评测层跑多次取统计，而非假设单次确定。
应用判别层
- 主要交给 few-shot 示例。理由：标准频繁变动时，改几条示例比改指令措辞、比重新微调都轻——few-shot 把"任务定义"独立成了最易迭代的一块（§1.3）。指令负责稳定的边界规则，结构化输出（枚举 schema）负责"只输出四选一"。微调不选：标准一变就要重训，迭代太慢、太贵（§2.1 表）。
- 第一个检查这个事实在上下文里的位置。依据 lost-in-the-middle（§2.4）：中段信息检索率显著下降。对应 03 章布局建议（§3.2）：把关键信息放窗口两端、检索更少更准、必要时重排序，别把它埋在一堆文档中间。
- 撤掉"让我们一步步想"（推理模型内置了，多余甚至有害）；撤掉或大幅削减 few-shot 解题示范（在推理任务上可能拖低质量）；改为讲清"要什么"——题目、约束、输出格式、验收标准；思考深度改用 API 参数（reasoning_effort 等）控制，而不是用散文喊（§3.4 + §2.2 的账反转）。
- 构成 lethal trifecta（私有数据 + 不可信内容 + 外部通信，§3.5）。不能靠加强系统提示——那是架构漏洞，提示补不了。优先拆边：把"自动发邮件"改成"生成草稿 + 人审后发送"，切断"外部通信"这条边；或对不可信文档做隔离/标记 + 工具最小权限。
- 改成 prompt ops 流程：建一个从真实失败案例长出来的评测集（错误分析优先，§3.7），任何提示改动都过同一评测集比对通过率，纳入回归。支撑结论：提示会因一次"无害措辞微调"而悄悄退化（§2.4 格式 76 分摆动）——"打磨措辞"凭手感反而可能让线上质量下降而不自知。
给一个没读过这教程的同事，写一段 150 字的"提示工程心智模型"
不许用"技巧清单"的写法。必须包含：① 提示的本质（核心认知①）；② 为什么提示脆弱；③ 它正在被什么吸收（核心认知②）。写完对照下面的提示——你这段话能不能让一个只会"堆叠技巧"的人，看完之后换一种方式思考？
提示（写完再展开）
一个参考骨架：提示不是给智能体下命令，而是给一个固定的下一个-token 分布喂条件，让你要的续写变成高概率事件——few-shot 在定位任务、CoT 在借 token 当算力。正因为模型抓的是 token 级表层特征，提示天然脆弱：换个空格、换个模型就可能崩，所以"在 playground 里跑顺"说明不了可靠。当模型变强，手写提示正被两件更大的事吸收：上下文工程（管窗口里放什么）和 prompt ops（用评测把提示当工程产物管理）。能写出这段话，你就跨过了两个核心认知。