CLAUDE.md 约束提示词指南:让 Claude Code 守规矩的工程模板
我是 Quentin,OpenClaw 作者。
Claude Code 用得久了你会发现一个事实:它有多守规矩,完全取决于你 CLAUDE.md 写得有多狠。没有约束 = 它会按训练分布的「平均代码质量」来 —— 单文件 800 行、文件夹乱糟糟、commonjs / esm 混着用、pip 和 uv 各装一半。
这篇文章给你一份我自己每个项目都粘进去的约束模板。配合 OpenClaw 一起用最舒服 —— OpenClaw 的 skills 系统会自动把 CLAUDE.md 注入到每次对话的 system prompt 里。
还没接拼车的话,先把 token 搞定再谈守规矩:
curl -fsSL https://cp.bizq.net/setup.sh | bash -s -- claude-max-20x
怎么用这份模板
- 把下面整段复制到项目根目录的
CLAUDE.md - 根据你的技术栈删掉不相关的章节(比如纯 Python 项目就删掉 React 那段)
- 行数限制可以根据项目调,200-400 是安全区间
- 跟 Claude Code 对话时偶尔提醒一句「先看一眼 CLAUDE.md」—— 上下文窗口大了之后它会忘
我的 CLAUDE.md 模板(直接拷走)
# 任何项目都务必遵守的规则(极其重要!!!)
## Communication
- 永远使用简体中文进行思考和对话
## Documentation
- 编写 .md 文档时,也要用中文
- 正式文档写到项目的 docs/ 目录下
- 用于讨论和评审的计划、方案等文档,写到项目的 discuss/ 目录下
## Code Architecture
- 编写代码的硬性指标,包括以下原则:
(1)对于 Python、JavaScript、TypeScript 等动态语言,尽可能确保每个代码文件不要超过 300 行
(2)对于 Java、Go、Rust 等静态语言,尽可能确保每个代码文件不要超过 400 行
(3)每层文件夹中的文件,尽可能不超过 8 个。如有超过,需要规划为多层子文件夹
- 除了硬性指标以外,还需要时刻关注优雅的架构设计,避免出现以下可能侵蚀我们代码质量的「坏味道」:
(1)僵化 (Rigidity): 系统难以变更,任何微小的改动都会引发一连串的连锁修改。
(2)冗余 (Redundancy): 同样的代码逻辑在多处重复出现,导致维护困难且容易产生不一致。
(3)循环依赖 (Circular Dependency): 两个或多个模块互相纠缠,形成无法解耦的"死结",导致难以测试与复用。
(4)脆弱性 (Fragility): 对代码一处的修改,导致了系统中其他看似无关部分功能的意外损坏。
(5)晦涩性 (Obscurity): 代码意图不明,结构混乱,导致阅读者难以理解其功能和设计。
(6)数据泥团 (Data Clump): 多个数据项总是一起出现在不同方法的参数中,暗示着它们应该被组合成一个独立的对象。
(7)不必要的复杂性 (Needless Complexity): 用"杀牛刀"去解决"杀鸡"的问题,过度设计使系统变得臃肿且难以理解。
- 【非常重要!!】无论是你自己编写代码,还是阅读或审核他人代码时,都要严格遵守上述硬性指标,以及时刻关注优雅的架构设计。
- 【非常重要!!】无论何时,一旦你识别出那些可能侵蚀我们代码质量的「坏味道」,都应当立即询问用户是否需要优化,并给出合理的优化建议。
## Run & Debug
- 必须首先在项目的 scripts/ 目录下,维护好 Run & Debug 需要用到的全部 .sh 脚本
- 对于所有 Run & Debug 操作,一律使用 scripts/ 目录下的 .sh 脚本进行启停。永远不要直接使用 npm、pnpm、uv、python 等等命令
- 如果 .sh 脚本执行失败,无论是 .sh 本身的问题还是其他代码问题,需要先紧急修复。然后仍然坚持用 .sh 脚本进行启停
- Run & Debug 之前,为所有项目配置 Logger with File Output,并统一输出到 logs/ 目录下
## Python
- 数据结构尽可能全部定义成强类型。如果个别场景不得不使用未经结构化定义的 dict,需要先停下来征求用户的同意
- Python 虚拟环境永远使用 .venv 作为目录名
- 必须使用 uv,而不是 pip、poetry、conda、python3、python。包括依赖管理、构建、调试启动等所有环节
- 项目的根目录必须保持简洁,只保留必须存在的文件
- main.py 内容也要简洁。只保留必须存在的代码
## React / Next.js / TypeScript / JavaScript
- Next.js 强制使用 v15.4 版本,不要再用 v15.3 或 v14 或以下版本
- React 强制使用 v19 版本,不要再用 v18 或以下版本
- Tailwind CSS 强制使用 Tailwind CSS v4。不要再用 v3 或以下版本
- 严禁使用 commonjs 模块系统
- 尽可能使用 TypeScript。只有在构建工具完全不支持 TypeScript 的时候,才使用 JavaScript(如微信小程序的主工程)
- 数据结构尽可能全部定义成强类型。如果个别场景不得不使用 any 或未经结构化定义的 json,需要先停下来征求用户的同意每条规则背后的设计哲学
模板看着像一堆 nag,其实每一条都对应一个我踩过的坑。
为什么强制中文?
Claude 的英文输出比中文多一倍 token。如果你团队是中文沟通,统一中文:
- 节省拼车 token(直接省钱)
- diff / commit message / 文档语言一致,不用反复切换
- 中文 LLM 现在准确度跟英文已经持平,没有 quality 损失
为什么 300 行 / 400 行?
这是经验值。超过 300 行的 Python 文件、超过 400 行的 Go 文件,Claude 改一处就容易误删别处 —— 上下文窗口够,但它的「修改 attention」会失焦。
强行卡这个上限会逼出更好的模块拆分,副作用全是正的。
为什么 8 个文件 / 文件夹?
人脑对同层兄弟节点的工作记忆是 7±2。文件夹下文件多了,Claude 列目录时也会漏看。8 是经验上限。
为什么必须 scripts/*.sh?
这是我吃过最大的亏。如果你让 Claude 直接跑 npm run dev,它会:
- 在不同终端里启动多个实例
- 忘记关上一个,端口冲突
- 用错版本的 node / python
- 日志全部 inline 在它自己的 stdout 里,事后翻不回去
把所有启停都收口到 scripts/*.sh:
scripts/dev.sh # 启动开发
scripts/stop.sh # 干净停掉
scripts/test.sh # 跑测试
scripts/build.sh # 构建
scripts/logs.sh # tail 日志每个脚本写好 PID 管理 + 日志重定向到 logs/,事故率下降 80%。
为什么强制 uv 而不是 pip?
2026 年了,pip install 等于自找麻烦。uv 比 pip 快 10-100 倍,依赖解析正确率更高,跨平台 lockfile 一致。Claude 默认会按训练数据用 pip,你不约束它就一定会用错。
为什么禁 commonjs?
ESM 已经是 Node 22 的默认,commonjs / esm 混用会出现:
__dirname在 ESM 里不存在 → import.meta.url 转换坑require()动态加载 ESM 模块时 async 化失败- TypeScript 配置
module字段一旦写错全炸
新项目直接禁 commonjs,省事。
为什么强制 React 19 / Next 15.4 / Tailwind 4?
工具链有断代。Next 14 → 15 是 App Router 默认化,Tailwind 3 → 4 是配置文件移动到 CSS-in-CSS。Claude 的训练数据混杂着所有版本,不约束 = 它给你混搭。
进阶:把 CLAUDE.md 拆分
当模板太长(> 500 行)时,拆出来:
CLAUDE.md # 入口,引用其它
docs/claude/
├── architecture.md
├── python-rules.md
├── nextjs-rules.md
└── run-debug.md入口文件长这样:
# 项目约束(必读)
完整规则见:
- 架构原则:[docs/claude/architecture.md](docs/claude/architecture.md)
- Python:[docs/claude/python-rules.md](docs/claude/python-rules.md)
- Next.js:[docs/claude/nextjs-rules.md](docs/claude/nextjs-rules.md)
- Run & Debug:[docs/claude/run-debug.md](docs/claude/run-debug.md)
## 黄金法则(无论如何遵守)
1. 一律中文
2. 文件 ≤ 300 行(动态语言)/ ≤ 400 行(静态语言)
3. 启停只走 scripts/*.sh
4. 数据结构强类型,不允许裸 dict / anyClaude Code 看到链接会自己 follow。
跟 OpenClaw 的配合
OpenClaw 的 skills 系统天然把 CLAUDE.md 当成全局 system prompt 的一部分。在你的 ~/.openclaw/openclaw.json:
{
"agents": {
"defaults": {
"system_prompt_files": [
"${PROJECT_ROOT}/CLAUDE.md"
]
}
}
}这样无论你从 Telegram、IDE、CLI 任何地方触发 agent,CLAUDE.md 都会被加载。比 Claude Code 原生只在 CWD 自动读取要强得多 —— OpenClaw agent 不一定有 CWD 概念。
我自己的「补充铁律」
除了上面的标准模板,我个人还会再加这几条:
## Git
- commit message 一律中文,简短一句话说清楚「为什么」
- 不要写「修复 bug」「更新代码」这种废话标题
- 多个独立改动不要塞同一个 commit
## Tests
- 写新功能前先写一个最小可跑的失败测试
- 测试文件命名 *_test.{py,ts},跟源文件同级
- 不准 mock 太多,集成测试优先
## Secrets
- 永远不要把 .env 文件 git add
- 任何 API key 都用环境变量,并在 .env.example 里列出占位
- 提交前必须 grep "sk-" 检查一遍这三条尤其在让 AI 帮你写代码时救命 —— Claude 没有「这玩意是 secret」的直觉,你必须显式告诉它。
立即开始
接拼车 token 让 Claude Code 跑起来:
curl -fsSL https://cp.bizq.net/setup.sh | bash -s -- claude-max-20x然后把这份 CLAUDE.md 模板粘进你的项目根目录,从此告别 800 行单文件。
相关文章
- OpenClaw Claude Code 拼车配置指南 — 一键接入完整流程
- Claude Code 拼车最佳实践 — 服务器选型 + 时区编排
- OpenClaw 完整指南 — 框架总览