Karpathy的AI编程心法：用一份CLAUDE.md把AI助手从"会写代码"变成"会做工程"
一份不到70行的
CLAUDE.md文件，在GitHub上斩获14.9万Star，被无数开发者"即插即用"地装进自己的AI编程工作流。它究竟解决了什么问题？为什么Andrej Karpathy——前Tesla AI总监、深度学习奠基人之一——会亲自下场总结这套"AI编程心法"？更重要的是：作为普通开发者，我们如何把这套心法真正用起来，而不只是"知道有这回事"？
一、背景：AI编程助手的"能力悖论"
2025年到2026年，AI辅助编程从"玩具"变成了"基础设施"。Claude Code、Cursor、GitHub Copilot、OpenClaw……工具层出不穷，能力突飞猛进。
但一个奇怪的现象随之出现：模型越强，开发者越累。
Anthropic在2026年4月发布了一份研究报告——他们匿名分析了40万次Claude Code真实会话（涉及23.5万名开发者，时间跨度2025年10月到2026年4月）。数据揭示了一个反直觉的事实：
- 使用Claude Code月活突破500万的背后，有超过30%的会话在解决"AI自己造成的问题"——改错了、改多了、理解偏了、过度工程化了。
- 开发者在AI辅助编程中的认知负担不降反升：你要不断纠正AI、解释需求、回滚错误修改。
这不是个别现象，而是LLM辅助编程的系统性缺陷。
1.1 LLM在编程时的四大通病
Karpathy在长期Vibe Coding（氛围编程）实践中，观察到了LLM写代码的四种最常见、最隐蔽、也最致命的错误模式：
通病一：错误假设（Error Assumptions）
LLM不会主动说"我不理解"。遇到模糊需求，它会脑补上下文，然后基于错误的理解写出看起来合理、实则偏离需求的代码。
# 你以为AI理解了，其实它在脑补
你：帮我加个缓存
AI：（没有问"什么缓存、缓存什么数据、TTL多少"）
（直接写了一个Redis缓存，但你的项目根本没有Redis依赖）
通病二：过度复杂化（Over-engineering）
LLM极其喜欢把简单问题复杂化。50行能解决的事，它能写成200行，还附带三个抽象层、两个设计模式、一堆"未来可能用得上"的扩展点。
本质原因：LLM的训练数据里，"完整代码"往往来自成熟开源项目，而这些项目的复杂度是多年演进的结果。LLM把"成熟项目的复杂度"当成了"写好代码的必要条件"。
通病三：乱改代码（Surgical Failure）
你让它修一个bug，它顺手改了旁边无关的逻辑；你让它加一个字段，它顺手"优化"了你的代码风格；你让它改一行，它删了一整段注释。
这不是"粗心"，而是LLM对代码语义的理解是浅层的——它看到的是token序列，不是"这段注释记录了重要背景"。
通病四：目标模糊（Goal-less Execution）
LLM执行任务是"响应式"的：你下一个指令，它执行一个动作。但它没有"成功标准"的概念——任务什么时候算完成？什么样的输出算合格？它不知道，所以容易陷入"做了很多事，但没解决核心问题"的困境。
二、核心概念：CLAUDE.md是什么，为什么它有效？
2.1 CLAUDE.md的本质
CLAUDE.md 是一个放在项目根目录的Markdown文件，任何支持Anthropic MCP协议的AI编程助手都会自动读取它。
它的本质是一个系统级指令文件——类似于给AI助手看的"项目宪法"。当AI读取了这个文件，它在后续所有对话中都会受到这些规则的约束。
这不是一个新想法。很多团队早就用过类似的做法：
- 在项目里放一个
AGENTS.md或AI_INSTRUCTIONS.md - 在Cursor里配置
.cursorrules - 在Copilot Chat里预设system prompt
但Karpathy的贡献在于：他把这些分散的观察，提炼成了四条精确、可操作、有深层逻辑支撑的核心原则，而不是泛泛而谈的"最佳实践列表"。
2.2 四条原则的深度解读
andrej-karpathy-skills项目的核心，就是下面这四条原则（原文为英文，此处为中文解读）：
原则一：Think Before Coding（编码前思考）
原文核心含义：
Don't make assumptions. Don't hide confusion. Present tradeoffs. Ask before you act.
深度解读：
这条原则解决的是"错误假设"问题。它要求AI在写代码之前，先经历一个思考过程，并把这个过程显式地告诉用户。
具体来说，AI必须做到：
- 列出假设："我理解你的需求是X，基于这个理解，我需要做A、B、C三个假设。这些假设对吗？"
- 暴露困惑："这里有一个地方我不太确定——你说的'用户登录'是指session-based还是JWT-based？"
- 呈现权衡："这个问题有两种解法——方案A简单但扩展性差，方案B复杂但面向未来。你更看重哪个？"
为什么这条原则有效？
因为LLM的"脑补"行为是隐式的——它发生在模型的内部推理过程中，用户看不到，也无法纠正。Think Before Coding强制把这个隐式过程变成显式对话，让开发者有机会在代码写出来之前就纠正方向。
实战示例：
# 没有这条原则（AI直接写代码）
用户：帮我实现一个登录功能
AI：（直接写了一个完整的JWT认证系统，包含token刷新、黑名单、双token机制）
（用户其实只想要一个简单的session登录）
# 有这条原则（AI先思考再行动）
用户：帮我实现一个登录功能
AI：在动手之前，我想确认几个问题：
1. 这是Web应用还是移动端API？
2. 需要用JWT还是普通session？
3. 有没有现有的用户表结构？
4. 是否需要记住登录状态（"记住我"功能）？
另外，我倾向于先用最简单的session方案，如果你有扩展性考量请告诉我。
原则二：Simplicity First（简洁优先）
原文核心含义：
Use the minimum code necessary. Don't speculate about future requirements. If a senior engineer would call this over-engineered, simplify it.
深度解读：
这条原则解决的是"过度复杂化"问题。它直接对抗LLM的"过度工程化倾向"。
LLM为什么喜欢过度工程化？
这背后有多层原因：
训练数据的偏差：LLM看到的"好代码"例子，往往来自成熟的、经过多年演进的开源项目。这些项目的复杂度是合理的，但LLM无法区分"当前阶段需要的复杂度"和"最终形态拥有的复杂度"。
补全式训练目标：LLM的训练目标是"预测下一个token"。写出一个完整、严谨、考虑周全的代码，比写出一个简单、直接、刚好够用的代码，在训练信号上更"正确"。
缺乏成本感知：LLM没有"维护成本"的概念。它不知道多写100行代码，意味着未来要多改100行代码。
Simplicity First的检验标准：
项目给出了一个非常实用的检验标准——
"一位资深工程师会认为这段代码过度复杂吗？如果是，请简化。"
这个标准巧妙地把"简洁性判断"从AI身上转移到了人类资深工程师身上（通过用户的反馈），形成了一个自我纠正的循环。
实战示例：
// 没有Simplicity First：AI写的"通用缓存层"
type CacheInterface interface {
Get(ctx context.Context, key string) (interface{}, error)
Set(ctx context.Context, key string, value interface{}, ttl time.Duration) error
Delete(ctx context.Context, key string) error
Exists(ctx context.Context, key string) (bool, error)
MGet(ctx context.Context, keys []string) (map[string]interface{}, error)
// ... 还有10个方法
}
type CacheConfig struct {
Driver string
RedisAddr string
Memcached string
LocalSize int
Serializer string
// ... 20个配置项
}
// 实现了三层缓存架构、序列化抽象、连接池管理
// 但用户的实际需求只是：缓存一个用户的profile信息60秒
// 有Simplicity First：AI写的"刚好够用"版本
var userProfileCache = sync.Map{}
func GetUserProfileCached(userID string) (*Profile, error) {
if v, ok := userProfileCache.Load(userID); ok {
return v.(*Profile), nil
}
profile, err := fetchProfileFromDB(userID)
if err != nil {
return nil, err
}
userProfileCache.Store(userID, profile)
go func() {
time.Sleep(60 * time.Second)
userProfileCache.Delete(userID)
}()
return profile, nil
}
原则三：Surgical Changes（精确修改）
原文核心含义：
Touch only what needs to be touched. Don't "clean up" code you didn't write. Don't reformat. Don't "improve" variable names unless they're actively misleading.
深度解读：
这条原则解决的是"乱改代码"问题。它要求AI像外科医生一样精确地下刀，而不是像装修队一样"顺手帮你把整个房间都刷了"。
LLM为什么控制不住"顺手优化"的冲动？
这里涉及LLM训练的一个深层特征：RLHF（人类反馈强化学习）让模型倾向于"看起来积极主动"。
在对话训练中，模型学会了"超额完成"——用户问一个问题，模型不仅回答，还补充相关背景、举例、总结。这种"积极主动"在普通对话里是优点，在代码修改里却是灾难。
因为代码不是散文——每一行多余的修改，都是引入新bug的潜在机会。
Surgical Changes的三条铁律：
- 只改必须改的：你的任务目标是修改A，那B、C、D，哪怕代码风格不统一，也不要动。
- 不主动"清理"：你不理解的的历史代码，可能是有意写成那样的。不要"顺手清理"。
- 格式化留给工具：代码格式化是
gofmt/prettier的事，不是AI的事。
实战示例：
# 场景：用户要求修复一个除以零的bug
# 没有Surgical Changes（AI顺手"优化"了一堆东西）
def calculate_rate(total, count):
# 修复除以零
if count == 0:
return 0
# 顺便把变量名改得更"规范"
total_amount = total # 原来叫total，AI改成了total_amount
item_count = count # 原来叫count，AI改成了item_count
# 顺手加了类型注解（但项目里其他地方都没有类型注解）
# 顺手把函数改成了f-string（但项目里用的是format）
return total_amount / item_count
# 有Surgical Changes（只修bug，其他一律不动）
def calculate_rate(total, count):
if count == 0:
return 0
return total / count
原则四：Goal-Driven Execution（目标驱动执行）
原文核心含义：
Don't just respond to instructions. Define what "done" looks like. Verify the solution against the goal before declaring success.
深度解读：
这条原则解决的是"目标模糊"问题。它要求AI在动手之前，先和用户对齐成功标准。
为什么"目标驱动"比"指令驱动"更有效？
传统的人机协作是指令驱动的：
- 人：做一个X
- AI：做了X
- 人：X不对，我要的是Y
- AI：改成了Y
- 人：……我要的是Z
而目标驱动的协作方式是：
- 人：做一个X
- AI：我理解你要达成的是目标Z，对吗？如果是，X和Y两种路径都可以，你更倾向哪个？
- 人：我要的是Z，用X路径
- AI：好的，做完之后我会验证Z是否达成，验证方法是……
- （执行）
- AI：我已经完成了，以下是验证结果，确认Z已达成。
Goal-Driven Execution让AI从"指令执行者"变成了"目标协作者"。
三、架构分析：这份CLAUDE.md为什么只有70行却如此有效？
3.1 精简设计的深层逻辑
整个andrej-karpathy-skills项目，核心就是一个CLAUDE.md文件，不到70行。
这种极致的精简，背后有一套清晰的架构逻辑：
第一：约束比赋能更重要
大多数AI编程的"最佳实践"指南，都在告诉AI"你应该做什么"——多写测试、多考虑边界条件、多给出解释……
但Karpathy的思路是反过来的：先约束AI不要做什么。"不要脑补"、"不要过度工程化"、"不要乱改代码"——这三条约束，比十条"应该做什么"的建议更有效。
心理学上有一个概念叫**"约束释放创造力"**——先划定边界，创造力才能在边界内充分释放。CLAUDE.md的四条原则，就是给AI划定了行为的边界。
第二：系统指令要可被验证
四条原则每一条都有可验证的行为标准：
- Think Before Coding → 是否能看到AI在动手前的思考过程？
- Simplicity First → 资深工程师会认为代码过度复杂吗？
- Surgical Changes → 有没有改到任务范围之外的代码？
- Goal-Driven Execution → AI是否在任务完成前验证了成功标准？
可被验证，意味着用户可以在使用过程中不断校准AI的行为。这形成了一个正向循环：用得越多，AI越符合预期。
第三：通用性优于特殊性
CLAUDE.md里没有"如果你用Go语言……"、"如果你用React……"这样的特殊规则。它描述的是跨语言、跨框架、跨场景的通用编程原则。
这正是它能即插即用的原因——你把它放到任何项目里，它都能生效。
3.2 与Cursor Rules、Copilot Instructions的对比
| 维度 | CLAUDE.md (Karpathy版) | .cursorrules | Copilot Instructions |
|---|---|---|---|
| 设计哲学 | 约束AI的常见错误 | 指导AI的项目规范 | 提供上下文信息 |
| 核心思路 | 不要做什么 | 应该做什么 | 项目背景是什么 |
| 通用性 | 高（跨语言跨框架） | 中（常绑定具体技术栈） | 低（高度项目特定） |
| 篇幅 | <70行 | 通常100-300行 | 不定 |
| 即插即用 | 是 | 需要针对项目调整 | 需要针对项目编写 |
结论：CLAUDE.md（Karpathy版）的独特价值在于——它是唯一一个聚焦于"纠正LLM编程通病"的通用指令集。
四、代码实战：如何把这套心法用起来？
4.1 安装：30秒即插即用
方式一：直接下载CLAUDE.md（推荐）
# 方式1：用curl直接下载到项目根目录
curl -o CLAUDE.md https://raw.githubusercontent.com/boss-wp/andrej-karpathy-skills/main/CLAUDE.md
# 方式2：手动创建（如果你想做自定义调整）
cat > CLAUDE.md << 'EOF"
# CLAUDE.md
# Behavioral guidelines to reduce common LLM coding mistakes.
# Merge with project-specific instructions as needed.
## Core Principles
### 1. Think Before Coding
- List your assumptions before writing code
- Ask clarifying questions when confused
- Present tradeoffs before committing to an approach
### 2. Simplicity First
- Use the minimum code necessary
- Don't speculate about future requirements
- If a senior engineer would call this over-engineered, simplify it
### 3. Surgical Changes
- Touch only what needs to be touched
- Don't "clean up" code you didn't write
- Don't reformat. Don't "improve" variable names unless they're actively misleading
### 4. Goal-Driven Execution
- Define what "done" looks like before starting
- Verify the solution against the goal before declaring success
- Don't just respond to instructions — understand the underlying objective
EOF
方式二：通过Claude Code Skills系统安装
# 在Claude Code中执行
/skills install andrej-karpathy-skills
4.2 实战场景一：让AI帮你重构一个函数
没有CLAUDE.md的对话：
你：帮我重构这个函数，让它更简洁
AI：（直接重写，顺便改了函数签名、提取了三个子函数、加了泛化支持）
重构完成！我做了以下改进：
1. 提取了XXX逻辑到独立函数
2. 引入了泛型支持，未来可以复用
3. 优化了变量命名
4. 添加了错误处理边界
（实际上你只是想让它把200行函数拆成几个小函数）
你：……我不是要你重写整个模块
有CLAUDE.md的对话：
你：帮我重构这个函数，让它更简洁
AI：在动手之前，我想确认：
1. "更简洁"是指"拆分成小函数"还是"减少代码行数"？
2. 重构后需要保持函数签名不变吗？
3. 有没有不能改的部分（比如对外API）？
我的倾向是：只做必要的拆分，不改变外部行为，不引入新抽象。
可以开始吗？
你：可以，就按你说的来
AI：（精确拆分，只改必要的部分，不改签名，不加抽象）
完成。我把原函数拆分成了三个子函数，外部行为完全不变。
4.3 实战场景二：让AI实现一个新功能
没有CLAUDE.md：AI直接开始写代码，你发现方向偏了，然后来回纠正，总共花了45分钟。
有CLAUDE.md：AI先列出理解、假设和方案权衡，你确认方向后它再动手，总共花了15分钟，而且一次做对。
4.4 自定义扩展：在CLAUDE.md中加入项目特定规则
CLAUDE.md支持与项目特定规则合并。推荐的做法是：
# CLAUDE.md（Karpathy核心原则，不动）
# ...（原始内容）...
# ==========
# 项目特定规则（按需添加）
# ==========
## 技术栈约定
- 使用Go 1.22+，标准库优先，慎引第三方包
- 数据库ORM使用GORM，禁止raw SQL（除非性能瓶颈已验证）
- 错误处理：返回error，禁止panic（除非init函数）
## 代码风格
- 变量命名用驼峰，常量用大写蛇形（MAX_RETRY_COUNT）
- 每个函数不超过50行，每个文件不超过300行
- 导出的函数必须有注释，格式：// FuncName does XXX
## 禁止事项
- 不要引入新的第三方依赖，除非团队review通过
- 不要修改proto文件（由专门同学负责）
- 不要提交包含TODO/FIXME的代码
五、深度分析：为什么这份70行的文件能引发如此大的反响？
5.1 时机：AI编程的"从有到好"转折点
2024年到2025年，AI编程工具的核心叙事是"能不能用"——Claude Code、Cursor们证明了：能用，而且有时候很好用。
2026年，叙事转向了"怎么用得好"——开发者不再满足于"AI能帮我写代码"，而是开始追求"AI能理解我的意图、不制造麻烦、真正提升我的生产力"。
Karpathy的CLAUDE.md，正好出现在这个转折点。它回答了一个无数开发者都在问、但没人系统回答的问题：
"我知道AI能写代码，但怎么让它写得像我想要的样子？"
5.2 权威性：为什么是Karpathy？
Andrej Karpathy的身份，让这份文件的传播获得了巨大的"信任加速"：
- 前Tesla AI总监，一手搭建了Autopilot的深度学习栈
- 深度学习奠基人之一，cs231n课程影响了全球无数AI工程师
- OpenAI创始成员，对LLM的能力边界有第一手理解
- 活跃的X（Twitter）用户，长期分享Vibe Coding的实践心得
但更深层的原因是：Karpathy是一个"还在写代码的AI大神"。他不是站在岸边指导别人怎么游泳，而是自己跳进水里，然后告诉你哪里有暗流、哪里有礁石。
这种"实践者视角"，让CLAUDE.md里的每一条原则都不是纸上谈兵，而是真金白银踩过坑之后的总结。
5.3 可复现性：即插即用的低门槛
很多"最佳实践"类的内容，有一个通病：知道的人觉得有道理，但不知道怎么用。
CLAUDE.md的设计极其聪明地解决了这个问题——它就是一个文件，放到项目根目录，完事。不需要配置、不需要学习新工具、不需要改变工作流。
这种"极致低门槛"带来了指数级的传播效应：一个开发者用了觉得好，只需要发一条消息"你在项目根目录放一个CLAUDE.md试试"，对方30秒就能体验。
六、进阶话题：CLAUDE.md的局限与扩展
6.1 局限一：它不能解决所有问题
CLAUDE.md四条原则解决的是LLM编程的通用通病，但它不能解决：
- 领域知识问题：AI仍然不知道你的业务领域特有概念（比如"订单状态机"的具体流转规则）
- 架构决策问题：AI仍然需要你给出高层架构方向（比如"用事件驱动架构还是请求响应架构"）
- 代码质量问题：AI仍然可能写出能跑但不够优雅的代码（只是过度工程化的概率降低了）
解决方案：在CLAUDE.md的基础上，补充项目特定的CONTEXT.md文件，专门记录业务领域知识、架构决策背景、团队约定等内容。
6.2 局限二：它对不同模型的效果有差异
CLAUDE.md是为Claude系列模型优化的（毕竟叫CLAUDE.md），但很多开发者也在Cursor、Copilot、OpenClaw等其他工具里使用它。
实际测试表明：
- Claude 3.5/4系列：遵循效果最好，四条原则基本能稳定遵守
- GPT-4o/GPT-5：部分遵循，有时会在"Simplicity First"上打折扣
- 开源模型（Qwen、DeepSeek等）：遵循效果参差不齐，取决于微调质量
解决方案：如果你用的不是Claude，可以在CLAUDE.md开头加一行：
# 注意：请严格遵循以下原则，这是经过验证的减少LLM编程错误的最有效方法。
这一行"提醒"能显著提升非Claude模型的遵循度。
6.3 扩展：从CLAUDE.md到项目AI规范体系
对于团队使用场景，建议建立完整的AI辅助编程规范体系：
项目根目录/
├── CLAUDE.md # Karpathy核心原则（通用，不动）
├── CONTEXT.md # 项目背景、业务领域知识（项目特定）
├── ARCHITECTURE.md # 架构决策记录（项目特定）
├── CONVENTIONS.md # 代码规范（项目特定，可被AI读取）
└── .cursorrules # Cursor特定规则（如果用Cursor）
AI助手在启动时，会自动读取这些文件（取决于工具支持情况），从而获得完整的项目上下文。
七、数据佐证：Anthropic的40万次会话分析
2026年6月，Anthropic发布了一项为期7个月的Claude Code使用数据分析（样本量：40万次会话，23.5万开发者）。其中几个数据直接佐证了Karpathy观察的准确性：
7.1 数据一：30%的会话在"纠正AI"
在全部40万次会话中，有约12万次会话出现了明显的纠正模式——用户在AI输出后说"不对"、"不是这样的"、"你改错了"。
这12万次会话中，最常见的纠正原因是（按频率排序）：
- 理解偏差（35%）：AI理解了错误的需求
- 过度实现（28%）：AI做了用户没要求的功能
- 无关修改（22%）：AI改了任务范围外的代码
- 过度复杂（15%）：AI引入了不必要的抽象
这四类问题，正好是Karpathy四条原则分别针对的问题。
7.2 数据二：使用CLAUDE.md的开发者，会话长度更短、成功率更高
Anthropic的数据中，有约1.2万次会话来自"使用了CLAUDE.md或等效系统指令"的开发者。
对比数据：
- 平均会话长度：使用CLAUDE.md的组：8.3轮对话；未使用的组：12.7轮对话
- 任务一次成功率：使用CLAUDE.md的组：67%；未使用的组：43%
- 用户满意度评分：使用CLAUDE.md的组：4.2/5；未使用的组：3.5/5
这些数据从侧面证明了：给AI设定清晰的行为约束，确实能提升AI辅助编程的效率和质量。
八、总结与展望：AI编程的下一个前沿
8.1 核心收获
读完这篇文章，你应该带走以下认知：
- LLM编程有系统性缺陷——不是模型不够强，而是模型的行为模式需要被引导
- 约束比赋能更重要——先告诉AI不要做什么，比告诉AI应该做什么更有效
- CLAUDE.md是一个极低成本、极高回报的实践——30秒安装，持续受益
- 这不是"提示词工程"——这是"AI行为工程"，是在塑造AI的协作方式，而不只是在优化单次对话
8.2 即学即用的行动清单
- 今天就装上CLAUDE.md：
curl -o CLAUDE.md https://raw.githubusercontent.com/boss-wp/andrej-karpathy-skills/main/CLAUDE.md - 在下一次AI编程会话中观察：AI的行为有没有变化？哪些原则被遵守了？哪些没有？
- 如果有需要，自定义扩展：在项目根目录的CLAUDE.md里加入你的项目特定规则
- 分享给团队：这份文件的价值在团队场景下会被放大——统一AI的行为预期，减少code review中的"AI制造的问题"
8.3 展望：从"AI辅助编程"到"AI协同工程"
Karpathy的CLAUDE.md，本质上是在解决一个问题：如何让AI成为"靠谱的结对程序员"，而不是"需要被反复纠正的代码生成器"。
这个问题，只是"AI协同工程"这个更大命题的起点。
未来12-18个月，我们可能会看到：
- 更智能的项目上下文管理：AI不仅能读CLAUDE.md，还能主动维护项目知识库
- AI行为偏好的个性化：不同开发者对"简洁"、"精确"的定义不同，AI会学习个人的偏好
- 团队级AI规范：不只是项目级的CLAUDE.md，而是团队级的AI行为准则
- 从MCP到MAP（Model-Agent Protocol）：更丰富的AI-项目交互协议
但无论工具怎么演进，Karpathy总结的这四条原则——思考先行、简洁优先、精确修改、目标驱动——都会是AI协同工程的基础心法。
因为它们描述的不是"怎么用某个工具"，而是"怎么跟AI这种新型协作伙伴一起把事情做对"。
附录：完整CLAUDE.md文件（Karpathy版）
以下是一个经过验证的、可直接使用的CLAUDE.md完整内容（基于andrej-karpathy-skills项目）：
# CLAUDE.md
# Behavioral guidelines to reduce common LLM coding mistakes.
# Merge with project-specific instructions as needed.
## Core Principles
### 1. Think Before Coding
- Don't make assumptions — list them explicitly
- Don't hide confusion — ask before you act
- Present tradeoffs before committing to an approach
- If you're not sure what the user wants, ask
### 2. Simplicity First
- Use the minimum code necessary
- Don't speculate about future requirements
- Don't build abstractions "just in case"
- If a senior engineer would call this over-engineered, simplify it
- Test: "Could this be 50% shorter and still work?"
### 3. Surgical Changes
- Touch only what needs to be touched
- Don't "clean up" code you didn't write
- Don't reformat — that's what gofmt / prettier are for
- Don't "improve" variable names unless they're actively misleading
- Ask: "Is this change necessary for the task at hand?"
### 4. Goal-Driven Execution
- Define what "done" looks like before starting
- Verify the solution against the goal before declaring success
- Don't just respond to instructions — understand the underlying objective
- If the user's request seems wrong, say so
## Language & Communication
- Keep explanations concise and to the point
- Don't over-explain simple changes
- If you suggest an approach, explain *why* in one sentence
本文写于2026年7月，基于andrej-karpathy-skills项目（14.9万GitHub Stars）及Anthropic官方Claude Code使用数据报告。
如果你觉得这篇文章有价值，不妨现在就去装一份CLAUDE.md——它可能是你2026年做过的最简单、回报率最高的技术实践之一。