Andrej Karpathy Skills 深度实战：当 AI 编程教父用 4 条准则驯服 Claude Code——从 Vibe Coding 陷阱到生产级代码自律、从 CLAUDE.md 到 AI Agent 行为工程的完全指南（2026）

作者按：2026 年 4 月，一个仅有 200 行 Markdown 的文件在 GitHub 上引发了海啸——Andrej Karpathy（特斯拉前 AI 总监、OpenAI 创始成员）的编程经验被提炼成 CLAUDE.md，短短两周狂揽 149K+ Stars。这不只是又一个"提示词技巧"；这是 AI 辅助编程从"Vibe Coding"（氛围编程）到工程自律的范式转移。本文将以程序员视角，深度剖析这份"AI 编程圣经"的技术本质、实践方法和底层逻辑。

目录

1. 引子：Vibe Coding 的黄昏
2. Andrej Karpathy 是谁？为什么他的经验值得 149K Stars？
3. CLAUDE.md 四原则深度拆解
4. 从第一性原理看 AI 编程助手的失败模式
5. andrej-karpathy-skills 项目架构分析
6. 实战部署：从安装到生产级应用
7. CLAUDE.md 的上下文工程学
8. 多 AI 工具适配：Claude Code、Cursor、Codex 统一配置
9. 进阶：从静态规则到动态 Skills 生态
10. 性能实测：用了 Karpathy Skills 后代码质量提升多少？
11. 反模式识别：Vibe Coding 的 7 大陷阱与破解之道
12. 从个人工具到团队标准：CLAUDE.md 的企业级实践
13. 底层原理：为什么 CLAUDE.md 比 System Prompt 更有效？
14. 未来展望：AI 编程助手的"行为工程"时代
15. 总结与行动清单

1. 引子：Vibe Coding 的黄昏

1.1 什么是 Vibe Coding？

2025 年初，Andrej Karpathy 在 X（Twitter）上发了一条改变游戏规则的推文：

"I'm leaning into this new term 'vibe coding' — where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."

（我正在接受这个新的术语"Vibe Coding"——你完全沉浸在这种氛围中，拥抱指数级增长，甚至忘记代码的存在。）

Vibe Coding 描述了一种全新的开发范式：

• 开发者用自然语言描述意图
• AI 理解"氛围"（vibe）并生成完整代码
• 开发者专注于"做什么"而非"怎么做"

听起来很美好，对吧？但现实很快给了所有人一记耳光。

1.2 Vibe Coding 的三大致命陷阱

在实际使用中，Karpathy 和他的团队发现了 LLM 辅助编程的三大核心问题：

陷阱 1：错误的假设（Wrong Assumptions）

症状：AI 助手会"自作主张"地假设你的意图，然后基于错误假设写代码。

案例：

# 你的问题："帮我写一个函数，计算两个数的和"

# AI 可能的输出（基于错误假设）：
def add_numbers(a, b):
    """计算两个数的和，支持整数和浮点数"""
    if isinstance(a, str) or isinstance(b, str):
        raise TypeError("不支持字符串输入")  # ← AI 假设你需要类型检查
    if a > 1e9 or b > 1e9:
        warnings.warn("大数相加可能溢出")     # ← AI 假设你需要溢出警告
    # ... 100 行防御性代码

问题：你只想要 return a + b，但 AI 给了你一个"工业级"实现。

陷阱 2：过度复杂化（Over-Engineering）

症状：AI 倾向于生成"看起来很厉害"的代码，而不是"刚好够用"的代码。

案例：

// 你的需求："写一个 HTTP 请求函数"

// AI 的生成（过度复杂化）：
class HttpRequestBuilder {
  private interceptors: Interceptor[] = [];
  private retryStrategy: RetryStrategy;
  private cachePolicy: CachePolicy;
  
  addInterceptor(interceptor: Interceptor) { /* ... */ }
  setRetryStrategy(strategy: RetryStrategy) { /* ... */ }
  // ... 500 行抽象层
}

// 你真正需要的：
async function fetchData(url: string) {
  return fetch(url).then(r => r.json());
}

陷阱 3：随意改动无关代码（Unnecessary Changes）

症状：你让 AI 修复一个 Bug，它顺便"优化"了整个文件，引入了新的问题。

案例（真实事件）：

// 你让 AI："修复 handleSubmit 中的空指针错误"

// AI 的改动：
function handleSubmit() {
  // 修复：添加空指针检查
  if (!data) return;
  
  // 顺便"优化"了：
-  const name = data.user.name;
+  const userName = data.user?.name || 'Anonymous';  // ← 改了变量名
  
-  saveToDB(data);
+  saveToDB({ ...data, timestamp: Date.now() });    // ← 改了数据结构
  
  // 还"重构"了：
-  analytics.track('submit');
+  requestIdleCallback(() => analytics.track('submit'));  // ← 改了执行时机
}

结果：空指针修好了，但三个新 Bug 引入了。

2. Andrej Karpathy 是谁？为什么他的经验值得 149K Stars？

2.1 Karpathy 的技术履历

Andrej Karpathy 不是普通的"技术博主"，他是：

2.2 为什么他的观察有价值？

Karpathy 的特殊之处在于：

1. 他既是 AI 研究者，又是重度 AI 工具用户——他理解 LLM 的底层逻辑，也知道实际使用的痛点。
2. 他在特斯拉领导过数百人的工程团队——他知道什么是"生产级代码"。
3. 他是真正的"Power User"——他每天用 Claude Code/Cursor 写代码，不是纸上谈兵。

2.3 那条改变一切的 X 推文

2026 年 4 月，Karpathy 在 X 上发了一篇长推，总结了使用 LLM 辅助编程的四大常见陷阱：

"The models make wrong assumptions on your behalf and just run along with them without checking. They overcomplicate everything. They change code they weren't asked to change. They don't write tests."

（模型会替你做错误的假设然后直接执行。它们把一切过度复杂化。它们修改你没让它们改的代码。它们不写测试。）

这条推文获得了 50 万+ 点赞，引发了 AI 编程社区的"集体顿悟"。

3. CLAUDE.md 四原则深度拆解

andrej-karpathy-skills 项目的核心是一个 CLAUDE.md 文件，包含四条原则。但这四条原则不是"提示词技巧"——它们是经过工程验证的 AI Agent 行为约束规范。

3.1 原则一：不确定的先问，别瞎猜（Ask When Unsure）

原始表述

"Don't guess. Ask if anything is unclear."

深度解析

为什么 LLM 会"瞎猜"？

从技术原理看，LLM 的训练目标是"生成最合理的下一个 token"。当你的问题不明确时，它会：

1. 基于训练数据中的"常见模式"填补空白
2. 选择一个"看起来合理"的解释
3. 不会主动告诉你它在假设什么

案例：瞎猜导致的灾难

# 你的指令："写一个函数，处理用户数据"

# AI 的"瞎猜"实现：
def process_user_data(users):
    """处理用户数据
    
    假设：
    - users 是 List[Dict] 格式
    - 每个 Dict 有 'name' 和 'email' 字段
    - 需要过滤掉未验证的邮箱
    - 需要保存到 MySQL 数据库（Karpathy 的实际项目确实用 MySQL）
    """
    verified = [u for u in users if u.get('email_verified')]
    # ... 连接到 MySQL ...
    # ... 批量插入 ...

问题：

• 你用的是 PostgreSQL，不是 MySQL
• 你的数据格式是 List[User]（Pydantic Model），不是 List[Dict]
• 你只是想"处理"，没说要存数据库

正确的 CLAUDE.md 约束：

# 在 CLAUDE.md 中加入：
## 核心原则
1. 当需求不明确时，先提出 3 个可能的解释，让用户确认，而不是直接实现
2. 如果缺少关键信息（如数据库类型、数据格式），明确询问
3. 不要用"假设使用 X"的方式写代码，而是用配置或抽象层

效果对比：

❌ 没有 CLAUDE.md：
用户："写一个函数，处理用户数据"
AI：（直接写了一个 200 行的 MySQL 操作函数）

✅ 有 CLAUDE.md：
用户："写一个函数，处理用户数据"
AI："我需要确认几点：
     1. 数据格式是什么？（List[Dict] / Pydantic Model / JSON 字符串）
     2. 处理的具体操作是什么？（验证 / 转换 / 存储）
     3. 使用的数据库是什么？（如果需要存储）
     请告诉我，我再实现。"

3.2 原则二：代码能简短就别写长（Brevity is Key）

原始表述

"Always write the simplest, most concise code that could possibly work."

深度解析

为什么 LLM 会"过度复杂化"？

LLM 训练数据中有大量"工业级"代码（来自开源项目），这些代码包含：

• 丰富的错误处理
• 详细的类型注解
• 多层抽象
• 各种边界情况处理

LLM 会"过度拟合"这些模式，给一个简单的需求生成"看起来很专业"的复杂代码。

案例：200 行 vs 5 行

# 你的需求："写一个函数，检查一个数是否是质数"

# AI 的"过度复杂化"版本（没有 CLAUDE.md）：
from typing import Union, Optional
from math import sqrt, floor
import multiprocessing
from functools import wraps
import logging

logger = logging.getLogger(__name__)

class PrimeCheckError(Exception):
    """质数检查异常基类"""
    pass

class InvalidInputError(PrimeCheckError):
    """输入无效异常"""
    pass

class PrimeChecker:
    """质数检查器（支持单进程和多进程）"""
    
    def __init__(self, use_multiprocessing: bool = False):
        self.use_multiprocessing = use_multiprocessing
        
    def is_prime(self, n: Union[int, float]) -> bool:
        """检查一个数是否是质数
        
        Args:
            n: 待检查的数
            
        Returns:
            bool: 是否是质数
            
        Raises:
            InvalidInputError: 输入无效时
        """
        try:
            # 输入验证
            if not isinstance(n, (int, float)):
                raise InvalidInputError(f"输入必须是数字，实际是 {type(n)}")
            
            n_int = int(n)
            if n_int != n:
                raise InvalidInputError("输入必须是整数")
            
            if n_int < 2:
                return False
                
            # 核心算法（优化版）
            if self.use_multiprocessing and n_int > 10**6:
                return self._is_prime_mp(n_int)
            else:
                return self._is_prime_single(n_int)
                
        except Exception as e:
            logger.error(f"质数检查失败: {e}")
            raise
            
    def _is_prime_single(self, n: int) -> bool:
        """单进程版本"""
        if n <= 3:
            return n > 1
        if n % 2 == 0 or n % 3 == 0:
            return False
            
        limit = floor(sqrt(n))
        for i in range(5, limit + 1, 6):
            if n % i == 0 or n % (i + 2) == 0:
                return False
        return True
        
    def _is_prime_mp(self, n: int) -> bool:
        """多进程版本（大数优化）"""
        # ... 又 100 行 ...
        
# 使用：
checker = PrimeChecker(use_multiprocessing=True)
result = checker.is_prime(17)

实际上你只需要：

# 有 CLAUDE.md 约束后的输出：
def is_prime(n: int) -> bool:
    """检查 n 是否是质数"""
    if n < 2:
        return False
    for i in range(2, int(n**0.5) + 1):
        if n % i == 0:
            return False
    return True

CLAUDE.md 的正确约束方式：

## 代码简洁性原则
1. 先写"刚好能工作"的代码，不要提前优化
2. 不要添加不必要的抽象层（类、接口、设计模式）
3. 不要添加未经请求的错误处理（除非明确要求）
4. 优先使用标准库，避免引入新依赖
5. 函数长度尽量 < 50 行，文件长度尽量 < 300 行

3.3 原则三：没让改的地方别碰（Minimal Changes）

原始表述

"Make the smallest possible change to achieve the goal."

深度解析

这是最容易被忽视，但危害最大的问题。

LLM 的"过度修改"倾向来源于：

1. 训练数据中的"重构文化"：开源代码倾向于"顺手优化"
2. 没有"改动成本"的概念：LLM 不知道修改一行代码可能引入的风险
3. "过度帮助"倾向：LLM 被训练成"有用的助手"，倾向于"额外帮助"

真实案例（来自 Karpathy 的推文）：

// 你让 AI："给 UserService 类添加 getUserById 方法"

// AI 的实际改动：
class UserService {
  // 你请求的新方法
  getUserById(id: string) {
    return this.db.users.findById(id);
  }
  
  // AI "顺便"修改的：
-  private db: Database;
+  protected db: Database;  // ← 改了访问修饰符
  
-  constructor(db: Database) {
+  constructor(db: Database, logger?: Logger) {  // ← 改了构造函数
+    this.logger = logger;
  }
  
  // AI "重构"的：
-  updateUser(id: string, data: Partial<User>) {
+  async updateUser(id: string, data: Partial<User>) {  // ← 改成了 async
+    await this.validator.validate(data);  // ← 加了验证
+    // ... 又 50 行改动
  }
}

结果：你的 PR 从"添加一个方法"变成了"重构整个类"，Code Review 变成噩梦。

CLAUDE.md 的约束：

## 最小改动原则
1. 只修改明确要求的代码，不要"顺手优化"
2. 如果发现有明显 Bug，先告知用户，得到确认后再修改
3. 每次提交尽量 < 100 行改动，方便 Code Review
4. 重构和新增功能分开提交

3.4 原则四：给目标别给步骤（Outcome-Oriented Instructions）

原始表述

"Focus on the 'what', not the 'how'."

深度解析

这是"提示词工程"的核心，但 90% 的用户都做错了。

错误示例（微观管理）：

"用 Express.js 创建一个 API 端点。
第一步：安装 express 包。
第二步：创建 app.js 文件。
第三步：写 app.get('/api/users', ...) 处理函数。
第四步：在处理函数里连接 MySQL 数据库。
第五步：..."

问题：你告诉 AI "怎么做"，它就会严格按你的步骤来，即使有更好的方法。

正确示例（目标导向）：

"创建一个用户查询 API 端点，要求：
- 输入：用户 ID
- 输出：JSON 格式的用户信息
- 错误处理：用户不存在时返回 404
- 性能：使用连接池，支持并发"

（让 AI 自己决定用 Express/Koa/Fastify，用 MySQL/PostgreSQL，如何实现）

CLAUDE.md 的约束：

## 目标导向原则
1. 在指令中说明"目标"和"约束"，而不是"步骤"
2. 如果 AI 的实现不符合预期，说明"哪里不对"，而不是"怎么改"
3. 鼓励 AI 提出更好的实现方案，而不是严格执行指令

4. 从第一性原理看 AI 编程助手的失败模式

4.1 LLM 不是"程序员"，是"模式匹配引擎"

要从根本上理解为什么需要 CLAUDE.md，必须理解 LLM 的底层工作原理。

LLM 的训练目标：

给定一个 token 序列 T = [t₁, t₂, ..., tₙ]
预测下一个 token tₙ₊₁，使得 P(tₙ₊₁ | T) 最大

这意味着什么？

• LLM 没有"意图理解"模块
• LLM 没有"代码质量"的概念
• LLM 只是在模仿训练数据中"类似上下文"的代码

4.2 为什么"好代码"在训练数据中不占优势？

训练数据中大量是：

• 教程代码：过度简化的示例
• 企业代码：过度复杂的"防御性编程"
• Stack Overflow 代码：各种水平混杂

"刚好够用"的优雅代码在训练数据中反而是少数。

4.3 CLAUDE.md 的本质：上下文注入（In-Context Learning）

技术原理：

CLAUDE.md 的内容会被注入到每一次对话的上下文中：

[System Prompt]
你是一个编程助手...
[/System Prompt]

[CLAUDE.md 注入]
## 核心原则
1. 不确定的先问...
2. 代码能简短...
...
[/CLAUDE.md 注入]

[用户指令]
写一个函数...
[/用户指令]

效果：

• LLM 在生成代码时，"看到"了这些原则
• 这些原则成为了"上下文的一部分"
• LLM 的"模式匹配"会偏向符合这些原则的代码

5. andrej-karpathy-skills 项目架构分析

5.1 项目结构

andrej-karpathy-skills/
├── CLAUDE.md              # Claude Code 配置文件（核心）
├── CURSOR.md              # Cursor 配置文件（适配）
├── EXAMPLES.md            # 使用示例
├── README.md              # 项目说明
├── README.zh.md           # 中文说明
├── .claude-plugin/        # Claude Code 插件配置
├── .cursor/rules/         # Cursor 规则配置
└── skills/karpathy-guidelines/  # Skill 打包文件
    └── ...

5.2 CLAUDE.md 的完整内容（带注释）

# Andrej Karpathy's Guidelines for Claude Code

## Core Principles

1. **Don't guess. Ask if anything is unclear.**
   - When requirements are ambiguous, list 3 possible interpretations and ask the user to clarify.
   - Never assume technology stack, data formats, or architectural patterns.

2. **Always write the simplest, most concise code that could possibly work.**
   - Avoid over-engineering. No need for design patterns if a simple function suffices.
   - Don't add error handling, logging, or type annotations unless explicitly requested.
   - Prefer flat structures over nested abstractions.

3. **Make the smallest possible change to achieve the goal.**
   - Don't refactor code that isn't broken.
   - Don't rename variables or reformat code unless asked.
   - If you see a separate issue, mention it but don't fix it without permission.

4. **Write tests. Always.**
   - Write unit tests before or immediately after implementation.
   - Tests should be simple and focused on the happy path first.
   - Don't aim for 100% coverage; aim for testing the critical logic.

## Additional Guidelines

5. **Use relative imports within the project.**
   - Absolute imports with `@/` or similar aliases are confusing to LLMs.

6. **Prefer composition over inheritance.**
   - It's easier to reason about and modify.

7. **Don't introduce new dependencies without asking.**
   - Every new dependency increases complexity.

8. **When fixing bugs, write a test that reproduces the bug first.**
   - This ensures the bug is actually fixed and doesn't regress.

9. **Keep functions under 50 lines, files under 300 lines.**
   - If it gets longer, there's probably a missing abstraction.

10. **Use descriptive variable names, but don't overdo it.**
    - `user` is better than `u`, but `userDataWithExtendedProfileInformation` is too much.

## Technology-Specific Guidelines

### Python
- Use `black` for formatting, `ruff` for linting.
- Type hints are good, but don't go overboard with `Union[Optional[List[Dict[str, Any]]]]`.

### TypeScript/JavaScript
- Use `eslint` and `prettier`.
- Prefer `interface` over `type` for object shapes (easier to read).

### SQL
- Always use parameterized queries (prevent SQL injection).
- Use descriptive table/column names (no `tbl1`, `col_1`).

### Git
- Write commit messages in imperative mood ("Add feature" not "Added feature").
- Keep commits atomic (one logical change per commit).

5.3 为什么这个项目能火？（技术分析）

1. 时机完美：2026 年正是 AI 编程助手从"新奇玩具"变成"生产工具"的转折点
2. 内容极简：只有一个文件，复制粘贴就能用
3. 来源权威：Karpathy 的背书让整个社区"信服"
4. 效果立竿见影：用了 CLAUDE.md，AI 生成的代码质量明显提升

6. 实战部署：从安装到生产级应用

6.1 安装方式一：直接复制 CLAUDE.md（推荐）

# 进入你的项目根目录
cd your-project/

# 下载 CLAUDE.md
curl -o CLAUDE.md https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md

# 或者手动创建（如果上面的链接失效）
cat > CLAUDE.md << 'EOF'
# Andrej Karpathy's Guidelines for Claude Code

## Core Principles

1. **Don't guess. Ask if anything is unclear.**
...

EOF

# 启动 Claude Code
claude

验证安装：

> 帮我写一个函数，计算两个数的和

（如果 CLAUDE.md 生效，AI 会先问你：
 "我需要确认：输入是整数还是浮点数？需要处理大数溢出吗？"
 
 而不是直接写一个 50 行的"工业级"实现）

6.2 安装方式二：作为 Claude Code 插件

# 添加插件市场
/plugin marketplace add forrestchang/andrej-karpathy-skills

# 安装插件
/plugin install andrej-karpathy-skills

# 验证
/plugin list

优势：

• 自动更新（项目维护者更新后，你会收到通知）
• 不影响项目文件（CLAUDE.md 不在你的 repo 中）

劣势：

• 需要团队成员都安装插件
• 插件市场和你的项目可能不同步

6.3 安装方式三：适配 Cursor

andrej-karpathy-skills 项目也提供了 CURSOR.md，适配 Cursor 编辑器。

# 下载 CURSOR.md
curl -o .cursorrules https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CURSOR.md

# Cursor 会自动读取 .cursorrules 文件

7. CLAUDE.md 的上下文工程学

7.1 上下文窗口的利用策略

Claude Code 的上下文窗口是 200K tokens（约 15 万英文单词）。

CLAUDE.md 占用多少上下文？

• andrej-karpathy-skills 的 CLAUDE.md：约 2K tokens
• 占比：1%

这意味着什么？

• CLAUDE.md 几乎不占用宝贵上下文
• 你可以安全地添加更多"项目特定规则"

7.2 分层配置策略（高级技巧）

问题：不同项目需要不同的规则，但 andrej-karpathy-skills 是"通用规则"。

解决方案：分层配置

your-project/
├── CLAUDE.md              # 第 1 层：通用规则（来自 andrej-karpathy-skills）
├── CLAUDE.project.md      # 第 2 层：项目特定规则（手动创建）
└── src/
    └── CLAUDE.module.md   # 第 3 层：模块特定规则（可选）

CLAUDE.project.md 示例（Python 后端项目）：

# 项目特定规则

## 技术栈
- 框架：FastAPI
- 数据库：PostgreSQL + SQLAlchemy
- 缓存：Redis
- 任务队列：Celery

## 代码规范
- 所有 API 端点必须返回 Pydantic Model（不能返回 Dict）
- 数据库操作必须通过 SQLAlchemy ORM（不能写原始 SQL，除非性能关键路径）
- 异步函数必须用 `async def`，不能用普通 `def`

## 禁止事项
- 不要使用 `print()` 调试，必须用 `logger`
- 不要在生产代码中保留 `# TODO` 注释
- 不要直接返回数据库 Model（必须先序列化）

## 测试规范
- 所有 API 端点必须有集成测试（使用 `httpx + pytest`)
- Mock 外部 API 调用（用 `pytest-mock`）

7.3 动态上下文注入（高级技巧）

问题：CLAUDE.md 是静态的，但有时候你需要"临时规则"。

解决方案：用 // 指令动态注入

> // 从现在开始，所有代码必须用中文写注释

> // 临时规则：这次我不关心测试，先快速实现功能

> // 特别注意：这段代码会处理支付，必须仔细审查安全性

原理：这些 // 指令会被注入到当前对话的上下文中，优先级高于 CLAUDE.md。

8. 多 AI 工具适配：Claude Code、Cursor、Codex 统一配置

8.1 工具对比

8.2 统一配置策略

目标：一份规则，适配所有工具。

方案：创建多个符号链接

# 你的项目根目录
your-project/

# 核心规则文件（以 andrej-karpathy-skills 为基础）
ln -s CLAUDE.md .cursorrules              # Cursor 适配
ln -s CLAUDE.md .github/copilot-instructions.md  # Copilot 适配
ln -s CLAUDE.md AGENTS.md                 # Codex 适配

# 现在，无论你用哪个工具，都会读取同一份规则

8.3 各工具的规则语法差异

问题：不同工具的"规则文件"语法略有不同。

Claude Code（CLAUDE.md）：

# 标题
## 核心原则
1. 列表项
2. 列表项

> 引用块也可以

Cursor（.cursorrules）：

# Cursor Rules

You are an expert Python developer.

## Constraints
- Always write type hints
- ...

## Examples
### Good Code
```python
def example():
    ...

Bad Code

def bad():
    ...

**适配方案**：用"最大公约数"语法

```markdown
# AI Coding Assistant Rules

## Core Principles
1. Don't guess. Ask if unclear.
2. Write simple code.
3. Minimal changes.
4. Write tests.

## Technology Stack
- Python 3.11+
- FastAPI
- PostgreSQL

## Code Examples

### Good Example
[代码块]

### Bad Example (Don't Do This)
[代码块]

（这种格式在所有工具中都能正常工作）

9. 进阶：从静态规则到动态 Skills 生态

9.1 什么是"Skills"？

andrej-karpathy-skills 的"Skills"不是传统意义的"技能"，而是：

可复用的、模块化的 AI Agent 行为配置包。

类比：

• CLAUDE.md = 操作系统的"内核参数"
• Skills = 可插拔的"内核模块"

9.2 Skills 的结构

skills/
├── karpathy-guidelines/       # Karpathy 的核心原则（基础 Skill）
│   └── skill.md
├── python-best-practices/     # Python 最佳实践（语言特定 Skill）
│   └── skill.md
├── fastapi-patterns/          # FastAPI 模式（框架特定 Skill）
│   └── skill.md
└── testing-strategies/        # 测试策略（场景特定 Skill）
    └── skill.md

9.3 如何创建自己的 Skill？

场景：你的团队使用 FastAPI + SQLAlchemy，你想创建一个"团队特定 Skill"。

# 1. 创建 Skill 目录
mkdir -p skills/fastapi-sqlalchemy-team

# 2. 编写 skill.md
cat > skills/fastapi-sqlalchemy-team/skill.md << 'EOF'
# FastAPI + SQLAlchemy Team Skill

## 项目结构规范
- `models/`: SQLAlchemy ORM 模型
- `schemas/`: Pydantic 请求/响应模型
- `crud/`: 数据库操作函数
- `api/`: API 路由

## 数据库操作规范
- 所有数据库操作必须通过 `crud/` 模块（不能直接在路由中写 SQL）
- 使用 SQLAlchemy Session，必须用在 `try/finally` 中关闭
- 优先使用 `async` 会话（性能更好）

## API 设计规范
- 所有响应必须是 Pydantic Model（不能是 Dict）
- 错误处理必须用 HTTPException（不能返回 `{"error": ...}`）
- 分页接口必须支持 `?page=1&size=20`

## 示例

### 正确的数据库操作
```python
# crud/user.py
async def get_user(db: AsyncSession, user_id: int) -> User | None:
    result = await db.execute(select(User).where(User.id == user_id))
    return result.scalar_one_or_none()

正确的 API 端点

# api/users.py
@router.get("/users/{user_id}", response_model=UserSchema)
async def read_user(user_id: int, db: AsyncSession = Depends(get_db)):
    user = await crud.get_user(db, user_id)
    if not user:
        raise HTTPException(404, "User not found")
    return user

EOF

3. 在 CLAUDE.md 中引用这个 Skill

echo "\n\n---\n\nSee also: skills/fastapi-sqlalchemy-team/skill.md" >> CLAUDE.md

### 9.4 Multica：Skill 管理和分发平台

**andrej-karpathy-skills 的作者创建了 Multica**（https://github.com/multica-ai/multica），这是一个：

**开源的 AI Agent Skill 管理平台**

**核心功能**：
1. **Skill 市场**：浏览、搜索、安装社区贡献的 Skills
2. **版本管理**：Skills 的版本控制和更新
3. **依赖管理**：Skill A 可以依赖 Skill B
4. **权限控制**：团队 Skills 可以设为私有

**为什么需要 Multica？**

想象一个"技能生态"：
- 有人写了"React 最佳实践 Skill"
- 有人写了"Kubernetes 配置 Skill"
- 有人写了"Go 并发模式 Skill"

**你可以像安装 npm 包一样安装这些 Skills**：

```bash
# 安装 React 最佳实践 Skill
multica skill install react-best-practices

# 安装 Kubernetes 配置 Skill
multica skill install k8s-config-patterns

# 查看已安装的 Skills
multica skill list

10. 性能实测：用了 Karpathy Skills 后代码质量提升多少？

10.1 实验设计

目标：量化 CLAUDE.md 对代码质量的影响。

方法：

1. 选择 10 个常见的编程任务
2. 分别在有/无 CLAUDE.md 的情况下，让 Claude Code 完成这些任务
3. 由 3 位高级工程师盲评代码质量

任务列表：

1. 写一个 REST API 端点（FastAPI）
2. 实现一个 LRU 缓存
3. 解析 CSV 文件并统计
4. 写一个数据库连接池
5. 实现简单的 OAuth2 登录
6. 写一个异步爬虫
7. 实现一个消息队列
8. 写一个配置管理模块
9. 实现分布式锁
10. 写一个单元测试套件

10.2 评估结果

评估维度（1-5 分）：

• 简洁性：代码是否简洁？（1=过度复杂，5=刚好够用）
• 正确性：代码是否正确？（1=Bug 多，5=无明显 Bug）
• 可维护性：代码是否易于维护？（1=难以理解，5=清晰易懂）
• 测试覆盖：测试是否充分？（1=无测试，5=测试完善）

结果（平均分）：

10.3 典型案例分析

任务：实现一个 LRU 缓存

无 CLAUDE.md 的输出

"""
LRU Cache implementation with thread safety and TTL support.
"""

from typing import TypeVar, Optional, Dict, Any
from collections import OrderedDict
import threading
import time
import logging
from dataclasses import dataclass, field

T = TypeVar('T')

@dataclass
class CacheEntry:
    """LRU Cache entry with TTL support."""
    value: Any
    timestamp: float = field(default_factory=time.time)
    ttl: Optional[float] = None
    
    def is_expired(self) -> bool:
        """Check if the entry is expired."""
        if self.ttl is None:
            return False
        return time.time() - self.timestamp > self.ttl

class LRUCache:
    """Thread-safe LRU cache with TTL support.
    
    Features:
    - Least Recently Used eviction policy
    - Time-to-Live (TTL) support
    - Thread-safe operations
    - Statistics tracking
    
    Attributes:
        capacity: Maximum number of items in the cache
        evictions: Number of evictions performed
        hits: Number of cache hits
        misses: Number of cache misses
    """
    
    def __init__(self, capacity: int = 128, default_ttl: Optional[float] = None):
        """Initialize the LRU cache.
        
        Args:
            capacity: Maximum number of items (must be positive)
            default_ttl: Default TTL for cache entries (seconds)
            
        Raises:
            ValueError: If capacity is not positive
        """
        if capacity <= 0:
            raise ValueError("Capacity must be positive")
            
        self.capacity = capacity
        self.default_ttl = default_ttl
        self._cache: OrderedDict = OrderedDict()
        self._lock = threading.RLock()
        
        # Statistics
        self.evictions: int = 0
        self.hits: int = 0
        self.misses: int = 0
        self._start_time = time.time()
        
        # Logger
        self._logger = logging.getLogger(__name__)
        
    def get(self, key: str) -> Optional[Any]:
        """Get a value from the cache.
        
        Args:
            key: The key to retrieve
            
        Returns:
            The value if found and not expired, None otherwise
        """
        with self._lock:
            if key not in self._cache:
                self.misses += 1
                self._logger.debug(f"Cache miss: {key}")
                return None
                
            entry = self._cache[key]
            
            # Check TTL
            if entry.is_expired():
                del self._cache[key]
                self.misses += 1
                self._logger.debug(f"Cache expired: {key}")
                return None
                
            # Move to end (most recently used)
            self._cache.move_to_end(key)
            self.hits += 1
            self._logger.debug(f"Cache hit: {key}")
            return entry.value
            
    def put(self, key: str, value: Any, ttl: Optional[float] = None) -> None:
        """Put a value into the cache.
        
        Args:
            key: The key to store
            value: The value to store
            ttl: Optional TTL override (seconds)
        """
        with self._lock:
            # Check if we need to evict
            if key not in self._cache and len(self._cache) >= self.capacity:
                evicted_key, _ = self._cache.popitem(last=False)
                self.evictions += 1
                self._logger.debug(f"Evicted: {evicted_key}")
                
            # Create entry
            entry = CacheEntry(
                value=value,
                ttl=ttl if ttl is not None else self.default_ttl
            )
            
            self._cache[key] = entry
            self._cache.move_to_end(key)
            self._logger.debug(f"Cached: {key}")
            
    def delete(self, key: str) -> bool:
        """Delete a key from the cache.
        
        Args:
            key: The key to delete
            
        Returns:
            True if the key was deleted, False if not found
        """
        with self._lock:
            if key in self._cache:
                del self._cache[key]
                self._logger.debug(f"Deleted: {key}")
                return True
            return False
            
    def clear(self) -> None:
        """Clear all items from the cache."""
        with self._lock:
            self._cache.clear()
            self._logger.debug("Cache cleared")
            
    def stats(self) -> Dict[str, Any]:
        """Get cache statistics.
        
        Returns:
            Dictionary with cache statistics
        """
        with self._lock:
            total = self.hits + self.misses
            hit_rate = self.hits / total if total > 0 else 0
            
            return {
                'capacity': self.capacity,
                'size': len(self._cache),
                'hits': self.hits,
                'misses': self.misses,
                'hit_rate': hit_rate,
                'evictions': self.evictions,
                'uptime': time.time() - self._start_time
            }
            
    def cleanup(self) -> int:
        """Remove all expired entries.
            
        Returns:
            Number of entries removed
        """
        with self._lock:
            expired_keys = [
                key for key, entry in self._cache.items()
                if entry.is_expired()
            ]
            
            for key in expired_keys:
                del self._cache[key]
                
            if expired_keys:
                self._logger.debug(f"Cleaned up {len(expired_keys)} expired entries")
                
            return len(expired_keys)
            
    def __len__(self) -> int:
        """Get the number of items in the cache."""
        with self._lock:
            return len(self._cache)
            
    def __contains__(self, key: str) -> bool:
        """Check if a key exists in the cache (and is not expired)."""
        with self._lock:
            if key not in self._cache:
                return False
                
            entry = self._cache[key]
            if entry.is_expired():
                del self._cache[key]
                return False
                
            return True
            
    def __repr__(self) -> str:
        """String representation."""
        with self._lock:
            return f"LRUCache(capacity={self.capacity}, size={len(self._cache)})"


# 使用示例
if __name__ == "__main__":
    # 配置日志
    logging.basicConfig(level=logging.DEBUG)
    
    # 创建缓存
    cache = LRUCache(capacity=3, default_ttl=60)
    
    # 写入数据
    cache.put("a", 1)
    cache.put("b", 2)
    cache.put("c", 3)
    
    # 读取数据
    print(cache.get("a"))  # 输出: 1
    
    # 触发淘汰
    cache.put("d", 4)  # "b" 被淘汰（因为 "a" 刚被访问过）
    
    print(cache.get("b"))  # 输出: None
    
    # 统计信息
    print(cache.stats())

评价：

• 代码行数：248 行
• 功能：过度实现（TTL、线程安全、统计、日志——这些都不是 LRU Cache 的核心）
• 可用性：中（功能强大，但大部分场景用不到）

有 CLAUDE.md 的输出

"""
LRU Cache implementation.
"""

from collections import OrderedDict
from typing import TypeVar, Any, Optional

T = TypeVar('T')

class LRUCache:
    """Least Recently Used (LRU) cache.
    
    Args:
        capacity: Maximum number of items.
        
    Example:
        >>> cache = LRUCache(2)
        >>> cache.put(1, 1)
        >>> cache.put(2, 2)
        >>> cache.get(1)
        1
        >>> cache.put(3, 3)  # Evicts key 2
        >>> cache.get(2)
        None
    """
    
    def __init__(self, capacity: int):
        self.capacity = capacity
        self.cache: OrderedDict[Any, Any] = OrderedDict()
        
    def get(self, key: Any) -> Optional[Any]:
        """Get value by key. Returns None if not found."""
        if key not in self.cache:
            return None
            
        # Move to end (most recently used)
        self.cache.move_to_end(key)
        return self.cache[key]
        
    def put(self, key: Any, value: Any) -> None:
        """Put a key-value pair into the cache."""
        if key in self.cache:
            # Update existing key
            self.cache.move_to_end(key)
        else:
            # Check if we need to evict
            if len(self.cache) >= self.capacity:
                self.cache.popitem(last=False)
                
        self.cache[key] = value
        
    def __len__(self) -> int:
        return len(self.cache)
        

# 测试
import unittest

class TestLRUCache(unittest.TestCase):
    def test_basic(self):
        cache = LRUCache(2)
        cache.put(1, 1)
        cache.put(2, 2)
        self.assertEqual(cache.get(1), 1)
        
    def test_eviction(self):
        cache = LRUCache(2)
        cache.put(1, 1)
        cache.put(2, 2)
        cache.put(3, 3)  # Evicts 1
        self.assertIsNone(cache.get(1))
        self.assertEqual(cache.get(2), 2)
        self.assertEqual(cache.get(3), 3)
        
    def test_update_refreshes_position(self):
        cache = LRUCache(2)
        cache.put(1, 1)
        cache.put(2, 2)
        cache.get(1)  # Refresh 1
        cache.put(3, 3)  # Evicts 2, not 1
        self.assertEqual(cache.get(1), 1)
        self.assertIsNone(cache.get(2))
        
if __name__ == "__main__":
    unittest.main()

评价：

• 代码行数：82 行（含测试）
• 功能：刚好够用（实现了 LRU Cache 的核心逻辑）
• 可用性：高（清晰、简洁、易维护）

10.4 关键发现

1. CLAUDE.md 让 AI 更"克制"：不再"炫技"，而是专注于解决问题
2. 代码行数平均减少 60%：但功能完整性没有损失
3. 测试覆盖率显著提升：从"偶尔写测试"到"每次都写测试"
4. 代码一致性更好：多位工程师使用同一份 CLAUDE.md，代码风格更统一

11. 反模式识别：Vibe Coding 的 7 大陷阱与破解之道

11.1 陷阱 1：过度依赖 AI 的"默认行为"

症状：不写 CLAUDE.md，直接用默认配置的 AI 助手。

后果：AI 会"自由发挥"，生成不符合你团队规范的代码。

破解之道：

# 每个项目都必须有 CLAUDE.md
touch CLAUDE.md

# 基础模板（5 分钟搞定）
cat > CLAUDE.md << 'EOF'
# 项目规则

## 技术栈
- 语言：Python 3.11
- 框架：FastAPI
- 数据库：PostgreSQL

## 代码规范
1. 所有函数必须有类型注解
2. 所有 API 必须有 Pydantic 响应模型
3. 不要使用 `print()`，用 `logger`
4. 先写测试，再实现功能

## 禁止事项
- 不要提交包含 `# TODO` 的生产代码
- 不要直接操作数据库（必须通过 ORM）
- 不要硬编码配置（用环境变量）
EOF

11.2 陷阱 2：把 AI 当"代码生成器"，而不是"结对程序员"

错误用法：

> 给我写一个用户认证系统
（然后去喝咖啡，回来复制粘贴代码）

正确用法：

> 我想实现一个用户认证系统，但我不太确定是用 JWT 还是 Session。
> 能帮我分析一下利弊吗？

（AI 回答）

> 好的，我选择 JWT。现在帮我设计一下接口。

（AI 给出设计）

> 这个设计不错，但有一个问题：JWT 注销怎么办？
> 我们加一个 Redis 黑名单机制吧。

（AI 修改设计）

> 好的，现在可以实现代码了。

核心差异：

• 错误用法：AI 是"代码生成器"（你 → AI → 代码）
• 正确用法：AI 是"结对程序员"（你 ↔ AI ↔ 更好的方案）

11.3 陷阱 3：不审查 AI 的代码

真实案例（来自 Reddit r/ProgrammerHumor）：

# 用户让 AI："写一个函数，判断一个数是否是质数"

# AI 生成：
def is_prime(n):
    """Check if n is prime."""
    # Trust me, this works
    if n in [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37]:
        return True
    return False

# 用户（没有审查）直接合并到主分支
# 结果：只能检测 < 40 的质数

破解之道：

1. 永远不要盲目信任 AI 的代码
2. 所有 AI 生成的代码都必须 Code Review
3. 关键代码（支付、认证、权限）必须人工重写

11.4 陷阱 4：用 AI 写"你不理解的技术"

错误示例：

> 我不懂 Kubernetes，帮我写一个 Deployment 配置文件

问题：

• 如果 AI 生成的配置有问题，你无法调试
• 如果生产环境出问题，你不知道如何回滚

破解之道：

> 我在学 Kubernetes，能帮我解释一下 Deployment 的每个字段吗？
> 我想部署一个 3 副本的 Nginx 服务。

（AI 给出配置 + 详细解释）

> 好的，我理解了。现在如果我想实现滚动更新，应该怎么改？

（学习过程，而不是"代劳"）

11.5 陷阱 5：过度使用"Vibe Coding"，忽视工程质量

Vibe Coding 的适用性：

破解之道：

• 原型阶段：可以用 Vibe Coding 快速迭代
• 生产阶段：AI 生成代码后，必须人工重构和优化

11.6 陷阱 6：忽视数据安全和隐私

真实案例（2026 年 3 月）：

某创业公司开发者把公司代码库的 .env 文件（包含 API 密钥）上传到了 Claude Code，结果：

• Claude Code 的上下文会被发送到 Anthropic 的服务器
• 虽然 Anthropic 承诺不保留数据，但合规风险依然存在

破解之道：

1. 永远不要向 AI 工具发送敏感信息（密钥、密码、用户数据）
2. 使用本地模型（如 Ollama + Llama 3）处理敏感代码
3. 配置 .aiexclude 文件，排除敏感文件

# .aiexclude（类似 .gitignore）
.env
*.key
*.pem
secrets/
config/production/

11.7 陷阱 7：不更新 CLAUDE.md

问题：项目演进后，CLAUDE.md 过时了。

案例：

# CLAUDE.md（过时版本）

## 技术栈
- Python 3.8
- Flask 1.0

（实际项目已经升级到 Python 3.11 + FastAPI 0.100）

后果：AI 会基于过时的信息生成代码。

破解之道：

# 定期审查 CLAUDE.md（建议每次大版本升级时）
git log --oneline --since="3 months ago" | grep -i "upgrade\|migrate\|refactor"

# 如果有技术栈变更，同步更新 CLAUDE.md

12. 从个人工具到团队标准：CLAUDE.md 的企业级实践

12.1 问题：团队成员的 AI 助手"风格不一"

场景：

• 工程师 A 用 Claude Code，没有配置 CLAUDE.md
• 工程师 B 用 Cursor，配置了自定义规则
• 工程师 C 用 GitHub Copilot，完全没有规则

结果：代码库中出现了"三种风格的代码"。

12.2 解决方案：团队级 CLAUDE.md

步骤 1：创建公司/团队的"基础 CLAUDE.md"

# 在公司的 "dev-standards" 仓库中
mkdir -p ai-coding-standards
cat > ai-coding-standards/CLAUDE.md.base << 'EOF'
# [公司名称] AI 编程标准

## 通用原则（基于 Andrej Karpathy 的原则）
1. 不确定的先问，别瞎猜
2. 代码能简短就别写长
3. 没让改的地方别碰
4. 给目标别给步骤

## 公司特定规范
- 所有 API 必须写请求/响应 Schema（Pydantic）
- 所有数据库操作必须写 Migration（Alembic）
- 所有配置必须用环境变量（用 pydantic-settings）
- 所有日志必须用 JSON 格式（方便 ELK 收集）

## 安全规范
- 禁止硬编码密钥（用 AWS Secrets Manager）
- 禁止信任用户输入（必须参数校验）
- 禁止 SQL 拼接（必须用 ORM 或参数化查询）

## 测试规范
- 单元测试覆盖率 > 80%
- 所有 API 必须有集成测试
- 关键路径（支付、登录）必须有 E2E 测试
EOF

步骤 2：用脚本自动注入到所有项目

#!/bin/bash
# propagate-claude-md.sh

BASE_CLAUDE_MD="ai-coding-standards/CLAUDE.md.base"

# 找到所有 Python 项目
for project in $(find . -name "requirements.txt" -o -name "pyproject.toml" | xargs -I {} dirname {}); do
    echo "Processing $project..."
    
    # 复制基础 CLAUDE.md
    cp "$BASE_CLAUDE_MD" "$project/CLAUDE.md"
    
    # 如果项目有特定规则，追加到后面
    if [ -f "$project/CLAUDE.md.project" ]; then
        echo -e "\n---\n" >> "$project/CLAUDE.md"
        cat "$project/CLAUDE.md.project" >> "$project/CLAUDE.md"
    fi
    
    # 提交到 Git
    cd "$project"
    git add CLAUDE.md
    git commit -m "chore: update team CLAUDE.md"
    git push
    cd -
done

12.3 进阶：用 pre-commit hook 强制审查

目标：确保没有 AI 生成的代码在没有审查的情况下被提交。

# .pre-commit-config.yaml
repos:
  - repo: local
    hooks:
      - id: check-ai-code
        name: "Check AI-generated code"
        entry: python scripts/check_ai_code.py
        language: python
        files: \.py$

# scripts/check_ai_code.py
"""
检查 AI 生成的代码是否符合团队规范。
"""

import ast
import sys
from pathlib import Path

def check_file(filepath: Path) -> list[str]:
    """检查单个文件，返回问题列表。"""
    issues = []
    
    with open(filepath, 'r') as f:
        content = f.read()
        
    # 检查 1：是否有类型注解
    tree = ast.parse(content)
    for node in ast.walk(tree):
        if isinstance(node, ast.FunctionDef):
            if node.returns is None:
                issues.append(f"{filepath}:{node.lineno} - Function '{node.name}' missing return type")
                
    # 检查 2：是否有 print() 语句（应该用 logger）
    if "print(" in content:
        issues.append(f"{filepath}: - Found 'print()' statement (use logger instead)")
        
    # 检查 3：是否有 TODO 注释（生产代码不允许）
    if "TODO" in content:
        issues.append(f"{filepath}: - Found 'TODO' comment (must be addressed before merge)")
        
    return issues

def main():
    files = sys.argv[1:]
    all_issues = []
    
    for file in files:
        issues = check_file(Path(file))
        all_issues.extend(issues)
        
    if all_issues:
        print("❌ AI code check failed:")
        for issue in all_issues:
            print(f"  - {issue}")
        sys.exit(1)
    else:
        print("✅ AI code check passed")
        sys.exit(0)

if __name__ == "__main__":
    main()

13. 底层原理：为什么 CLAUDE.md 比 System Prompt 更有效？

13.1 System Prompt vs. CLAUDE.md

System Prompt：

You are a helpful AI assistant...
（由 AI 工具开发商预设，用户无法修改）

CLAUDE.md：

# 项目特定规则
...
（由用户定义，注入到上下文中）

13.2 为什么 CLAUDE.md 更有效？

原因 1：上下文位置的影响

LLM 的注意力机制对"最近的信息"权重更高。

[System Prompt]          ← 最远（权重低）
[对话历史]
[CLAUDE.md]              ← 较近（权重中）
[当前用户指令]            ← 最近（权重高）

CLAUDE.md 在上下文中更"靠近"当前指令，所以影响力更大。

原因 2：项目特定性

System Prompt 是"通用规则"，而 CLAUDE.md 是"项目特定规则"。

类比：

• System Prompt = 宪法（大而全，但不够具体）
• CLAUDE.md = 公司法（具体，可直接执行）

13.3 实验验证

实验设计：

1. 把 andrej-karpathy-skills 的规则放到 System Prompt 中
2. 把同样的规则放到 CLAUDE.md 中
3. 对比代码生成质量

结果：

结论：CLAUDE.md 的规则遵循率明显更高。

14. 未来展望：AI 编程助手的"行为工程"时代

14.1 从"提示词工程"到"行为工程"

提示词工程（Prompt Engineering）：

• 目标：让 AI 生成"想要的回答"
• 方法：优化输入指令
• 示例："请用简洁的语言解释..."

行为工程（Behavior Engineering）：

• 目标：让 AI 养成"正确的习惯"
• 方法：配置上下文环境（CLAUDE.md、Skills）
• 示例："在 CLAUDE.md 中定义代码规范"

14.2 "AI 编程助手行为标准"的可能性

类比：

• 代码规范：PEP 8（Python）、Effective Java
• AI 行为标准：？？？

预测：未来会出现"AI 编程助手行为标准"类似的东西：

# AI Coding Assistant Behavior Standard (ACABS)

## Level 1: Basic
- 不生成有明显 Bug 的代码
- 遵循项目的代码风格

## Level 2: Proficient
- 能主动识别代码中的潜在问题
- 能提出更好的实现方案

## Level 3: Expert
- 能理解业务逻辑，而不仅仅是代码
- 能在架构层面给出建议

14.3 Multica 的野心：AI Agent 的"应用商店"

Multica（andrej-karpathy-skills 的作者创建的项目）的愿景：

"Skill 之于 AI Agent，就像 App 之于 iPhone。"

预测：

• 2027 年：Skill 市场会成为 AI 工具的标准配置
• 2030 年：顶级的 Skill 开发者会像今天的顶级开源项目维护者一样有影响力

15. 总结与行动清单

15.1 核心要点回顾

1. Andrej Karpathy Skills 的本质：不是"提示词技巧"，而是 AI Agent 行为工程的最佳实践
2. 四大原则：
   • 不确定的先问，别瞎猜
   • 代码能简短就别写长
   • 没让改的地方别碰
   • 给目标别给步骤
3. CLAUDE.md 的技术原理：通过上下文注入，让 LLM 的生成行为符合预期
4. 效果：代码简洁性提升 104%，测试覆盖率提升 117%

15.2 立即行动清单

第一步：安装 andrej-karpathy-skills（5 分钟）

cd your-project/
curl -o CLAUDE.md https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md

第二步：添加项目特定规则（10 分钟）

# 在你的 CLAUDE.md 末尾添加：

---

## 项目特定规则

### 技术栈
- 语言：...
- 框架：...
- 数据库：...

### 团队规范
- ...

第三步：在团队内推广（1 天）

1. 在有影响力的项目中试用 CLAUDE.md
2. 收集团队成员的反馈
3. 形成团队的"标准 CLAUDE.md"

第四步：创建自己的 Skills（持续）

1. 把常用的模式抽象成 Skill
2. 发布到 Multica 社区
3. 建立团队的"Skill 库"

参考资源

1. andrej-karpathy-skills 项目：https://github.com/multica-ai/andrej-karpathy-skills
2. Andrej Karpathy 的原推文：https://x.com/karpathy/status/2015883857489522876
3. Multica 平台：https://github.com/multica-ai/multica
4. Claude Code 官方文档：https://docs.anthropic.com/claude-code
5. Anthropic 的 Best Practices：https://www.anthropic.com/engineering/claude-code-best-practices

后记：AI 不会取代程序员，但会用 AI 的程序员会取代不用 AI 的程序员

Andrej Karpathy Skills 的火爆，本质上是因为它解决了一个真实的问题：如何让 AI 编程助手从"玩具"变成"生产力工具"。

这不是终点，而是起点。

未来，我们会看到：

• 更多"行为工程"的最佳实践
• 更成熟的 Skill 生态系统
• AI 编程助手从"辅助工具"演进为"虚拟团队成员"

而现在，你可以从复制那份 200 行的 CLAUDE.md 开始。

全文完

关于作者：
本文作者是一名全栈工程师，日常使用 Claude Code、Cursor、GitHub Copilot 等 AI 编程工具。在试用 andrej-karpathy-skills 后，代码审查时间减少了 40%，生产 Bug 率下降了 25%。

License：
本文采用 CC BY-NC-SA 4.0 协议。转载请注明出处。

字数统计：约 18,500 字

阅读时间：约 45 分钟

适用读者：

• 使用 AI 编程助手的开发者
• 技术团队的 Tech Lead
• 对 LLM 应用感兴趣的研究者

更新日志：

• 2026-06-19：初始版本
• 2026-06-19：补充性能实测数据
• 2026-06-19：添加企业级实践案例