Andrej Karpathy 的 Claude Code Skills 深度解析：AI 编程的「纪律革命」与四大原则工程实践（2026）

一份 CLAUDE.md 文件，60 天内斩获 149K Stars——它揭示了 AI 辅助编程时代的「纪律危机」，并给出了一套可执行的解决方案。本文将从工程实践视角，深度拆解 Karpathy Skills 的四大原则、底层逻辑、集成方案与生产级应用。

目录

1. 引言：AI 编程的「纪律危机」
2. Karpathy Skills 的起源与背景
3. 四大原则深度解析
   • 3.1 Think Before Coding（编码前先思考）
   • 3.2 Simplicity First（简单优先）
   • 3.3 Surgical Changes（手术式修改）
   • 3.4 Goal-Driven Execution（目标驱动执行）
4. CLAUDE.md 与 Cursor/Copilot 集成实战
5. 代码实战：Bad vs Good 对比
6. 团队协作中的 Karpathy Skills 落地方案
7. 性能与质量影响：数据视角
8. 进阶：构建你自己的 Skills 体系
9. 总结与展望

1. 引言：AI 编程的「纪律危机」

2026 年，AI 辅助编程已从「尝鲜」走向「生产主力」。GitHub Copilot、Claude Code、Cursor、Codex 等工具正在重塑软件开发流程。然而，随着使用深入，一个结构性问题逐渐暴露：

LLM 在编程任务中缺乏「工程纪律」。

Andrej Karpathy（前 Tesla AI 总监、OpenAI 创始成员）在使用 Claude Code 的过程中，观察到一系列反复出现的问题：

"The models make wrong assumptions on your behalf and just run along with them without checking. 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."

翻译成中文就是：模型会在你没有明确要求的情况下擅自做错误假设，然后沿着错误方向一路狂奔；它们不管理自己的困惑，不主动寻求澄清，不暴露矛盾，不呈现权衡方案，在应该质疑的时候保持沉默。

这不仅仅是 Claude Code 的问题——它是所有当前 LLM 编程助手的系统性缺陷。

问题的本质：缺失的「工程师判断力」

传统编译器报错是因为语法错误；传统 Linter 报错是因为风格违规。但 LLM 生成代码的问题更加隐蔽：

这些问题不是「模型不够聪明」，而是模型没有被正确地「约束」。

2. Karpathy Skills 的起源与背景

2.1 Andrej Karpathy 的原始推文

2026 年 4 月，Karpathy 在 X（Twitter）上发布了一条推文（来源），总结了他在使用 Claude Code 时的观察。这条推文迅速引发共鸣——因为它描述了每个使用 AI 编程的开发者都经历过的痛苦。

2.2 multica-ai/andrej-karpathy-skills 项目

开发者 Forrest Chang（GitHub: forrestchang）将 Karpathy 的观察提炼为一份结构化的 CLAUDE.md 文件，并发布在 GitHub 上：

• 仓库地址：https://github.com/multica-ai/andrej-karpathy-skills
• Stars：149K+（截至 2026 年 6 月）
• 核心文件：CLAUDE.md（Claude Code 自动读取的项目级指令文件）
• 兼容：同时支持 Claude Code（CLAUDE.md）和 Cursor（.cursor/rules/）

2.3 为什么是一个 CLAUDE.md 文件？

Claude Code 会在启动时自动读取项目根目录下的 CLAUDE.md 文件，将其内容作为系统级指令注入对话上下文。这意味着：

• 你不需要每次都重复输入「不要过度复杂化」之类的指令
• 指令对项目内所有会话持久生效
• 可以版本控制、团队共享、持续迭代

这正是 Karpathy Skills 能够「病毒式传播」的技术基础——它把一个高手的隐性经验，转化为 AI 可以理解和执行的显性规则。

3. 四大原则深度解析

3.1 Think Before Coding（编码前先思考）

原则核心

Don't assume. Don't hide confusion. Surface tradeoffs.

问题场景

场景 1：沉默的误解

用户需求：「帮我实现一个用户登录功能」

LLM 输出（问题版）：
- 自动选择了 JWT + Redis Session 方案
- 没有询问：要 Session 还是 JWT？
- 没有确认：需要第三方登录吗？
- 没有暴露：JWT 在某些场景下有安全隐患

场景 2：困惑的隐藏

LLM 在不确定的情况下，倾向于「猜一个最合理的」而不是「承认不确定」。这导致错误在后续对话中被放大。

正确做法

# 在 CLAUDE.md 中定义的行为规范

When receiving a task:
1. If any requirement is ambiguous, STOP and ask clarifying questions
2. Present at least 2 alternative approaches with tradeoffs
3. Explicitly state your assumptions before writing code
4. If you would push back on a senior engineer making this request, push back here too

代码示例：需求澄清模板

# === BAD：直接开始写代码 ===
def implement_auth():
    # 没有澄清需求，直接实现了 JWT
    ...

# === GOOD：先澄清，再实现 ===
def clarify_auth_requirements():
    questions = [
        "认证方式偏好：Session / JWT / OAuth2？",
        "需要支持第三方登录吗（Google/GitHub）？",
        "密码重置流程需要包含吗？",
        "Token 过期时间预期是多少？"
    ]
    return {"status": "need_clarification", "questions": questions}

# 在获得明确答案后，再实现对应方案

深度分析：为什么 LLM 难以「主动提问」？

从技术角度看，这是因为：

1. 训练目标不匹配：LLM 训练目标是「生成合理 continuation」，而不是「生成最有用的 continuation」
2. RLHF 的副作用：人类反馈倾向于奖励「直接给出答案」而非「先问问题」
3. 上下文窗口压力：提问意味着多轮对话，消耗更多 token

Think Before Coding 原则本质上是在重新对齐 LLM 的优化目标——从「快速给出答案」转向「给出正确的答案」。

3.2 Simplicity First（简单优先）

原则核心

Minimum code that solves the problem. No premature abstraction. YAGNI.

问题场景

场景：过度工程化（Over-engineering）

任务：「解析一个 CSV 文件」

LLM 输出（问题版）：
- 定义了 5 个抽象类（Parser, Strategy, Factory, Registry, Validator）
- 引入了插件系统（「方便以后扩展」）
- 代码量：1200 行
- 实际需要的代码量：30 行（用 Python csv 模块）

正确做法

# === BAD：过度抽象 ===
from abc import ABC, abstractmethod
from typing import Protocol, runtime_checkable

@runtime_checkable
class DataSource(Protocol):
    def read(self) -> Iterator[dict]: ...

class CSVDataSource:
    def __init__(self, path: str, strategy: ParseStrategy):
        self._path = path
        self._strategy = strategy  # 不必要的策略模式

    def read(self) -> Iterator[dict]:
        # 300 行实现...

# === GOOD：简单直接 ===
import csv

def parse_csv(path: str) -> list[dict]:
    """Parse a CSV file into a list of dicts."""
    with open(path, newline='') as f:
        return list(csv.DictReader(f))

深度分析：为什么 LLM 倾向于「过度复杂」？

1. 训练数据偏差：GitHub 上的明星项目往往有复杂的抽象（因为它们需要可维护性），LLM 学习了这种「风格」
2. 模糊的「最佳实践」：「要可扩展」「要解耦」等建议在简单场景下是毒药
3. 没有代价感知：LLM 不支付「维护这个抽象层」的代价

Simplicity First 原则通过明确的约束，强制 LLM 从「展示我懂设计模式」转向「用最简单的方式解决问题」。

实战技巧：给 LLM 设置「复杂度预算」

# 在 CLAUDE.md 中添加

Complexity Budget:
- Default: aim for the simplest solution that could possibly work
- If a task can be solved in < 50 lines, reject any solution > 100 lines
- Before adding an abstraction layer, write: "Is this abstraction pulling its weight?"
- Prefer duplication over premature abstraction (Sandi Metz rule)

3.3 Surgical Changes（手术式修改）

原则核心

Touch only what you must. No side-effect edits. Respect orthogonal code.

问题场景

场景：范围蔓延（Scope Creep）

任务：「修复用户登录时的 SQL 注入漏洞」

LLM 的修改（问题版）：
1. 修复了 SQL 注入（好）
2. 顺便「优化」了密码哈希算法（无关）
3. 重构了整个 auth 模块的结构（无关）
4. 更新了相关注释的措辞（无关）
5. 删除了「看起来没用」的旧代码（危险！）

正确做法

# === BAD：修改了不应该修改的代码 ===
# 任务：修复 login 函数中的 SQL 注入

def login(username, password):
    # 修复：使用参数化查询 ✓
    cursor.execute("SELECT * FROM users WHERE username = ?", (username,))
    
    # 无关修改 1：重构了密码检查逻辑 ✗
    # 无关修改 2：「优化」了 session 管理 ✗
    # 无关修改 3：删除了旧版兼容代码 ✗
    ...

# === GOOD：只修改必要的部分 ===
def login(username, password):
    # 唯一修改：使用参数化查询防止 SQL 注入
    cursor.execute("SELECT * FROM users WHERE username = ?", (username,))
    # 其余代码完全不变
    ...

深度分析：为什么 LLM 难以「克制」？

1. 「帮忙」的倾向：RLHF 训练让模型倾向于「超额完成」
2. 缺乏「尊重代码历史」的意识：LLM 不理解「这段代码存在是有原因的」
3. 上下文丢失：LLM 看不到 Git Blame，不知道某行代码是谁、为什么写的

Surgical Changes 原则要求 LLM 在每次修改前明确声明修改范围：

# 在 CLAUDE.md 中定义

Before making changes:
1. State explicitly: "I will modify ONLY these files/functions: ..."
2. If you find yourself wanting to "improve" orthogonal code, STOP
3. Ask: "Is this change necessary to complete the task?"
4. Respect dead code: don't delete without asking

3.4 Goal-Driven Execution（目标驱动执行）

原则核心

Define success criteria upfront. Tests first. Verifiable outcomes.

问题场景

场景：模糊的任务描述

任务：「优化数据库查询性能」

LLM 输出（问题版）：
- 加了两个索引（没有基准测试证明有效）
- 修改了查询语句（没有验证是否正确）
- 声称「性能提升 50%」（无法验证）

正确做法

# === GOOD：目标驱动的执行流程 ===

## Step 1: Define success criteria
TARGET_PERFORMANCE = {
    "query_latency_p99": "< 100ms",
    "throughput": "> 1000 QPS",
    "verification": "benchmarks/query_bench.py"
}

## Step 2: Write tests FIRST
def test_query_latency():
    """Verify query latency meets SLA."""
    results = run_benchmark(iterations=1000)
    p99 = np.percentile(results, 99)
    assert p99 < 100, f"P99 latency {p99}ms exceeds 100ms threshold"

## Step 3: Implement ONLY after tests fail
def optimize_query():
    # Now implement the optimization
    ...

## Step 4: Verify
# Run: pytest tests/test_query_latency.py
# Run: python benchmarks/query_bench.py
# Report: actual measured improvement

深度分析：测试驱动开发（TDD）在 AI 编程中的特殊价值

对人类程序员，TDD 的价值是「设计工具」和「回归防护」。对 LLM，TDD 还有一层额外价值：

TDD 为 LLM 提供了「可验证的完成标准」。

没有测试，LLM 只能靠「我感觉写完了」来判断任务完成。有了测试，LLM 可以：

1. 知道什么时候该停（测试通过 = 任务完成）
2. 知道自己错了（测试失败 = 需要修正）
3. 避免过度修改（不需要让所有测试「更绿」，只需要让目标测试通过）

# 在 CLAUDE.md 中强制 TDD 流程

Goal-Driven Execution Rules:
1. For any task, FIRST write a test that would fail with current code
2. Show the test failure as evidence of understanding the problem
3. Implement the minimal change to make the test pass
4. Run the full test suite to ensure no regressions
5. Report: which tests were added, what they verify, and the actual test results

4. CLAUDE.md 与 Cursor/Copilot 集成实战

4.1 Claude Code 集成（原生支持）

Claude Code 会自动读取项目根目录的 CLAUDE.md：

your-project/
├── CLAUDE.md          # Claude Code 自动读取
├── src/
├── tests/
└── README.md

示例 CLAUDE.md：

# Project Guidelines (Karpathy-Inspired)

## Core Principles
1. Think before coding: clarify ambiguities, present tradeoffs
2. Simplicity first: minimize code, reject premature abstraction
3. Surgical changes: modify only what's necessary
4. Goal-driven: write tests first, define success criteria

## Project-Specific Rules
- Language: Python 3.12+
- Formatting: ruff format (max line length: 100)
- Type checking: mypy --strict
- Testing: pytest with ≥90% coverage
- No print() debugging: use logging
- Error handling: use custom exceptions, not generic Exception

## Forbidden Patterns
- No `from module import *`
- No mutable default arguments
- No catching generic Exception without logging
- No hardcoded secrets (use env vars or secrets manager)

4.2 Cursor 集成

Cursor 使用 .cursor/rules/ 目录下的 .mdc 文件：

your-project/
├── .cursor/
│   └── rules/
│       └── karpathy-guidelines.mdc
└── ...

.mdc 文件格式：

---
description: Karpathy-inspired coding guidelines for Cursor
alwaysApply: true
---

# Karpathy Guidelines for Cursor

## Think Before Coding
- Ask clarifying questions when requirements are ambiguous
- Present at least 2 approaches with tradeoffs before implementing

## Simplicity First
- Minimum viable code
- No premature abstraction
- If solution > 100 lines, justify why simpler approach won't work

## Surgical Changes
- State explicitly which files/functions will be modified
- No "improvements" to orthogonal code

## Goal-Driven
- Write tests first
- Define verifiable success criteria

4.3 GitHub Copilot Chat 集成

Copilot Chat 不直接读取 CLAUDE.md，但可以通过 .github/copilot-instructions.md 提供指令：

your-project/
├── .github/
│   └── copilot-instructions.md
└── ...

4.4 跨工具统一配置方案

为了让团队中的所有 AI 工具共享同一套规则，可以采用以下结构：

your-project/
├── .ai/
│   ├── SHARED_GUIDELINES.md    # 统一规则定义
│   └── tools/
│       ├── CLAUDE.md           # 软链接或复制到项目根目录
│       ├── .cursor.rules      # Cursor 格式转换
│       └── copilot-instructions.md  # Copilot 格式转换
├── scripts/
│   └── sync-ai-rules.sh      # 同步脚本
└── ...

sync-ai-rules.sh：

#!/bin/bash
# 从统一源同步 AI 工具规则

set -e

SRC=".ai/SHARED_GUIDELINES.md"

# Claude Code
cp "$SRC" CLAUDE.md

# Cursor (需要转换为 .mdc 格式)
# 这里需要自定义转换逻辑
python3 scripts/convert_to_cursor_format.py "$SRC" .cursor/rules/karpathy-guidelines.mdc

# Copilot
mkdir -p .github
cp "$SRC" .github/copilot-instructions.md

echo "AI rules synchronized across all tools."

5. 代码实战：Bad vs Good 对比

5.1 场景一：实现缓存装饰器

BAD（违反 Simplicity First + Think Before Coding）

"""过度复杂的缓存装饰器实现（BAD）"""

from typing import Any, Callable, Optional, TypeVar, Generic
from abc import ABC, abstractmethod
from dataclasses import dataclass
from enum import Enum
import time
import pickle
import hashlib

T = TypeVar('T')

class CacheStrategy(Enum):
    LRU = "lru"
    LFU = "lfu"
    FIFO = "fifo"

@dataclass
class CacheConfig:
    strategy: CacheStrategy
    max_size: int
    ttl: Optional[int] = None
    persistent: bool = False
    serialize: bool = False

class CacheBackend(ABC):
    @abstractmethod
    def get(self, key: str) -> Any: ...
    @abstractmethod
    def set(self, key: str, value: Any) -> None: ...
    @abstractmethod
    def invalidate(self, key: str) -> None: ...

class MemoryCacheBackend(CacheBackend):
    def __init__(self, config: CacheConfig):
        self._config = config
        self._store: dict[str, Any] = {}
        self._access_count: dict[str, int] = {}
    
    def get(self, key: str) -> Any:
        if key not in self._store:
            return None
        self._access_count[key] = self._access_count.get(key, 0) + 1
        return self._store[key]
    
    def set(self, key: str, value: Any) -> None:
        if len(self._store) >= self._config.max_size:
            self._evict()
        self._store[key] = value
    
    def invalidate(self, key: str) -> None:
        self._store.pop(key, None)
        self._access_count.pop(key, None)
    
    def _evict(self) -> None:
        if self._config.strategy == CacheStrategy.LRU:
            # LRU eviction logic (50+ lines)
            ...
        elif self._config.strategy == CacheStrategy.LFU:
            # LFU eviction logic (50+ lines)
            ...

def cached(
    strategy: CacheStrategy = CacheStrategy.LRU,
    max_size: int = 128,
    ttl: Optional[int] = None
):
    """Cache decorator with enterprise-grade features."""
    def decorator(func: Callable) -> Callable:
        config = CacheConfig(
            strategy=strategy,
            max_size=max_size,
            ttl=ttl
        )
        backend = MemoryCacheBackend(config)
        
        def wrapper(*args, **kwargs):
            key = f"{func.__name__}:{hashlib.md5(pickle.dumps((args, kwargs))).hexdigest()}"
            cached = backend.get(key)
            if cached is not None:
                return cached
            result = func(*args, **kwargs)
            backend.set(key, result)
            return result
        
        return wrapper
    return decorator

# 实际使用（100+ 行框架，只为了一个简单的缓存！）
@cached(strategy=CacheStrategy.LRU, max_size=128)
def fibonacci(n: int) -> int:
    if n <= 1:
        return n
    return fibonacci(n-1) + fibonacci(n-2)

GOOD（遵循 Simplicity First）

"""简单直接的缓存装饰器实现（GOOD）"""

import functools
from typing import Any, Callable

def cached(func: Callable) -> Callable:
    """Simple in-memory cache decorator.
    
    Usage:
        @cached
        def expensive_function(x: int) -> int:
            ...
    """
    cache: dict[tuple[Any, ...], Any] = {}
    
    @functools.wraps(func)
    def wrapper(*args, **kwargs):
        key = (args, tuple(sorted(kwargs.items())))
        if key not in cache:
            cache[key] = func(*args, **kwargs)
        return cache[key]
    
    # Expose cache for testing/debugging
    wrapper.cache = cache  # type: ignore
    return wrapper


# 实际使用（15 行核心代码，清晰易懂）
@cached
def fibonacci(n: int) -> int:
    if n <= 1:
        return n
    return fibonacci(n-1) + fibonacci(n-2)

对比分析：

5.2 场景二：修复 Bug（Surgical Changes 实战）

任务：修复用户注册时的邮箱重复检查缺失

BAD（违反 Surgical Changes）

# === 原始代码 ===
def register_user(email: str, password: str) -> User:
    # 原始逻辑（有 Bug：没有检查邮箱重复）
    hashed_pw = bcrypt.hash(password)
    user = User(email=email, password=hashed_pw)
    db.session.add(user)
    db.session.commit()
    return user

# === LLM 的修改（BAD）===
def register_user(email: str, password: str, username: str = "") -> User:  # 无关修改：加了 username
    """Register a new user with enhanced security."""
    # 修复：添加邮箱重复检查 ✓
    if User.query.filter_by(email=email).first():
        raise ValueError("Email already registered")
    
    # 无关修改 1：重构了密码哈希逻辑 ✗
    # （「顺便」换了哈希算法）
    import argon2
    hashed_pw = argon2.hash(password)  # 原来是 bcrypt
    
    # 无关修改 2：「优化」了数据库操作 ✗
    # （「顺便」加了事务管理）
    with db.session.begin_nested():
        user = User(email=email, password=hashed_pw, username=username)
        db.session.add(user)
    
    # 无关修改 3：加了邮件验证流程 ✗
    # （「顺便」实现了原本没有的功能）
    send_verification_email(email)
    
    return user

# 还「顺便」修改了 User 模型（另一文件！）
# models/user.py（被无关修改）
class User(db.Model):
    # ... 原有字段 ...
    
    # 无关修改：加了新字段
    username = db.Column(db.String(80), unique=True)  # 原本没有这个字段
    
    # 无关修改：重构了 to_dict 方法
    def to_dict(self):  # 原本返回简单 dict，现在返回详细 dict
        return {
            "id": self.id,
            "email": self.email,
            "username": self.username,
            "created_at": self.created_at.isoformat(),  # 原本没有这行
        }

GOOD（遵循 Surgical Changes）

# === 修改仅限于必要部分 ===

def register_user(email: str, password: str) -> User:
    """Register a new user.
    
    Raises:
        ValueError: If email is already registered.
    """
    # 唯一修改：添加邮箱重复检查
    if User.query.filter_by(email=email).first():
        raise ValueError("Email already registered")
    
    # 其余逻辑完全不变
    hashed_pw = bcrypt.hash(password)
    user = User(email=email, password=hashed_pw)
    db.session.add(user)
    db.session.commit()
    return user

# 没有修改其他文件
# 没有修改函数签名
# 没有「优化」无关逻辑

Surgical Changes 检查清单：

- [ ] 我修改的函数/文件是否超出了任务描述的范围？
- [ ] 我是否「顺便」优化了无关代码？
- [ ] 我的修改是否改变了公共 API（函数签名、返回值类型）？
- [ ] 我是否删除了「看起来没用」的代码？（先问再删）
- [ ] 我的修改是否可以用最少的 diff 实现？

6. 团队协作中的 Karpathy Skills 落地方案

6.1 渐进式 adoption 路径

6.2 Code Review 检查清单（针对 AI 生成代码）

# AI-Generated Code Review Checklist

## Think Before Coding
- [ ] AI 是否在没有澄清的情况下擅自做了假设？
- [ ] 代码是否呈现了多种方案并说明了选择理由？

## Simplicity First
- [ ] 代码是否比必要的更复杂？
- [ ] 是否存在不必要的抽象层？
- [ ] 能否用更简单的方式实现同样功能？

## Surgical Changes
- [ ] AI 是否修改了任务范围之外的代码？
- [ ] Diff 是否尽可能小？
- [ ] 是否有「顺手优化」无关代码的情况？

## Goal-Driven
- [ ] 是否有对应的测试？
- [ ] 测试是否在实现之前编写（或至少同时）？
- [ ] 成功标准是否可验证？

6.3 建立团队 Skills 库

基于 Karpathy 的四大原则，团队可以扩展出更具体的「子技能」：

team-skills/
├── README.md
├── foundations/
│   ├── 01-think-before-coding.md
│   ├── 02-simplicity-first.md
│   ├── 03-surgical-changes.md
│   └── 04-goal-driven.md
├── language-specific/
│   ├── python-best-practices.md
│   ├── typescript-best-practices.md
│   └── go-best-practices.md
├── framework-specific/
│   ├── react-guidelines.md
│   ├── django-guidelines.md
│   └── fastapi-guidelines.md
└── review/
    ├── code-review-checklist.md
    └── ai-output-evaluation.md

7. 性能与质量影响：数据视角

7.1 代码复杂度对比（模拟数据）

7.2 Token 消耗对比

遵循 Simplicity First 原则不仅提升代码质量，还直接降低使用成本：

场景：实现一个 REST API 端点

无原则约束：
- 生成代码：1200 tokens
- 调试对话：~5000 tokens
- 重构对话：~3000 tokens
总计：~9200 tokens

有原则约束（简单优先）：
- 生成代码：300 tokens
- 调试对话：~800 tokens
- 重构需求：大幅降低（因为代码本来就不复杂）
总计：~1100 tokens

成本降低：88%

8. 进阶：构建你自己的 Skills 体系

8.1 Skills 的层次结构

Level 1：基础原则（Karpathy 四原则）
  ↓
Level 2：语言/框架特定规则
  ↓
Level 3：项目特定约定
  ↓
Level 4：个人/团队风格偏好

8.2 示例：完整的团队级 CLAUDE.md

# Team Claude Guidelines

## Foundation (from Karpathy)
- Think before coding
- Simplicity first
- Surgical changes
- Goal-driven execution

## Python Specifics
- Python 3.12+ syntax (use `type` statement for unions)
- Ruff for formatting + linting (config: pyproject.toml)
- Type hints required for all public APIs
- `mypy --strict` must pass

## Testing
- pytest as test framework
- Minimum 90% coverage for business logic
- Integration tests for all API endpoints
- Mock external services in unit tests

## Security
- No hardcoded secrets (use AWS Secrets Manager or env vars)
- All user input validated with Pydantic v2
- SQL queries must use parameterized queries (SQLAlchemy ORMs)
- Regular dependency scanning (pip-audit in CI)

## Performance
- Profile before optimizing (cProfile + SnakeViz)
- Database query optimization: check with EXPLAIN ANALYZE
- Cache strategy: Redis for sessions, in-memory for hot paths

## Git Workflow
- Main branch protected (require PR + 2 approvals)
- Commit messages: Conventional Commits format
- PR title must include issue number (e.g., "fix(#123): ...")
- Delete branch after merge

## Forbidden Patterns
- `print()` for logging (use `logging` module)
- `except Exception:` without logging
- Mutable default arguments
- `from module import *`
- Hardcoded configuration values

9. 总结与展望

9.1 核心要点回顾

1. AI 编程的纪律危机是真实存在的——不是模型不够聪明，而是缺乏约束
2. Karpathy 四原则（Think/Simple/Surgical/Goal-driven）是一套可执行的解决方案
3. CLAUDE.md 机制是落地的技术基础——版本控制、团队共享、跨会话持久
4. 简单优先原则可能是最重要的——它对抗了 LLM 的「过度工程化」倾向
5. 手术式修改保护了代码库的健康——防止 AI 「顺手」引入新 Bug

9.2 对软件工程未来的影响

Karpathy Skills 的流行揭示了一个更深层的趋势：

AI 编程工具的未来不在「更聪明的模型」，而在「更好的约束系统」。

当模型能力达到某个阈值后，边际收益递减。而如何让模型更好地与人类工程实践对齐，才是下一个数量级的效率提升来源。

这可能催生：

• IDE 原生的 Skills 管理系统（类似 Linter 配置）
• 团队 Skills 市场（共享、评分、fork）
• Skills 与静态分析的融合（Skills 规则可被编译器验证）
• 多模型 Skills 适配层（同一套原则，不同模型的语言表达）

9.3 行动建议

1. 今天：在你的项目中添加 CLAUDE.md，复制 Karpathy 四原则
2. 本周：在一次 Code Review 中，用这四原则评估 AI 生成的代码
3. 本月：根据团队实践，扩展出你们自己的 CLAUDE.md
4. 本季度：建立团队 Skills 库，并纳入新员工 onboarding

参考资源

• 原始项目：https://github.com/multica-ai/andrej-karpathy-skills
• Karpathy 原始推文：https://x.com/karpathy/status/2015883857489522876
• Claude Code 文档：https://docs.anthropic.com/claude/docs/claude-code
• Cursor Rules 文档：https://cursor.sh/docs/rules
• 相关讨论：Hacker News, Reddit r/LocalLLaMA, CSDN 技术博客

本文约 10,000 字，撰写于 2026 年 6 月。如有实践中的问题或扩展思路，欢迎在评论区讨论。

Tags: Claude Code | AI编程 | Karpathy | LLM | 软件工程 | 代码质量 | Cursor | TDD | 代码审查