用 Claude Code 的 /goal 打造自动 QA：让测试和 Lint 自己跑到全绿
你写完一个功能，准备提 PR。
结果一跑测试：红了。
再跑 Lint：也红了。
更烦的是，错误不是一个。这里类型不对，那里格式不对，还有一个测试因为 mock 数据过期直接炸掉。
这时候，如果你让 Claude Code 只做一件事：
/goal all tests pass and lint is clean
它就很像一个坐在你旁边的 QA 工程师：读错误、找原因、改代码、再跑命令，直到测试和 Lint 都干净。
这篇教程就讲清楚怎么用它，怎么写目标，怎么加约束，怎么避坑。
这个 /goal 到底适合干什么？
/goal 的核心价值很简单：
你告诉 Claude Code 一个最终状态，它会围绕这个状态持续推进。
不是让它“帮我看看”。
也不是让它“优化一下”。
而是给它一个可以验证的结果。
比如：
/goal all tests pass and lint is clean
这个目标非常适合做代码验收。
因为它有清晰的判断标准：
- 测试命令跑完，不能有失败
- Lint 命令跑完，不能有报错
- 修完后需要再次验证
- 不能只改表面，得把真正问题处理掉
这比一句“帮我修一下代码”靠谱太多。
推荐提示词：直接照抄这个版本
如果你只是想快速用起来，可以直接复制下面这段：
/goal all tests pass and lint is clean
Run the project test and lint commands. Fix the root causes of any failures. After each change, rerun the relevant command to verify. Keep changes minimal and do not refactor unrelated code.
中文理解一下：
目标：所有测试通过，Lint 没有错误。
请运行项目里的测试和 Lint 命令。遇到失败就修根因。每次改完都重新运行相关命令验证。改动尽量小，不要顺手重构无关代码。
我建议保留英文版本。
Claude Code 对开发任务理解英文指令通常更稳，尤其是 tests pass、lint is clean、root causes 这种表达，很贴近工程语境。
为什么这条指令好用？
它好用，不是因为它玄学。
而是因为它把任务从“聊天”变成了“验收”。
很多人用 AI 写代码，最大的问题是指令太虚：
帮我修复这个项目的问题
这句话看着没毛病，其实很难执行。
问题是什么？
修到什么程度算完成？
要不要跑测试？
Lint 算不算？
能不能大改？
AI 很容易开始自由发挥，然后你收获一堆看似努力、实际难验收的改动。
换成 /goal 后，目标变成了：
all tests pass and lint is clean
清楚、可检查、能闭环。
这就是关键。
适合哪些场景？
1. 写完功能，提 PR 前自检
你刚写完一个登录弹窗。
本地页面看着没问题。
但测试可能已经炸了：
- 旧快照没更新
- 表单校验文案变了
- 某个组件 props 类型变了
- ESLint 抓到了未使用变量
这时候丢给 Claude Code：
/goal all tests pass and lint is clean
让它把红灯处理掉。
你可以去倒杯咖啡，回来重点看 diff。
2. 接手老项目，先把基线跑绿
老项目最吓人的不是代码烂。
是没人知道它到底还能不能跑。
你可以让 Claude Code 先建立质量基线：
/goal npm test passes and npm run lint has zero errors
它会根据报错逐个处理。
这一步很适合放在重构前。
因为基线不绿，你后面每改一处都像在拆炸弹。
3. 升级依赖后修兼容问题
比如你升级了 TypeScript、React、Next.js、ESLint。
然后项目开始疯狂报错。
别一条条复制错误去问。
直接给目标：
/goal the project builds successfully, all tests pass, and lint is clean
注意这里多加了 builds successfully。
依赖升级后，构建错误也很常见。
4. 修复 CI 失败
CI 挂了，团队群里开始安静。
你可以把 CI 日志贴给 Claude Code，再给它目标：
/goal fix the CI failure. All tests, lint, and build commands should pass locally.
它会根据日志定位问题。
如果项目里命令明确，效果会更稳。
更稳的写法：把命令写死
有些项目脚本很多。
比如：
{
"scripts": {
"test": "vitest",
"test:unit": "vitest run",
"test:e2e": "playwright test",
"lint": "eslint .",
"typecheck": "tsc --noEmit"
}
}
如果你只说 all tests，Claude Code 可能不知道你想跑哪些。
更推荐这样写：
/goal npm run test:unit passes, npm run lint has zero errors, and npm run typecheck passes
Use these exact commands:
- npm run test:unit
- npm run lint
- npm run typecheck
Fix only the issues needed to make these commands pass. Do not update snapshots unless the UI output change is intentional.
这就很扎实。
它不用猜。
你也不用担心它跑错命令。
我常用的 4 个模板
模板 A：日常提交前检查
/goal all tests pass and lint is clean
Run the standard test and lint commands for this repo. Fix failures with minimal changes. Rerun commands after fixes and summarize what changed.
适合：每天写完代码准备提交。
模板 B：加上类型检查
/goal tests pass, lint is clean, and typecheck passes
Run test, lint, and typecheck commands. Fix root causes. Avoid unrelated refactors. If a failure is caused by a broken test, explain why before changing the test.
适合：TypeScript 项目。
尤其适合那种类型报错一长串的仓库。
模板 C：修 CI
/goal fix the CI failure and make the local verification commands pass
Use the CI log as the source of truth. Reproduce the failing command locally when possible. Fix the smallest necessary scope. Verify with the same command that failed in CI.
适合：GitHub Actions、GitLab CI、Vercel 构建失败。
模板 D：限制不能乱改
/goal all tests pass and lint is clean
Constraints:
- Do not change public APIs unless required
- Do not update snapshots without explaining the visible behavior change
- Do not silence lint rules globally
- Do not skip or delete tests
- Keep the diff small
适合：多人协作项目。
这段很重要。
AI 有时候为了“变绿”，会动歪脑筋。比如跳过测试、放宽规则、改配置。
提前写清楚，能少很多离谱操作。
标准工作流：别让它蒙头改
我建议你按这个流程用。
第一步：确认项目命令
打开 package.json，看这几个脚本：
{
"scripts": {
"test": "vitest run",
"lint": "eslint .",
"typecheck": "tsc --noEmit",
"build": "next build"
}
}
然后把命令写进 /goal。
不要只说“跑测试”。
你越具体，它越像靠谱同事。
第二步：给出清晰验收标准
比如：
The goal is complete only when these commands all pass:
- npm run test
- npm run lint
- npm run typecheck
这句话很关键。
它告诉 Claude Code：不是改完代码就结束，是命令全通过才结束。
第三步：要求它小步验证
加上这句：
After each fix, rerun the relevant failing command before moving on.
别让它一次改十个文件，然后才发现方向错了。
小步跑，小步修。
人类工程师也是这么干的。
第四步：看 diff，而不是只看结果
命令全绿也别直接闭眼合并。
重点看这些地方：
- 有没有跳过测试：
it.skip、describe.skip - 有没有删断言
- 有没有把严格类型改成
any - 有没有关闭 ESLint 规则
- 有没有更新大量快照
- 有没有动到无关业务逻辑
AI 干活快，但你要当 code owner。
别把方向盘完全交出去。
一个完整示例
假设你在一个 Next.js 项目里改了用户设置页。
现在你要做提交前检查。
可以这样发给 Claude Code：
/goal npm run lint, npm run typecheck, and npm test all pass
Use these exact commands:
- npm run lint
- npm run typecheck
- npm test
Fix root causes with minimal changes. Do not skip tests, delete assertions, use `any` to bypass type errors, or disable lint rules. If snapshots need to change, explain the user-visible change before updating them. Rerun the relevant command after each fix.
它理想情况下会这样推进：
- 运行
npm run lint - 发现
SettingsForm.tsx有未使用变量 - 删除变量或补上真实使用
- 重跑
npm run lint - 运行
npm run typecheck - 发现
UserSettings类型缺少字段 - 修类型或补 mock 数据
- 重跑
npm run typecheck - 运行
npm test - 修失败测试
- 全部通过后总结改动
你拿到的不是一坨“我帮你优化了代码”。
而是一组有验证链路的修复。
这才像工程协作。
避坑清单：这些话一定要加
坑 1：它为了变绿，直接跳过测试
危险写法：
it.skip('should submit form', () => {})
加约束：
Do not skip, delete, or weaken tests.
坑 2：它用 any 糊类型错误
危险写法：
const user: any = response.data
加约束：
Do not use `any` or type assertions to hide type errors unless there is no safer option. Explain if used.
坑 3：它关掉 Lint 规则
危险写法：
// eslint-disable-next-line
或者更狠：直接改 .eslintrc。
加约束：
Do not disable lint rules globally. Avoid inline disables unless clearly justified.
坑 4：它乱更新快照
快照测试很容易被“批量更新”糊过去。
加约束：
Do not update snapshots unless the rendered output change is intentional. Explain the visible change first.
坑 5：它顺手重构半个项目
你只是想修一个测试。
它给你换了架构。
头大不头大？
加约束：
Keep changes minimal and avoid unrelated refactors.
什么时候不要用这条指令？
有些场景不适合直接让它冲。
测试本身已经大面积腐烂
如果 300 个测试挂了，原因横跨五个模块。
不要一口气丢给它。
拆小：
/goal make the tests in src/features/billing pass
先修一个目录。
再修下一个。
需求还没想清楚
如果你自己都不知道正确行为是什么，AI 只能猜。
测试红了不代表代码错。
也可能是测试过时。
这时应该先写清楚预期：
The intended behavior is: when the user has no payment method, show the empty state instead of throwing an error.
再让它修。
项目命令跑得特别慢
比如 E2E 一跑 40 分钟。
别直接让它全量跑。
指定更小命令：
/goal the billing unit tests pass and lint is clean for changed files
不然它会把时间烧光。
我的推荐配置：PR 前一键 QA
你可以把下面这段存成自己的常用提示词。
每次准备提交前直接贴：
/goal the PR is ready for review: tests pass, lint is clean, and typecheck passes
Verification commands:
- npm run lint
- npm run typecheck
- npm test
Rules:
- Fix root causes, not symptoms
- Keep the diff small
- Do not skip or delete tests
- Do not weaken assertions
- Do not use `any` to hide type errors
- Do not disable lint rules globally
- Do not update snapshots unless the UI change is intentional
- Rerun the relevant command after each fix
- When done, summarize the commands run and the files changed
这段适合大多数前端项目。
如果你是 Python 项目，可以换成：
/goal all tests pass, lint is clean, and type checking passes
Verification commands:
- pytest
- ruff check .
- mypy .
Rules:
- Fix root causes with minimal changes
- Do not skip tests
- Do not silence lint or type errors without justification
- Rerun the relevant command after each fix
- Summarize changes when done
如果你是 Go 项目：
/goal all Go tests pass and lint is clean
Verification commands:
- go test ./...
- golangci-lint run
Rules:
- Keep changes minimal
- Do not remove tests
- Do not ignore errors just to satisfy lint
- Rerun commands after fixes
- Summarize the final result
关键点记住这几个就够了
/goal要写成可验证结果，不要写成模糊愿望- 把具体命令列出来，别让它猜
- 加限制：不跳测试、不乱用
any、不关 Lint、不乱更新快照 - 要求改完重跑命令
- 全绿后看 diff，别只看成功提示
最短可用版就是这句：
/goal all tests pass and lint is clean
更稳的工程版是这句：
/goal all tests pass and lint is clean
Run the project test and lint commands. Fix the root causes of any failures. After each change, rerun the relevant command to verify. Keep changes minimal and do not refactor unrelated code.
把它当成你的自动 QA 助手。
别让它替你拍板。
让它替你跑腿、读日志、修小坑、反复验证。
这才是最舒服的用法。
