## Before Writing Code - Read the files you're about to modify. Not skim. Read. - Look at how similar things are done elsewhere in the project. - Check the imports at the top of the file. - Look at the test files. - State your assumptions before coding. - If something is confusing, stop and ask. - Every task should have a clear success criterion before you start writing code.
## Keep Changes Small - Write the minimum amount of code that solves the problem. - "In case we need to" is not a requirement. - Don't touch what you weren't asked to touch. - Match the existing style. - Clean up after yourself, not after others. - Don't reformat. - Can you justify every single changed line? - Don't add dependencies without thinking about it.
这段适合所有“让 Claude Code 改现有代码”的场景，尤其是小修小改。它管的不是能力，是手别太长。
The difference between code that works and code you think works is testing.
后面还有一句更硬：
Write the test first when fixing bugs.
这里不是在推崇某种测试流派。
它只是给 Claude Code 加了一个很硬的约束：修 bug 之前，先证明 bug 存在。
如果它不能复现问题，就很容易修症状，而不是修原因。
截图里还有一条我建议保留：
Run existing tests before and after your changes.
这句话非常适合真实项目。
因为有时候测试本来就失败。如果 Claude Code 没有先跑一遍，它后面就分不清哪些失败是自己造成的，哪些是历史问题。最后总结时一句“测试失败”，你也不知道该怪谁。
Debugging 这条规则更像一套调试流程。
截图里几个关键动作是：
Read the error message.
Reproduce first.
Change one thing at a time.
Don't add workarounds without understanding the root cause.
这些句子都很朴素，但正好克制了 Claude Code 最容易犯的错：看到一个报错类型，就立刻生成一个看似合理的修复。
真实调试要先读完整错误和堆栈，要复现，要一次只改一个变量。
否则 bug 消失了，你也不知道是哪一处改动让它消失的。更麻烦的是，其他改动可能又埋了新问题。
这一类规则可以这样放：
## Debugging And Verification - The difference between code that works and code you think works is testing. - Write the test first when fixing bugs. - Run existing tests before and after your changes. - Read the error message. - Reproduce first. - Change one thing at a time. - Don't add workarounds without understanding the root cause.
这段特别适合放在有测试体系的项目里。
如果项目测试很少，也不是没用。至少可以要求 Claude Code 提供最小复现、手动验证步骤，或者说明为什么暂时无法写测试。
## Communication And Stop Conditions - Say what you did and why. - Flag concerns. - Be precise about what you're uncertain about. - If you notice a common failure mode, stop and reconsider. - Watch for: Kitchen Sink, Wrong Abstraction, Invisible Decision, Optimistic Path, Knowledge Hallucination, Style Drift, Runaway Refactor.
这段尤其适合长任务。
比如你让 Claude Code 连续修测试、补实现、跑验证，或者配合 /goal 做目标驱动执行时，最需要的不是让它一路狂奔，而是让它在发现范围扩大时停下来。
能一直继续不稀奇。
知道什么时候该停，才是长任务里更稀缺的能力。
如果你只想抄作业，可以先抄这一版
下面这份是简化版。
不是原文件完整翻译，也不是我重新写的一套规则。它只保留原文件里最适合直接放进项目配置的句子。
你可以先复制进去，再根据项目实际情况增删。
# CLAUDE.md ## Before Writing Code - Read the files you're about to modify. Not skim. Read. - Look at how similar things are done elsewhere in the project. - Check the imports at the top of the file. - Look at the test files. - State your assumptions before coding. - If something is confusing, stop. - Every task should have a clear success criterion before you start writing code. ## Keep Changes Small - Write the minimum amount of code that solves the problem. - "In case we need to" is not a requirement. - Don't touch what you weren't asked to touch. - Match the existing style. - Clean up after yourself, not after others. - Don't reformat. - Can you justify every single changed line? - Don't add dependencies without thinking about it. ## Debugging And Verification - The difference between code that works and code you think works is testing. - Write the test first when fixing bugs. - Run existing tests before and after your changes. - Read the error message. - Reproduce first. - Change one thing at a time. - Don't add workarounds without understanding the root cause. ## Communication And Stop Conditions - Say what you did and why. - Flag concerns. - Be precise about what you're uncertain about. - If you notice a common failure mode, stop and reconsider. - Watch for: Kitchen Sink, Wrong Abstraction, Invisible Decision, Optimistic Path, Knowledge Hallucination, Style Drift, Runaway Refactor.
粤ICP备14082021号
免费POC，
零成本试错
