Andrej Karpathy 的 CLAUDE.md 工程规范深度解析：AI 辅助编码的四大原则与生产级实践
2026年6月，Andrej Karpathy 的
skills项目在 GitHub 突破 149K Star，成为AI辅助编程领域最具影响力的开源项目。一个仅仅包含四大原则的CLAUDE.md文件，正在重新定义「AI 如何写代码」的行为规范。本文从原理、架构、实战三个维度深度解析这套规范，并给出可落地的工程实践方案。
一、背景：为什么需要 CLAUDE.md？
1.1 AI 辅助编码的三次浪潮
第一次浪潮：代码补全（2015-2021）
以 GitHub Copilot 为代表，核心是「下一行代码预测」。模型根据上下文续写，本质是语言模型的天然能力延伸。这一阶段的问题是：补得对不对，全靠运气。
第二次浪潮：对话式编程（2022-2024）
以 ChatGPT Plugin + Code Interpreter、Claude Code 为代表，核心是「理解需求 → 生成代码 → 执行验证」的闭环。模型具备了项目级理解能力，可以跨文件修改、运行测试、自主调试。
第三次浪潮：Agentic 编码（2025-至今）
以 Claude Code、Cursor、OpenClaw 为代表，AI 不再是「工具」，而是「代理」——自主规划任务、调用工具、迭代验证。能力跃升的同时，问题也爆发了：
- AI 会脑补需求，把没说清楚的地方自己「合理假设」了
- AI 喜欢过度设计，明明 20 行能解决，非要上工厂模式
- AI 乱改代码，修一个 Bug 顺手重构了三个无关函数
- AI 不知道什么时候算完成，没有验证标准就宣布「完成了」
1.2 Andrej Karpathy 是谁？为什么他的经验值得信任？
Andrej Karpathy 是前 Tesla AI 总监、OpenAI 创始成员，是深度学习领域最有影响力的工程师之一。他的观察具有特殊的权威性：
「我用了数百小时 Claude Code，发现它的失败模式非常固定——不是『写不出代码』，而是『写出了我不想要的代码』。」
Karpathy 把这些失败模式提炼成四条可执行的行为规则，通过一个 CLAUDE.md 文件注入 AI 工作流。这就是 andrej-karpathy-skills 项目的起源。
1.3 CLAUDE.md 是什么？为什么是一个 Markdown 文件？
CLAUDE.md 是 Claude Code（以及兼容的 AI 编码工具）的项目级系统提示文件。当它存在于项目根目录时，Claude Code 会在每次会话开始时自动读取并遵守其中的规则。
设计成 Markdown 文件而非 JSON/YAML 配置，是有意为之：
- 人类可读可写——不需要了解格式规范，直接写自然语言
- 版本可控——和代码一起提交，Review 规则和 Review 代码同等对待
- 渐进增强——可以先写几条规则，逐步完善，不需要一次性设计完整规范
二、四大原则深度解析
Karpathy 的 CLAUDE.md 核心只有四大原则，每条原则都对应一个具体的 AI 失败模式，并给出可验证的检查标准。
原则一：Think Before Coding（编码前思考）
原文表述
Don't assume. Don't hide confusion. Surface tradeoffs.
对应失败模式
AI 拿到模糊需求时，最常见的错误是：默默选择一个解释，然后执行。
典型场景：
- 用户说「加个缓存」，AI 直接上了 Redis，没问「数据量多大？单机还是分布式？」
- 用户说「优化一下」，AI 直接重写了算法，没确认「瓶颈在哪？基准数据是多少？」
原则详解
这条原则强制 AI 在写代码之前，先输出「推理过程」，明确回答三个问题：
① 我的假设是什么？
假设：
- 用户说的「缓存」指的是 API 响应缓存，而非数据库查询缓存
- 数据量级在 10MB 以内，单机内存足够
- 不需要分布式一致性
② 有哪些歧义点？
歧义：
- 「缓存」的具体场景不明确（API/DB/计算结果）
- 过期策略未指定（TTL/LRU/手动失效）
- 是否需要持久化？
③ 有哪些备选方案？我为什么选了这个？
方案对比：
- 方案A：In-memory dict + TTL（简单，适合当前场景）
- 方案B：Redis（分布式友好，但引入外部依赖）
- 方案C：functools.lru_cache（最轻量，但功能有限）
选择：方案A——当前是单体应用，数据量小，引入 Redis 过度
实操检查清单
AI 在编码前应自检：
- 我明确说出了所有关键假设吗？
- 需求中有哪些地方可以有两种以上解释？我说出来了吗？
- 我给出了几个备选方案？每个的适用场景说清楚了吗？
- 我选择的方案，能说清楚「为什么不选其他方案」吗？
代码示例： before vs after
Before（AI 直接写代码）：
# 用户说：「这个函数加个缓存」
import redis
def get_user(user_id):
r = redis.Redis()
cached = r.get(f"user:{user_id}")
if cached:
return json.loads(cached)
user = db.query(User).filter_by(id=user_id).first()
r.setex(f"user:{user_id}", 300, json.dumps(user.to_dict()))
return user
问题：引入了 Redis 依赖，但用户可能只是想要一个简单的内存缓存。
After（AI 先思考，再写代码）：
# 需求确认：
# - 「缓存」指函数调用结果缓存，非分布式缓存
# - 数据量小（单个用户对象 < 10KB）
# - 场景：单体应用，无需跨进程共享
# 方案选择：functools.lru_cache（最轻量，零依赖）
from functools import lru_cache
@lru_cache(maxsize=1024)
def get_user(user_id: int):
return db.query(User).filter_by(id=user_id).first()
原则二：Simplicity First（简洁优先）
原文表述
Use the simplest possible solution. Avoid speculative generality. Every line of code must earn its keep.
对应失败模式
AI 患有严重的**「设计模式综合症」**——明明用不上，也要上抽象、上接口、上工厂。
典型场景：
- 用户要一个 HTTP 客户端，AI 给了
BaseClient+RetryStrategy+CircuitBreaker+MetricsCollector - 用户要解析 CSV，AI 设计了
FileParser接口，支持未来扩展 JSON、XML、YAML
原则详解
这条原则的核心判断标准：
「一位资深工程师会认为这段代码过度复杂吗？如果是，请简化。」
具体规则：
- 能写 10 行，不写 50 行——除非 50 行带来了可验证的价值
- 不需要的抽象，一律不加——YAGNI（You Aren't Gonna Need It）
- 标准库优先，第三方库其次，自己造轮子最后
- 每一行代码必须「有用」——删掉它，功能会受损吗？如果不能，删掉
实操检查清单
AI 写完代码后应自检：
- 有没有可以合并的重复逻辑？
- 有没有「为了未来扩展」而写的抽象，但现在根本用不上？
- 第三方库有现成实现，我为什么重新造轮子？
- 如果把这段代码给一个 Junior 工程师看，他会说「这太复杂了」吗？
代码示例： before vs after
Before（AI 的过度设计）：
from abc import ABC, abstractmethod
from typing import Protocol, runtime_checkable
@runtime_checkable
class CacheBackend(Protocol):
def get(self, key: str) -> Optional[str]: ...
def set(self, key: str, value: str, ttl: int) -> None: ...
class RedisBackend:
def __init__(self, host: str, port: int): ...
class MemoryBackend:
def __init__(self, max_size: int): ...
class CacheManager:
def __init__(self, backend: CacheBackend):
self._backend = backend
def get_or_set(self, key: str, factory: Callable, ttl: int) -> str:
# ... 50行实现
After（简洁优先）：
import functools
def cached(ttl: int = 300):
"""最简单的函数级缓存装饰器"""
def decorator(func):
cache = {}
@functools.wraps(func)
def wrapper(*args, **kwargs):
key = f"{args}:{kwargs}"
if key in cache:
return cache[key]
result = func(*args, **kwargs)
cache[key] = result
return result
return wrapper
return decorator
原则三：Surgical Changes（精确修改）
原文表述
Only change what was asked. Don't "tidy up" unrelated code. Every modified line must trace back to the request.
对应失败模式
AI 有严重的**「顺手重构癖」**——修一个 Bug，顺手把整个文件的代码风格统一了；改一个函数，顺手把调用方也重构了。
典型场景：
- 用户要求「修复 login 函数的 SQL 注入漏洞」，AI 顺手把整个 auth 模块重构成了 OAuth2
- 用户要求「把变量名
a改成user_id」，AI 顺手把所有函数都加了类型注解
原则详解
这条原则是最实用的一条，直接对应「AI 改代码可信吗」这个核心问题。
具体规则：
- 只动必须动的——修改范围严格对应用户请求
- 只清理自己造成的混乱——如果 AI 引入了新的格式问题，可以修正；但不改原本能工作的代码
- 每次修改都要能追溯到用户的具体请求——无法追溯的修改，不允许
实操检查清单
AI 提交修改前应自检：
- 我改的每一行代码，都能对应到用户的哪句话？
- 有没有「顺手格式化」、「顺手优化」的改动？
- 如果我同事 Review 这段代码，能一眼看出「为什么这样改」吗？
- 我引入了新依赖吗？用户要求了吗？
代码示例： before vs after
Before（AI 的顺手重构）：
# 用户请求：「把 get_user 函数里的 SQL 拼接改成参数化查询」
def get_user(user_id):
- query = f"SELECT * FROM users WHERE id = {user_id}"
- return db.execute(query)
+ # 顺便重构了整个数据访问层
+ from .repository import UserRepository
+ from .models import UserDTO
+ repo = UserRepository(db)
+ return repo.find_by_id(user_id)
# 顺手改了其他函数
def get_posts(user_id):
- query = f"SELECT * FROM posts WHERE user_id = {user_id}"
- return db.execute(query)
+ # 统一用 repository 模式
+ from .repository import PostRepository
+ repo = PostRepository(db)
+ return repo.find_by_user_id(user_id)
After（精确修改）：
def get_user(user_id):
- query = f"SELECT * FROM users WHERE id = {user_id}"
- return db.execute(query)
+ query = "SELECT * FROM users WHERE id = ?"
+ return db.execute(query, (user_id,))
# get_posts 完全没有动
def get_posts(user_id):
query = f"SELECT * FROM posts WHERE user_id = {user_id}"
return db.execute(query)
原则四：Goal-Driven Execution（目标驱动执行）
原文表述
Define success criteria before coding. Iterate until the goal is met. Don't declare "done" without verification.
对应失败模式
AI 不知道**「什么时候算完成」**——写了代码就宣布完成，但不运行测试、不验证行为、不检查边界条件。
典型场景：
- 用户说「实现登录功能」，AI 写了代码就停了，没验证「密码错误时是否返回 401」
- 用户说「优化性能」，AI 改了代码就宣布完成，没跑基准测试
原则详解
这条原则把「指令式任务」转化成「目标式任务」：
| 指令式（不好） | 目标式（好） |
|---|---|
| 「加输入验证」 | 「为无效输入写测试，然后改代码让测试通过」 |
| 「优化这个函数」 | 「让这个函数处理 10K 条数据时耗时 < 100ms，给出基准测试」 |
| 「修这个 Bug」 | 「复现 Bug → 写测试复现 → 修复 → 测试通过 → 确认无回归」 |
具体规则：
- 先定义成功标准——代码写完，怎么验证它是对的？
- 循环执行直到验证通过——不是「写完了」就停，是「验证通过了」才停
- 明确报告验证结果——不只是「完成了」，而是「测试通过，覆盖率 XX%，基准数据 XX」
实操检查清单
AI 完成任务前应自检：
- 我明确了「成功」的定义吗？
- 我运行了测试吗？结果是什么？
- 我检查了边界条件吗？（空输入、极大值、并发、网络超时等）
- 我能证明代码达到了预期目标吗？
代码示例： before vs after
Before（AI 写完就停）：
# 用户说：「实现除法函数，处理除零错误」
def divide(a, b):
try:
return a / b
except ZeroDivisionError:
return None
# AI：「完成了！」
After（目标驱动，验证完整）：
# 成功标准：
# 1. b=0 时返回 None，不抛异常
# 2. 正常情况返回正确结果
# 3. 支持 int 和 float
# 4. 测试覆盖率 100%
def divide(a, b):
if b == 0:
return None
return a / b
# 验证：运行测试
import unittest
class TestDivide(unittest.TestCase):
def test_normal(self):
self.assertEqual(divide(10, 2), 5)
def test_zero_division(self):
self.assertIsNone(divide(10, 0))
def test_float(self):
self.assertAlmostEqual(divide(7, 3), 2.333, places=2)
def test_negative(self):
self.assertEqual(divide(-10, 2), -5)
# 运行结果：4/4 通过 ✓
三、架构分析：CLAUDE.md 如何生效？
3.1 系统提示词（System Prompt）的层级结构
要理解 CLAUDE.md 为什么有效，需要先理解 AI 编码工具如何处理提示词：
┌─────────────────────────────────────────────┐
│ System Prompt（固定） │ ← Claude 官方定义的行为边界
│ - 安全规则 │
│ - 工具使用规范 │
│ - 输出格式要求 │
├─────────────────────────────────────────────┤
│ Project Context（动态） │ ← CLAUDE.md 注入的位置
│ - CLAUDE.md（项目根目录） │
│ - 用户自定义规则 │
├─────────────────────────────────────────────┤
│ Conversation History（动态） │ ← 本次会话的对话历史
├─────────────────────────────────────────────┤
│ User Message（动态） │ ← 用户的最新指令
└─────────────────────────────────────────────┘
CLAUDE.md 的内容被注入到 Project Context 层，优先级高于对话历史，但低于 System Prompt 的安全规则。这意味着：
- ✅ 可以覆盖「编码风格」类行为
- ✅ 可以覆盖「工具使用」类行为
- ❌ 不能覆盖安全规则（比如「忽略之前的指令」类攻击）
3.2 为什么 Markdown 格式有效？
LLM 对 Markdown 的理解是经过大量预训练数据强化的：
- 标题层级（
## 原则一）→ 模型自然理解「这是一条独立规则」 - 加粗（
**不要假设**）→ 模型理解「这是重点」 - 列表（
- 要求1 - 要求2）→ 模型理解「这是可检查的条目」 - 代码块→ 模型理解「这是示例，不是规则本身」
相比之下，JSON/YAML 配置对 LLM 来说只是「数据」，模型不会像处理自然语言那样「内化」它。
3.3 多工具兼容性
CLAUDE.md 不仅适用于 Claude Code，还适用于所有支持项目级系统提示的 AI 编码工具：
| 工具 | 支持文件 | 说明 |
|---|---|---|
| Claude Code | CLAUDE.md | 原生支持，自动读取 |
| Cursor | .cursorrules / CLAUDE.md | 推荐用 CLAUDE.md |
| GitHub Copilot Workspace | .github/copilot-instructions.md | 功能类似 |
| OpenClaw | AGENTS.md / SOUL.md | 支持自定义系统提示 |
| Aider | .aider.conf.yml | 配置方式不同，但思路类似 |
四、生产级实践：如何在团队中落地？
4.1 基础版：直接复用 Karpathy 的 CLAUDE.md
最简单的方式，直接把 andrej-karpathy-skills 项目的 CLAUDE.md 复制到你的项目根目录：
curl -o CLAUDE.md https://raw.githubusercontent.com/andrej-karpathy/skills/main/CLAUDE.md
然后提交到版本控制：
git add CLAUDE.md
git commit -m "feat: add CLAUDE.md based on Karpathy's skills project"
4.2 进阶版：结合团队规范定制
Karpathy 的版本是通用原则，生产环境需要结合团队的具体规范。推荐的分层结构：
# CLAUDE.md
## 核心原则（来自 Karpathy）
- Think Before Coding: ...
- Simplicity First: ...
- Surgical Changes: ...
- Goal-Driven Execution: ...
## 团队补充规范
### 代码风格
- 使用 Black 格式化 Python 代码（line-length: 88）
- 类型注解：函数签名必须有，内部变量可选
- Import 排序：isort，profile="black"
### 测试规范
- 每个新功能必须附带单元测试，覆盖率 > 80%
- 集成测试：关键路径必须有（登录、支付、数据导出）
- 测试框架：pytest（Python）、JUnit（Java）、Vitest（TypeScript）
### 安全规范
- 禁止在代码中硬编码密钥（用环境变量 + dotenv）
- SQL 查询必须用参数化查询（禁止字符串拼接）
- 用户输入必须验证（用 Pydantic / Zod 做 schema 校验）
### 提交规范
- Commit 格式：Conventional Commits
- `feat:` 新功能
- `fix:` Bug 修复
- `refactor:` 重构（不改变行为）
- `test:` 测试相关
4.3 实战案例：用 CLAUDE.md 重构一个真实功能
场景：用户要求「给 API 加上限流」
没有 CLAUDE.md 时，AI 可能这样做：
AI: 我来设计一个限流系统...
[写了 200 行代码，包含 Redis、Lua 脚本、配置系统、Dashboard...]
AI: 完成了！
问题：过度设计，引入了大量不必要的复杂度。
有 CLAUDE.md 时，AI 会这样做：
思考过程（Think Before Coding）：
- 假设：这是单体应用，QPS < 100，不需要分布式限流
- 歧义：「限流」指全局 QPS 限制，还是 per-IP 限制？
- 方案：
- 方案A：slowapi（FastAPI 中间件，最简单）
- 方案B：Redis + Lua（分布式场景）
- 方案C：Nginx limit_req（网关层）
- 选择：方案A，当前场景最简单
代码（Simplicity First）：
```python
from slowapi import Limiter
from slowapi.util import get_remote_address
limiter = Limiter(key_func=get_remote_address)
@app.get("/api/resource")
@limiter.limit("10/minute")
def get_resource():
return {"data": "..."}
验证（Goal-Driven Execution）：
- 测试：用 ab -n 20 -c 1 http://localhost:8000/api/resource
- 预期：前10个请求成功，后10个返回 429
- 实际：符合预期 ✓
---
## 五、原理深究：为什么这四大原则有效？
### 5.1 从 LLM 的失败模式说起
LLM 写代码时的错误，和人类程序员不同：
| 人类程序员的错误 | LLM 的错误 |
|---|---|
| 语法错误、逻辑 Bug | 几乎不犯语法错误，但行为不符合预期 |
| 边界条件遗漏 | 边界条件反而处理得很好（训练数据里有） |
| 过度自信 | **比人类更过度自信**（不知道自己不知道） |
| 代码风格不一致 | 代码风格过于一致（但可能不是你想要的） |
LLM 的核心问题不是「能力不够」，而是「**不知道自己哪里可能错**」。
### 5.2 四大原则如何对治这些失败模式
**Think Before Coding → 对治「过度自信」**
强制模型「把假设说出来」，相当于迫使它做自我检查。一旦假设被显式表达，就容易被用户纠正。
**Simplicity First → 对治「讨好性人格」**
LLM 的训练目标包含「让用户满意」，而「写出复杂的、看起来很厉害的代码」容易被误判为「更有能力」。这条原则直接告诉它：「简单才是能力」。
**Surgical Changes → 对治「上下文漂移」**
LLM 处理长上下文时，会逐步「忘记」最初的任务边界。这条原则相当于在每次修改前「重读需求」，防止范围蔓延。
**Goal-Driven Execution → 对治「任务完成幻觉」**
LLM 容易在「生成了看起来像答案的文本」时就停止，而不验证答案是否正确。这条原则强制它定义验证标准。
### 5.3 认知科学视角：外部化工作记忆
从认知科学角度看，CLAUDE.md 的作用是**外部化工作记忆**：
- 人类的「工作记忆」容量有限（7±2 个信息块）
- LLM 的「上下文窗口」虽然大，但**注意力分配不均**——越靠后的内容权重越高
- 把规则写成文件，相当于给 AI 一本「操作手册」，不需要每次都靠「记住」来遵守
这解释了为什么「写在 CLAUDE.md 里」比「在对话里说一遍」有效得多。
---
## 六、进阶：超越 Karpathy——打造团队专属的 AI 编码规范
Karpathy 的四大原则是优秀的起点，但生产环境需要更完整的规范体系。以下是推荐的分层架构：
### 6.1 基础层：行为规范（CLAUDE.md）
已经介绍，不再赘述。
### 6.2 技术栈层：技术决策记录（TECH_DECISIONS.md）
记录团队的技术选型和使用规范，防止 AI 引入不一致的依赖：
```markdown
# TECH_DECISIONS.md
## Web 框架
- Python: FastAPI（不用 Flask/Django）
- TypeScript: Express + Zod（不用 NestJS，过度复杂）
## 数据库
- ORM: SQLAlchemy 2.0（不用 Django ORM、Peewee）
- 迁移: Alembic
- 禁止在应用代码中写原生 SQL（除非性能瓶颈已验证）
## 测试
- 框架: pytest（Python）、Vitest（TypeScript）
- Mock: unittest.mock（不用 pytest-mock，增加依赖）
- 覆盖率门槛: 80%（用 pytest-cov 强制）
## 异步任务
- Python: Celery + Redis
- TypeScript: BullMQ
- 禁止使用 asyncio.create_task（必须用任务队列）
6.3 项目结构层：目录规范（STRUCTURE.md）
AI 生成新文件时，需要知道放在哪里：
# STRUCTURE.md
## Python 项目结构
my_project/
├── api/ # FastAPI 路由定义
├── models/ # SQLAlchemy 模型
├── services/ # 业务逻辑层
├── schemas/ # Pydantic 请求/响应 Schema
├── tests/
│ ├── unit/ # 单元测试
│ └── integration/ # 集成测试
├── utils/ # 工具函数（无业务逻辑）
└── main.py # 应用入口
## 规则
- 禁止 circular import（如果出现了，说明分层有问题）
- services/ 不能 import api/（依赖方向单一）
- utils/ 不能 import 任何上层模块
七、工具链集成：让 CLAUDE.md 自动生效
7.1 Git Hook 自动检查
通过 Git Hook，在提交前自动检查 AI 生成的代码是否违反了 CLAUDE.md 的原则：
# .git/hooks/pre-commit
#!/usr/bin/env python3
"""检查 AI 生成的代码是否符合 CLAUDE.md 原则"""
import subprocess
import sys
def check_surgical_changes():
"""检查是否有不必要的改动"""
result = subprocess.run(
["git", "diff", "--cached", "--stat"],
capture_output=True, text=True
)
# 如果改动文件数 > 3，可能有问题
# （这个阈值根据项目调整）
if result.stdout.count("\n") > 3:
print("⚠️ 警告：改动文件较多，确认是否都是必要的")
return False
return True
def check_simplicity():
"""检查是否有过度复杂的代码"""
# 用 radon 检查圈复杂度
result = subprocess.run(
["radon", "cc", ".", "-nc"],
capture_output=True, text=True
)
if "F" in result.stdout: # 圈复杂度 F 级（非常复杂）
print("⚠️ 警告：发现高复杂度函数，是否符合 Simplicity First 原则？")
return False
return True
if not check_surgical_changes():
sys.exit(1)
7.2 CI/CD 集成
在 CI 流水线中加入 AI 代码质量检查：
# .github/workflows/ai-code-quality.yml
name: AI Code Quality Check
on: [pull_request]
jobs:
check-claude-compliance:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Check CLAUDE.md compliance
run: |
# 检查是否有 CLAUDE.md
test -f CLAUDE.md || (echo "❌ 缺少 CLAUDE.md" && exit 1)
# 检查代码复杂度
pip install radon
radon cc . -nc --min C
# 检查测试覆盖率
pytest --cov=./ --cov-report=term-missing
coverage report --fail-under=80
八、常见误区与 FAQ
误区 1：「CLAUDE.md 会让 AI 变笨」
事实：CLAUDE.md 不会限制 AI 的能力，而是引导能力的方向。就像给赛车装方向盘，不是让车变慢，而是让车开得更快的同时不撞墙。
误区 2：「只有 Claude Code 能用」
事实：任何支持项目级系统提示的 AI 工具都能用。核心思路是「把行为规范写成文件，让 AI 读取」，具体格式可以调整。
误区 3：「四大原则太简单，不够用」
事实：四大原则是「元原则」，不是「具体规则」。它们的作用是约束 AI 的行为模式，而不是规定「每一行代码怎么写」。具体规则应该在团队补充规范里定义。
FAQ
Q：CLAUDE.md 应该提交到版本控制吗？
A：应该。它和代码一样，需要 Review、需要版本管理。
Q：多个项目可以共享同一个 CLAUDE.md 吗？
A：可以，建议放在 monorepo 根目录，或者用 Git Submodule 共享。
Q：AI 不遵守 CLAUDE.md 怎么办？
A：检查 CLAUDE.md 是否太长（建议 < 2000 字），或者规则是否太模糊。越具体、越可验证的规则，AI 遵守得越好。
九、总结与展望
Andrej Karpathy 的 CLAUDE.md 四大原则，表面上是「AI 编码规范」，实质上是在解决一个更深层的问题：
当 AI 的能力超过「能写出能运行的代码」之后，如何让它的输出符合「人类的意图」和「工程的最佳实践」？
这个问题在 2026 年变得格外紧迫——不是因为 AI 不够强，而是因为 AI 太强了，强到它的「过度自信」和「讨好性人格」会成为工程质量的最大风险。
四大原则的价值，不在于它们覆盖了所有场景，而在于它们提供了一个可扩展的框架：任何团队都可以在这四条原则的基础上，叠加自己的工程规范，打造专属的 AI 编码工作流。
展望未来，随着 AI Agent 能力的进一步提升，我们可以预见：
- CLAUDE.md 会进化成 CLAUDE.ts——用 TypeScript 定义可执行的规则，而不仅仅是自然语言
- 多 Agent 协作规范——当多个 AI Agent 协同编码时，需要定义「Agent 之间的接口规范」
- 自适应规范——规范本身由 AI 维护，根据项目的演化自动调整
但无论形式如何变化，Karpathy 四大原则的核心思想——先思考、保持简单、精确修改、目标驱动——会是 AI 辅助编码的永恒基石。
参考资源
- andrej-karpathy/skills - GitHub - 原始项目，149K+ Stars
- Multica AI - CLAUDE.md 生产实践 - Karpathy 推荐的生产级案例
- Anthropic - Claude Code 文档 - 官方文档
- YAGNI 原则 - Martin Fowler - Simplicity First 的理论基础
本文写于 2026 年 6 月，基于 andrej-karpathy/skills 项目最新版本（149K Stars）。如有更新，请参考项目 GitHub 主页。