CLAUDE.md 模板库

CLAUDE.md 不应该从空白开始写。可以按项目类型准备模板,再让 CC 基于真实文件只读调整,形成适合当前项目的长期工作说明。

CLAUDE.md 是给 CC 看的项目工作说明。它不需要写得华丽,但必须具体、可执行、可检查。

下面提供几类常见模板。使用时不要原样复制到项目里,应该让 CC 先只读分析当前项目,再按模板生成草稿。

模板里不要写真实 API Key、Token、密码、服务器地址、内部账号或生产数据。所有敏感信息都应该用占位说明,不进入项目记忆。

通用模板

适合大多数项目先起步。

# CLAUDE.md

## Project Overview
- 这个项目的用途:
- 主要用户:
- 主要技术栈:

## Important Directories
- `src/`:
- `docs/`:
- `scripts/`:
- `tests/`:

## Working Rules
- 修改前先说明计划和影响范围。
- 不做无关重构。
- 不新增依赖,除非先说明理由并等待确认。
- 不修改密钥、部署配置、生产数据。
- 生成文件不要手改,应修改源文件。

## Verification
- 小改动:
- 前端页面:
- 后端接口:
- 发布前:

## Report Format
- 修改了什么:
- 为什么这样改:
- 如何验证:
- 剩余风险:

静态网站模板

适合文档站、教程站、企业官网、纯 HTML/CSS/JS 项目。

# CLAUDE.md

## Project Overview
- 这是一个纯静态网站。
- 页面以 HTML/CSS/JS 和 Markdown 内容为主。
- 优先保证 SEO、可读性、链接正确和移动端表现。

## Content Rules
- 文档内容优先写在 `content/` 的 Markdown 中。
- 构建产物不要手工修改。
- 新增文档后必须更新学习路线或目录入口。
- 页面标题、description、canonical 和站内链接要同步检查。

## Design Rules
- 保持现有品牌色和排版节奏。
- 不要新增重型前端框架。
- 移动端文字不能溢出,按钮不能挤压。
- 文档页要保持左侧目录、正文、右侧目录结构稳定。

## Verification
- 修改 Markdown 后运行构建。
- 检查新增页面是否能通过干净 URL 访问。
- 检查站内链接是否 200。
- 检查 sitemap 是否包含新页面。

前端应用模板

适合 React、Vue、Nuxt、Next、Svelte 等项目。

# CLAUDE.md

## Project Overview
- 这是一个前端应用。
- 修改 UI 时要同时考虑桌面端和移动端。
- 用户可见变化必须通过真实页面或截图验收。

## Working Rules
- 优先复用现有组件和样式系统。
- 不随意新增依赖。
- 不做无关重构。
- 不修改与任务无关的格式。
- 表单、按钮、菜单和路由修改后必须说明交互影响。

## Verification
- 页面类任务优先使用 `/run` 观察真实页面。
- 修改逻辑后说明是否需要测试。
- 如果无法运行项目,要说明原因和替代检查方式。

## Report Format
- 改了哪些组件:
- 用户能看到什么变化:
- 验证了哪些页面:
- 未验证内容:

后端接口模板

适合 Node、Python、Java、Go 等后端项目。

# CLAUDE.md

## Project Overview
- 这是一个后端服务项目。
- 接口修改要关注入参、出参、错误处理、兼容性和日志。

## Working Rules
- 修改接口前先定位路由、控制器、服务层和数据模型。
- 不随意修改数据库结构。
- 不连接生产数据库。
- 不把密钥、Token、账号写入代码或文档。
- 涉及兼容性变化时必须明确说明。

## Verification
- 优先运行项目已有测试。
- 如果没有测试,说明最小手动验证方式。
- 接口变更要列出受影响调用方。

## Report Format
- 修改接口:
- 影响范围:
- 兼容性说明:
- 验证方式:
- 风险:

让 CC 基于模板生成草稿

请基于当前项目生成 CLAUDE.md 草稿。

要求:
1. 先只读分析项目文件。
2. 参考“【项目类型】模板”,但不要机械照抄。
3. 只写当前项目能确认的事实。
4. 不写密钥、账号、Token、生产地址。
5. 标出哪些内容是“需要用户确认”。
6. 只输出草稿,不要写入文件。

模板使用后的审查

请审查这份 CLAUDE.md 草稿。

重点检查:
1. 是否有模板残留的无关内容。
2. 是否有未确认的项目事实。
3. 是否有敏感信息。
4. 是否有不可执行的空话。
5. 是否有适合拆到 Skill 或 Hook 的内容。

不要写入文件,只给修改建议。

验收结果