Claude Code 的 /goal 用法：一句话，让 AI 持续修到测试通过、Lint 干净
你可以把这条提示词直接丢给 Claude Code：
/goal all tests pass and lint is clean
中文意思很简单：
让所有测试通过，并确保 Lint 检查没有问题。
看起来只有一句话，实际用途很猛。
它把 Claude Code 从“帮我改一段代码”，变成了一个会持续检查结果的 QA 工程师：运行测试、定位报错、修改代码、重新验证，直到项目达到目标状态。
这类工作平时特别磨人。
你改完一个函数，测试挂了；修完测试，Lint 又报错；Lint 修好，另一个边界场景开始失败。来回折腾半小时，真正写业务的时间反而没剩多少。
/goal 就适合接管这段脏活累活。
这条命令到底做了什么？
/goal 的重点不在“执行一次命令”，而在于给 Claude Code 一个持续追踪的目标。
它会围绕目标反复工作：
- 检查当前项目状态
- 运行已有测试
- 查看测试失败原因
- 修改相关代码
- 重新运行测试
- 执行 Lint 或格式检查
- 继续处理新出现的问题
- 直到测试和静态检查都达到要求
你不需要每次都回复：
测试又失败了，继续修。
也不用盯着终端，一看到报错就手动复制给它。
这就是它像 QA 工程师的地方：它盯的是结果，不是某一行代码。
推荐用法：在项目根目录执行
进入项目目录后启动 Claude Code：
cd your-project
claude
然后输入：
/goal all tests pass and lint is clean
如果项目使用了明确的测试和检查命令，最好把它们写出来。这样 Claude Code 不用猜，也不容易漏掉某个检查环节。
/goal
Run npm test and npm run lint.
Fix the code until all tests pass and lint reports no errors.
Do not weaken or delete tests.
Keep the existing behavior unless a failing test proves it is wrong.
Python 项目可以这样写：
/goal
Run pytest and ruff check .
Fix all failures until the test suite passes and Ruff reports no issues.
Do not skip tests or silence warnings without explaining why.
TypeScript 项目可以这样写：
/goal
Run pnpm test, pnpm lint, and pnpm typecheck.
Keep working until all checks pass.
Do not use any or disable TypeScript rules as a shortcut.
为什么这比普通提示词更实用？
普通提示词往往只描述“做什么”：
修复这个项目的问题。
问题是，什么叫“修复”？
代码能运行算不算？测试过一部分算不算？Lint 还有 30 个警告算不算？Claude Code 只能自己猜，结果容易跑偏。
/goal 的思路更直接：给出可验证的终点。
所有测试通过
Lint 没有错误
类型检查通过
目标越具体，执行越稳。
你不是让 AI “努力一点”，而是告诉它：验收标准就在这里。
一条命令适合哪些场景？
1. 接手一个陌生项目
刚拉下来的项目，可能有几十个测试失败。你连目录结构都没摸清，手动排查非常痛苦。
可以直接让 Claude Code 建立问题清单：
/goal all tests pass and lint is clean
它会从实际报错入手。你也能顺便了解项目的测试框架、代码规范和常见问题。
2. 完成一轮重构后
重构最怕“表面上改完了，细节全碎了”。
比如你把一个巨大的 Service 拆成了三个模块，代码看起来清爽很多，结果：
- 导入路径变了
- Mock 没更新
- 类型定义不一致
- 某个边界测试失败
- 格式化规则出现冲突
这时让 Claude Code 继续追踪目标，比逐个复制错误信息省事得多。
3. 让 AI 先写代码，再自己验收
你可以把需求交给 Claude Code：
实现用户注册接口，包含邮箱校验、重复注册处理和密码加密。
完成后运行测试，并持续修复，直到所有测试通过且 Lint 干净。
这段话把“开发”和“验收”连到了一起。
AI 写完代码后，不会马上停在“看起来没问题”的状态，而是要用测试结果证明它确实能工作。
4. CI 报错后的本地修复
线上 CI 挂了，你可以把日志交给 Claude Code，再配合目标：
这是 CI 的失败日志：
[粘贴日志]
/goal
Fix the CI failures.
Run the same local checks used by CI.
All tests, lint, and type checks must pass.
这样能减少“本地没问题，CI 还是挂”的尴尬。
更稳的提示词模板
直接使用下面这个模板，适合大多数项目：
/goal
Make the project pass all automated checks.
Run these commands:
- npm test
- npm run lint
- npm run typecheck
Requirements:
- Fix the root cause instead of hiding errors.
- Do not delete or weaken tests.
- Do not skip failing checks.
- Preserve existing behavior unless the tests show it is incorrect.
- After every meaningful change, rerun the relevant checks.
- Stop only when all tests pass, lint is clean, and type checking succeeds.
- Summarize the changes and remaining risks when done.
把里面的命令换成你项目真实使用的命令即可。
别只说“测试通过”，要写清楚测试范围
下面两种写法，效果差别很大。
模糊写法
/goal make everything work
“Everything”到底包括什么？Claude Code 需要猜。
可执行写法
/goal
Run the full Jest test suite, ESLint, and TypeScript type checking.
Fix every failure until all three checks pass.
这就清楚多了：
- 用什么测试工具
- 检查哪些内容
- 什么状态才算完成
你给出的验收标准越像 CI 配置，结果越可靠。
一定要加的安全限制
让 AI 自动改代码很方便，也有一个现实问题：它可能为了“通过检查”走捷径。
比如：
- 删除失败测试
- 把断言改得更宽松
- 添加
eslint-disable - 使用
any绕过类型检查 - 跳过某个测试文件
- 修改配置，让工具少检查一部分代码
所以建议把限制直接写进目标里：
Do not delete, skip, or weaken tests.
Do not disable lint or type-check rules as a shortcut.
Do not change CI configuration unless explicitly requested.
Fix the underlying implementation instead.
中文项目也可以直接写：
不要删除、跳过或削弱测试。
不要通过关闭规则、增加忽略项或使用 any 来绕过检查。
不要修改 CI 配置来掩盖问题。
优先修复真正的代码原因。
这几句很关键。没有它们，AI 有时会选择“让报错消失”，而不是“把问题修好”。
什么时候不要直接让它自动改？
遇到下面几类情况，建议先让 Claude Code 分析，再决定是否修改：
- 生产数据库迁移
- 支付、权限、登录等核心逻辑
- 大范围删除或移动文件
- CI、Docker、部署配置
- 不熟悉的第三方 SDK
- 测试本身可能写错的项目
可以先用这条：
Analyze all test and lint failures.
Do not modify files yet.
Group the failures by root cause and propose a fix plan.
确认方案后，再让它执行：
Apply the approved fix plan.
Run all tests and lint after each group of changes.
这样更适合老项目，也更适合涉及线上业务的代码库。
一套实用工作流
你可以把整个流程固定下来：
第一步：先看项目规则
Read the project instructions, package scripts, CI configuration, and contribution guide.
Do not modify files yet.
Tell me which commands define a successful build.
第二步：执行完整检查
Run all tests, lint, and type checks.
Report the failures grouped by root cause.
第三步：开始修复
/goal
Fix all identified root causes.
Keep tests meaningful and preserve existing behavior.
Run the relevant checks after each fix.
第四步：检查变更范围
Review the git diff.
Identify unrelated changes, risky changes, and any test modifications.
Do not commit yet.
第五步：人工验收
重点看这些地方：
- 有没有删测试
- 有没有改业务逻辑来迎合测试
- 有没有新增大量忽略规则
- 有没有出现不必要的依赖
- 有没有把错误吞掉
- 有没有修改与任务无关的文件
AI 能帮你跑检查，不能替你承担上线责任。这个边界要守住。
常见避坑清单
避坑 1：没有确认测试命令
有些项目的 test 只跑单元测试，不包含集成测试。也有项目把真正的检查放在 make verify 或 CI 脚本里。
先查看：
cat package.json
cat Makefile
ls .github/workflows
Python 项目还要留意：
cat pyproject.toml
cat tox.ini
cat setup.cfg
别让 AI 只跑一个“看起来像测试”的命令。
避坑 2：项目本身就有历史失败
老项目可能一开始就有 100 个失败测试。你需要明确范围：
Run the existing test suite first.
Separate pre-existing failures from regressions caused by my changes.
Focus on the failures related to the current task.
否则 Claude Code 可能一路修到天黑，甚至误改大量旧逻辑。
避坑 3：无限循环修复
测试之间可能互相冲突。修好 A，B 又失败；修好 B，A 再次失败。
加一个停止条件：
If the same failure reappears after two fix attempts, stop and explain the conflict instead of making more speculative changes.
这句能防止 AI 陷入“再改一行试试”的循环。
避坑 4：把警告当成错误处理
Lint 没报 Error，不代表代码真的没风险。你可以要求它把 Warning 也列出来：
Lint must have zero errors.
Report all warnings separately, including their file locations and whether they should be fixed.
这样不会因为“命令返回成功”就把问题一笔带过。
避坑 5：不看 Git Diff
AI 改完后，别急着提交。
git status
git diff --stat
git diff
几分钟的检查，能避免把临时调试代码、无关格式化和危险配置一起提交进仓库。
一句话版本，适合日常使用
如果你只想记住一条，就用这个：
/goal all tests pass and lint is clean
项目复杂一点，就升级成：
/goal
Run the project’s full test, lint, and type-check commands.
Fix root causes until every check passes.
Do not delete tests, weaken assertions, skip checks, or disable rules.
Review the final diff and summarize any remaining risks.
它不是魔法按钮，也不会替你判断所有业务细节。
可在大量重复的“运行检查—定位报错—改代码—再运行”工作上，它确实能省掉不少时间。尤其适合重构、修 CI、接手旧项目，以及处理一批零碎测试失败。
把目标写清楚，把限制写明白，再认真看一遍 Diff。这样用 /goal，Claude Code 才更像一个靠谱的 QA 搭档，而不是一个只想把红色报错变绿色的代码改写器。
