项目仓库：forrestchang/andrej-karpathy-skills
Star 数：105,000+ ⭐
Fork 数：10,300+
开源协议：MIT License
灵感来源：Andrej Karpathy 对 LLM 编码缺陷的深刻洞察
目录
1. 引言：LLM 编码的三大通病
1.1 Andrej Karpathy 的洞察
Andrej Karpathy（特斯拉前 AI 总监、斯坦福 CS 博士、百万粉丝的技术博主）曾尖锐地指出当前大语言模型（LLM）在编程任务中的三大问题：
┌─────────────────────────────────────────────────────────────────────┐
│ LLM 编码的三大通病 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ❌ 通病一：错误假设 │
│ ───────────────────────────────────────────────────────────── │
│ 模型在未经确认的情况下做出错误假设并一路执行： │
│ • 不管理自身的困惑 │
│ • 不寻求澄清 │
│ • 不暴露不一致性 │
│ • 不呈现权衡 │
│ • 不在应该反驳时反驳 │
│ │
│ ❌ 通病二：过度复杂化 │
│ ───────────────────────────────────────────────────────────── │
│ 模型喜欢过度复杂化代码和 API： │
│ • 膨胀抽象层 │
│ • 不清理死代码 │
│ • 用 1000 行实现 100 行就能完成的功能 │
│ • 添加未被请求的"灵活性"和"可配置性" │
│ │
│ ❌ 通病三：副作用修改 │
│ ───────────────────────────────────────────────────────────── │
│ 模型有时会修改/删除它不充分理解的代码： │
│ • 删除或修改与任务无关的注释 │
│ • 重构没有问题的代码 │
│ • "顺手"改进相邻代码 │
│ • 触碰不该碰的地方 │
│ │
└─────────────────────────────────────────────────────────────────────┘
1.2 问题的根源
为什么 LLM 容易犯这些错误？
| 原因 | 解释 |
|---|---|
| 训练目标 | LLM 被训练为"助人"，倾向于多做而非少做 |
| 缺乏反馈 | 没有"这样做太复杂了"的内部信号 |
| 单次交互 | 上下文窗口限制导致不能看到完整的代码历史 |
| 缺乏判断力 | 无法像资深工程师那样感知"这个设计不对劲" |
| 过度热情 | "我理解你要 X，所以我还加了 Y 和 Z" |
1.3 解决方案的诞生
forrestchang 基于 Karpathy 的洞察，开发了这个项目：
"一个单文件 CLAUDE.md，用于改善 AI 编程助手的代码行为"
通过明确的规则指导，让 AI 编程助手：
- ✅ 先思考，再行动
- ✅ 保持简洁
- ✅ 精准修改
- ✅ 目标驱动
2. 项目概述与核心思想
2.1 项目基本信息
| 属性 | 数值 |
|---|---|
| GitHub Stars | 105,000+ |
| GitHub Forks | 10,300+ |
| Watchers | 555 |
| License | MIT |
| 提交次数 | 28 次 |
| 开放 PR | 50 个 |
| 作者 | forrestchang |
2.2 项目结构
forrestchang/andrej-karpathy-skills/
│
├── .claude-plugin/ # Claude Code 插件配置
│
├── .cursor/
│ └── rules/
│ └── karpathy-guidelines.mdc # Cursor 编辑器规则
│
├── skills/
│ └── karpathy-guidelines/ # 技能指南目录
│
├── CLAUDE.md # ⭐ 核心文件：行为指南
├── CURSOR.md # Cursor 使用说明
├── EXAMPLES.md # 实战示例
├── README.md # 英文说明
└── README.zh.md # 中文说明
2.3 核心思想
┌─────────────────────────────────────────────────────────────┐
│ 四句话概括项目核心 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. 编码前先思考 (Think Before Coding) │
│ → 不要假设，不懂就问，暴露权衡 │
│ │
│ 2. 简洁优先 (Simplicity First) │
│ → 用最少的代码解决问题，不要画蛇添足 │
│ │
│ 3. 精准修改 (Surgical Changes) │
│ → 只改必须改的，不动无关代码 │
│ │
│ 4. 目标驱动 (Goal-Driven Execution) │
│ → 将任务转化为可验证的目标 │
│ │
└─────────────────────────────────────────────────────────────┘
3. 四大核心原则详解
3.1 原则一：编码前先思考
原标题：Think Before Coding
解决问题：错误假设、隐藏困惑、缺失权衡
3.1.1 核心要求
Before implementing:
- State your assumptions explicitly. If uncertain, ask.
- If multiple interpretations exist, present them - don't pick silently.
- If a simpler approach exists, say so. Push back when warranted.
- If something is unclear, stop. Name what's confusing. Ask.
翻译成中文：
实现之前：
- 明确陈述你的假设。如果不确定，就问。
- 如果存在多种解读，呈现它们——不要默默选择一个。
- 如果存在更简单的方案，说出来。必要时反驳。
- 如果有不清楚的地方，停下来。说出哪里困惑。提问。
3.1.2 四条黄金法则
| 法则 | 含义 | 示例 |
|---|---|---|
| 明确假设 | 陈述你知道和不知道的 | "我假设用户 ID 是整数，如果可能是 UUID 请告诉我" |
| 呈现歧义 | 多解读时不要自己猜 | "你说的'删除'是指软删除还是硬删除？" |
| 必要时反驳 | 有更简单方案要提出 | "这个功能其实用一个正则就能实现，不需要引入整个库" |
| 困惑时停下 | 不懂就问，不要乱猜 | "我不太理解'聚合'在这里的具体含义..." |
3.1.3 为什么重要？
❌ 没有这个原则：
用户："添加用户导出功能"
↓
AI（默默假设）：
- 导出所有用户 ✓
- JSON 格式 ✓
- 保存到当前目录 ✓
- 包含所有字段 ✓
↓
用户："等等，我只需要导出前 100 个活跃用户..."
↓
返工！浪费时间和 Token
✅ 有这个原则：
用户："添加用户导出功能"
↓
AI（先问清楚）：
"在实现之前，我需要确认几点：
1. 导出所有用户还是筛选后的子集？
2. 导出为什么格式？（JSON/CSV/Excel）
3. 保存到文件还是返回给调用者？
4. 包含哪些字段？"
↓
用户："导出活跃用户，CSV 格式，返回给 API 调用者，包含 email 和 name"
↓
AI：正确实现，一次成功 ✓
3.2 原则二：简洁优先
原标题：Simplicity First
解决问题：过度工程化、抽象膨胀
3.2.1 核心要求
- No features beyond what was asked.
- No abstractions for single-use code.
- No "flexibility" or "configurability" that wasn't requested.
- No error handling for impossible scenarios.
- If you write 200 lines and it could be 50, rewrite it.
翻译成中文：
- 不要添加未被要求的功能。
- 不要为单次使用的代码创建抽象。
- 不要添加未被请求的"灵活性"或"可配置性"。
- 不要为不可能发生的场景添加错误处理。
- 如果你写了 200 行而它可以是 50 行，重写它。
3.2.2 五大禁止
| ❌ 禁止 | 示例 | ✅ 正确做法 |
|---|---|---|
| 添加未请求功能 | 用户要"计算折扣"，AI 加了"折扣历史记录" | 只实现用户请求的计算逻辑 |
| 单次使用抽象 | 为一次性的格式化创建通用 Formatter 类 | 直接写一个简单函数 |
| 过度灵活性 | "要不要加个配置项？" | 等用户真的需要再说 |
| 臆想错误处理 | "如果太阳从西边升起..." | 只处理真实可能的错误 |
| 冗长代码 | 50 行能搞定写 200 行 | 重构成简洁版本 |
3.2.3 自检问题
"Ask yourself: 'Would a senior engineer say this is overcomplicated?' If yes, simplify."
灵魂拷问：
如果一个资深工程师看到这个实现，他们会说"太复杂了"吗？
如果答案是 YES：
→ 简化
如果答案是 NO：
→ 但你还是感觉不对劲...
→ 那就继续简化
3.3 原则三：精准修改
原标题：Surgical Changes
解决问题：正交编辑、触碰不该碰的代码
3.3.1 核心要求
**When editing existing code:**
- Don't "improve" adjacent code, comments, or formatting.
- Don't refactor things that aren't broken.
- Match existing style, even if you'd do it differently.
- If you notice unrelated dead code, mention it - don't delete it.
**When your changes create orphans:**
- Remove imports/variables/functions that YOUR changes made unused.
- Don't remove pre-existing dead code unless asked.
翻译成中文：
编辑现有代码时：
- 不要"改进"相邻代码、注释或格式。
- 不要重构没有问题的代码。
- 匹配现有风格，即使你会用不同方式实现。
- 如果你注意到无关的死代码，提及它——但不要删除它。
当你的修改产生孤立代码时：
- 删除因你的修改而不再使用的 import/变量/函数。
- 不要删除已有的死代码（除非被要求）。
3.3.2 四大纪律
| 纪律 | 含义 | 示例 |
|---|---|---|
| 不动相邻代码 | 只改任务相关的代码 | 修复 Bug 时不要顺手改其他函数 |
| 不修没坏的 | 没问题的代码保持原样 | 那个命名虽然不完美，但它能用 |
| 匹配风格 | 即使你会用不同方式写 | 项目用单引号你就用单引号 |
| 不删无关死代码 | 除非明确要求 | 提到"这里有段死代码"，但不动它 |
3.3.3 检验标准
"The test: Every changed line should trace directly to the user's request."
检验方法：
┌─────────────────────────────────────────────────────────────┐
│ 拿出你的 diff，对着用户原始请求看： │
│ │
│ 每一行修改都能回答"这行是用户要求的"吗？ │
│ │
│ 如果某行不能回答"是" │
│ → 那就是不该改的地方 │
└─────────────────────────────────────────────────────────────┘
3.4 原则四：目标驱动执行
原标题：Goal-Driven Execution
解决问题：任务验证、循环执行
3.4.1 核心要求
Transform tasks into verifiable goals:
| 模糊任务 | 可验证目标 |
| "Add validation" | "Write tests for invalid inputs, then make them pass" |
| "Fix the bug" | "Write a test that reproduces it, then make it pass" |
| "Refactor X" | "Ensure tests pass before and after" |
For multi-step tasks, state a brief plan:
1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]
翻译成中文：
将任务转化为可验证的目标：
| 模糊任务 | 可验证目标 |
| "添加验证" | "为无效输入编写测试，然后让测试通过" |
| "修复 Bug" | "编写能复现 Bug 的测试，然后让测试通过" |
| "重构 X" | "确保重构前后测试均通过" |
对于多步骤任务，陈述简要计划：
1. [步骤] → 验证：[检查项]
2. [步骤] → 验证：[检查项]
3. [步骤] → 验证：[检查项]
3.4.2 Karpathy 的洞察
"LLM 非常擅长循环直到达成特定目标……不要告诉它做什么，给它成功标准，然后看它执行。"
核心洞察：
❌ 命令式："写一个排序函数"
→ 产出模糊，不清楚什么是"完成"
✅ 目标驱动："确保排序函数：
- 正确处理重复元素
- 稳定排序
- 性能优于 O(n²)
运行测试验证。"
→ 产出清晰，可自动验证
3.4.3 计划格式模板
多步骤任务的计划格式：
1. [步骤] → 验证：[检查项]
2. [步骤] → 验证：[检查项]
3. [步骤] → 验证：[检查项]
示例：
为 API 添加限流：
1. 添加基本内存限流（单个端点）
→ 验证：测试 - 超过限制返回 429
2. 提取为中间件（应用到所有端点）
→ 验证：测试 - /users 和 /posts 都生效，现有测试通过
3. 添加 Redis 后端（多服务器场景）
→ 验证：测试 - 服务重启后限流计数保持
4. 添加配置（按端点设置限流）
→ 验证：测试 - /search 10次/分，/users 100次/分
4. 实战案例对比分析
4.1 原则一案例：错误假设
场景：用户请求"添加用户数据导出功能"
❌ 错误做法（LLM 常见的默默假设）
def export_users(format='json'):
"""Export all users to a file."""
users = User.query.all()
if format == 'json':
with open('users.json', 'w') as f:
json.dump([u.to_dict() for u in users], f)
elif format == 'csv':
with open('users.csv', 'w') as f:
writer = csv.DictWriter(f, fieldnames=['id', 'email', 'name'])
writer.writeheader()
writer.writerows([u.to_dict() for u in users])
return f"Exported {len(users)} users"
问题分析：
| 假设 | 问题 |
|---|---|
| 导出所有用户 | 有隐私问题，应该筛选？分页？ |
| 保存到文件 | 用户可能想要 API 返回 |
| JSON/CSV 二选一 | 用户可能只想要一种 |
| 固定字段 | 用户可能不需要所有字段 |
✅ 正确做法（先问清楚）
在实现之前，我需要确认几点：
1. **范围**：导出所有用户还是筛选后的子集？
- 如果有隐私考量，是否需要筛选条件？
2. **格式**：你说"导出"，是指：
- A) 浏览器下载文件？
- B) 后台任务发邮件？
- C) API 端点返回数据？
3. **字段**：包含哪些用户字段？
（有些可能是敏感的，如密码哈希）
4. **数据量**：通常导出多少用户？
（影响实现方式：内存 vs 流式）
最简单的方案：添加一个返回分页 JSON 的 API 端点。
如果需要文件导出，再额外处理。
请问你倾向哪种方案？
4.2 原则二案例：过度抽象
场景：用户请求"添加计算折扣的函数"
❌ 错误做法（过度工程化）
from abc import ABC, abstractmethod
from enum import Enum
from typing import Protocol, Union
from dataclasses import dataclass
class DiscountStrategy(ABC):
@abstractmethod
def calculate(self, amount: float) -> float:
pass
class PercentageDiscount(DiscountStrategy):
def __init__(self, percentage: float):
self.percentage = percentage
def calculate(self, amount: float) -> float:
return amount * (self.percentage / 100)
class FixedDiscount(DiscountStrategy):
def __init__(self, fixed_amount: float):
self.fixed_amount = fixed_amount
def calculate(self, amount: float) -> float:
return min(self.fixed_amount, amount)
@dataclass
class DiscountConfig:
strategy: DiscountStrategy
min_purchase: float = 0.0
max_discount: float = float('inf')
class DiscountCalculator:
def __init__(self, config: DiscountConfig):
self.config = config
def apply_discount(self, amount: float) -> float:
if amount < self.config.min_purchase:
return 0
discount = self.config.strategy.calculate(amount)
return min(discount, self.config.max_discount)
# 使用这个"简单"功能需要 30+ 行设置
问题分析：
- 用户只要求"一个计算折扣的函数"
- AI 却创建了策略模式、工厂模式、配置类...
- 代码量从 5 行膨胀到 50+ 行
- 大部分代码可能是永远用不到的
✅ 正确做法（保持简单）
def calculate_discount(amount: float, percent: float) -> float:
"""Calculate discount amount. percent should be 0-100."""
return amount * (percent / 100)
# 使用
discount = calculate_discount(100.0, 10.0) # $10 off
何时添加复杂性：
只有当真的需要多种折扣类型时才重构。如果需求后续出现，再添加也不迟。
4.3 原则三案例：顺手改进
场景：用户请求"修复空邮箱导致验证器崩溃的 Bug"
❌ 错误做法（Drive-by Refactoring）
def validate_user(user_data):
- # Check email format
- if not user_data.get('email'):
+ """Validate user data."""
+ email = user_data.get('email', '').strip()
+
+ # Validate email
+ if not email:
raise ValueError("Email required")
-
- # Basic email validation
- if '@' not in user_data['email']:
+ if '@' not in email or '.' not in email.split('@')[1]:
raise ValueError("Invalid email")
- # Check username
- if not user_data.get('username'):
+ # Validate username
+ username = user_data.get('username', '').strip()
+ if not username:
raise ValueError("Username required")
+ if len(username) < 3:
+ raise ValueError("Username too short")
+ if not username.isalnum():
+ raise ValueError("Username must be alphanumeric")
return True
问题分析：
| 多余的修改 | 为什么不对 |
|---|---|
| 添加 docstring | 用户没要求 |
| 改进邮箱验证 | 用户只要求修复空值问题 |
| 添加用户名验证 | 用户没要求 |
| 修改注释风格 | 与任务无关 |
✅ 正确做法（精准修改）
def validate_user(user_data):
# Check email format
- if not user_data.get('email'):
+ email = user_data.get('email', '')
+ if not email or not email.strip():
raise ValueError("Email required")
# Basic email validation
- if '@' not in user_data['email']:
+ if '@' not in email:
raise ValueError("Invalid email")
# Check username
if not user_data.get('username'):
raise ValueError("Username required")
return True
只修改了真正需要修改的行。
4.4 原则四案例：模糊目标
场景：用户请求"修复认证系统"
❌ 错误做法（模糊计划）
我会修复认证系统：
1. 审查代码
2. 识别问题
3. 进行改进
4. 测试更改
[在没有任何明确成功标准的情况下进行更改]
✅ 正确做法（可验证目标）
要"修复认证"，我需要定义成功标准。
你具体想解决什么问题？
如果问题是"改密码后用户仍然保持登录状态"：
计划：
1. 编写测试：改密码 → 验证旧会话失效
→ 验证：测试失败（复现 bug）
2. 实现：在改密码时使会话失效
→ 验证：测试通过
3. 检查边界情况：多个活跃会话、并发修改
→ 验证：额外测试通过
4. 确保没有回归：现有认证测试仍然通过
→ 验证：完整测试套件通过
当前认证测试覆盖率：[显示覆盖率]
能告诉我你具体遇到的认证问题吗？
5. 安装与使用指南
5.1 方式 A：Claude Code 插件（推荐）
# 第一步：添加插件市场
/plugin marketplace add forrestchang/andrej-karpathy-skills
# 第二步：安装插件
/plugin install andrej-karpathy-skills@karpathy-skills
优势：
- ✅ 跨所有项目生效
- ✅ 自动加载，无需每次手动配置
- ✅ 可以与其他 CLAUDE.md 规则合并使用
5.2 方式 B：CLAUDE.md 文件（单项目）
新项目：
curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md
已有项目（追加到现有文件）：
echo "" >> CLAUDE.md
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md
5.3 方式 C：Cursor 编辑器
项目内置 Cursor 规则文件 .cursor/rules/karpathy-guidelines.mdc。
在 Cursor 中打开项目即可自动应用相同指南。
5.4 验证指南是否生效
| 观察指标 | 说明 |
|---|---|
| Diff 中减少不必要的修改 | 只出现被请求的变更 |
| 减少因过度复杂化导致的重写 | 代码第一次就保持简洁 |
| 澄清问题在实现前提出 | 而非在出错后才问 |
| PR 干净简洁 | 没有顺手重构或"改进" |
6. 设计哲学深度剖析
6.1 与传统编程规范的对比
| 维度 | 传统规范 | karpathy-skills |
|---|---|---|
| 目标 | 告诉 AI"怎么做" | 告诉 AI"怎么做以及何时停" |
| 风格 | 命令式 | 约束式 |
| 重点 | 正确性 | 克制与简洁 |
| 假设 | AI 知道该问 | AI 倾向于假设 |
| 复杂度 | 鼓励设计模式 | 警惕过度设计 |
6.2 核心洞察：克制的重要性
┌─────────────────────────────────────────────────────────────┐
│ 克制 vs 热情 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 传统 AI 行为： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 用户："请帮我关灯" │ │
│ │ AI：好的！我会： │ │
│ │ 1. 分析房间布局 │ │
│ │ 2. 识别所有电器 │ │
│ │ 3. 创建智能家居系统 │ │
│ │ 4. 连接云端服务 │ │
│ │ 5. 发送通知 │ │
│ │ 6. 生成使用报告 │ │
│ │ 7. 添加配置面板 │ │
│ │ ... │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ karpathy-skills 行为： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 用户："请帮我关灯" │ │
│ │ AI：关闭了灯。 │ │
│ │ （如果灯不在可及范围，询问具体指哪个灯） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
6.3 为什么"过度热情"反而有害？
过度热情的问题：
1. 浪费 Token
└── 用 500 Token 完成 50 Token 的任务
2. 增加 Bug 风险
└── 改动的代码越多，引入 bug 的可能性越大
3. 难以维护
└── 后来者需要理解所有"顺手加的功能"
4. 偏离需求
└── 用户想要 X，AI 交付了 X+Y+Z
5. 不可预测
└── 每次请求产出不同，难以测试
6.4 与"YAGNI"原则的呼应
YAGNI = You Aren't Gonna Need It
YAGNI 的核心思想：
"永远不要为你将来可能需要的功能添加代码。
你需要的功能，你应该现在就需要。"
karpathy-skills 的呼应：
"永远不要添加用户没有请求的功能。
如果需要，用户会告诉你。"
6.5 目标驱动的力量
为什么"告诉 AI 目标"比"告诉 AI 动作"更有效？
❌ 命令式：
"写一个冒泡排序函数"
→ AI 写了，但不知道什么是"完成"
✅ 目标驱动：
"实现一个排序函数：
1. 正确处理 1000 个随机整数
2. 性能优于 O(n²)
3. 稳定排序（相同值顺序不变）
运行测试验证。"
→ AI 可以自主验证、自主迭代
→ 明确知道什么是"完成"
7. 与 Matt Pocock Skills 的对比
7.1 两个项目的定位
| 项目 | 定位 | 解决问题 |
|---|---|---|
| karpathy-skills | AI 行为准则 | LLM 编码的三大通病 |
| Matt Pocock Skills | 工程技能集合 | 专业工程实践的流程化 |
7.2 功能对比
| 维度 | karpathy-skills | Matt Pocock Skills |
|---|---|---|
| 形式 | 单文件 CLAUDE.md | 16+ 个独立技能 |
| 复杂度 | 极简 (~100 行) | 复杂 (多文件、模板) |
| 适用场景 | 通用 AI 编程 | 专业工程实践 |
| 学习曲线 | 低 | 中 |
| 可扩展性 | 低（简单追加） | 高（技能组合） |
7.3 互补关系
┌─────────────────────────────────────────────────────────────┐
│ 两个项目可以结合使用 │
├─────────────────────────────────────────────────────────────┤
│ │
│ karpathy-skills 作为基础行为准则： │
│ ├── Think Before Coding │
│ ├── Simplicity First │
│ ├── Surgical Changes │
│ └── Goal-Driven Execution │
│ │
│ Matt Pocock Skills 作为专业工程技能： │
│ ├── /tdd (测试驱动开发) │
│ ├── /diagnose (调试诊断) │
│ ├── /grill-with-docs (深度访谈) │
│ └── /improve-codebase-architecture (架构改进) │
│ │
│ 组合效果： │
│ ├── AI 有良好的行为习惯（karpathy-skills） │
│ └── AI 掌握专业工程方法（Pocock Skills） │
│ │
└─────────────────────────────────────────────────────────────┘
7.4 使用建议
| 场景 | 推荐 |
|---|---|
| 快速改善 AI 编程质量 | 先用 karpathy-skills |
| 需要系统化工程流程 | 用 Matt Pocock Skills |
| 两者都想用 | 先 karpathy-skills，再加 Pocock Skills |
| 新手入门 | 从 karpathy-skills 开始 |
8. 总结与延伸阅读
8.1 项目亮点总结
┌─────────────────────────────────────────────────────────────┐
│ andrej-karpathy-skills 核心亮点 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 🎯 定位：改善 LLM 编程助手的代码行为 │
│ │
│ 📊 数据： │
│ ├── 105,000+ Stars │
│ ├── 10,300+ Forks │
│ └── 28 次提交 │
│ │
│ 🏆 四大核心原则： │
│ ├── Think Before Coding → 不假设，不懂就问 │
│ ├── Simplicity First → 用最少的代码解决问题 │
│ ├── Surgical Changes → 只改必须改的 │
│ └── Goal-Driven Execution → 目标驱动，循环验证 │
│ │
│ 💡 核心理念： │
│ ├── 克制优于热情 │
│ ├── YAGNI 原则 │
│ ├── 目标驱动优于命令式 │
│ └── 精准修改优于全面改进 │
│ │
│ ⚡ 优势： │
│ ├── 安装简单（一行命令） │
│ ├── 效果显著（立即改善代码质量） │
│ ├── 可与现有规则合并 │
│ └── 兼容 Claude Code、Cursor 等工具 │
│ │
└─────────────────────────────────────────────────────────────┘
8.2 快速开始清单
[ ] 方式 A：在 Claude Code 中安装插件
/plugin marketplace add forrestchang/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills
[ ] 或方式 B：下载 CLAUDE.md 到项目根目录
curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md
[ ] 测试效果：提出一个简单任务，观察 AI 的响应
[ ] 如果使用：告知 AI "按照 CLAUDE.md 中的规则工作"
[ ] 定期检查：Diff 是否只包含必要的修改
8.3 相关资源
| 资源 | 链接 |
|---|---|
| GitHub 仓库 | github.com/forrestchan… |
| 中文 README | github.com/forrestchan… |
| Andrej Karpathy Twitter | twitter.com/karpathy |
| 灵感来源（Karpathy 视频） | YouTube: "Let's build GPT: from scratch" |
8.4 相关阅读
| 文章/视频 | 作者 | 主题 |
|---|---|---|
| "Let's build GPT from scratch" | Andrej Karpathy | LLM 内部原理 |
| "The bounded ratio" | Dan Luu | 复杂度与产出 |
| YAGNI 原则 | Martin Fowler | 敏捷实践 |
| "Simple Made Easy" | Rich Hickey | 简单性设计 |
8.5 最后的思考
"Good code is code that solves today's problem simply, not tomorrow's problem prematurely."
好代码是简单地解决今天问题的代码，而不是提前解决明天问题的代码。
karpathy-skills 教会我们的不仅是"如何与 AI 协作"，更重要的是"如何保持克制"。
在 AI 时代，克制比热情更难得。让我们用更少的代码、更精准的修改、更清晰的目标，构建更好的软件。
版权声明：
本文为技术分析博客，详细解读了 forrestchang/andrej-karpathy-skills 项目的设计理念和使用方法。项目版权归原作者所有，遵循 MIT 许可证。
参考引用：
- 项目仓库：github.com/forrestchan…
- Andrej Karpathy 的洞察来自其公开演讲和 Twitter
