CLAUDE.md 行为驱动设计
CLAUDE.md 的正确定位——不是项目说明书，而是行为驱动引擎：只写能驱动 AI 行为的约束，描述性内容不写
简介
CLAUDE.md 是 Claude Code 等 Agent 类工具在工作目录中读取的顶层配置文件，它定义了 AI 在该目录中的行为模式、角色身份和工作方式。但其真正的价值不在于”介绍项目”，而在于作为行为驱动引擎——每一行内容都应当直接驱动 AI 在特定场景下的具体行为决策。
这个认知来自 WangZhu 在搭建 AI 工作台过程中的 8 次迭代实践：最初 CLAUDE.md 包含标题、项目描述、沟通约定、迭代原则等大量描述性内容，经过反复删减后只剩 4 章——角色设定、用户画像（指向外部文件）、目录结构一览、工作模式（9 种驱动所有行为的入口）。每一次迭代都在验证同一个判断视角：打开文件看到一行字，就知道”哦，这时候我应该这么干”——它才是有价值的。
关键信息
- 类型：配置文件 / 行为引擎
- 领域：AI 协作 / Agent 配置 / 上下文工程
- 核心原则：只写驱动行为的约束，描述性内容不写
- 典型结构：角色设定 + 用户画像引用 + 目录结构一览 + 工作模式（入口列表）
- 相关概念：Claude Code、AI 工作台、工作模式、目录精简、上下文工程、CLAUDE.md 项目指令
核心特性
8 版迭代的进化路径
| 版本 | 关键改动 | 认知突破 |
|---|---|---|
| v1→v2 | 去掉标题（如”AI Workspace 项目配置”），第一行直接是”我是小瑞，你的 AI 助手” | 标题不驱动任何行为——打开文件就知道谁在跟你说话更有价值 |
| v3 | 加入工作模式 | 整个工作台的转折点——CLAUDE.md 从”关于文件”变成”操作手册” |
| v5→v8 | 大量删减沟通约定、迭代进化原则、目录使用指引等描述性内容 | 反复验证同一原则：只有驱动行为的约束值得保留 |
最终四章结构
- 🤖 角色设定：我是谁，我怎么沟通
- 👤 用户画像 →
memory/user-profile.md：不在 CLAUDE.md 中堆个人信息，而是指向专门的 memory 文件 - 📁 工作区目录结构：5 个目录快速一览（skills/memory/knowledge/assets/sessions）
- 🎯 工作模式（9 个）：驱动所有行为的入口，每种模式对应一类任务，引用对应的 skill 或 memory
与 CLADE.md 项目指令的区别
CLAUDE.md 项目指令 是 @Sean 在知识库构建中提出的概念——CLAUDE.md 作为”给每次新会话植入记忆的行为宪法”，侧重让 Claude Code 记住项目级规则和约定。CLAUDE.md 行为驱动设计则更精炼地聚焦于”驱动行为”这一核心筛选标准，并强调结构精简（从 8 版删到 4 章）、与外部 memory 文件的分工（用户画像不写本体只指路径）。
不同素材中的观点
- 2026-07-15-woshipm-ai-workbench-7-days：王耑通过 8 版 CLAUDE.md 迭代验证了行为驱动原则——从最初的”项目配置”式文档不断删减不驱动行为的内容，最终只保留角色设定 + 用户画像引用 + 目录一览 + 9 种工作模式。核心判断视角：“每一行都要问自己——这句话驱动行为吗？” 工作模式的加入是整个 CLAUDE.md 的转折点——从”关于我的文件”变成”操作手册”。
实用信息
写作自查标准
每写一行 CLADE.md 内容时问自己：
- 这句话会在什么具体场景下驱动 AI 改变行为？
- AI 看到这句话后应该”怎么做”而非”知道了什么”？
- 如果不写这一行，AI 的行为会发生偏离吗？
三个答案都是明确肯定 → 保留；任何一个模糊或否定 → 考虑删掉。
注意事项
- 不要把 CLAUDE.md 写成项目介绍文档——AI 不需要你介绍项目，它需要你告诉它怎么跟你协作
- 描述性内容（如”本项目使用 React 框架”）本身不驱动行为——改成”当修改组件时，必须参考
components/README.md中的规范” - 个人信息不堆在 CLAUDE.md 本体——指向 memory/user-profile.md，让 CLAUDE.md 保持极简
- 工作模式的数量不要一次性设计——边用边加，只有真实需要的模式才值得写入