用 AI 写代码，很多人都在用。但真正用得好的人，少之又少。
今天分享 6 条 Claude Code 实用提醒，简单但极其有效。
这些规则不仅适用于 Claude Code，也适用于所有 AI 编程助手（Cursor、GitHub Copilot、Windsurf 等）。
为什么需要这些规则？
AI 编程助手很强大，但它不是魔法。
很多人用 AI 写代码的方式是：
- 直接扔一句话：“帮我写个登录功能”
- AI 生成一堆代码
- 发现不对，再改
- 改了又改，越改越乱
这种方式效率极低，而且容易出问题。
真正高效的 AI 编程，需要建立一套协作规则。
这 6 条规则，就是为了解决这个问题。
规则 1：在编写任何代码前，先描述你的方法并等待批准
原文：
Before writing any code, describe your approach and wait for approval.
为什么重要？
AI 写代码很快，但方向错了，再快也没用。
很多时候，AI 理解的需求和你想要的不一样。如果直接开始写代码，等发现问题时，已经浪费了大量时间。
正确做法：
❌ 错误示范：
你：帮我写个用户登录功能
AI：好的，我来写... (直接开始写代码)✅ 正确示范：
你：帮我写个用户登录功能
AI：好的，我计划这样实现：
1. 使用 JWT 做身份验证
2. 密码用 bcrypt 加密
3. 登录失败 3 次后锁定账号 15 分钟
4. 支持记住登录状态（7 天）
请确认这个方案是否符合你的需求？
你：方案可以，但不需要锁定账号功能
AI：明白，我会去掉锁定功能，现在开始写代码...好处：
- 避免方向性错误
- 节省返工时间
- 确保 AI 理解你的真实需求
规则 2：如果我给出的需求模糊，请在编写代码前提出澄清问题
原文：
If I give vague requirements, ask clarifying questions before writing code.
为什么重要？
程序员最怕的就是需求不清楚。
AI 也一样。如果需求模糊，AI 只能靠”猜”，猜错的概率很高。
正确做法：
❌ 错误示范：
你：帮我优化这个查询
AI：好的，我加了索引... (直接开始改)✅ 正确示范：
你：帮我优化这个查询
AI：好的，我需要先了解几个问题：
1. 当前查询的性能瓶颈是什么？（慢查询日志显示什么？）
2. 数据量有多大？
3. 查询频率如何？
4. 可以接受的响应时间是多少？
5. 是否可以修改表结构？
你：数据量 100 万，查询很频繁，希望在 100ms 内返回，不能改表结构
AI：明白，我会通过添加复合索引和优化 WHERE 条件来解决...好处：
- 避免无效优化
- 找到真正的问题
- 给出更精准的解决方案
规则 3：完成任何代码编写后，列出边缘案例并建议覆盖它们的测试用例
原文：
After completing any code, list edge cases and suggest test cases to cover them.
为什么重要？
AI 写的代码，往往只考虑了”正常情况”。
但真实世界充满了边缘案例：
- 用户输入为空
- 网络请求超时
- 数据库连接失败
- 并发冲突
- …
如果不考虑这些，代码上线后就是定时炸弹。
正确做法：
✅ 示范：
AI：我已经完成了用户注册功能，以下是需要测试的边缘案例：
1. 邮箱格式不正确
2. 密码长度不符合要求
3. 用户名已存在
4. 邮箱已被注册
5. 注册时网络中断
6. 数据库写入失败
7. 邮件发送失败
8. 并发注册相同用户名
建议的测试用例：
- test_register_with_invalid_email()
- test_register_with_weak_password()
- test_register_duplicate_username()
- test_register_duplicate_email()
- test_register_network_timeout()
- test_register_db_failure()
- test_register_email_send_failure()
- test_register_concurrent_same_username()好处：
- 提前发现潜在问题
- 提高代码健壮性
- 减少线上 bug
规则 4：如果任务需要修改超过 3 个文件，先停止并将其拆分成更小的任务
原文：
If a task requires modifying more than 3 files, stop and break it into smaller tasks.
为什么重要？
一次性改太多文件，容易出问题：
- 难以 review
- 容易引入 bug
- 出问题后难以定位
- 回滚困难
正确做法：
❌ 错误示范：
你：帮我重构用户模块
AI：好的，我会修改：
- User.ts
- UserService.ts
- UserController.ts
- UserRepository.ts
- UserDTO.ts
- UserValidator.ts
- user.routes.ts
- user.test.ts
(一次性改 8 个文件)✅ 正确示范：
你：帮我重构用户模块
AI：这个任务比较大，我建议拆分成 3 个小任务：
任务 1：重构数据层
- UserRepository.ts
- User.ts
任务 2：重构业务层
- UserService.ts
- UserDTO.ts
任务 3：重构接口层
- UserController.ts
- user.routes.ts
- UserValidator.ts
每个任务完成后，我们可以测试验证，然后再进行下一个。
你想从哪个任务开始？好处：
- 降低风险
- 更容易 review
- 出问题容易定位
- 可以逐步验证
规则 5：出现 bug 时，先编写能重现该 bug 的测试，再修复直到测试通过
原文：
When there’s a bug, write a test that reproduces it first, then fix until the test passes.
为什么重要？
这是 TDD（测试驱动开发）的核心思想。
很多人修 bug 的方式是：
- 发现 bug
- 直接改代码
- 手动测试一下
- 看起来好了，提交
这种方式的问题：
- 不确定是否真的修好了
- 可能引入新的 bug
- 同样的 bug 可能再次出现
正确做法：
✅ 示范：
你：用户登录时，如果密码包含特殊字符会报错
AI：好的，我先写一个测试来重现这个 bug：
test('should handle password with special characters', () => {
const password = 'P@ssw0rd!#$%';
const result = login('user@example.com', password);
expect(result.success).toBe(true);
});
运行测试... ❌ 失败（成功重现 bug）
现在我来修复这个问题...
(修改代码)
运行测试... ✅ 通过
bug 已修复，并且我们有了一个测试来防止它再次出现。好处：
- 确保 bug 真的被修复
- 防止 bug 再次出现
- 积累测试用例
- 提高代码质量
规则 6：每次我纠正你时，反思你做错了什么，并制定永不再犯的计划
原文：
Every time I correct you, reflect on what you did wrong and make a plan to never do it again.
为什么重要？
AI 会犯错，这很正常。
但如果每次都犯同样的错误，那就是浪费时间。
这条规则让 AI 具备”学习能力”。
正确做法：
✅ 示范：
你：你生成的 SQL 查询没有考虑 SQL 注入问题
AI：非常抱歉，我犯了一个严重的安全错误。
反思：
1. 我直接拼接了用户输入到 SQL 语句中
2. 没有使用参数化查询
3. 没有进行输入验证
改进计划：
1. 以后所有 SQL 查询都使用参数化查询（PreparedStatement）
2. 对用户输入进行严格验证和转义
3. 在生成数据库相关代码时，主动提醒安全风险
我已经记住了这个教训，以后不会再犯同样的错误。好处：
- AI 不会重复犯错
- 提高协作效率
- 建立更好的工作习惯
如何应用这些规则？
方法 1：直接告诉 AI
在开始工作前，把这 6 条规则发给 AI：
在我们开始工作前，请遵守以下规则：
1. 在编写任何代码前，先描述你的方法并等待批准
2. 如果我给出的需求模糊，请在编写代码前提出澄清问题
3. 完成任何代码编写后，列出边缘案例并建议覆盖它们的测试用例
4. 如果任务需要修改超过 3 个文件，先停止并将其拆分成更小的任务
5. 出现 bug 时，先编写能重现该 bug 的测试，再修复直到测试通过
6. 每次我纠正你时，反思你做错了什么，并制定永不再犯的计划
明白了吗？方法 2：写入项目文档
在项目的 CLAUDE.md 或 .cursorrules 文件中，加入这些规则。
AI 会自动读取并遵守。
方法 3：逐步培养习惯
不需要一次性应用所有规则。
可以先从最重要的 1-2 条开始，逐步养成习惯。
这些规则适用于哪些场景？
✅ 适用场景
- 开发新功能
- 重构代码
- 修复 bug
- 代码 review
- 编写测试
❌ 不适用场景
- 快速原型验证（可以放宽规则）
- 一次性脚本（不需要那么严格）
- 学习实验（重点是理解，不是规范）
我的看法
这 6 条规则，本质上是在建立一套人机协作的工作流程。
AI 很强大，但它不是万能的。
真正高效的 AI 编程，不是让 AI 替你写代码，而是让 AI 成为你的编程伙伴。
这需要：
- 清晰的沟通
- 明确的规则
- 持续的反馈
这 6 条规则，就是一个很好的起点。
结论
AI 编程助手是工具，不是魔法。
工具用得好不好，取决于你怎么用。
这 6 条规则，简单但有效：
- 先描述方法，再写代码 - 避免方向性错误
- 需求模糊时，先澄清 - 避免无效工作
- 列出边缘案例和测试 - 提高代码质量
- 大任务拆小 - 降低风险
- 先写测试，再修 bug - 确保真的修好了
- 反思错误，避免重犯 - 持续改进
试试这些规则，你会发现 AI 编程的效率能提升好几倍。
你在用 AI 写代码时，有什么心得和技巧？欢迎在评论区分享！