AI 辅助下的代码质量守门(译编)
更新 2026-10-11 25 分钟(含落地) 难度 ★★★☆☆作者 Skills 编辑部(译编)
相关搜索
这篇用到的 skill(3)
Web 应用测试。
npx skills add anthropics/skills -g怎么向人/AI 请求审查。
npx skills add obra/superpowers -gTDD 工作流。
npx skills add affaan-m/ECC -g
AI 写代码飞快,但"质量门"反而更要紧。社区共识三点:反向 TDD(先让 AI 出测试再写实现)、零警告门禁(--max-warnings=0,警告会悄悄变成新基线)、审查作为关卡(每次改动都过同一道闸)。核心是让 AI 产出可验证、可守门,而不是又快又野。
这篇适合谁 / 不适合谁
适合:用 AI 写代码、要团队质量不掉的人。 不适合:直接合未经测试/审查的 AI 代码的人。
操作步骤
1. 反向 TDD
先自然语言规格 → AI 出测试 → AI 写最小实现过测试:
text
按这个规格先写测试(覆盖边界与异常),再写最小实现让它变绿,别超规格。2. 零警告门禁
ESLint 设 --max-warnings=0,pre-commit 跑机械层;警告积累会成新基线,零警告才守得住。
text
eslint . --max-warnings=03. 审查当关卡
每次改动用 requesting-code-review 走同一道闸,自动检查先挡一批缺陷,人只看"标准是否跨场景成立"。
text
按团队标准审这段代码:列问题、严重度、改法;标准是否成立要跨场景判断。会踩的坑
| 坑 | 现象 | 绕法 |
|---|---|---|
| 不写测试 | 回归 | 反向 TDD |
| 警告堆积 | 基线烂 | 零警告 |
| 无门禁 | 漏缺陷 | pre-commit |
| 盲信 AI | 事故 | 人做最终判断 |
FAQ
TDD 怎么用 AI?
先测试后实现。
警告要管吗?
要,零警告门禁。
审查谁做?
自动检查 + 人终审。
团队怎么统一?
同一套门禁所有人过。
相关源码
- Quality Assurance in AI-Assisted Development (yushi91)
- Test-Driven Development with AI (Kinde)
- Making AI Coding Agents Follow True TDD (brgr.one)
- Keep Consistent Coding Standards with AI Code (exceeds.ai)
一句话结论
结论:AI 写代码要把质量门做硬——反向 TDD、零警告门禁、审查当关卡,让 AI 产出可验证可守门,你做最终判断。
参考来源
相关场景
测试与质量
用 AI 写测试用例和自动化脚本
测试最大的价值不是"覆盖率高",是"抓住会真出事的路径"。让 AI 生成测试的核心是:先给它已实现的代码或明确的行为约定,再让它补边界用例——别让它凭空造被测对象,造出来的测试再绿也没意义。
★★☆☆☆ 20 分钟(含跑通)3 个 skill
测试与质量
让 AI 做一次像样的代码评审
AI 代码评审有个典型毛病:**它会给你 20 条"建议",其中 18 条是风格偏好**。真正有用的评审只有两类信息——哪里会坏、哪里别人看不懂。所以这套流程的重点不是"让 AI 多说",而是**先限定它只能报这两类问题**。
★★★☆☆ 一次 PR 约 15 分钟3 个 skill