质量不是「事后修」，是「进门就卡」
规模化交付里，靠「人自觉」保质量行不通——人太多、项目太多，漏一个就出事。正确的做法是质量门禁：在自动化流水线里设「关卡」，不达标就不放行。
一句话：质量不是在发布前「检查」出来的，是在每个环节「卡」出来的。
什么是质量门禁
质量门禁 = 流水线里的「关卡」：某个标准不达标，就拦住，不让它通过。
代码提交 → [测试门禁] → 不达标：卡住 → 修复再提交
→ 达标：放行 → 下一环节
门禁把「人记得检查」变成「系统强制把关」。
对 deploy-bot：它部署前就要过门禁，过不了就不部署。这把「靠人记得先测」变成「系统强制：测试没过就卡住」，从源头挡住坏改动。
自动化测试：门禁的基础
测试是质量门禁的第一道闸。自动化测试保证「改动不破坏已有功能」。
- 单元测试：测单个函数/模块
- 集成测试：测模块间协作
- 回归测试：防止老功能被新改动弄坏
有自动化测试，门禁才有「判据」——没有测试，门禁无从谈起。
对 deploy-bot 尤其重要：它自己是「部署机器人」，它的逻辑（判断门禁过没过、选择目标环境、触发回滚）如果没测试，改坏一次就可能把坏代码部署上线。deploy-bot 自己的逻辑也要测。
质量门禁的几道关
可以设多道门禁，层层把关：
| 门禁 | 卡什么 |
|---|---|
| 测试通过 | 改动不破坏已有功能 |
| 覆盖率达标 | 关键路径有测试覆盖 |
| 无「必须改」未处理 | 审查出的高危问题清干净 |
| 构建成功 | 能正常构建出产物 |
每道门禁不达标，改动就停在门口。
对 deploy-bot 的部署门禁，落到场景里：
deploy-bot 部署前的门禁（production 前必经）
1. 测试全部通过（npm test 退出码 0）
2. 覆盖率 ≥ 80%
3. 无未处理的「必须改」审查问题
4. 构建成功
5. staging 验收通过
→ 全过才允许部署 production；任一门禁不过就卡住
让 AI 帮你补测试
Codex 可以帮你写测试，让门禁有判据：
给这个函数补单元测试，覆盖：
正常输入、边界输入、异常输入。
AI 补测试 + 人审查，测试覆盖更快更全。
对 deploy-bot，可以让它帮你补「部署逻辑」的测试：
给 deploy-bot 的门禁判断函数补测试：
- 测试全部通过时返回放行
- 覆盖率不达标时返回卡住
- 有「必须改」未处理时返回卡住
- 异常输入时不会误放行
AI 起草 + 你审查，保证 deploy-bot 自己的逻辑被覆盖。
门禁的三个原则
- 可自动化：门禁要能机器判断，别靠人拍板
- 先严后松：宁可误拦，不可漏放
- 可回退：门禁卡住后，改动能退回修正再重来
对 deploy-bot：门禁必须可机器判断（测试退出码、覆盖率数字、是否通过），这样流水线才能自动卡；production 门禁先严，宁可多拦一次，也别放坏代码；被卡住的改动要能退回修正重来，而不是卡死。
一个落地示例
流水线：
1. 提交触发
2. 跑测试：npm test → 失败则卡住
3. 覆盖率：低于 80% 卡住
4. 构建：失败卡住
5. 全部通过 → 合并/部署
每一道都「不达标不放行」，质量就稳了。
对 deploy-bot，把「部署」也接进门禁：
deploy-bot 流水线：
1. 提交触发
2. 测试 → 失败卡住
3. 覆盖率 ≥ 80% → 不达标卡住
4. 构建 → 失败卡住
5. 部署 staging → 冒烟验收
6. staging 通过 → 才允许 production（否则卡住）
常见坑：门禁只设「测试通过」，覆盖率形同虚设
门禁最常见也最容易自欺的坑，是只设「测试跑过」，但测试本身很稀薄、覆盖率很低，门禁名存实亡。
真实场景：你给 deploy-bot 的流水线设了「测试通过」门禁。但测试只有几个 happy path，deploy-bot 的「门禁判断 / 环境选择 / 回滚触发」这些关键路径根本没测。覆盖率只有 20%，可门禁照样放行，因为「测试通过了」——它通过是因为压根没测到要害。
为什么：没有覆盖率门槛的「测试通过」，只能证明「写了的那点测试过了」，证明不了「代码质量好」。关键路径没覆盖，等于门禁只拦最浅的错误。
怎么破：门禁加「覆盖率门槛」（如 ≥ 80%），并把关键路径（deploy-bot 的门禁判断、回滚、环境选择）列为必须覆盖项；用 AI 补测试时，优先补这些高风险逻辑；覆盖率数字要真实，别靠「只测好消息」刷高。
小结
- 质量不是事后修，是进门就卡——靠门禁
- 自动化测试是门禁的基础（判据）
- 可设多道门：测试、覆盖率、无高危未处理、构建成功
- 三原则：可自动化、先严后松、可回退
下一节，讲多项目复用与治理。