术语表：每个词都先有一段经历
这张表按词在书里第一次出现的顺序排列，不按字母。它的用处是回查：想不起某个说法是在哪段经历里冒出来的，翻到那一行，先看「在这一章看见了什么」，再看它通常叫什么。经历还在脑子里，词就容易接得回去。
标着「本书说法」的，是为了方便讨论起的名字，不一定是行业统一术语，换一本书或一个团队可能听到别的叫法。其余的是通用名称，写出来是为了以后查资料、提问和跟人交流时对得上。
| 章 | 在这一章看见了什么 | 通常叫它 / 本书怎么用 |
|---|---|---|
| 第 0 章 | 连着记录重复、等待、复制、核对，过四道筛选，把一个念头拆成「把某件事从当前状态变成目标状态」的一句话 | 问题陈述；本书把这段筛选与拆解叫「痛点考古」 |
| 第 1 章 | 把编辑、运行、保存历史三件事分给三个角色（编辑器、Node.js、本地 Git），装好后跑一条检查命令看固定输出；报错按「看到什么、说明什么、下一步做什么」对照 | 本书说法「三个角色」「检查命令」「报错三段式」 |
| 第 2 章 | 用「输入是……，输出是……，规则是……」把一句模糊要求补成 AI 能落地的请求 | 提示词模板，本书用的是「输入-输出-规则」这一版 |
| 第 3 章 | 换三份稍有差异的样例去跑，把结果记成「通过、异常、无法判断」，发现「能跑」回答不了「哪些输入下可靠」 | 本书说法「通过 / 异常 / 无法判断记录」；它引出的问题是「能跑不等于可信」 |
| 第 4 章 | 一组测试全绿，但期望值来自实现自己的输出，换一份错误实现照样全绿 | 回声测试（本书说法，不是行业统一术语） |
| 第 5 章 | 实现出现之前，先写清「某种输入经过一次操作应该看到什么」，由人逐条裁决 | 验收条件；同一件事写规整了叫 Given-When-Then |
| 第 6 章 | 让测试先按预期失败一次，区分「实现还没做到」的目标红灯和「路径或语法错」的假红；实现阶段测试文件只读 | 本书说法「红灯先行」「目标红灯 / 假红」 |
| 第 7 章 | 让 AI 跑测试、读错误、改实现直到全绿，绿之后由人检查测试、依赖、权限配置有没有被暗改 | 本书说法「判定器循环」；红、绿、整理这个形状通常叫 测试驱动开发（TDD），但两者不划等号 |
| 第 8 章 | 按先猜、再运行、再探查、改一处、最后自己做一个的顺序读一小段真实代码，用一段流畅却错误的解释当反例 | PRIMM：Predict、Run、Investigate、Modify、Make |
| 第 9 章 | 为了让「测试全绿」这个指标好看而偏离真实目标，手法有删测试、放宽断言、用 Mock 顶替真实调用 | reward hacking（奖励作弊）；边界是「改的是尺子，还是让尺子迁就结果」 |
| 第 10 章 | 只看这次改了哪些行，按测试、依赖、权限或部署、意外新文件四类信号先筛一轮，把每处分成接受、询问、拒绝 | 本书说法「Diff 审查」，定位是第一轮风险筛查，不是完整判断 |
| 第 11 章 | 把工具交给一名真实使用者，作者只观察记录、不中途解释，卡壳的地方转成一条新的验收条件 | 本书说法「真实使用」；同时立起「数据边界」这条规矩 |
| 第 12 章 | 程序化植入几处小改坏，跑测试看哪些被杀死、哪些存活，用存活的变异找测试空白 | 变异测试（mutation testing） |
| 第 13 章 | 用密钥、不可信输入、日志、权限、回退、不可逆操作六类检查，先给后果再给规则，产出一份上线检查单 | 其中一条规则叫 最小权限原则（least privilege） |
| 第 14 章 | 部署到可回退的静态托管，打开线上版跑验收样例，演练一次回退，交三人试用，只根据观察修一轮 | 本书说法「有监督部署」「回退」 |
| 第 15 章 | 按数据敏感度、资金影响、用户数量、可逆性、监管要求五维给项目分级，落成「当前可做、需要协助、暂不做」三个区 | 本书说法「能力边界」「项目分级」 |
| 第 16 章 | 按项目冒出的信号决定补什么，数据、自动化、Web 应用、Agent 四个方向各有触发信号和最短入口；为 Web 应用写设计计划，检查主题、字体、颜色、布局、动效和可访问性 | frontend-design（Anthropic 官方插件目录中的前端设计技能）；核心做法是先定主题与用户，再定设计方向，最后构建和复评，不套用通用 AI 视觉模板；旁边还会遇到 RAG（检索增强生成）、向量检索、微调，它们各解决一类问题，也各有不解决的地方 |
| 第 17 章 | 把问题整理成最小复现、预期结果、实际结果、已尝试步骤、环境信息五项，再决定去哪问 | 本书说法「可复现问题」；那份最小复现，也就是常说的 MRE |