全流程质量门与任务级验证

内容类型：方法说明难度：进阶适合：需要判断 AI 生成内容能否进入下一阶段或交付的人阅读时间：约 12 分钟

质量门解决两个不同问题：

1. 项目阶段能不能继续向前走 —— 用 G0–G9；
2. 当前这一处修改要验证到什么程度 —— 用 V0–V4。

不要把两套体系混成“任何小改都必须走完整需求、设计、构建、启动和全量回归”。

1. G0–G9：项目阶段门继续保留

门禁	检查时机	最低通过标准
G0 所有权与可恢复性门	重要写入、高风险修改、危险动作或难恢复对象前	Owner、目标、恢复方式和不可逆后果可解释
G1 材料门	问题定义前	材料来源、版本、缺失项明确
G2 问题定义门	需求分析前	用户、场景、目标、非目标明确
G3 需求基线门	总体设计前	本版范围、优先级、验收方式明确
G4 总体设计门	详细设计前	系统边界、模块、数据流和关键取舍明确
G5 详细设计门	任务拆分前	本次高风险 UI/通信/数据/状态/异常设计足够
G6 开发准入门	大功能编码前	修改边界、禁止范围、验证方法明确
G7 代码合入门	合入前	Diff 可解释，相关验证有结论，高风险 Review 关闭
G8 发布门	交付前	正常/异常路径、遗留风险、回退版本和待现场项明确
G9 经验沉淀门	写入公共 Skill/Rule 前	事实可追溯，适用/不适用范围明确，加入后有净增益

G0–G9 是完整项目和高风险阶段的治理框架，不是每次改一个按钮文字都要填十张表。

普通 Git 工作区中的可逆 MicroPatch 由 Fast Lane + Diff + V0/V1 管理，不需要先触发 G0 文档化流程。

2. Intent Gate：只读问题不进入修改门

用户只是问当前阈值、采样次数、SING/RUN 或配置来源时，走 Read-Only Trace：

精确搜索 → 最短调用链 → 证据 → 结论 → END

不创建修改快照，不跑 build/test，不写变更记录。只有用户随后要求“那就改成……”才进入修改质量门。

3. 修改任务先选最轻安全路线

路线	适合	最低过程
Fast	文案、颜色、布局、明确局部修改	精确定位 → 最小 patch → V0/V1
Execution	目标和业务后果已经明确	Compact Brief / Behavior Contract → 实现 → 精准验证
Discovery	新项目、新流程、仍有业务未知	Decision Tree / Frontier → 基线 → 设计 → 实现

Fast 不要求迷你设计卡

纯文案、颜色、字号、Margin、列宽、已有样式复制等 MicroPatch，只需要确认：

Target / NonGoal（有必要时） / Verification

不要为了统一格式先输出完整 Plan、迷你设计卡或架构说明。

BehaviorPatch 用 6 行契约代替长 Plan

Trigger:
Condition:
Action:
Reset:
Record:
NonGoals:

4. V0–V4：验证强度

等级	典型修改	默认验证
V0	纯文案、注释、非编译静态内容	git diff --check / 静态检查
V1	XAML、样式、普通局部代码	受影响 App/项目构建；明确相关测试才跑 focused test
V2	设备、通信、MES、存储、共享约束	affected build + focused fake/replay/unit test
V3	状态机、联锁、并发、启动停止、告警后果	affected build + focused tests + WorkflowSmoke
V4	发布、大重构、公共协议/Schema/依赖兼容	完整 checkpoint / 广泛回归

Read-Only / Fast / Execution / Discovery 决定“当前任务需不需要先讨论清楚以及讨论到多深”；V0–V4 决定“改完证明到什么程度”。构建成功不等于必须继续跑所有 UnitTests。

5. R1–R5 和 V0–V4 不冲突

本站部分教学文章继续使用 R1–R5 描述修改风险/影响范围；V0–V4 描述验证成本和深度。

同一个 R1 任务可能是 V0，也可能是 V1；一个需求很明确的联锁 Bug 虽然走 Execution，仍可能需要 V3。

6. 代码所有权门：要求能解释，不要求先写文档

进入合入或交付前，至少能回答：为什么改、改了哪里、为什么这样改、可能影响什么、怎么证明没坏。

“能解释”不等于“每次必须产出正式设计文档”。

7. 备份和 RecoverySnapshot 按风险使用

普通 Git 工作区的小改，Git 状态、Diff 和可回退提交通常已经足够。

RecoverySnapshot 更适合：

• 已知 E-SafeNet/DLP 写入不稳定；
• 文件曾乱码/变空；
• 高价值配置/正式文档特殊写回；
• 非 Git 或难恢复对象；
• 用户明确要求额外恢复点。

不要把“每次改一行都先复制工作副本、建立项目外快照”写成普遍硬门。

8. Bug 门：证据等级比“有没有自动 red test”更重要

focused test
→ Fake/Simulation
→ Replay
→ 日志/时间线/known-good diff
→ harness
→ 只读设备
→ HITL

EvidenceGrade A/B/C/D；D 级不能写“根因已确认”。重试后自行恢复只能先标记 SuspectedTransient。

9. 真实设备和危险动作的硬边界

默认：

HardwareAction: ForbiddenByDefault

高压、运动、阀门、继电器、加热、气路、危险联锁等改变真实设备状态的动作不由 Agent 为了验证自动执行。

Agent 可以完成设计、静态/focused/Fake/Replay、软件侧状态验证，以及在明确安全且授权时的只读观察。

需要真实设备动作但尚未执行时：

HardwareVerification: HardwarePending

不是 EnvironmentBlocked，也不能写成“已验证通过”。获得授权后仍按风险保持 HITL。

详见 真实设备操作安全。

10. 最短质量门

只是问现状？ → Read-Only Trace
只是显示小改？ → Fast + V0/V1
规则已明确？ → Execution + 对应 V 等级
业务还没想清？ → Discovery + 必要的 G2/G3/G4/G5
准备发布？ → G7/G8 + V4
需要真机？ → 软件证据 + HardwarePending → HITL

下一步

功能修改最小流程 验证体系 回归与验收 真机安全 V10 Skill 说明