Claude Code 官方文档将工具操作区分为只读、命令执行和文件修改等类型；项目指令与操作权限本来就是不同控制层。CLAUDE.md 怎么约束 Claude Code？把任务边界、修改前计划、最小改动和验证要求写清楚，能降低 AI 乱改代码的概率，但不能把它变成权限隔离或绝对执行保证。(官方权限说明)
症状：Claude Code 改了任务范围外的文件、顺手重构，或报告测试通过却没有实际运行。
最快解法：先用项目规则限定工作方式；必须阻止的操作，再配置权限规则或 hook。
谁该看这篇：
正在用 Claude Code 写代码、遇到改动范围失控的开发者。
想为团队建立项目指令的技术负责人。
参考 Andrej Karpathy Skills、希望把编码行为转成具体约定的工程师。
先判断：CLAUDE.md 怎么约束 Claude Code 到哪一步
Claude Code 会读取项目中的 CLAUDE.md，将其中内容作为项目背景和指令；你可以借此说明代码约定、任务边界和验证方式。官方文档将它定位为持续提供项目上下文的文件，而非执行权限配置。具体加载方式和规则适用范围可查阅官方项目记忆文档。
这意味着，写下“不要修改其他文件”，不等于工具层面禁止它修改。指令可能被误解，也可能与任务要求冲突；因此，完成任务后仍要检查改动文件和 diff。
如果规则写明未经确认不得扩大改动范围，是否就能确保它停下？不能仅靠这句话保证。它能表达你的期望，但不能替代审批机制；需要限制工具操作时，应进一步设置权限规则，或根据工作流配置hook。
把 Andrej Karpathy Skills 与 CLAUDE.md 分开理解
Andrej Karpathy Skills 是社区项目，不应把它的规则描述成 Karpathy 本人发布的官方规范。Karpathy 在原始发言中谈到使用代码代理时会遇到的假设错误、过度复杂化等问题；社区项目则将相关观察整理成面向编码代理的行为建议，作者与项目沿革可从项目仓库核对。本文下面的四条规则是针对项目管理的实践建议，不是对原文的逐字引用，也不是 Claude Code 的保证。
还要区分项目约定与可复用技能。CLAUDE.md 适合写当前代码库长期需要遵循的规则；Skill 更适合封装特定任务的知识或流程。Claude Code 的官方 Skills 文档说明了技能的组织与调用方式。团队可先把通用约定放进项目指令，再将较长、仅在特定任务中使用的流程单独整理。
用第一条规则圈定修改边界
只写“不要改无关代码”不够可操作。把任务目标、允许修改的位置、禁止顺手处理的事项，以及遇到范围外问题时的处理方式一起写明。目录示例应按你自己的仓库调整，不能照搬成不存在的项目路径。
改动范围：
- 只修改完成当前任务所必需的文件。
- 本次允许修改的文件或目录：由任务说明明确列出。
- 不要顺手重构无关模块、更新依赖或改动配置。
- 如确实需要修改范围外文件，先说明原因与文件清单，等待确认。
任务说明也要列清本次目标文件，而不只是把一份宽泛规则长期放在根目录。任务结束后，对照允许清单和实际变更；如果发现额外文件，先判断它是否为完成任务所必需，再决定是否接受。
要求先计划，再开始改代码
先计划不是正确性的担保，而是让你在改动前检查模型是否理解了目标。要求 Claude Code 先说明需求理解、拟查看和修改的位置、验证思路；遇到歧义，或计划需要扩大文件范围时，先停下来请你确认。
例如，接到一个输入校验问题时，可要求它按以下里程碑推进：
- 复述要修复的行为，并标出尚不明确的条件。
- 检查相关实现与已有验证方式，不先改代码。
- 列出预计修改的文件和验证方案。
- 若方案超出任务范围，先解释原因并等待确认。
- 确认计划后再实施，完成后复核真实改动。
项目指令里怎样写，才能减少 AI 乱改代码？把抽象要求改成能检查的动作：先复述、列计划、遇到歧义就询问、不要擅自增加目标。避免只写“认真思考”或“保持谨慎”，因为这些表达没有清晰的验收方式。Claude Code 的官方最佳实践也建议先探索、再规划、然后编码，并给出具体上下文。
用不同控制手段对照风险
下面的对比表帮助你判断规则应放在哪一层。项目指令适合表达工作习惯；如果某个动作必须被拦截，就要采用能控制工具操作的机制。
| 选项 | 适合处理的问题 | 能否保证阻止动作 | 怎么使用 |
|---|---|---|---|
| CLAUDE.md | 项目约定、改动边界、计划和验证要求 | 不能保证 | 写跨任务适用的项目指令 |
| 每次任务说明 | 本次目标、允许文件、验收标准 | 不能保证 | 开始时补充具体范围 |
| 权限规则 | 限制工具可执行的操作 | 可按规则控制相应操作 | 按风险设置允许、询问或拒绝 |
| hook | 在指定流程节点执行检查或阻止操作 | 取决于 hook 配置 | 用于需要自动执行的检查 |
让改动保持最小，并逐项审查 diff
“最小改动”不是单纯追求少改几行，而是只做满足当前目标所需的变更。要求沿用项目现有架构、命名与风格，不因偏好增加新依赖或替换实现；确有必要扩展时，先解释与目标的关系。
改动原则：
- 只实现当前任务明确要求的行为。
- 沿用项目已有架构、命名和格式。
- 不做无关重构、格式化或依赖替换。
- 完成后列出改动文件，并说明每个文件与任务的关系。
审查时先确认工作区原有的未提交改动，再核对实际文件清单和 diff。重点检查新增文件、删除内容、格式变更及注释调整是否与目标直接相关。最小改动不等于跳过必要修复：如果修复本身要求更新相邻逻辑或测试，应说明理由并纳入审查。
⚠️ 仓库若已有未提交改动，先区分原有变化和本次新增变化；否则，diff 中的内容可能被错误归因给 Claude Code。
要求验证，并如实报告结果
验证规则应参照仓库现有的测试、构建或静态检查约定，而不是在指令文件里猜一条命令。要求 Claude Code 报告实际运行了什么、结果如何、哪些检查没有运行以及原因；找不到项目验证方式时，先检查仓库文档和脚本，再与你确认。
验证与汇报：
- 根据项目现有文档或脚本执行相关检查。
- 列出实际运行的检查及结果。
- 说明未运行的检查及原因；不要声称未运行的测试已通过。
- 找不到项目约定的验证方式时，先报告情况并请求确认。
这样能减少“没有验证却宣布完成”的情况，但不能自动证明测试覆盖充分。你仍需要检查失败信息、任务边界和最终 diff。
从一个小任务检查规则是否有效
不要只凭 CLAUDE.md 看起来完整，就断定它解决了 AI 乱改代码。选一个目标清楚、改动范围有限的任务，沿着下面的时间线核对实际行为：
- 开始前：记录工作区已有变化，明确本次任务目标和允许修改的位置。
- 计划后：检查它是否正确理解需求，预计修改是否越界；不合适就先纠正。
- 实施后：对照计划、文件清单与 diff，标出无关改动或没有提前说明的范围扩张。
- 验证后：逐项核对实际运行结果、未运行项目及最终汇报。
- 复盘时：只调整含糊、冲突或无法验收的规则，再用相近的小任务重新检查。
如需确认项目指令是否被读入，可查看官方项目记忆文档中关于记忆与加载的说明。检查过程中，若发现团队需要“必须拦截”的保障，就不要继续堆叠自然语言规则，应进一步审视权限配置与代码审查流程。
应用前核对：任务目标是否可验收？允许修改的位置是否明确？越界时是否要求先询问？验证要求是否来自项目现状？最终汇报是否区分已运行与未运行？有任何一项说不清，就先补充规则或任务说明，再让 Claude Code 开始修改。
CLAUDE.md 能让工作约定更清楚，却不能取代代码审查、版本控制和必要的权限控制。若你在本地开发，依赖与配置会随当前机器和项目变化；共享环境还可能出现工作区冲突，远程环境则要考虑连接条件。需要临时 Mac 测试环境时，可以将 Kvmkit 的美国东部 Mac mini 租用方案与租用价格信息一并评估；如果主要是长期固定负载或必须连接本地物理设备，自购设备可能更合适。先用清单审阅现有规则，再从小任务验证效果，比把项目指令误当作权限锁更稳妥。