Claude Code 如何少乱改代码？关键不是把提示词写得更凶，而是给它一套能执行的边界。andrej-karpathy-skills 的价值就在这里：它把常见的 LLM 编程问题压成几条行为规则，让 Claude Code 在动手前先判断任务、暴露不确定点、缩小改动范围，并在收尾时给出验证标准。

规则一：先想清楚，再写代码

乱改通常从第一步就开始了。需求还没读完，模型已经开始补抽象、换结构、改命名。andrej-karpathy-skills 里的 CLAUDE.md 把“Think Before Coding”放在前面，就是提醒 Claude Code 不要把猜测当事实。实际用法很简单：让它先复述目标、列出会碰到的文件、说明不确定点，再允许它修改代码。

规则二：不确定就说出来

Claude Code 容易装确定。比如接口真实返回值没看到、测试命令没跑过、业务边界没问清，它也可能直接写一版。四大规则里最该保留的一条，是让模型暴露 tradeoff：哪里有假设，哪里需要你确认，哪里只是按现有代码推断。这样做会慢一点，但能减少“看起来完成，实际跑不通”的返工。

规则三：只改必要范围

少乱改的核心是范围控制。修一个登录按钮，不要顺手重构表单体系；补一个类型错误，不要改完整个状态管理。给 Claude Code 的任务里可以写清三句话：只改和问题有关的文件；不要引入新依赖；不要做风格化重构。改完后看 Git Diff，如果出现无关文件，就让它解释为什么必须改，解释不清就回退。

规则四：用验证收尾

很多 AI 代码问题不是写错，而是没人检查。andrej-karpathy-skills 适合配合一个固定收尾模板：改了什么、没改什么、跑了什么命令、哪些测试没跑、还有什么风险。这个模板能逼 Claude Code 从“我已经修好了”回到可核验状态。没有验证命令，也要给人工检查点。

怎么把四条规则放进项目？

1. 把 CLAUDE.md 合并到项目根目录，不要覆盖已有团队规则。
2. 补上本项目的启动命令、测试命令、构建命令和禁止改动目录。
3. 每次任务都要求先说计划，再动代码。
4. 提交前检查 Git Diff，确认改动集中在目标文件。

适合哪些任务？

它适合 bug 修复、PR 级小功能、多文件维护、旧项目梳理和代码审查。不适合拿来解决一句话大需求，比如“重做整个后台”或“把系统优化一下”。这类任务范围太大，规则只能减少乱改，不能替你拆需求。

使用检查清单

• 任务开始前，Claude Code 是否先说明理解和不确定点？
• 改动范围是否只覆盖目标文件？
• 有没有新增依赖、重构或格式化无关文件？
• 结尾是否给出测试命令、检查结果和剩余风险？
• Git Diff 是否能让人一眼看懂这次改了什么？