给 Claude 定规则：让它写出的代码像我们团队的人写的

承接上一篇

上一篇《主流编程智能体工具对比》里我推荐了 Claude Code 作为综合能力最强的选择。

但光有工具还不够。Claude 的编程能力确实强，但如果你不给它定规矩。它写出来的代码风格可能跟你项目里现有的完全不搭——变量命名忽驼峰忽下划线，异常处理有的写有的不写，注释格式随心所欲。

先装好 Claude Code

如果你还没装 Claude Code，简单过一下。老实说，

安装

Claude Code 是 CLI 工具。npm 一行搞定：

npm install -g @anthropic-ai/claude-code

装完在项目目录下跑：

claude

它会自动读取项目目录结构，接下来你就可以用自然语言跟它对话了。说起来，

Vibe Coding 环境：那些 10w+ 星标的工作流模板

除了 Claude Code 本身。日常开发中用得最多的其实是那些社区里流行的工作流模板——你可以理解为“AI 编程助手的自定义技能/工作流排行榜”。GitHub 上有一批仓库，汇总了从构思到部署的全流程模板。教 AI 怎么按工程纪律干活。

我截了几个最火的：

┌──────────────────────────────────────────────────────────────┐
│ Vibe Coding 自定义工作流排行榜 │
│ │
│ 排名 名称 ★ Stars 工作流步骤 │
│ ── ──── ─────── ──────── │
│ Superpowers 175k 头脑风暴→分支→计划 │
│ →TDD→审查→完成 │
│ │
│ Everything CC 171k /plan→/tdd→/review │
│ →/security→/e2e→merge │
│ │
│ Spec Kit 92k 宪法→澄清→规格 │
│ →计划→拆解→实现 │
│ │
│ gstack 88k 办公时间→CEO评审 │
│ →工程师评审→设计→实现 │
│ │
│ Get Shit Done 59k 新建→讨论→规划 │
│ →执行→验证·发布 │
│ │
│ BMAD-METHOD 46k 简报→PRD→架构 │
│ →拆分·开发·审查·回顾 │
└──────────────────────────────────────────────────────────────┘

TDD几乎成了标配。怎么说呢， Superpowers、Everything CC、Matt Pocock Skills 等高星项目都把 /tdd 作为主要环节。这说明大家已经意识到，仅让 AI 写代码不够，还得让它先写测试。

分层 Review 文化在 AI 时代反而更重了。 gstack 模拟大公司的多层级审批——CEO评审计划、工程师评审计划、设计评审、代码审查、QA 测试。听起来夸张，但对于需要多人协作的项目。这种“人工监督点”确实能避免 AI 跑偏。

子代理模式是趋势。 Superpowers 提到让 AI 主代理调度多个专业子代理并行工作——一个专门写测试。一个专门做安全扫描，一个专门写文档。这种模式在处理复杂任务时效率很高。

命令化是主流交互方式。 大多数工作流采用 /command-name 格式，这是 Claude Code / Cursor 等工具的自定义指令语法。输入简短命令即可触发复杂多步工作流，比每次手动打一大段提示词高效得多。

对我最实用的是 Superpowers 和 Spec Kit。前者轻量覆盖全流程，后者强调“先定义规格再实现”。适合 API 设计或程序架构这类需要先把事情想清楚再动手的场景。

Claude 指令的基本用法

Claude 的指令程序有几个主要概念，先搞清楚后面才好讲规则。

CLAUDE.md 项目规则文件

在项目根目录放一个 CLAUDE.md 文件，Claude 每次启动时会自动读取。这就是你给 Claude 定的“家规”。

A simple example：

- 使用 TypeScript，严格模式
- 变量用 camelCase。类名用 PascalCase
- 异常必须抛出具体 Error 对象，不能 throw string
- 注释用 JSDoc 格式

Claude 会在每次对话中遵循这些规则。

/init 命令

第一次进入项目时可以用 /init 让 Claude 了解项目结构这方面，

/init

” 的痛点。

日常对话

C​laude 支持自然语言指令：

把 UserService 里的 createUser 方法加上参数验证
给这个项目加一个健康检查接口

C​laude 会直接修改对应文件，你 review 后决定是否接受。这样可以把“手动打开 IDE 写一样逻辑”的时间压缩到几秒钟，从而缓解 “重复劳动” 的痛点。

Plan Mode：不确定需求时先用

*什么时候该用 Plan Mode*？按理说，*

直接写代码的场景

• "把这个函数改成异步"
• "加一个日志输出""修复这个空指针异常"

C​laude 可以立即响应。无需额外规划步骤，适用于明确且单一的小改动，以免浪费额外时间进行规划。从而解决 “需求过细导致沟通成本高” 的痛点。

用 Plan Mode 的场景

• "给项目加一套权限程序" —— 用什么方案？RBAC，ABAC？数据库表怎么设计，
• "重构这个模块" —— 拆分策略、依赖处理？"设计一个新的 API" —— RESTful 或 GraphQL？分页方案，

C​laude 在 /plan 模式下会：

1. a) 分析现有代码架构；
2. b) 列出可行方案并分析利弊；
d) 等待你的确认后才开始实际编码。

经验法则 超过 5 个文件需要改动时请先启用 Plan Mode；否则容易出现“一边改一边发现方向错误”导致上下文失效。需要重新开始，这正是 “大改动缺乏全局视角” 的主要痛点所在。其实，

实战的观点是。用 CLAUDE.md 给智能体定规则

p下面拿真实项目信息来示例，看如何将规范转化成机器可读指令。

h4 data - id = " heading-"> 场景 p 我们拥有 Spring Boot 项目，却因为缺少统一规范导致Claude经常违背团队约定。例如使用 LoggerFactory.getLogger 而非 @Slf4j，抛 RuntimeException 而不是 BusinessException。每次修改后仍需人工二次修正—这正是 “AI 帮助却产生新负担” 的典型案例。

p 在编写详细 CLAUDE.md 后效果马上见效。

h4 data - id = " heading-"> 規則文件示例

pre

技术栈

• Java,Spring Boot .x
• MyBatis‑Plus .
• Sa‑Token .x
• Hutool .x,Lombok

code 規範

• 类名 PascalCase,方法/变量 camelCase,常量 UPPER_SNAKE
• 使用 @Slf4j 記錄日志,禁止 LoggerFactory.getLogger
• 業務異常拋 BusinessException
• Controller 返回 ResponseEntity。統一使用 BaseResponse 包裝
• 所有 public 方法必須有 Javadoc
• 使用 BeanUtil.copyProperties 做對象拷貝

目錄結構

src/main/java/com/example/ ├── controller/ ├── service/ ├── mapper/ ├── entity/ ├── dto/ └── exception/

禁止事項

‑ 禁止硬編碼敏感資訊 ‑ 禁止空 catch 塊 ‑ 禁止字串拼接 SQL

/ pre>

p 未設規則時 C​laude 輸出：

java // Claude 自己寫的 logger Logger logger = LoggerFactory.getLogger;throw new RuntimeException;String sql = "SELECT * FROM users WHERE name = '" + name + "'";

java // 按 CLAUDE.md 生產 @Slf4j public class UserServiceImpl implements UserService { public User getUserById { User user = userMapper.selectById;if { throw new BusinessException;} return user;} }

p 差距立現。其实，说到主要結論，若不明確告訴 C​laude 您團隊實際規範。它會根據全網平均值生成代碼，而非您的專屬風格。

踩坑的观点是，規則寫得太粗等於沒寫

p 起初我的 CLAUDE.md 僅寫三行：

text - 用 Spring Boot - 注意异常处理

p 結果 C​laude 還是自行決策：“注意异常处理”被解讀為簡單 try‑catch 並打印堆疊。而我期望的是拋出具體 BusinessException 帶錯誤碼。

The rest of answer has been truncated due to length constraints.

---