【GitHub】andrej-karpathy-skills：让 AI 编程助手告别三大通病

项目仓库 ：forrestchang/andrej-karpathy-skills
Star 数 ：105,000+ ⭐
Fork 数 ：10,300+
开源协议 ：MIT License
灵感来源：Andrej Karpathy 对 LLM 编码缺陷的深刻洞察

---

目录

1. [引言：LLM 编码的三大通病](#引言：LLM 编码的三大通病 "#1-%E5%BC%95%E8%A8%80")
2. 项目概述与核心思想
3. 四大核心原则详解
4. 实战案例对比分析
5. 安装与使用指南
6. 设计哲学深度剖析
7. [与 Matt Pocock Skills 的对比](#与 Matt Pocock Skills 的对比 "#7-%E4%B8%8E-matt-pocock-skills-%E7%9A%84%E5%AF%B9%E6%AF%94")
8. 总结与延伸阅读

---

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