ENZOMEGA.
Clipping 微信公众号

CLAUDE.md 从入门到精通（上）

by 朱昆鹏mm 原文 ↗
Created: 2026-06-14
#公众号文章

公众号名称：朱昆鹏AI手记

作者名称：朱昆鹏mm

发布时间：2026-05-11 22:25

1.前言

大家好，这是我日更文章的第1篇

《CLAUDE.md 从入门到精通》我计划分为三个章节来写，希望你读完这个系列之后，能对CLAUDE.md有更深刻的理解和运用，希望能帮到你

  • 上篇：讲解CLAUDE.md基础使用和技巧

  • 中篇：讲解CLAUDE.md深层细节和技巧

  • 下篇：从源码角度来补充理解CLAUDE.md

你现在阅读的是 上篇，我们现在吧～

2.为什么要写 CLAUDE.md

不知道你有没有这样的困扰，明明已经和AI说了代码要写注释并且用英文，使用驼峰变量命名规范等要求

但是重新打开claude code 之后，他还是会不按照你之前的要求来写代码

以至于网络上流传的一张人类和AI对话 最多的榜单，其中大部分也都是类似的问题

这是因为重新打开CLAUDE.md，AI的记忆就会清空，他不会记录你们对话过的要求

CLAUDE.md 可以解决上述问题，CLAUDE.md 是一个 md文件，可以写各种对AI的要求

CLAUDE.md不止可以解决上述这些问题，它其实是一套AI编程时代的新规范，是AI“入职”新公司的”员工手册”

3.CLAUDE.md 初步介绍

CLAUDE.md 最常见的的位置，会放到这两个地方，一个是项目目录下面的 CLAUDE.md，一个是项目目录下面 .claude 文件夹下的 CLAUDE.md

其实CLAUDE.md的位置摆放一共有11种，都是在什么场景使用，我们中篇详细讲解

虽然每个人的项目不太一样，但是生成的CLAUDE.md 大概有这么几个内容

  • 项目介绍，如：目录介绍，模块介绍，命令介绍

  • 开发规范，如：命名规范，代码风格，Git提交规范

  • 注意事项，如：特别约束，采坑文档

你可能会把上述内容都写到MD文档中，堆砌500行 甚至1000多行的内容，这样其实在我看来是不好的

我更推荐你分开来写，CLAUDE.md文件的内容最好精简到100行以内

借助 CLAUDE.md 支持引用其他文件的特性，我们可以将CLAUDE.md拆分来写

例如下面是我举例的一个拆分文件结构

这是CLAUDE.md 的演示内容（真实内容需要大家业务中自行沉淀）

# CLAUDE.md

本项目请遵循如下规范，并在项目中称呼我为"老公"

# 项目介绍
@/rules/introduction.md

# Git规范
@/rules/git.md

# 采坑文档
@/rules/pitfalls.md

# vercel-react-best-practices React实践Skills
@../.agents/skills/vercel-react-best-practices

# andrej-karpathy-skills 规范
@/rules/karpathy-skills.md

......

4.写CLAUDE.md 的小技巧

技巧一：不要写多余的话，你越简洁清晰，AI越容易理解

技巧二：有的人会在CLAUDE.md中写到，请在后续的对话中用老公来称呼我，这样可以观测到AI是否在长上下文中，不遵守CLAUDE.md中的规范

技巧三：渐进式披露，不要将所有的信息都放到CLAUDE.md中，CLAUDE.md 最好只保持100行

技巧四：不要使用 inti 自动化生成CLAUDE.md，你需要自己花时间去思考

5.GitHub爆火项目介绍：andrej-karpathy-skills

最后我想介绍一个CLAUDE.md领域最火的一个GitHub项目，andrej-karpathy-skills

这是一个：124k star 的 CLAUDE.md 单文件项目，核心只有一个CLAUDE.md文件却能有这么多的Star

开源地址：https://github.com/forrestchang/andrej-karpathy-skills

我将这个单md文件翻译为了中文，我感觉我们可以一起阅读一下，我自己开发CC GUI 的时候，也使用了这个MD文件

# CLAUDE.md

用于减少常见 LLM 编码错误的行为准则。可根据需要与项目特定指令合并使用。

权衡：这些准则更偏向谨慎而不是速度。对于非常简单的任务，请自行判断。

## 1. 写代码前先思考

不要假设。不要掩盖困惑。把权衡说清楚。

在实现之前：

明确说明你的假设。如果不确定，就提问。  
如果存在多种理解方式，把它们列出来，不要默默选择其中一种。  
如果有更简单的方案，要说出来。必要时应提出反对意见。  
如果有不清楚的地方，就停下来。说明哪里令人困惑，然后提问。

## 2. 简单优先

用最少的代码解决问题。不要做 speculative 的东西。

不要实现用户没有要求的功能。  
不要为只用一次的代码抽象。  
不要添加未被要求的“灵活性”或“可配置性”。  
不要为不可能发生的场景添加错误处理。  
如果你写了 200 行，但其实 50 行就能解决，那就重写。  
问问自己：“资深工程师会不会觉得这过度复杂？”如果会，那就简化。

## 3. 精确修改

只改必须改的地方。只清理你自己造成的问题。

编辑现有代码时：

不要顺手“改进”相邻代码、注释或格式。  
不要重构没有坏掉的东西。  
匹配现有风格，即使你自己会用不同方式写。  
如果发现无关的死代码，提出来，但不要删除它。

当你的修改产生了孤立代码时：

删除因你的修改而变成未使用的 import、变量或函数。  
不要删除原本就存在的死代码，除非用户要求。

检验标准：每一行被修改的代码都应该能直接追溯到用户的请求。

## 4. 目标驱动执行

定义成功标准。循环处理，直到验证通过。

把任务转化为可验证的目标：

“添加校验” → “为非法输入写测试，然后让测试通过”  
“修复 bug” → “写一个能复现 bug 的测试，然后让测试通过”  
“重构 X” → “确保重构前后测试都通过”

对于多步骤任务，先给出一个简短计划：

1. [步骤] → 验证：[检查项]
2. [步骤] → 验证：[检查项]
3. [步骤] → 验证：[检查项]

强成功标准能让你独立循环推进。弱标准，比如“让它能用”，会导致不断需要澄清。

如果这些准则有效，你会看到：diff 中不必要的修改更少，因为过度复杂导致的重写更少，澄清问题会发生在实现之前，而不是犯错之后。

内容效果不满意？点此反馈

输入关键词开始搜索