GITHUB DAILY · 第038期
一个 .md 文件，150K Stars：
Karpathy 的 AI 编程四诫
从 OpenAI 联合创始人的洞察到全球开发者的行为准则
用 4 条规则解决 LLM 编程 80% 的常见错误
📋 项目速览
项目名称andrej-karpathy-skills
GitHub 地址multica-ai/andrej-karpathy-skills
总 Stars⭐ 149,580+
今日新增🔥 +3,507（Trending 榜首）
Forks15,300+
协议MIT
核心文件单个 CLAUDE.md（Markdown）
适配平台Claude CodeCursorCopilot****Codex
灵感来源Andrej Karpathy（OpenAI 联合创始人、前 Tesla AI 总监）
🤔 它能解决什么问题？
你用 Claude Code、Cursor 等 AI 编程工具时，是不是经常遇到这些"翻车"场景？
翻车一：AI 默默猜需求，执行完了才发现方向全错
你说"添加用户验证"，AI 直接写了一套 OAuth 完整流程——但你只需要一个简单的手机号验证。它不问、不确认、不展示方案，直接"开干"。
翻车二：改一行代码，AI 顺手"优化"了整个文件
让它修一个 bug，它顺便重构了错误处理、改了变量命名、删了"看起来没用"的注释、格式化了整个文件——结果 Diff 有 200 行，其中 180 行跟任务无关。
翻车三：100 行能搞定的事，AI 写了 800 行
改个数据库连接字符串，AI 给你整出 800 行配置系统：环境变量 + JSON 文件 + 远程配置中心 + 热更新 + Schema 验证……你只需要一行代码。
翻车四：AI 说"应该能工作了"，但你不知道到底行不行
没有测试验证、没有成功标准、没有自动校验——AI 写完就算"完成"，正确性完全靠手动检查，人变成了 AI 的 QA。
Andrej Karpathy 在 X（Twitter）上精准总结了 LLM 编程的三大通病：错误假设不检查、过度复杂化、副作用修改。这些问题不是偶发，而是 LLM 的系统性缺陷。
✨ 核心亮点：四条规则，系统治愈 LLM 编程通病
andrej-karpathy-skills 的核心是一个 CLAUDE.md 文件，里面只有 4 条行为规则。每条规则精确对应一个 Karpathy 观察到的 LLM 编程陷阱，从推理、架构、修改范围、目标定义四个维度规范 AI 行为。
🧠 规则一：Think Before Coding（先思考，再编码）
**针对问题：**AI 默默假设需求，不澄清就执行
**核心要求：**在写任何代码之前，AI 必须——
-
明确陈述自己对需求的所有假设
-
如果需求有多种解读，主动展示 2-3 种方案并说明各自的取舍
-
发现更简单或更优的方案时，主动提出建议
-
遇到模糊不清的地方，先停下来寻求用户澄清
❌ 没有 Karpathy Skills用户：帮我添加用户验证
AI：（默默假设需要邮箱+密码+记住我+密码强度检测，直接写出完整 OAuth 流程）
✅ 有 Karpathy SkillsAI：在开始之前，我需要确认几个问题：
1. 验证方式选 JWT 还是 Session？
2. 需要社交登录吗？
3. 你的系统是单体应用，我推荐 Session 方案，同意吗？
✂️ 规则二：Simplicity First（简洁优先）
**针对问题：**AI 过度设计，100 行能搞定的写出 1000 行
**核心要求：**用最少的代码解决问题——
-
不添加任何未被要求的功能
-
不为单次使用的代码创建抽象层
-
不添加未请求的"灵活性"或"可配置性"
-
不为不可能发生的场景写错误处理
-
如果 200 行能压缩成 50 行，就重写它
**检验标准：**资深工程师看到这段代码，会觉得"这也太复杂了"吗？如果是，就继续简化。
**❌ 过度设计（200 行）**class UserValidator:
def __init__(self, config=None):
self.config = config or self._load_default_config()
self.strategies = self._init_strategies()
self.cache = self._init_cache()
self.observers = []
# ... 共 200 行
**✅ 简洁实现（8 行）**def validate_user(email, password):
if not email or '@' not in email:
return False
if len(password) < 8:
return False
return True
🔬 规则三：Surgical Changes（精准修改）
**针对问题：**AI "顺手优化"无关代码，污染整个 Diff
**核心要求：**只触碰必须触碰的内容——
-
不"改进"相邻的代码、注释或格式
-
没有问题的代码不重构
-
匹配现有代码风格，即使你会用不同的方式写
-
发现死代码时，仅提示用户，不直接删除
**检验标准：**每一行修改都能直接追溯到用户的请求。说不清楚为什么改的那行，就不改。
🎯 规则四：Goal-Driven Execution（目标驱动执行）
**针对问题：**AI 写完代码就算"完成"，没有验证标准
**核心要求：**定义可验证的成功标准，循环直到通过——
-
把命令式任务转化为可验证目标
-
多步骤任务使用"步骤 → 验证"格式
-
编写测试定义"完成"是什么样子
-
让 AI 自主循环迭代，减少人工介入
Karpathy 的关键洞察："LLMs 非常擅长循环直到达成特定目标。不要告诉它做什么，给它成功标准，然后看它执行。"
| 命令式描述（弱） | 目标驱动描述（强） |
|---|---|
| "添加验证" | |
| "编写失败输入的测试用例，然后让用例通过" | |
| "修复 bug" | |
| "编写能复现 bug 的测试用例，然后让测试通过" | |
| "重构 X 模块" | |
| "确保重构前后所有测试用例都通过" | |
🧬 行为工程：为什么一个 .md 文件能改变 AI 行为？
这不是传统意义上的"提示词工程"，而是一种新的范式——行为工程（Behavior Engineering）。
工作原理
CLAUDE.md 是 Claude Code 的项目级配置文件。当 Claude Code 启动时，它会自动读取项目根目录的 CLAUDE.md，将内容注入到对话上下文中。这意味着每一条规则都会在每次会话开始时自动生效，持续影响 AI 的行为模式。
# 工作机制 项目根目录/CLAUDE.md ↓ Claude Code 启动时自动读取 ↓ 内容注入对话上下文 ↓ 成为每次对话的"前置工作守则" AI 行为被持久影响 ✅
多层配置体系
项目支持三级配置，实现全局规则和项目特殊规则的灵活组合：
| 层级 | 配置路径 | 生效范围 | 优先级 |
|---|---|---|---|
| 全局级 | |||
| Claude Code 插件安装 | |||
| 所有项目 | |||
| 最低 | |||
| 用户级 | |||
| ~/.claude/CLAUDE.md | |||
| 当前用户所有项目 | |||
| 中 | |||
| 项目级 | |||
| 项目根目录/CLAUDE.md | |||
| 仅当前项目 | |||
| 最高 | |||
高优先级的规则会覆盖低优先级的冲突内容，同时不同层级的规则会合并生效。你可以把 Karpathy 的四条通用规则作为全局配置，再在每个项目中添加特定的技术栈要求。
与提示词工程的关键区别
| 维度 | CLAUDE.md（行为工程） | 普通提示词工程 |
|---|---|---|
| 作用域 | ||
| 项目级，跨对话持续生效 | ||
| 会话级，随对话结束消失 | ||
| 复用性 | ||
| 可共享、可版本管理 | ||
| 一次性，不可复用 | ||
| 针对性 | ||
| 针对 LLM 编码的底层失败模式设计 | ||
| 零散的提示词，无系统性 | ||
| 验证性 | ||
| 内置目标驱动执行原则 | ||
| 依赖人工判断 | ||
🔧 实战场景展示
场景一：接手陌生代码库，让 AI 先理解再动手
假设你让 Claude Code 在一个不熟悉的仓库中添加缓存功能。没有 Karpathy Skills 时，AI 可能直接引入 Redis 并重写整个数据访问层。有了 Skills 后——
❌ 无约束直接写 Redis 集成代码（500+ 行），包括连接池管理、序列化/反序列化、缓存淘汰策略……用户实际只需要内存缓存，浪费半天时间。
✅ 有约束先澄清 3 个问题：①缓存策略选内存还是 Redis？②缓存粒度？③失效机制？结合单机服务的现状，推荐内存缓存 + TTL，获得用户同意后再实现。
场景二：Code Review 不再是噩梦
团队成员使用 AI 生成的代码提交 PR 时，没有 Skills 的 PR 通常包含大量无关修改——格式调整、变量重命名、"顺手"的重构。有了 Skills 后——
-
Diff 中减少不必要的修改，只出现被请求的变更
-
没有顺手重构或"改进"，每一行改动都可追溯到需求
-
代码审查时间预计减少 50% 以上
场景三：敏捷开发中快速迭代不翻车
需求经常变化的敏捷项目中，AI 遵循"简洁优先"和"目标驱动"原则后，不会为"将来可能的需求"提前做设计，每一轮迭代都保持最小可行方案，极大降低了技术债务的累积速度。
💡 返工减少 80%
遵循四条原则后，AI 编程中最常见的四类错误可被系统性消除，开发者对 AI 生成代码的信任度显著提升。
🚀 上手指南
整个安装过程只需要 1 分钟，支持三种方式：
1
方式一：Claude Code 插件（推荐，全局生效）
打开 Claude Code，依次执行：
# 添加插件市场源/plugin marketplace add multica-ai/andrej-karpathy-skills# 安装插件/plugin install andrej-karpathy-skills@karpathy-skills
2
方式二：项目级 CLAUDE.md（单项目生效）
将规则文件放到项目根目录即可：
# 新项目：直接下载curl -o CLAUDE.md raw.githubusercontent.com/multica-ai/… 已有项目：追加到现有文件echo "" >> CLAUDE.mdcurl raw.githubusercontent.com/multica-ai/… >> CLAUDE.md
3
方式三：Cursor 用户
官方已提供 Cursor 适配文件，复制到项目的规则目录即可自动生效：
cp .cursor/rules/karpathy-guidelines.mdc your-project/.cursor/rules/
自定义扩展
四条规则可与项目特定指令合并，在 CLAUDE.md 底部追加你的项目专属规则：
## Project-Specific Guidelines - Use TypeScript strict mode - All API endpoints must have tests - Follow the existing error handling patterns in src/utils/errors.ts
如何验证规则已生效？
| 生效信号 | 对应规则 |
|---|---|
| Diff 更干净，只有被请求的改动 | |
| Surgical Changes | |
| AI 首次输出就简洁，不需要重写 | |
| Simplicity First | |
| 澄清问题出现在实现之前（不是出错后） | |
| Think Before Coding | |
| PR 无无关的"顺手"改动 | |
| Surgical Changes | |
| AI 编写测试来验证自己的输出 | |
| Goal-Driven | |
异常信号识别
| AI 出现这些话 | 违反的规则 |
|---|---|
| "顺便优化一下" | |
| Surgical Changes | |
| "加个抽象层会更灵活" | |
| Simplicity First | |
| "我猜你是想…" | |
| Think Before Coding | |
| "应该能工作了" | |
| Goal-Driven Execution | |
⚖️ 权衡与局限
官方坦诚说明了这些规则的适用边界：
-
偏向谨慎而非速度：对于改拼写、改一行代码等简单任务，规则可能显得过于严格，不需要每次都走完整流程
-
软约束而非硬编码：CLAUDE.md 不是系统级提示词，AI 在复杂任务中存在上下文优先级权衡，规则不一定总是赢
-
仅覆盖编码场景：四条规则专为代码开发设计，不适用于文档生成、数据分析等非编码类 AI 任务
-
探索性原型需调整：快速试错的探索开发场景下，建议临时关闭"简洁优先"原则，允许 AI 做更多尝试
📝 今日总结
最小有效干预：一个 .md 文件、4 条规则、0 行代码，解决了 LLM 编程 80% 的常见错误——这是"最小可行方案"的完美诠释
行为工程新范式：不是让 AI 更聪明，而是给 AI 明确的行为边界。从"提示词工程"到"行为工程"的思维转变
顶级洞察 + 极简执行：Karpathy 从特斯拉和 OpenAI 的实战经验中提炼的观察，被压缩成可直接复制的配置文件
三级配置体系：全局 + 用户 + 项目级配置叠加，一套规则适配所有场景，还可自由扩展项目专属规则
150K Stars 的启示：最好的工具不一定是框架或 SDK，有时只是一份让所有人都能共鸣的洞察
即插即用：1 分钟安装，支持 Claude Code / Cursor / Copilot 等主流 AI 编程工具，零学习成本
📍 项目地址：github.com/multica-ai/andrej-karpathy-skills
🌟 今日 Stars：149,580+ | 🔥 今日新增：+3,507
GitHub Daily · 每天一个值得深读的开源项目
