# Understanding Gates

> 当一个构建、修复或升级正从意图走向交付、你需要证明它仍然对得上最初的请求时用它。以 approve/revise/reject 裁决逐一审问 Design、Plan、Build、Test、Ship 五个阶段，具名失败即修复目标，每次修复后重跑该关。Trigger words: understanding, stage gates, validate build, spec match, verdict, green but wrong, echo check, done means done. 中文触发词：理解关卡、阶段关卡、对齐原始需求、裁决、绿了但不对、回声检查、做完才算完。

- Skill: `tcuzzo/understanding-gates-7` (Agent Skill)
- Install (CLI): `npx skillmds@latest add tcuzzo/understanding-gates-7`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tcuzzo/understanding-gates-7/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: Tcuzzo (https://skillmd.com/u/tcuzzo)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tcuzzo/understanding-gates-7

---


# Understanding Gates
**Effort:** light — 每个阶段跑一轮验证器，对照最初的请求打分，每次修复后重跑。消除：对照转述被验证通过的漂移——绿着落地、回答的却是没人问过的问题的构建。

一套面向构建的验证纪律。它在五个阶段审问工作——Design、Plan、Build、Test、Ship——永远对照**最初的**请求，绝不对照工作对请求的转述。每道关返回证据：分数、一个裁决、具名的失败、修复动作。它约束 agent，不约束人：不加新的审批步骤，不给提需求的人添摩擦。

## 什么时候跑

- 任何会落到真实地方的构建、修复或升级。
- 任何你正要说"做完了"、而唯一凭据是一个绿色测试的时刻。
- 每次修复之后，在失败的同一阶段上。

## 第 0 阶段 — 锚定意图

打分之前，先钉死比较的锚点：人的**原话**，加上一行翻译过的指令（见 [intent-compiler](../intent-compiler/SKILL.md)）。每道关都对着这个锚点打分。绝不对着你自己的转述打分——转述会漂移，然后每道关就都在悄悄验证漂移，而不是验证请求。

## 五道关

每道关对照原始意图问一个问题：

| 阶段 | 问题 |
| --- | --- |
| Design | spec 清晰，并且忠于最初的请求吗？ |
| Plan | 计划回应了意图，并且适配它要发布到的界面吗？ |
| Build | 代码满足 spec，没有漂移吗？ |
| Test | 测试锻炼的是真实行为，不是替身吗？ |
| Ship | 它能干净地应用、失败会大声，而且交付声明经得起事实核查吗？ |

**每道**关都用同样五个镜头打分，每个 0–4：spec 契合、架构契合、类型安全、可测性、安全性——按阶段措辞（在 Design，"可测性"问的是 spec 可不可检验；在 Ship，问的是交付声明可不可检验）。汇总：五个镜头求和（0–20），乘以 5——就是该关 0–100 的裁决分。记录每个镜头的分，不只记总分——总分会藏住是哪个镜头失败了。

## 裁决

把镜头分滚成 0–100，分档：

- **Approve**（80+）：证据充分。仍然不是"做完"的证明——见第二条法则。
- **Revise**（60–79）：存在具名失败。每一条都是修复目标。
- **Reject**（低于 60）：工作偏离了意图。退回上一阶段。

背后没有具名失败的裁决是低信息量裁决。要清单。

## 修复纪律

1. 每次重跑都以最初的意图为锚。
2. 记录每个镜头的分，不只记最上面那个数。
3. 每条具名失败都当成修复目标。没有一条失败是装饰。
4. 修复后，**重跑同一道关**。没有重跑的修复只是一个声明。
5. 绝不把信心升格为就绪。由测试和真实界面说了算。

## 两条法则

**1. 回声法则。** 一个只会同意的检查是回声，不是验证器。诚实的证明是反驳：喂给它一条你明知为假的声明，看它把那条判掉。假话都能过，这个检查就是演戏。关于 mock 的推论：只 mock 不稳定的外部叶子——付费 API、抽风的网络。绝不 mock 行为本身就是证明的那个器官；它的打分、声明抽取和判定逻辑必须真跑。

**2. 必要，不充分。** 通过的测试是必要的，永远不充分。"做完"的意思是：人真正使用的那个真实界面，自己把活干了。点名那个界面，触发真实路径，看着正确结果到达。绝不把一张单元测试的回执升格成实况能力声明。

## 硬性规则（什么会让这个技能失败）

- 对着转述打分，而不是对着最初的请求。
- 一个 revise 或 reject 裁决背后没附任何具名失败。
- 修复了却没重跑失败的那道关。
- mock 了验证器本身，或 mock 了正在改动的那条接缝。
- 凭一个绿色测试、没有真实界面证明就宣称做完。

## 保留构建记录

每个阶段留下：意图、确切的输入产物、分数、具名失败、执行的修复、重跑结果、真实界面的证据。指不到可复现证据的记录是横幅，不是记录。

## 搭配使用

- [intent-compiler](../intent-compiler/SKILL.md) — 打分之前先翻译请求。
- [red-first](../red-first/SKILL.md) — Test 关的契约：先 commit 失败测试。
- [sniper-testing](../sniper-testing/SKILL.md) — 真实副作用，没有 mock 剧场。
- [blind-tribunal](../blind-tribunal/SKILL.md) — 架在这些关卡之上的独立评分者。
- [repair-loop](../repair-loop/SKILL.md) — 把 revise 裁决推到绿的那个循环。