质量门禁
Quality Gate
高级通用质量门禁（Quality Gate）是在合并代码或部署上线等关键节点设置的放行条件，检查结果不达标就暂停下一步。它解决的是团队靠人记住检查项、带着已知问题继续交付的风险，例如测试失败时阻止合并。
你可能会说：「我想让 AI 改完代码后先跑检查，没通过就别合并或上线，并告诉我卡在哪里。」
动手看看优惠券功能合并前的质量门禁
1
优惠券功能写好了，提交代码后自动运行测试和安全检查。这两项都是合并前必须达标的条件。
要点质量门禁怎样决定放行还是拦下？
- 1
先定清楚检查发生的节点
我们可以在提交合并请求后、合并前或部署前设门禁。节点不同，拦住的动作也不同：合并前检查挡住代码进入主分支，部署前检查挡住版本进入目标环境。
- 2
把放行条件写成可判断的结果
条件可以是构建成功、关键测试通过、代码规范检查无错误。因为系统要根据结果决定是否放行，所以“代码看起来不错”不能直接充当自动门禁条件；这类判断更适合人工评审。
- 3
检查失败要能找到原因
门禁不只是亮一个红灯。你还需要看到哪个检查失败、对应的日志在哪里，才知道该修代码、修测试，还是排查检查环境。若允许人工放行，最好留下原因，方便之后追查。
容易混淆的地方
测试用例回答“这段功能在某个条件下是否正常”，质量门禁回答“检查结果不合格时，流程能不能继续”。持续集成负责自动运行构建和测试等任务，门禁则利用这些结果决定是否放行。测试覆盖率可以作为参考指标，但覆盖率高不等于关键行为都测对了。
什么时候用
适合用
- 团队通过合并请求开发后台功能，想在合并前拦住构建失败或关键测试失败的代码。
- 网站每次部署前都要检查核心下单流程，失败时先停下发布并查看测试报告。
- AI Agent 经常批量修改代码，你想让它提交结果前通过约定的检查，再交给人复核。
不适合用
- 你只是在本地试一个不会合并或发布的界面草稿，直接预览并手动检查反馈更快。
- 你想知道已上线服务是否正在报错或变慢，这属于运行期问题，用监控和告警持续观察。
- 你还没决定新功能是否值得做，先做产品发现或用户访谈；门禁不能替你判断需求价值。
练一练选一个答案，看看解释
你们的 AI Agent 修改了支付页。团队希望关键测试失败时无法合并，但仍能让开发者看见失败原因。哪种做法最符合质量门禁？
让 AI 帮你做复制给 AI Agent 直接用
请为这个项目设计合并前的质量门禁：先查看现有构建、测试和代码规范检查，再建议哪些结果作为阻止合并的条件。说明每项检查如何运行、失败后到哪里看原因；不要凭空添加项目没有的工具。