新手如何给 Claude Code 定规则？

很多人刚开始用 Claude Code，把力气花在“提示词怎么写得更聪明”上，改了又改，结果还是时好时坏：有时改动的范围大得离谱，有时把本来没问题的代码改坏，有时修了半天，一跑还是不行。

问题往往不在提示词，而在项目里没有一套它读得到的工作规则。Claude Code 能干活，也愿意干活，可它不知道你们踩过哪些坑，不知道哪个目录不能乱动，也不知道某些看着多余的代码其实在兼容历史逻辑。

这些背景，一份写在项目里的 CLAUDE.md 就能交代清楚。写什么、怎么写才有效，可以按几个问题来想；12 条适合新手的工作规则，加一份可以直接拿去改的模板，足够让你很快有个起点。

规则也不是越多越好，真正起作用的，是让 Claude Code 按流程做事。

01 为什么你需要 CLAUDE.md

很多新手刚开始用 Claude Code，会把重点放在"提示词怎么写得更聪明"上。这当然重要，但还不够。

真正决定 Claude Code 是否稳定的，是项目里有没有一套清楚的工作规则。没有规则，它会像一个刚入职但没人带的新同事：能干活，也愿意干活，但容易误判项目背景，改动范围过大，甚至把本来没问题的代码改坏。

CLAUDE.md 的作用，就是把这些规则写下来。它是一份给 Claude Code 的项目工作手册。每次进入项目，Claude Code 都能先读到它，知道这个项目怎么运行、哪些文件重要、修改代码前要做什么、修改后必须怎么验证。

如果你刚开始用 Claude Code，最该先做的是给自己的项目写一份可执行的 CLAUDE.md，而不是学更多高级命令。

02 新手常见的四类错误

Claude Code 很强，但它不了解你的项目。它不知道你们踩过哪些坑，不知道哪个目录不能乱动，也不知道某些"看起来多余"的代码其实是在兼容历史逻辑。

新手常见的错误有四类。

只给目标，不给背景

比如直接说："帮我修复登录问题。"这个指令太粗。Claude Code 会先猜登录逻辑在哪，再猜失败原因，最后给一个看似合理但不符合项目实际的修改。

只要求改代码，不要求验证

很多代码看起来正确，实际跑不通。没有测试、构建、lint 或复现步骤，Claude Code 容易停在"我已经修改完成"的状态，而不是"我已经证明它能工作"的状态。

让它一次做太多事

比如："重构用户系统，顺便优化接口，再修一下页面样式。"范围太大，Claude Code 会同时处理多个方向，最后很难判断每个改动是否必要。

没有禁止事项

你不说"不要重构无关代码"，它可能顺手整理一堆文件。你不说"不要删除已有测试"，它可能为了让测试通过而移除失败用例。

CLAUDE.md 要解决的，就是这些问题。

03 CLAUDE.md 要回答的五个问题

一份有效的 CLAUDE.md，至少要回答五个问题。

第一，这是什么项目？Claude Code 需要知道项目类型、技术栈和核心业务。比如这是 Next.js 应用、Node.js 服务、Python 脚本，还是一个文档项目。

第二，项目怎么运行？启动、测试、构建、格式化命令必须写清楚。别让 Claude Code 每次都去猜用 npm、pnpm 还是 yarn。

第三，修改代码前要先看什么？有些项目入口在 src/app，有些在 pages，有些关键逻辑藏在 lib 或 services。把关键目录写出来，减少无效搜索。

第四，修改时有哪些边界？比如不要改数据库迁移文件、不要改生成文件、不要做无关重构、不要改变公共 API、不要引入新依赖。

第五，修改后怎么证明完成？这是最重要的一点。Claude Code 需要明确的验收方式：运行哪条测试命令、检查哪个页面、确认哪个接口返回正常。

如果 CLAUDE.md 只写"请写高质量代码"，基本没用。规则必须具体到能执行。

Claude Code 的项目记忆文档也建议把构建命令、代码规范与工作流程写进 CLAUDE.md，用具体指令交代项目约定。

04 适合新手的 12 条工作规则

下面这 12 条规则，可以直接放进你的 CLAUDE.md，再按项目实际情况微调。

修改前先理解项目结构。动手前先阅读项目目录、入口文件和相关模块，不要一上来就改。
先定位根因，不要只修表象。很多 bug 表现在页面，根因可能在接口、状态管理或权限判断里。
一次只解决一个明确问题。新手最容易把任务说得太大，大任务必须拆。
不做无关重构。AI 喜欢"顺手整理"，但在真实项目里这会增加风险。
不随意删除已有代码。尤其是测试、兼容逻辑、配置文件和类型定义。
不确定时先提问。Claude Code 的危险在于它有时会猜，把"不确定先问"写进规则能减少低级错误。
优先读相关文件，不盲目扫描全项目。盲目读取大量文件会浪费 token，也会让重点变模糊。
长文件先定位，再阅读。直接整篇读入效率低，也容易遗漏重点。
复杂任务分阶段完成。先计划，再执行，再验证。
修改前说明计划。计划不需要长，但必须具体：要改哪些文件、为什么改、怎么验证。
修改后说明变更。不能只说"完成了"，要说清楚改了什么、影响哪些地方。
必须运行验证命令。没有验证，代码只是"看起来完成"。

如果项目没有测试，也要让 Claude Code 给出替代验证方式，比如启动页面、调用接口、检查输出文件。

验证规则可以参照 Claude Code 官方最佳实践，把能判断通过或失败的检查命令直接交给它。

05 新手可以直接用的 CLAUDE.md 模板

下面是一份简洁模板，复制到项目根目录，替换成自己的信息就行。

# CLAUDE.md

## 项目概述
这是一个 [项目类型] 项目，主要用于 [项目目标]。
技术栈：[框架/语言/数据库/构建工具]。

## 常用命令
- 安装依赖：`pnpm install`
- 启动开发：`pnpm dev`
- 运行测试：`pnpm test`
- 代码检查：`pnpm lint`
- 构建项目：`pnpm build`

## 关键目录
- `src/`：核心源码
- `src/components/`：组件
- `src/lib/`：共享工具和业务逻辑
- `tests/`：测试

## 工作规则
- 修改前先阅读相关文件，确认调用链和根因。
- 修改前先给出简短计划，不要直接动手。
- 一次只解决当前任务，不做无关重构。
- 不要随意删除已有代码、测试或配置。
- 不确定需求或业务规则时，先提问。
- 修改后必须说明改了哪些文件、为什么改。
- 修改后运行相关测试、lint 或构建命令。
- 如果无法验证，说明原因和风险。

## 禁止事项
- 不要引入新依赖，除非用户明确同意。
- 不要修改生成文件。
- 不要改动无关样式或格式。
- 不要为了通过测试而删除测试。
- 不要在没有确认的情况下修改数据库迁移或公共 API。

模板不要写得太满。CLAUDE.md 的价值，规则准比信息多重要。

06 怎么把普通指令改成高质量指令

有了 CLAUDE.md，日常指令也要更具体。

比如"帮我修一下登录 bug"，Claude Code 只能猜。换成"用户登录后刷新页面会退出，请先阅读认证相关代码，定位根因，说明计划后再修改，完成后运行测试"，效果会好很多。

好的指令通常包含四个要素：任务目标、修改范围、限制条件、验证方式。只要这四点说清楚，Claude Code 的输出稳定性会明显提高。

07 规则不是越多越好

很多新手会把 CLAUDE.md 写成一本厚手册。项目背景、业务介绍、接口文档、会议纪要，全都塞进去。这不是好做法。

CLAUDE.md 应该放稳定、长期、经常用的信息：项目命令、目录职责、编码规范、验证流程、禁止事项。

不要放三类内容：大段教程（Claude Code 不需要读课程才能改代码）、频繁变化的信息（临时需求、当天任务写在当前对话里就行）、空话（"请认真思考""请保证质量"这些没有执行标准）。

更好的方式是持续迭代。经常改错某个目录？把"不要改这个目录"写进去。经常忘记跑测试？把测试命令写进去。

CLAUDE.md 是项目协作规则的沉淀，不是一次写完的文档。

08 真正的关键：让 AI 按流程工作

Claude Code 能力很强，但强能力必须配合清楚流程。

新手最容易犯的错，是把 Claude Code 当成许愿池：输入一个愿望，期待它自动给出正确结果。更稳定的用法，是把它当成一个能干活的新同事：先给背景，再给边界，再给验收标准。

CLAUDE.md 的价值，是让 Claude Code 少猜、少乱改、少遗漏验证。

一份好的 CLAUDE.md，至少能做到三件事：让 Claude Code 更快理解项目；让它的修改范围更可控；让每次改动都有验证闭环。

刚开始用 Claude Code？别急着研究复杂技巧，先给项目写一份简洁、具体、可执行的 CLAUDE.md，把常用命令、关键目录、工作规则和禁止事项写清楚。

从这一步开始，AI 编程才会从"看运气"变成"按流程交付"。