验收用例，才是驾驭 AI 编码的那根缰绳

我以前有一位老同事，是位很资深的 QA。每次和她做完 Design Review，她很快就会拿出一整套 Acceptance Test Cases（验收测试用例），然后把话说得很直：这些用例要是不通过，就别把软件包交给我测。

她不是故意给开发找麻烦。恰恰相反，这条规矩替大家省了不少时间。验收用例摆在前面，开发知道“做到什么程度才算完成”，QA 也不用接过一个半成品，再陪着开发玩“你修一个、我测一个”的乒乓球。软件包在交给她之前，开发必须先证明：这些双方确认过的基本行为，已经全部成立。

而且，那套用例从来不是写完就供起来。随着设计细化和风险暴露，她会继续补充、修订。等软件包真的交到她手上，通过既定用例也只算拿到入场券。她还会做探索性测试，换些事先没写进脚本的走法去“找茬”；性能和压力测试少不了，异常路径、边界条件也一个都不肯放过。

后来老东家经历了几次裁员，我们已经不是同事了。我却常常怀念那段有人替软件质量认真把关的日子。现在回头看，她当年做的，不就是一套很扎实的工程 Harness（约束和验证 AI 行为的工程护栏）吗？

这不，我把她“蒸馏”成了一个 Skill。

当然，我蒸馏的不是一个人，而是她那套质量纪律：先把 High Level Design 说清楚，再把 Acceptance Test Cases 写扎实；基本门槛没过，不准交付；门槛过了，还要继续探索。 无论用 OpenSpec、Superpower，还是别的 Agent 工具，真正决定成败的都不是提示词有多花哨，而是你有没有把“什么叫做对”讲清楚。

• 一句话主张：AI 编码的上限，由你的验收标准决定，而不是由模型决定。
• 要区分：验收用例不是“事后测一测”，而是“事前把话说死”——它是需求的可执行版本，也是 Agent 交付软件包之前必须跨过的门槛。

为什么是 Acceptance Test Case，而不是别的

先说个容易被忽略的常识：AI 不缺生成能力，缺的是边界。你给它的自由度越大，它漂移（drift）得越远。人跟人交流靠默契补齐语义，AI 没有你脑子里那套默契，它只会拿着你字面上的话，挑一条最省力的路走完。

我们做工程的其实早有对策，只是过去用得不够狠。测试驱动开发（TDD，先写测试再写实现）讲的就是“先把对错定义好”。到了 AI 时代，这个思路的价值被明显放大——因为写实现越来越快，写实现的那个“人”也不再总是你。既然实现随时可以重来，那唯一稳定的锚点，就是验收标准。

需求是愿望，验收用例是合同。
AI 只对合同负责，不对你的愿望负责。

打个厨房里的比方。你跟厨师说“做个好吃的”，端上来什么都可能；你说“番茄炒蛋，糖两克盐一克，蛋要嫩，出锅前十秒下葱花”，那道菜的下限就被你锁住了。验收用例干的就是后面那件事——把“好吃”翻译成可以逐条打勾的动作。越详尽，AI 越无处遁形。

这里要厘清一组容易混的概念：

很多人一上来就让 AI “写代码 + 写测试”，结果测试是 AI 自己出的题、自己判卷——它当然容易全过。我那位老同事的做法正好相反：验收用例在开发交付之前就摆上桌，而且由开发、QA 和需求相关方共同确认。AI 可以帮忙补充用例，但验收标准必须由人主导，这是不能外包给 AI 的部分。

ATC 是灵魂，但不是整套 Harness

读到这里，很容易产生另一个误会：是不是 ATC 写得足够详细，其他东西就都不重要了？当然不是。ATC 是 Behavior Harness（行为验证层）里最关键的合同，却不是整个 Harness。

一套能驾驭 AI 的 Harness，至少要形成一前一后的闭环：

只有 Feedforward，没有 Feedback，规则很容易沦为墙上的标语；只有 Feedback，没有 Feedforward，AI 就会一次次撞上本可避免的同一堵墙。前者负责让它少走弯路，后者负责在它走偏时尽快拉回来。

从验证对象看，还可以把 Harness 分成三层：

我的老同事把 Behavior Harness 守得很牢，但她也从不只看功能：性能、压力、异常路径和边界条件，本来就横跨行为与架构两层。到了 AI 编码时代，还得再加两条横梁：Safety and Permissions 管住密钥、生产数据、部署、迁移和破坏性操作；Entropy Management 明确谁维护这些规则、多久复查一次，免得半年后命令早就失效，Agent 还在一本正经地照着跑。

所以更完整的说法应该是：

HLD 和项目指南负责告诉 AI 怎么做，ATC 负责定义什么叫做对，三层 Harness 负责拿出证据，安全边界和维护机制负责让这套系统不失控、不过期。

第一根缰绳：把 High Level Design 说清楚

验收用例不是凭空冒出来的，它长在设计上。老同事之所以能在 Design Review 之后很快拿出测试用例，是因为她会盯着设计里的每个承诺追问：输入是什么？输出是什么？依赖挂了怎么办？并发上来会怎样？所以第一步永远是 High Level Design（高层设计，简称 HLD）。这里不需要 UML 画到手抽筋，关键是把下面几件事写死：

• 系统边界：这个模块负责什么，明确不负责什么。“不负责”往往比“负责”更重要——它挡住 AI 自作主张。
• 核心数据流：输入从哪来，怎么变换，输出到哪去。一张 Mermaid 流程图胜过三段话。
• 关键约束：并发模型、性能目标、一致性要求、失败时的行为。例如设计一个令牌桶限流器，只要 HLD 里写死一句“令牌必须连续补充，不能在整秒边界重置全部额度”，实现就少了一大块含糊空间。
• 架构风格：分层还是六边形？依赖往哪个方向流？错误怎么传播？这些定了，AI 生成的代码才不会四不像。

HLD 的作用是给 AI 一张地图。但地图只管方向，不管你有没有走到目的地——验收有没有过，得靠用例说话。

第二根缰绳：把验收用例写到 AI 无处发挥

这是整套方法的核心。一条合格的验收用例，我要求它满足 Given-When-Then 的结构（给定前置条件—当发生某操作—则应有某结果），并且每一条都要可执行、可判定、有边界。

拿限流器举例，一份“越详尽越好”的验收用例长这样：

Feature: 令牌桶限流器

  Scenario: 稳态放行
    Given 限流器配置为每秒 10 个令牌、桶容量 10
    When 客户端以每秒 10 个的均匀速率请求 5 秒
    Then 全部 50 个请求都应放行

  Scenario: 突发削峰
    Given 桶已满（10 个令牌）
    When 客户端在 1ms 内发起 20 个请求
    Then 前 10 个放行，后 10 个应被拒绝并返回 429

  Scenario: 跨整秒边界不能重复获得完整额度
    Given 桶已满（10 个令牌）且测试使用可控的单调时钟
    When 在第 999ms 发起 10 个请求，并在 2ms 后再发起 10 个请求
    Then 第一批 10 个请求应放行
    And 第二批 10 个请求应全部拒绝
    And 直到累计补充至少 1 个令牌后，才应再次放行请求

  Scenario: 令牌恢复
    Given 桶被瞬间耗空
    When 等待 500ms 后再请求
    Then 应恰好放行约 5 个（10 令牌/秒 × 0.5 秒）

  Scenario: 边界与异常
    Given 配置速率为 0
    When 任意请求到达
    Then 应拒绝所有请求，且不得抛出未捕获异常

注意几个细节，它们正是拉开“能用”和“扛揍”差距的地方：

• 把隐含假设写成显式断言。在这个例子里，“令牌连续补充”不能只存在于设计者脑中。跨整秒边界的双突发一旦变成会失败的用例，AI 就没法拿固定窗口实现蒙混过关。
• 数值要具体。“大概”“合理”这类词是 AI 的免死金牌，能删就删。
• 一定要有异常路径。速率为 0、并发爆炸、依赖超时……这些是 AI 最爱偷懒略过的地方，也是线上最爱出事的地方。
• 覆盖边界值。桶满、桶空、恰好一个令牌，这些临界点比正常路径值钱得多。

我那位老同事给我留下的经验法则很朴素：写用例时，要像一个想找茬的 QA，而不是一个想交差的开发。 你替 AI 想到的每一个刁钻场景，都是未来少熬的一个夜。

把这些缰绳套进一套 Prompt

方法论落到实处，得有个能复用的提示词模板。下面这套骨架可以直接抄去改：

# 角色
你同时扮演严谨的资深开发和高级 QA。
开发负责实现，QA 对不满足验收标准的交付拥有否决权。

# 任务
实现 <模块名>。你必须让下面的验收用例全部通过，一条都不能少。

# 项目上下文（Feedforward）
- 先读取仓库真实存在的 AGENTS.md / 模块指南 / README / 架构文档。
- 从 Makefile、package.json、pyproject.toml、Maven / Gradle 配置或 CI 中发现真实命令。
- 找出架构边界、高风险目录、批准过的 fixture / golden file 和安全规则。
- 未发现的命令或规则必须标记为缺口，不得自行编造。

# High Level Design
<粘贴 HLD：边界 / 数据流 / 关键约束 / 架构风格>

# Acceptance Test Cases（不可协商）
<粘贴 Given-When-Then 用例，含正常、边界、异常路径>

# 专项测试目标
- 性能目标：<延迟 / 吞吐量 / 资源占用>
- 压力目标：<并发量 / 持续时间 / 降级行为 / 恢复时间>
- 探索性测试重点：<最担心出错的区域和待验证假设>

# 工程约束（硬性）
- 架构风格：<项目实际采用的分层、模块和依赖规则>
- 代码规范：<项目已有规范和配置，不得凭空增加工具>
- 统一验证入口：<项目真实存在的 make check / mvn verify / gradle check / npm run check 等>
- 架构检查：<项目真实存在的边界、API / Schema 兼容性检查>
- 安全检查：<项目真实存在的 SAST、依赖和密钥扫描>
- 覆盖率门槛：<项目已有门槛；如果没有，列为待确认，不得擅自设定>
- 权限边界：未经明确批准，不得部署、迁移数据库、访问生产数据或执行破坏性命令

# 工作流（严格按序）
1. 先报告你找到的项目指南、技术栈、验证入口和缺失项，不要直接写代码。
2. 复述你对 HLD 与验收用例的理解，列出遗漏的边界、异常、安全和兼容性风险，等我确认。
3. 建立“需求 / ATC → UT / IT / 架构检查 / 专项测试 / 人工判断”的追踪矩阵。
4. 先写测试（把验收用例翻译成可执行测试），再写实现。
5. 通过项目现有的统一入口运行 Maintainability / Architecture / Behavior 三层检查。
6. 本地检查通过后，确认 CI / Pre-merge 运行同一组关键检查；不一致就明确报告。
7. 给出最终证据：运行了什么、结果如何、什么没运行、为什么没运行、还剩什么风险。
8. 全部通过后，再给出探索性测试章程，说明还准备从哪些角度继续找问题。
9. 若有任何一条用例无法满足，停下来说明，不要擅自修改需求。

# 禁止
- 禁止修改或"放宽"验收用例来让测试变绿。
- 禁止随意改写批准过的 fixture、golden file 或 snapshot 来迁就实现。
- 禁止用 mock 绕过真实行为断言。
- 禁止编造命令、工具、文件、测试结果或覆盖率。
- 禁止在注释里声称"应该没问题"而不给出验证证据。
- 禁止未经批准触碰密钥、生产环境、部署和破坏性操作。
- 禁止把“现有测试通过”表述成“软件没有其他缺陷”。

这个 Prompt 的精髓不只是“先复述、先建追踪矩阵、再写测试”，还多了一条很容易被忽略的纪律：先从仓库里找事实，再决定跑什么。 Harness 最怕漂亮的假动作——文档里写了一个根本不存在的命令，报告里说“应该通过”，或者为了变绿悄悄改掉批准过的 fixture。诚实地写“这项检查目前缺失”，比编一个看上去很专业的结果强得多。

我把她“蒸馏”成了一个 Skill

我当然没法把一位经验丰富的高级 QA 塞进 Markdown 文件。她在测试过程中表现出来的直觉、怀疑和判断，也不是几条指令能够复制的。不过，她坚持的工作方式可以留下来：Design Review 之后先定义验收用例，基本门槛没过不接包，接包之后继续探索，发现新问题再反过来充实用例。

如果你在用 OpenSpec、Superpower 或任何支持 Skill / 自定义指令的工具，就可以把这套纪律沉淀成一个可复用的 Skill。一个 Skill 说白了就三部分：什么时候触发、要做什么、怎么算做完。

# Skill: acceptance-driven-coding

## 触发时机
当用户要求"实现 / 重构 / 修复"某个有明确行为预期的模块时。

## 执行契约
1. 建立基线：读取真实的 Agent 指南、构建配置、CI 和测试资产，识别技术栈与可执行命令。
2. 若没有 HLD，先引导用户补齐边界 / 数据流 / 约束 / 架构风格。
3. 从 HLD 中提取可测试的行为、架构不变量、安全边界和非功能目标，交用户确认。
4. 与用户共同产出 Given-When-Then 用例，至少覆盖：
   正常路径、边界值、异常路径、并发、性能、压力与故障恢复。
5. 生成实现前，建立 ATC 到 UT / IT / 架构检查 / 专项测试 / 人工判断的追踪矩阵。
6. 实现后，优先调用项目已有的统一验证入口，不得编造命令或擅自增加依赖。
7. 检查本地验证与 CI / Pre-merge 是否覆盖同一组关键门禁。
8. 逐条给出通过 / 失败 / 未运行清单；未全过不得声明可交付。
9. 全绿后生成探索性测试章程；发现问题后补成回归用例。

## 完成定义（Definition of Done）
- 所有验收用例对应的测试通过
- Maintainability / Architecture / Behavior 三层检查通过（或已列出缺失项和豁免理由）
- 覆盖率和 HLD 中约定的性能 / 压力目标达标
- 验收追踪矩阵不存在无人负责、无法验证的空项
- 安全与权限边界未被突破，高风险操作均有人工批准
- 最终报告列出已运行、未运行的检查及剩余风险
- 已列出尚未验证的风险与探索性测试方向
- 未擅自修改任何验收用例或批准过的 fixture / golden file

把它存成团队共享的 Skill，好处是方法论从“存在某位高手脑子里”变成“长在工具里”。新来的同事、下一个项目，甚至三个月后的自己，都能直接复用同一套纪律，不靠记性。这就是我所说的“蒸馏”：Skill 替代不了那位 QA，却能让每个 Agent 在交包之前，都先听见她当年的那句话——这些用例不通过，就别交付。

通过 ATC 只是入场券

前面讲的都是“怎么定标准”。但标准如果要人手动一条条核对，AI 再快也白搭——瓶颈只是从写代码变成了验代码。真正的杀器，是把确定性的检查收进一个真实、可复用的验证入口，让 AI 一条命令就能跑，也能读懂结果。

这个入口应该优先长在项目已有的构建表面上，例如 make check、mvn verify、gradle check、npm run check 或现有的 ci/build.sh。不要一上来就另造一份“Agent 专用脚本”，结果人跑一套、AI 跑一套、CI 又跑一套，三套标准各自长歪。最理想的状态是：本地和 CI 调同一个入口，区别只在运行环境，不在质量标准。

但我那位老同事还教会我另一件事：自动化测试全绿，只代表已知问题没有重现，不代表未知问题不存在。 所以 Harness 不能只有一圈，而应该有内外两圈：内圈是确定性的自动验收，负责挡住不合格的软件包；外圈是探索性和专项测试，负责继续寻找我们还没想到的问题。

这条链适合按从快到慢、从便宜到贵的顺序排列，让问题尽量在成本最低的环节暴露：

flowchart TD
    P[Feedforward: AGENTS / HLD / ATC] --> N[统一验证入口: check / verify]
    CI[CI / Pre-merge] --> N
    N --> A[Maintainability: Format / Lint / Type Check]
    A --> B[Architecture: Boundary / API / Security]
    B --> C[Behavior: UT / IT / ATC]
    C --> G{全绿?}
    G -->|否| H[AI 读失败输出→定位→修复]
    H --> N
    G -->|是| I[候选软件包]
    I --> J[探索性 / 性能 / 压力测试]
    J --> K{发现新问题?}
    K -->|是| L[补充 HLD / ATC / 回归测试]
    L --> N
    K -->|否| M[人工终审与交付]

每一环各司其职，缺一不可：

• Format（格式化）：Prettier、gofmt、black 之类。统一风格，把“AI 的写法习惯”和“项目规范”对齐，省掉一堆无谓的 diff 噪音。
• Lint / Type Check（规范与类型检查）：抓坏味道、未使用变量、可疑比较、类型不匹配和圈复杂度等问题。这是代码规范的第一道机器闸门。
• Architecture Fitness（架构适应度）：文档里写“依赖只能向内”不算数，还要用项目技术栈适合的确定性规则守住模块依赖、API / Schema 兼容性和高风险目录。否则架构风格只是温馨提示。
• Static Scan（静态扫描 / 安全）：SonarQube、Semgrep、gosec。查的是 AI 最容易埋的雷：SQL 注入、硬编码密钥、空指针、资源泄漏。AI 生成代码尤其要过这一关，因为它可能生成看起来合理、实际上并不安全的写法。
• Unit Test（单元测试）：验证每个零件在隔离状态下正确。这里覆盖的是验收用例里那些“单点逻辑”。
• Integration Test（集成测试）：验证零件拼起来、跨模块、连上真实依赖（数据库、消息队列）之后还对。限流器跨整秒边界的行为，可以用可控时钟做确定性测试，再通过集成测试验证真实调用链。
• Acceptance（验收核对）：拿最终结果逐条对照 Given-When-Then，出一份通过 / 失败 / 未验证清单。对于关键流程，最好再配一份经人确认的 fixture、golden file 或示例输入输出；Agent 可以补测试，但不能为了迁就实现随手改答案。
• Performance / Stress（性能与压力测试）：验证系统不只在“能跑”的时候正确，也要在流量上来、资源吃紧、持续运行时守住 HLD 约定的指标和降级行为。
• Exploratory Testing（探索性测试）：不照脚本机械点选，而是带着风险假设去试不同路径。它不承诺穷尽所有缺陷，价值恰恰在于发现现有用例没有覆盖的盲区。

内圈的关键是把失败信息原样喂回给 AI。AI 读得懂 lint 报告和测试栈回溯，可以自己定位、自己修、再自己重跑。外圈的关键则是把每次新发现沉淀回内圈：探索性测试找到一个缺陷，就补一条 ATC、UT 或 IT；压力测试暴露一个临界点，就把那个数值写进 HLD 和回归测试。这样 Harness 才会越用越结实，而不是每次从头祈祷。

有个前提别忘了：这条链本身得由人来搭和把关。门槛设多严、哪些扫描项能豁免、覆盖率卡多少、什么风险值得继续探索，这些是工程判断，不能让 AI 自己给自己定。对于密钥、生产数据、部署、数据库迁移和破坏性命令，还要明确“默认不准做，除非得到人工批准”。缰绳可以让 AI 自己拉，但缰绳的另一头，得攥在人手里。

Harness 也要体检：Audit → Improve → Re-audit

还有一个经常被忽略的问题：我们辛辛苦苦搭好的 Harness，会过期。

目录会搬家，构建命令会变化，CI 会重构，批准过的行为样例也会被新需求淘汰。半年没人维护的 AGENTS.md，可能比没有更危险——没有的话，Agent 至少知道自己得去找；写错了，它反而会非常自信地跑偏。

为了解决这个问题，我后来做了两个配套 Skill：lazy-harness-audit 负责体检，lazy-harness-helper 负责按优先级补洞。它们背后的闭环很简单：

拿证据做基线审计 → 找到最高风险缺口 → 做最小改进 → 跑真实验证 → 重新审计

审计不是数一数仓库里有多少个 Markdown 和 YAML，而是看 Agent 能不能真正找到并用上这些东西。我把它拆成七个维度：

80 分以上是 GREEN，60 到 79 是 YELLOW，再低就是 RED。不过，分数不是用来刷成就的。真正有用的是那些封顶项（score cap）：它们告诉你，有些地基没打，别的地方装修得再漂亮也没用。

这就是 lazy-harness-helper 的基本策略：先解除 cap，再补得分最低、风险最高的两三项；优先复用项目已有工具，不为多拿几分就塞一堆新依赖。 如果项目已经有 Makefile，就在上面补 make check；如果 mvn verify 本来就是标准入口，就别再造一个 agent-check.sh 来制造第四套流程。

最后一定要重新审计，而且要诚实。命令没有跑，就写“未运行”以及原因；工具不存在，就写“当前缺失”；只改了文档，就别宣称“质量门禁已经完成”。Harness 的目的本来就是减少含糊，不能最后把含糊藏进一份更漂亮的报告里。

Score evidence, not intent：看证据，不看愿望。
ATC 写得再漂亮，如果没有测试真正执行；架构规范写得再严，如果没有检查真正拦截，都只能算半成品。

一套可以明天就用的清单

把上面这些收成一张能落地的 checklist，下次让 AI 写模块前对着走一遍：

1. 先做一次基线审计
   找到真实的 Agent 指南、构建配置、CI、测试和安全规则；先解除会封顶的缺口，不急着堆新工具。

2. 补 Feedforward
   在根级和必要的模块级指南里写清项目地图、真实命令、架构边界、危险区域和 Done 标准，并链接到 HLD / ADR 等深层文档。

3. 写 HLD 和验收用例（重头戏）
   HLD 写清边界、数据流、关键约束和架构风格；ATC 用 Given-When-Then 定义什么叫做对。

4. 把 ATC 写到可执行
   用 Given-When-Then 覆盖正常、边界、异常、并发和故障恢复；数值要具体，把隐含假设变成显式断言。

5. 建立验收追踪矩阵
   每条 ATC 都要落到 UT、IT、架构检查、专项测试或人工判断，不能有“写了要求但没人验证”的空项。

6. 建立统一验证入口
   优先复用 make check、mvn verify、gradle check、npm run check 等现有构建表面，让本地和 CI 跑同一组关键门禁。

7. 跑三层自动验收内圈
   Maintainability → Architecture → Behavior，一条命令跑通，失败输出回喂 AI 自修。没全绿，不交包；批准过的 ATC 和 fixture 不准为了迁就实现而改写。

8. 守住安全和权限边界
   密钥、日志、PII、生产数据、部署、迁移、批量删除和破坏性 Git 操作，默认需要人工批准，并尽量用沙箱或只读权限缩小爆炸半径。

9. 跑探索性测试外圈
   性能、压力、异常和边界条件继续找茬；发现新问题，就补进 HLD、ATC 和回归测试。

10. 报告、复审、维护
    说明运行了什么、什么没运行、还剩什么风险；机器证据全绿后由人做语义终审，再安排 Harness 的 owner、复查节奏和下一次审计。

一句话：

别再指望靠更聪明的提示词驯服 AI，靠的是更扎实的验收标准。
你把“对”定义得越清楚，AI 的自由发挥空间就越小，交付就越可控。

最后一句

我当然知道，一个 Skill 代替不了那位老同事。它没有她多年积累的测试直觉，也不会在拿到软件包后忽然换个角度，找到所有人都没想到的那条路径。但每当 Agent 兴冲冲地说“已经完成”，这个 Skill 至少会替她追问一句：验收用例都通过了吗？性能、压力、异常和边界条件测了吗？没通过，就先别交付。

AI 时代最值钱的工程能力，可能不再只是“把代码写对”，而是把“对”定义清楚，再建立一套不通过就不放行的 Harness。她以前替我们的软件质量把关；现在，我们虽然不再共事，那套方法却可以继续和我并肩干活。

全文思维导图

@startmindmap
<style>
mindmapDiagram {
  node {
    BackgroundColor #F8F9FA
    RoundCorner 10
    Padding 10
    FontSize 13
  }
  :depth(0) {
    BackgroundColor #1E3A5F
    FontColor white
    FontSize 18
    FontStyle bold
  }
  :depth(1) {
    FontSize 15
    FontStyle bold
  }
  :depth(2) {
    FontSize 13
  }
}
</style>

* 验收用例驾驭 AI 编码
** 一位高级 QA 老同事
*** Design Review 后先给 ATC
*** 用例不通过 不接软件包
*** 交包后继续探索和专项测试
*** 质量纪律蒸馏成 Skill
** 完整 Harness
*** Feedforward 指路
**** AGENTS / HLD / ADR / 安全规则
*** Feedback 纠偏
**** 本地检查 / CI / ATC / 人工评审
*** 三层验证
**** Maintainability / Architecture / Behavior
*** 两条横梁
**** Safety / Entropy Management
** 为什么是 ATC
*** AI 缺的是边界不是能力
*** 需求是愿望 用例是合同
*** 人主导定义 不外包给 AI
** 两根缰绳
*** High Level Design 定方向
**** 边界 / 数据流 / 约束 / 架构风格
*** Acceptance Test Case 定对错
**** Given-When-Then
**** 正常 + 边界 + 异常
**** 隐含假设变显式断言
** Prompt 与 Skill
*** 先复述 建矩阵 再写测试
*** 禁止改题 / mock 造假 / 口头担保
*** 沉淀成可复用 Skill
** Harness 内外两圈
*** 统一验证入口 本地与 CI 同构
*** Maintainability → Architecture → Behavior
*** 失败输出回喂 AI 自修
*** 探索性 / 性能 / 压力测试
*** 新问题沉淀成回归用例
** Audit → Improve → Re-audit
*** 七维 100 分审计
*** 先解除 score cap
*** 每次只补两三个高风险缺口
*** 看证据 不看愿望
@endmindmap

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。 欢迎在我的个人网站 https://www.fanyamin.com 访问原文并评论。