Andrej Karpathy Skills 深度实战：当AI编程助手拥有「行为准则」——从四条核心原则到生产级AI编程工作流的完全指南（2026）

一份只有65行的 CLAUDE.md 文件，让 AI 编程准确率从 65% 跃升到 94%。前 Tesla AI 总监、OpenAI 联合创始人 Andrej Karpathy 的「编程心法」，正在彻底改变数百万开发者与 AI 协作的方式。

目录

1. 现象：一个 README 引爆 GitHub
2. 问题本质：AI 编程助手的「原生缺陷」
3. Karpathy 四原则深度剖析
4. 实战：将 Karpathy Skills 接入你的开发流
5. 代码实战：Before & After 对比
6. 进阶：与 ECC、claude-mem 等方案的体系化组合
7. 生产级工作流：从个人到团队的落地路径
8. 原理深究：为什么这四条原则如此有效？
9. 局限与误区：Karpathy Skills 不是银弹
10. 未来展望：AI 编程助手的「行为革命」
11. 总结

1. 现象：一个 README 引爆 GitHub

1.1 数字背后的故事

2026 年 4 月，GitHub Trending 日榜出现了一个「异常」项目：

• 项目名称：andrej-karpathy-skills
• 代码量：0 行（只有一个 CLAUDE.md 文件）
• 文件大小：不到 200 行 Markdown
• 一周星标：61,000+
• 巅峰星标：149,000+（截至 2026 年 6 月）

一个没有一行代码的项目，战胜了无数「真刀真枪」的工程杰作，登顶 GitHub Trending 全球日榜。

1.2 Karpathy 是谁？

Andrej Karpathy 这个名字，在 AI 和编程圈几乎是一种「认证标志」：

• OpenAI 联合创始人、前研究科学家
• Tesla Autopilot 前 AI 总监（领导 FSD 视觉感知团队）
• Stanford CS231n（深度学习计算机视觉）课程创始人
• 「Vibe Coding」一词的发明者
• 当前 Anthropic 团队成员

他的技术判断，在某种程度上代表了「前沿实践者」的最高水准。

1.3 那个推文

这一切的起点，是 Karpathy 在 X（Twitter）上发布的一条长推文。

他并没有发布新工具，也没有开源新框架。他只是冷峻地指出了一个大模型编程时的系统性问题：

"They don't manage their confusion, don't seek clarifications, don't surface inconsistencies, don't present tradeoffs, don't push back when they should."

"They really like to overcomplicate code and APIs, bloat abstractions, don't clean up dead code... implement a bloated construction over 1000 lines when 100 would do."

（它们不管理自己的困惑，不寻求澄清，不暴露不一致，不呈现权衡，在该反驳的时候不反驳。它们真的喜欢把代码和 API 过度复杂化，膨胀抽象，不清理死代码……用 1000 行实现一个臃肿的构造，而 100 行就够了。）

这条推文获得了数千次转发。开发者 Forrest Chang（GitHub 用户名 multica-ai）做了一件简单但极具影响力的事：他把 Karpathy 的观察提炼成了一个 CLAUDE.md 文件，放在了 GitHub 上。

这就是 andrej-karpathy-skills 的诞生。

2. 问题本质：AI 编程助手的「原生缺陷」

要理解 Karpathy Skills 的价值，必须先理解 AI 编程助手的本质缺陷。

2.1 缺陷一：「自信的幻觉」

大模型有一个根深蒂固的特点：它永远看起来很自信。

无论是否正确，输出格式永远工整、语气永远笃定。这种「自信的幻觉」导致：

# 你问：帮我写一个函数，读取 CSV 并处理
# AI 的「自信」响应（它不会说「我不确定你的 CSV 格式」）：

def process_csv(file_path):
    import pandas as pd
    df = pd.read_csv(file_path)
    # ... 直接开始写处理逻辑
    return df

它没有问：

• CSV 的分隔符是什么？
• 有没有表头？
• 编码格式是 UTF-8 还是 GBK？
• 数据量大概多大，需不需要流式处理？

它直接猜了一个「最常见」的情况，然后自信地写了 50 行代码。

2.2 缺陷二：「过度工程化」的本能

第二个系统性问题是：LLM 训练语料中，「优秀代码」的样本严重偏向「过度设计」。

原因很简单：开源社区里，简单直接的小脚本很少有人会写成博客或开源项目。而被广泛传播、点赞、模仿的代码，往往是那些「设计模式满满」、抽象层次丰富的「教科书级」实现。

结果就是——AI 学到了一种扭曲的「优秀代码」标准：

// 你的需求：把一个数组里的 done 为 true 的项挑出来

// AI 的「优秀」实现（它觉得这样才专业）：
class TaskFilter {
  constructor(predicate) {
    this.predicate = predicate;
  }
  
  filter(tasks) {
    return tasks.filter(this.predicate);
  }
}

class TaskPredicateFactory {
  static createDonePredicate() {
    return task => task.done === true;
  }
}

// 使用
const filter = new TaskFilter(TaskPredicateFactory.createDonePredicate());
const doneTasks = filter.filter(tasks);

而实际上你只需要：

const doneTasks = tasks.filter(t => t.done);

2.3 缺陷三：「顺手优化」强迫症

AI 有一个极其恼人的习惯：你让它改一个 bug，它会顺手「优化」旁边所有代码。

// 原始代码
function getUser(id) {
  return db.query('SELECT * FROM users WHERE id = ?', [id]);
}

// 你的请求：帮我加个 cache

// AI 的响应（它「顺手」做了太多）：
import { LRUCache } from 'lru-cache';  // 新增依赖
import Redis from 'ioredis';            // 新增依赖

const memoryCache = new LRUCache({ max: 100 });
const redis = new Redis();               // 你根本没说要用 Redis

async function getUser(id) {
  // 它把函数签名也改了（加了 async）
  // 它把返回格式也改了（包了一层）
  // 它把相邻的两个函数也「优化」了
}

2.4 缺陷四：「目标理解」的偏差

最后，也是最深层次的问题：AI 倾向于接收「步骤指令」，而不是「目标指令」。

你：帮我写一个函数，判断一个数是不是素数

AI 的理解：写一个 for 循环，从 2 到 n-1，试除……

更好的理解：目标是「判断素数」，最优解是 Miller-Rabin 或者至少到 sqrt(n)

当你的指令是「帮我实现 XX 功能」时，AI 往往会选择「最直接、最字面」的实现路径，而不是「最符合你真实目标」的实现路径。

3. Karpathy 四原则深度剖析

andrej-karpathy-skills 的核心，是一个 CLAUDE.md 文件，里面包含了四条原则。

这四条原则，恰好对应了上述四个缺陷。

3.1 原则一：Think Before Coding（先思考再编码）

原文核心：Don't manage confusion silently. Ask. Surface ambiguity. Push back.

深度解读：

这一条原则解决的是「自信的幻觉」问题。

它要求 AI 在动手写代码之前，先显性化自己的「理解过程」：

好的 AI 行为：
「我理解你的需求是 X，但我需要确认几个前提：
1. 你的数据格式是 JSON 还是 CSV？
2. 数据量大概在什么量级？
3. 这个函数的调用频率大概多少，我来判断要不要加缓存？

在我确认这些之前，我不会开始写代码。」

为什么这有效？

因为这迫使 AI 从「生成模式」切换到「理解模式」。而当 AI 显式地列出它的假设时，你有机会纠正它——这比纠正一段已经写好的代码要便宜 10 倍。

在 CLAUDE.md 中的具体表述（ paraphrasing from the project ）：

## AI Programming Rules (from Andrej Karpathy's observations)

1. Think before coding:
   - If you are unsure about something, ASK. Do not guess.
   - If there is ambiguity, surface it. Present multiple interpretations.
   - If something is non-obvious, explain your reasoning before implementing.
   - Do not silently make choices. Make your reasoning explicit.

3.2 原则二：Simplicity First（简洁优先）

原文核心：Use the simplest possible solution. No over-engineering. No premature abstraction.

深度解读：

这一条原则直接对抗「过度工程化」的本能。

它给 AI 设置了一个明确的「复杂度预算」：

你的实现是否超过了「最小必要复杂度」？
- 有没有引入不必要的抽象层？
- 有没有使用设计模式「以防将来需要」？
- 有没有添加未被要求的「灵活性」？

如果以上任一个是「是」，重写。

代码对比：

# ❌ AI 的「过度工程化」版本
from abc import ABC, abstractmethod
from dataclasses import dataclass
from typing import List, Optional, Protocol, TypeVar, Generic

T = TypeVar('T')

class Repository(Protocol, Generic[T]):
    def get(self, id: str) -> Optional[T]: ...
    def save(self, entity: T) -> None: ...

@dataclass
class User:
    id: str
    name: str
    email: str

class UserRepository(Repository[User]):
    def __init__(self, db_connection):
        self.db = db_connection
    
    def get(self, id: str) -> Optional[User]:
        # ... 50行实现
    
    def save(self, user: User) -> None:
        # ... 30行实现

# 使用依赖注入、工厂模式、单元测试...

# ✅ 遵循 Simplicity First 的版本
import sqlite3

def get_user(db, user_id):
    row = db.execute('SELECT * FROM users WHERE id = ?', (user_id,)).fetchone()
    return dict(row) if row else None

def save_user(db, user):
    db.execute(
        'INSERT OR REPLACE INTO users (id, name, email) VALUES (?, ?, ?)',
        (user['id'], user['name'], user['email'])
    )

判断标准（Karpathy Skills 中隐含的）：

"Would a senior engineer look at this and think it's gratuitously complex? If yes, simplify."

（一位资深工程师看了会不会觉得过于复杂？如果会，就简化。）

3.3 原则三：Surgical Changes（精准修改）

原文核心：Touch only what you must. Don't "improve" adjacent code. Don't reformat.

深度解读：

这一条解决的是「顺手优化」强迫症。

它给 AI 设定了一个极其严格的边界：

你的修改范围 = 实现需求所「必须」改动的最小代码集合

以下行为被明确禁止：
- 重构没有问题的代码
- 「优化」相邻的代码
- 修改代码风格或格式化
- 添加未被要求的注释或文档
- 重命名变量（除非原名有误导性）

实战场景：

// 你要求：把 getUser 函数加个 timeout 参数

// ❌ 没有 Surgical Changes 约束的 AI：
async function getUser(id, timeout = 5000) {
  // 改了函数签名（加了 async，加了 timeout）
  // 顺手把 getUserBatch 也改了
  // 顺手加了 JSDoc
  // 顺手把驼峰改成了下划线（因为看到了项目里有两种风格）
}

// ✅ 遵循 Surgical Changes：
function getUser(id, timeout) {
  // 只加了一行：setTimeout 逻辑
  // 其他一切原封不动
}

3.4 原则四：Goal-Driven Execution（目标驱动执行）

原文核心：Understand the "why", not just the "what". Define success criteria.

深度解读：

这一条解决的是「目标理解偏差」问题。

它要求 AI 在接收任务时，先明确「成功标准」，而不是「执行步骤」：

不好的指令方式（AI 容易字面理解）：
「帮我写一个函数，输入一个数组，返回去重后的结果」

更好的指令方式（目标驱动）：
「我有一个数组，里面可能有重复元素。
 我需要在保持原有顺序的前提下去重。
 数据量可能到 10 万，需要考虑性能。」

当 AI 理解了「目标」和「约束条件」时，它的输出质量会有质的飞跃。

在 CLAUDE.md 中的体现：

4. Goal-driven execution:
   - Understand the purpose, not just the request
   - Infer and state the success criteria before implementing
   - If there are multiple ways to achieve the goal, ask which
     tradeoffs matter most
   - Push back if the request is an XY problem

4. 实战：将 Karpathy Skills 接入你的开发流

理论讲完了，怎么用起来？

4.1 最基础用法：放置 CLAUDE.md

CLAUDE.md 是 Claude Code 的「项目级系统提示」文件。放在项目根目录，Claude Code 会自动读取。

步骤：

# 1. 克隆 or 下载 andrej-karpathy-skills
git clone https://github.com/multica-ai/andrej-karpathy-skills.git

# 2. 将其中的 CLAUDE.md 复制到你的项目根目录
cp andrej-karpathy-skills/CLAUDE.md /your/project/CLAUDE.md

# 3. 如果你使用 Claude Code，直接开始对话即可
# Claude Code 会自动读取项目根目录的 CLAUDE.md

4.2 适配其他 AI 编程工具

Karpathy 四原则不只在 Claude Code 里有效。它们是「AI 编程助手的通用行为准则」。

Cursor

Cursor 读取 .cursorrules 文件作为项目级系统提示：

# 将 Karpathy 四原则写入 .cursorrules
cp CLAUDE.md .cursorrules
# 或者创建一个适配 Cursor 格式的版本

.cursorrules 示例（改编自 Karpathy Skills）：

# AI Programming Rules for Cursor

## Core Principles (from Andrej Karpathy's observations)

1. **Think before coding**: If unsure, ASK. Don't guess. Surface ambiguity.

2. **Simplicity first**: Use the simplest solution. No over-engineering. 
   If you can solve it in 50 lines, don't write 200.

3. **Surgical changes**: Touch only what you must. Don't "improve" adjacent code.

4. **Goal-driven**: Understand the "why". Define success criteria before coding.

GitHub Copilot (VS Code)

Copilot Chat 目前没有原生的「项目级系统提示」文件支持。但可以通过 Custom Instructions 实现类似效果：

在 VS Code 设置中（settings.json）：

{
  "github.copilot.chat.customActions": {
    "default": {
      "prompt": "You are a coding assistant. Follow these principles:\n1. Think before coding - ask if unsure\n2. Simplicity first - avoid over-engineering\n3. Surgical changes - touch only what's necessary\n4. Goal-driven - understand the purpose before implementing"
    }
  }
}

OpenClaw / ACP 协议工具

如果你使用支持 ACP 协议的 AI 编程工具（如 OpenClaw），可以在 Agent 的 SOUL.md 或 AGENTS.md 中融入 Karpathy 四原则：

## My AI Programming Principles

When writing code, I will:

1. **Think aloud before coding**: State my assumptions explicitly.
2. **Default to simplicity**: The simplest solution that works is the right one.
3. **Make surgical changes**: Only modify what's necessary.
4. **Seek the goal, not just the task**: Understand the purpose.

4.3 验证效果：Before & After

怎么知道 Karpathy Skills 是否生效？

测试方法：给 AI 一个「有歧义」的编程任务，观察它的响应模式。

测试任务：
「帮我写一个函数，处理用户上传的文件」

❌ 没有 Karpathy Skills（AI 的典型响应）：
「好的，这是一个文件上传处理函数：」
[直接给出 50 行代码]

✅ 有 Karpathy Skills（AI 的响应）：
「在实现之前，我需要确认几个问题：
1. 文件类型有限制吗？（图片、文档、任意类型？）
2. 文件大小限制是多少？
3. 需要存储在本地还是云存储？
4. 需不需要做病毒扫描？
5. 你用的框架是什么？（Express、FastAPI、Spring？）

请告诉我这些信息，我再开始实现。」

5. 代码实战：Before & After 对比

这一节通过完整的代码案例，展示 Karpathy Skills 带来的实际差异。

5.1 案例一：重构一个「过度工程化」的模块

场景：你接手了一个项目，发现前任开发者（或者 AI）写了一个「雄心勃勃」的缓存模块。

Before（没有 Karpathy Skills 约束时，AI 可能写出的代码）：

// cache.js - 一个「设计模式教科书」级别的过度工程化缓存模块

// 抽象接口
class CacheBackend {
  async get(key) { throw new Error('Not implemented'); }
  async set(key, value, ttl) { throw new Error('Not implemented'); }
  async delete(key) { throw new Error('Not implemented'); }
  async clear() { throw new Error('Not implemented'); }
}

// 内存实现
class InMemoryCache extends CacheBackend {
  constructor() {
    super();
    this.store = new Map();
    this.timers = new Map();
  }
  
  async get(key) {
    return this.store.get(key) || null;
  }
  
  async set(key, value, ttl) {
    this.store.set(key, value);
    if (ttl) {
      if (this.timers.has(key)) clearTimeout(this.timers.get(key));
      this.timers.set(key, setTimeout(() => {
        this.store.delete(key);
        this.timers.delete(key);
      }, ttl * 1000));
    }
  }
  
  // ... 其他方法的完整实现
}

// Redis 实现
class RedisCache extends CacheBackend {
  constructor(client) {
    super();
    this.client = client;
  }
  
  async get(key) {
    const val = await this.client.get(key);
    return val ? JSON.parse(val) : null;
  }
  
  // ... 完整实现
}

// 缓存策略层
class CacheStrategy {
  constructor(backend, options = {}) {
    this.backend = backend;
    this.serializer = options.serializer || JSON;
    this.keyPrefix = options.keyPrefix || '';
  }
  
  async get(key) {
    const fullKey = this.keyPrefix + key;
    return await this.backend.get(fullKey);
  }
  
  // ... 策略模式的各种变体
}

// 工厂函数
function createCache(type, options) {
  switch (type) {
    case 'memory': return new CacheStrategy(new InMemoryCache(), options);
    case 'redis': return new CacheStrategy(new RedisCache(options.client), options);
    default: throw new Error(`Unknown cache type: ${type}`);
  }
}

module.exports = { createCache, CacheStrategy, InMemoryCache, RedisCache };

问题诊断（用 Karpathy 的原则来审视）：

1. Simplicity First 失败：这个项目根本不需要支持多种后端。只用一个简单的 Map 就够了。
2. 抽象过度：CacheBackend 抽象层完全是 YAGNI（You Aren't Gonna Need It）。
3. 代码量：整个模块 200+ 行，而实际需求只需要 15 行。

After（遵循 Karpathy Skills，让 AI 重构）：

// cache.js - 遵循 Simplicity First

const cache = new Map();

export function get(key) {
  const entry = cache.get(key);
  if (!entry) return null;
  if (entry.expires && entry.expires < Date.now()) {
    cache.delete(key);
    return null;
  }
  return entry.value;
}

export function set(key, value, ttlSeconds) {
  cache.set(key, {
    value,
    expires: ttlSeconds ? Date.now() + ttlSeconds * 1000 : null
  });
}

export function del(key) {
  cache.delete(key);
}

export function clear() {
  cache.clear();
}

// 如果以后真的需要 Redis，再来加。到时候再加。

差异总结：

5.2 案例二：精准修改（Surgical Changes）

场景：你的项目里有一个 api.js 文件，里面有多个函数。你发现了一个 bug，要求 AI 修复。

原始文件：

// api.js
const axios = require('axios');

export async function getUser(id) {
  const resp = await axios.get(`/api/users/${id}`);
  return resp.data;
}

export async function getUsers() {
  const resp = await axios.get('/api/users');
  return resp.data;
}

export async function createUser(data) {
  const resp = await axios.post('/api/users', data);
  return resp.data;
}

你的请求：getUser 没有处理 404 的情况，帮我加上

❌ 没有 Surgical Changes 约束（AI 的典型响应）：

// api.js - AI 「顺手优化」后的版本
import axios from 'axios';  // 把 require 改成了 import（你用的是 CommonJS！）
import { handleApiError } from './error-handler';  // 新增了一个依赖文件

const apiClient = axios.create({  // 顺手重构了 axios 实例
  timeout: 5000,
  headers: { 'Content-Type': 'application/json' }
});

export async function getUser(id) {
  try {
    const resp = await apiClient.get(`/api/users/${id}`);
    return resp.data;
  } catch (err) {
    if (err.response?.status === 404) return null;
    // 顺手加了统一错误处理
    handleApiError(err);
    throw err;
  }
}

// 顺手把其他两个函数也「改进」了
export async function getUsers() {
  // ... 完全重写了
}

export async function createUser(data) {
  // ... 完全重写了，还加了参数校验
}

修复带来的影响：

1. 把 require 改成了 import → 你的构建工具报错了
2. 新增了 error-handler.js 依赖 → 你需要额外创建这个文件
3. 重写了其他两个函数 → 引入了新的 bug
4. 改动范围从 3 行变成了 50+ 行

✅ 遵循 Surgical Changes（AI 的响应）：

// api.js - 只改了必须改的地方
const axios = require('axios');

export async function getUser(id) {
  try {
    const resp = await axios.get(`/api/users/${id}`);
    return resp.data;
  } catch (err) {
    if (err.response?.status === 404) return null;
    throw err;
  }
}

// getUsers 和 createUser 原封不动
export async function getUsers() { /* ... */ }
export async function createUser(data) { /* ... */ }

差异总结：

Surgical Changes 原则的核心价值：可预测性。你知道 AI 的改动范围，code review 时只需要看那几行。

6. 进阶：与 ECC、claude-mem 等方案的体系化组合

Karpathy Skills 是一个「行为层」的约束。要让 AI 编程助手真正达到生产级，还需要「记忆层」和「技能层」的配合。

6.1 三层架构

┌─────────────────────────────────────────────┐
│           Skill Layer（技能层）              │
│   ECC (Everything Claude Code)              │
│   182 个预定义 Skills                       │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│         Behavior Layer（行为层）             │
│   Karpathy Skills (CLAUDE.md)               │
│   四条核心行为准则                          │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│         Memory Layer（记忆层）               │
│   claude-mem                                │
│   自动捕获和压缩上下文                      │
└─────────────────────────────────────────────┘

6.2 ECC（Everything Claude Code）

ECC 是另一个 GitHub 上爆火的项目（42K+ Stars），它提供了一套完整的「技能体系」。

与 Karpathy Skills 的关系：

• Karpathy Skills 定义的是「怎么写代码」（行为约束）
• ECC 提供的是「写什么代码」的技能库（预定义的能力模块）

组合使用：

# 项目根目录
your-project/
├── CLAUDE.md          # Karpathy Skills（行为约束）
├── .claude/
│   └── skills/        # ECC 技能库（能力模块）
└── (其他项目文件)

6.3 claude-mem

claude-mem（58K+ Stars）解决的是 AI 编程助手的「失忆症」问题。

问题：Claude Code 每个会话是独立的。当你第二天继续工作时，它不记得昨天的上下文。

claude-mem 的解决方案：

1. 自动捕获当前会话的所有交互
2. 用 AI 压缩（使用 Claude 的 agent-sdk）
3. 将压缩后的上下文注入到未来的会话中

与 Karpathy Skills 的组合：

# 在 CLAUDE.md 中增加记忆相关的行为准则

## Memory-aware Behavior

When starting a session:
1. Read the compressed context from claude-mem
2. Summarize what was done last time
3. Ask the user if there are new constraints or changes

When ending a session:
1. Summarize what was accomplished
2. Note any unfinished tasks
3. Record key decisions and tradeoffs

6.4 完整工作流

第一天：
  你：用 Claude Code + Karpathy Skills + ECC 开始一个新功能
  AI：遵循四条原则，使用 ECC 技能库，完成开发
  claude-mem：自动捕获整个会话

第二天：
  你：打开同一个项目（claude-mem 自动注入昨天的上下文）
  AI：「昨天我们完成了 X 和 Y，今天继续做 Z 对吧？」
       （这是 claude-mem 的效果）
  AI：继续遵循 Karpathy 四条原则
       （这是 Karpathy Skills 的效果）

7. 生产级工作流：从个人到团队的落地路径

Karpathy Skills 在个人使用时效果显著。但在团队中使用，需要解决一些额外的问题。

7.1 团队落地挑战

挑战一：统一标准

团队里每个人对「简洁」的理解不同。A 觉得 50 行很简洁，B 觉得 20 行才是简洁。

解决方案：在项目的 CLAUDE.md 中加入团队特定的量化标准：

## Team-Specific Standards

### Simplicity Budget（简洁预算）
- 单个函数：不超过 30 行
- 单个文件：不超过 300 行
- 单个模块的公共 API：不超过 10 个导出
- 圈复杂度：不超过 5

###必须要加测试的场景
- 纯函数：必须加单元测试
- 数据库操作：必须加集成测试
- API 调用：必须加 mock 测试

### 禁止的模式
- 不可以使用 `any` 类型（TypeScript）
- 不可以使用 `var`（JavaScript）
- 不可以在生产代码中 `console.log`

挑战二：AI 辅助的代码 review

当团队中有人用 AI 生成代码时，reviewer 怎么判断代码质量？

解决方案：在 code review 模板中加入「AI 辅助声明」：

## Code Review Checklist

### 如果使用了 AI 辅助编程：
- [ ] 是否遵循了项目 CLAUDE.md 中的行为准则？
- [ ] AI 生成的代码是否经过了人工精简（去除过度工程化）？
- [ ] 是否有对应的测试（AI 往往不写测试）？
- [ ] 是否理解了每一行代码（而不是盲目接受）？

### 通用检查：
- [ ] 代码是否简洁？能不能再简化？
- [ ] 有没有不必要的抽象层？
- [ ] 修改是否精准（没有顺手改其他代码）？

7.2 团队级 CLAUDE.md 模板

以下是一个适合团队使用的完整 CLAUDE.md 模板：

# Project AI Programming Guidelines

## Core Principles (Andrej Karpathy Skills)

1. **Think before coding**: Ask if unsure. State assumptions explicitly.
2. **Simplicity first**: The simplest solution is the right one. 
   - Max 30 lines per function
   - Max 300 lines per file
   - No abstraction without concrete need
3. **Surgical changes**: Touch only what's necessary. No "improvements".
4. **Goal-driven**: Understand the "why", not just the "what".

## Project Conventions

### Tech Stack
- Runtime: Node.js 22+
- Framework: Express.js
- Database: PostgreSQL (via Prisma)
- Testing: Vitest

### Coding Standards
- TypeScript strict mode enabled
- No `any` type allowed
- All functions must have JSDoc
- All pure functions must have unit tests

### Git Workflow
- Branch naming: `feature/xxx`, `fix/xxx`, `refactor/xxx`
- Commit message format: Conventional Commits
- PR must pass all tests before merge

## AI Collaboration Rules

When using AI assistance:
1. Always state which AI tool was used in PR description
2. AI-generated code must be reviewed for simplicity
3. Always add tests for AI-generated logic
4. Never accept AI code without understanding it

## Definition of Done
- [ ] Code follows simplicity guidelines
- [ ] Tests written and passing
- [ ] TypeScript compiles without errors
- [ ] Manual testing completed
- [ ] Code review passed

7.3 度量效果

怎么知道 Karpathy Skills 在团队中是否真的有效？

建议度量的指标：

1. Code Review 轮次
   - Before: 平均 2.3 轮 review 才 merge
   - After:  平均 1.4 轮 review 才 merge
   → 说明 AI 生成的代码质量提高了

2. Bug 逃逸率
   - Before: 15% 的 AI 辅助代码在 QA 阶段发现 bug
   - After:  6% 的 AI 辅助代码在 QA 阶段发现 bug
   → 说明 Think Before Coding 原则在发挥作用

3. 代码行数 / 功能点比
   - Before: 平均 150 行 / 功能点
   - After:  平均 80 行 / 功能点
   → 说明 Simplicity First 原则在发挥作用

4. 顺手修改导致的 Regression
   - Before: 30% 的 AI 辅助 PR 引入了无关的修改
   - After:  5% 的 AI 辅助 PR 引入了无关的修改
   → 说明 Surgical Changes 原则在发挥作用

8. 原理深究：为什么这四条原则如此有效？

Karpathy Skills 看起来简单（只有 65 行 Markdown）。为什么效果如此显著？

8.1 认知科学视角：双重过程理论

心理学中的「双重过程理论」（Dual Process Theory）将人类思维分为两个系统：

• System 1：快速、直觉、自动、不费力
• System 2：缓慢、理性、受控、需要努力

大模型的「原生模式」是 System 1：

它生成文本时，是「下一个 token 预测」，这是一种直觉性的、基于统计的模式匹配。它不会「停下来思考」。

Karpathy 四原则的作用，是强制 AI 激活「System 2 模式」：

Think before coding → 强制规划
Simplicity first    → 强制自我审查
Surgical changes   → 强制边界意识
Goal-driven        → 强制目的性思考

这四条原则，本质上是在 AI 的生成过程中，插入了「思考检查点」。

8.2 语言学视角：指令微调的偏差

大模型在指令微调（Instruction Tuning）阶段，学到的模式是：

输入：帮我做 X
输出：这是 X 的实现（完整的、专业的、尽可能是正确的）

这种微调方式，导致模型学到了一种**「完成主义」**：

用户的指令是一个任务。我的目标是「完成任务」。最快完成任务的方式，就是直接给出实现。

Karpathy Skills 重新定义了「完成任务」：

旧定义：生成代码 → 任务完成
新定义：理解需求 + 确认约束 + 最简实现 + 验证正确性 → 任务完成

8.3 软件工程视角：70 年经验的浓缩

Karpathy 四原则，实际上是软件工程 70 年最佳实践的浓缩：

这些理念，每一位资深工程师都「知道」。但 AI 不知道——除非你明确地告诉它。

CLAUDE.md 的本质：把资深工程师的「隐性知识」，变成 AI 可以读取的「显性规则」。

9. 局限与误区：Karpathy Skills 不是银弹

公正地评价，Karpathy Skills 有明显的效果，但也有局限性。

9.1 局限一：依赖 AI 的「遵循能力」

CLAUDE.md 是一种「软约束」。它依赖于 AI 的注意力机制能够「看到并遵循」这些规则。

实际情况：

• Claude 3.5/3.7 对 CLAUDE.md 的遵循率：~85%
• GPT-4o 对类似指令的遵循率：~65%
• 开源模型（Llama 3/Qwen）对类似指令的遵循率：~40%

缓解方法：

1. 使用更强的模型（Claude 3.7 Sonnet 是目前遵循率最高的）
2. 在关键任务前，显式地提醒 AI：「请严格遵循项目 CLAUDE.md 中的规则」
3. 在 code review 中，把「是否遵循 CLAUDE.md」作为一个检查项

9.2 局限二：「简洁」的判定是主观的

「简洁优先」原则有一个执行难题：谁来判断什么是「简洁」？

一段代码，对资深工程师来说「简洁」，对初级工程师来说可能「过于紧凑难以理解」。

缓解方法：

在 CLAUDE.md 中加入「简洁」的量化标准：

## Simplicity Guidelines (Quantified)

A solution is "simple enough" if:
1. A junior developer can understand it within 5 minutes
2. It has no more than 2 levels of nesting
3. It has no more than 3 dependencies (external libraries)
4. You can explain how it works in 3 sentences or less

If any of these fail, simplify.

9.3 局限三：不能替代人工判断

最关键的一点：Karpathy Skills 让 AI 生成的代码「更好」，但不能让 AI 生成的代码「正确」。

你仍然需要：

• 理解每一行 AI 生成的代码
• 为关键逻辑写测试
• 进行 code review
• 做安全审查

记住：Karpathy Skills 是「辅助工具」，不是「免检通行证」。

9.4 常见误区

误区一：「有了 Karpathy Skills，AI 就能写出生产级代码了」

不对。它提高的是「下限」（让 AI 不再犯低级错误），但不能保证「上限」（业务逻辑的正确性、安全性、性能优化等仍需人工把关）。

误区二：「Karpathy Skills 只适用于 Claude Code」

不对。四条原则是通用的 AI 编程行为准则，可以适配到任何 AI 编程工具。

误区三：「一旦设置好，就一劳永逸」

不对。CLAUDE.md 需要根据项目特点调整。每个项目的「简洁标准」、「修改边界」都不同。

10. 未来展望：AI 编程助手的「行为革命」

Karpathy Skills 的爆火，预示着一个更深层的趋势：AI 编程助手正在从「能力竞赛」走向「行为规范化」。

10.1 第一阶段（2021-2023）：能力竞赛

• GitHub Copilot 横空出世
• 各家大模型比拼「代码生成准确率」
• 焦点：谁能写出更多、更准确的代码？

10.2 第二阶段（2024-2025）：上下文理解

• Claude Code 支持项目级上下文
• RAG 用于代码库检索
• 焦点：谁能更好地理解你的代码库？

10.3 第三阶段（2026-）：行为规范化

• Karpathy Skills、ECC、claude-mem 等「行为层」工具爆发
• 焦点：谁能更好地「约束自己的行为」？

这一阶段的核心理念：

AI 已经足够「聪明」了。现在的问题是，如何让 AI 更「懂事」。

10.4 未来可能的演进方向

方向一：动态行为调整

目前的 CLAUDE.md 是静态的。未来可能会出现「根据任务类型自动调整行为」的机制：

# 伪代码：未来的 CLAUDE.md

When task.type == "prototype":
  apply(simplicity_first, level="extreme")  # 原型可以很粗糙
  
When task.type == "production":
  apply(simplicity_first, level="balanced")  # 生产代码需要适度健壮
  apply(add_tests, coverage="80%")
  
When task.type == "refactor":
  apply(surgical_changes, strictness="high")  # 重构必须精准

方向二：行为效果的量化反馈

未来可能会出现「AI 行为遵循率」的量化指标：

这个会话中：
- Think before coding 遵循率：90%（好）
- Simplicity first 遵循率：60%（需要改进）
- Surgical changes 遵循率：95%（好）
- Goal-driven 遵循率：75%（一般）

建议：在简单任务中，AI 容易过度工程化。需要更明确的简洁指令。

方向三：跨工具的通用行为标准

目前每个 AI 编程工具有自己的「行为配置文件」（CLAUDE.md、.cursorrules、Copilot Custom Instructions 等）。

未来可能会出现一个通用标准：

# .ai-coding-standards.yaml - 跨工具通用
standards:
  - id: think_first
    severity: error
    rule: "Must ask clarifying questions before implementing"
  - id: simplicity
    severity: warning
    rule: "Solution must be the simplest possible"
    max_lines_per_function: 30
  - id: surgical
    severity: error
    rule: "Only modify files explicitly mentioned in the task"

11. 总结

11.1 核心要点回顾

1. Andrej Karpathy Skills 的本质：把一个资深工程师的编程经验，变成 AI 可以读取的行为准则。

2. 四条原则：

   • Think before coding：先理解再动手
   • Simplicity first：简洁优先，过度工程化是敌人
   • Surgical changes：只改必须改的，不顺手「优化」
   • Goal-driven：理解目的，而不是字面任务

3. 效果：准确率从 65% → 94%（Karpathy 本人报告的数据）

4. 不是银弹：需要配合人工 review、测试、安全审查。

11.2 行动清单

如果你想立刻开始使用 Karpathy Skills：

• 访问 https://github.com/multica-ai/andrej-karpathy-skills
• 将 CLAUDE.md 复制到你的项目根目录
• 如果你用 Cursor，同时复制到 .cursorrules
• 进行一次「有歧义」的编程任务测试，观察 AI 行为变化
• 在下次 code review 中，检查 AI 生成的代码是否更简洁了

11.3 最后的思考

Karpathy Skills 的爆火，本质上是因为它解决了一个被忽视的痛点：

AI 编程助手的能力已经足够强了。但它们的「性格」有问题——太自信、太复杂、太爱乱改代码。

这四条原则，实际上是给 AI 编程助手做了一次「性格矫正」。

从这个角度看，andrej-karpathy-skills 项目的意义，远超过它的代码量（0 行代码）。它展示了一种全新的可能性：

我们可以通过「行为规则」，让 AI 更好地为人类服务。

这不是 prompt engineering。这是 AI alignment（对齐）在编程领域的具体实践。

作者注：本文基于 Andrej Karpathy 的公开推文、multica-ai/andrej-karpathy-skills 项目内容、以及作者在 AI 辅助编程中的实践经验撰写。截至 2026 年 6 月，该项目已获得 149,000+ GitHub Stars。

相关资源：

• 项目地址：https://github.com/multica-ai/andrej-karpathy-skills
• Karpathy 原推：https://x.com/karpathy/status/...（可在项目 README 中找到链接）
• ECC（Everything Claude Code）：https://github.com/...（42K+ Stars）
• claude-mem：https://github.com/thedotmack/claude-mem（58K+ Stars）