AI Coding Quality Gate：AI 说“完成”不算完成

什么是 Quality Gate？

它是一组明确的验收条件。根据项目类型，可以包括 lint、typecheck、unit test、integration test、build、schema 检查、API 验证、浏览器验收、git diff 等。

为什么 AI 编程更需要门禁？

AI 很容易生成“看起来合理”的代码，也很容易在修一个问题时顺手扩大改动。没有门禁时，用户往往只能相信模型自己的完成声明。

推荐闭环

目标 → 上下文 → 计划 → 最小实现 → 验证 → 独立复核 → Git 检查点 → 文档同步。任何一层验证失败，就回到当前层修正，而不是继续往下堆代码。

适合哪些工具？

这套方法和具体模型无关，可用于 ChatGPT、Claude Code、OpenCode、Cursor、Codex、Gemini CLI 等 AI Coding 工具。Vibe Coding 中文助手把这套门禁直接写进了 Skill。

不同阶段应该看什么证据？

需求阶段看验收标准是否明确；实现阶段看类型检查、静态分析和局部测试；集成阶段看 API、数据库、权限和真实数据流；发布前看 build、端到端流程、回归检查和部署环境。门禁不是固定的一条命令，而是和风险等级、技术栈、当前阶段对应的一组证据。

对于纯前端页面，浏览器实际渲染和交互往往比“代码看起来没问题”更重要；对于后端服务，接口响应、日志、schema 和异常路径更关键；对于数据库变更，还需要迁移、备份和回滚证据。

一个实用的最小门禁顺序

第一层先做低成本检查：格式、lint、typecheck。第二层运行受影响模块的单元测试或最小复现。第三层做 build 和集成验证。第四层才是浏览器、真实接口、人工验收等更贵的检查。这样可以尽早发现便宜的问题，避免把明显错误拖到最后。

如果某一层失败，不应该让 AI 同时修十件事。应该读取失败证据，定位最小原因，做一次有限修改，再从失败的门禁重新跑。

为什么要加 Git 检查点？

AI 编程修改速度快，最危险的情况不是报错，而是“改了很多但已经说不清哪一处导致结果变化”。在关键阶段保留 Git 检查点，可以随时比较差异、隔离问题和快速回滚。

推荐至少在需求冻结、基础架构确定、一个功能闭环通过、部署前这几个位置保留清晰提交。提交信息应该描述完成的结果，而不是写“AI 修改”“fix stuff”这类无法追踪的文字。

Quality Gate 常见误区

测试通过就一定能上线吗？ 不一定。测试只覆盖已写出的断言，还需要检查真实用户路径、环境变量、权限、网络、数据和部署配置。

同一个 AI 自己写再自己验可以吗？ 可以做第一层检查，但高风险或复杂任务最好增加隔离复核：新会话、独立测试、浏览器验证或人工检查，降低同一上下文自我确认的偏差。

是不是门禁越多越好？ 不是。门禁要和风险匹配。目标是让失败尽早暴露、结果可追溯，而不是堆一套没人维护的流程。