Andrej Karpathy Skills：AI 智能体编程四项原则 介绍及扩展

Andrej Karpathy Skills：AI 智能体编程四项原则 介绍及扩展

一个 GitHub 上 74.9k Stars 的项目，一份改善 AI 编码行为的准则。

---

一、项目介绍

1.1 起源

Andrej Karpathy，前特斯拉 AI 总监、李飞飞学生、OpenAI 创始成员，现任 AI 教育者。他最早提出了 LLM 作为"认知操作系统"的理念，并指出当前 AI 在编程任务中的系统性缺陷。

2025 年，他的推文引发广泛讨论，核心观点被社区总结为三个"模型原罪"：

"模型会代你做错误假设，然后不假思索地执行。它们不管理自身的困惑，不寻求澄清，不呈现矛盾，不展示权衡，在应该提出异议时也不反驳。"
"它们真的很喜欢把代码和 API 搞复杂，堆砌抽象概念，不清理死代码......明明 100 行能搞定的事情，非要实现成 1000 行的臃肿架构。"
"它们有时仍会改动或删除自己理解不足的代码和注释，即使这些内容与任务本身无关。"

forrestchang/andrej-karpathy-skills 项目的核心就是一份单一的 CLAUDE.md 文件（74.9k Stars，6.9k Forks），将这些观察系统化为四条可执行的原则，供 AI 编程工具（Claude Code、Cursor 等）直接使用。

1.2 四项原则总览

#	英文名	中文名	核心要求
1	Think Before Coding	编码前思考	不假设、不隐藏困惑、主动呈现权衡
2	Simplicity First	简洁优先	最少代码解决问题，不做过度推测
3	Surgical Changes	精准修改	只碰必须碰的，只清理自己造成的混乱
4	Goal-Driven Execution	目标驱动执行	定义成功标准，循环验证直到达成

---

二、四项原则详解

原则 1：Think Before Coding（编码前思考）

原文：

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

中文翻译：

不要假设。不要隐藏困惑。呈现权衡。

核心思想：

AI 在面对模糊需求时，最常见的错误是默默选择一个解释然后闷头执行，不汇报自己哪里不确定。这个原则强制 AI 在编码前输出"推理过程"，明确说出：

• 我的假设是什么
• 有哪些歧义点
• 有哪些备选方案
• 我为什么选了这个方案

子要求：

要求	含义
State assumptions explicitly（明确说明假设）	如果不确定，询问而不是猜测
Present multiple interpretations（呈现多种解释）	当存在歧义时，不要默默选择
Push back when warranted（适时提出异议）	如果存在更简单的方法，说出来
Stop when confused（困惑时停下来）	指出不清楚的地方并要求澄清

举例说明：

假设用户说："帮我把用户模块加上缓存。"

违背原则的行为：AI 直接选型 Redis，设计一套复杂的缓存失效策略，代码写了 300 行。

符合原则的行为：

用户需求中未明确：
1. 缓存层位置（本地 vs 分布式？）
2. 缓存失效策略（TTL？主动 invalidate？）
3. 是否需要分布式锁？

我建议先确认：
- Q1: 现有系统是否有 Redis/ Memcached？还是新增？
- Q2: 缓存的数据一致性要求级别？
- Q3: 并发更新同一个 Key 的场景是否存在？

在我得到明确答案之前，先实现一个基于内存的 TTL 缓存作为基础版本。

---

原则 2：Simplicity First（简洁优先）

原文：

Minimum code that solves the problem. Nothing speculative.

中文翻译：

用最少的代码解决问题。不要过度推测。

核心思想：

这是对抗过度工程的原则。AI 有强烈的"取悦用户"冲动，容易进入"万一以后要用呢"的思维陷阱，产生大量未 Requested 的灵活性、可配置性和抽象层。

原则 2 的核心是：只实现明确要求的东西。

子要求：

要求	含义
No features beyond what was asked	不要添加要求之外的功能
No abstractions for single-use code	不要为一次性代码创建抽象
No "flexibility" that wasn't requested	不要添加未要求的"灵活性"或"可配置性"
No error handling for impossible scenarios	不要为不可能发生的场景做错误处理
Rewrite if 200 lines → 50 lines	如果 200 行代码可以写成 50 行，重写它

检验标准（The Test）：

Would a senior engineer consider this overly complex? If yes, simplify.
资深工程师会觉得这过于复杂吗？如果是，简化。

举例说明：

用户需求：读取 CSV 文件并输出前 10 行。

违背原则的 AI 输出：

• 设计一个 DataReader 抽象基类
• 实现 CSVReader、JSONReader、XMLReader
• 加上策略模式和工厂模式
• 500 行代码，引入 3 个新依赖

符合原则的 AI 输出：

with open("data.csv", "r") as f:
    for i, line in enumerate(f):
        if i >= 10:
            break
        print(line.strip())

29 字节（或者如果用户接受 Python 的话）。

---

原则 3：Surgical Changes（精准修改）

原文：

Touch only what you must. Clean up only your own mess.

中文翻译：

只碰必须碰的。只清理自己造成的混乱。

核心思想：

这条原则解决的是 AI 的**范围蔓延（Scope Creep）**问题------修改 A 模块时顺手改了 B 模块的风格，重构了 C 模块的死代码，删了 D 模块的注释。

编辑现有代码时的规则：

要求	含义
Don't "improve" adjacent code	不要"改进"相邻的代码、注释或格式
Don't refactor things that aren't broken	不要重构没坏的东西
Match existing style	匹配现有风格，即使你更倾向于不同的写法
Mention unrelated dead code, don't delete	如果注意到无关的死代码，提一下------不要删除它

当你的改动产生孤儿代码时：

要求	含义
Remove unused imports/variables/functions	删除因你的改动而变得无用的导入/变量/函数
Don't remove pre-existing dead code	不要删除本就存在的死代码，除非被要求

举例说明：

用户要求：修复登录接口的 SQL 注入漏洞。

违背原则的 AI：

• 顺便把整个 auth.py 重构成了 async/await 风格
• 改了 user.py 的命名风格（下划线→驼峰）
• 删掉了几个"看起来没用"的函数（后来发现是其他模块在用）

符合原则的 AI：

• 只修改登录验证相关的 SQL 语句参数化
• 提到"发现 auth.py 第 142 行有个未使用的函数 legacy_hash"
• 提到"其他模块有对 user.py 的依赖，本次未改动"

---

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

原文：

Define success criteria. Loop until verified.

中文翻译：

定义成功标准。循环验证直到达成。

核心思想：

这条原则的核心是把指令性任务转化为可验证的目标。不是告诉 AI"怎么做"，而是告诉 AI"做到什么算成功"，让 AI 自己循环执行直到满足标准。

Karpathy 的原话：

"LLMs are exceptionally good at looping until they meet specific goals... Don't tell it what to do, give it success criteria and watch it go."

执行模式：

1. [Step 1] → verify: [success criteria check]
2. [Step 2] → verify: [success criteria check]
3. [Step 3] → verify: [success criteria check]

不是线性执行，而是每一步都带验证的循环。

举例说明：

用户需求（指令式）："帮我把用户数据导出成 CSV，包含用户名、邮箱、注册时间。"

Goal-Driven 版本：

Goal: 用户可通过 /export 端点下载包含 username, email, created_at 的 CSV 文件

[Step 1] 创建 /export 路由 → verify: curl 返回 200 且包含 CSV header
[Step 2] 添加字段 username → verify: CSV 第一列存在且数据正确
[Step 3] 添加字段 email → verify: CSV 第二列存在且格式正确
[Step 4] 添加字段 created_at → verify: CSV 第三列存在且为时间戳格式
[Step 5] 端到端测试 → verify: 完整 CSV 可下载且字段完整

Done --- Only requested changes appear.

---

三、思想提炼

3.1 每项原则的核心机制

原则	解决的问题	核心机制
Think Before Coding	模糊时闷头执行	强制显式推理：不确定就问，不要猜
Simplicity First	过度工程	需求边界控制：只做要求的，不做猜测的
Surgical Changes	范围蔓延	最小改动集：只碰必要的，不动无关的
Goal-Driven Execution	指令式陷阱	目标可验证化：给标准而非给步骤

3.2 四项原则的内在联系

Think Before Coding        →  定义"做什么"（以及"什么不做"）
         ↓
Simplicity First          →  定义"怎么做"（最小实现）
         ↓
Surgical Changes         →  定义"改什么"（最小改动）
         ↓
Goal-Driven Execution    →  定义"做到什么标准"（可验证）

四项原则构成一个完整的 AI 行为约束链：推理 → 设计 → 编辑 → 验证，每个环节都有明确的红线。

---

四、从编程领域到通用智能体领域的扩展

4.1 扩展思路

四项原则的底层逻辑并不依赖"代码"这个载体。它们本质上是：

• 认知对齐约束：让 AI 的推理过程对人类可见
• 资源边界约束：防止 AI 消耗远超必要算力
• 变更边界约束：防止 AI 对环境造成非预期的改变
• 目标澄清约束：把模糊指令转化为可测量标准

这些约束在通用智能体场景下同样适用，甚至更加重要------因为通用任务的边界比编程任务更模糊，环境比代码仓库更复杂。

4.2 扩展对照表

编程场景	通用智能体场景
写代码	执行多步骤任务（发邮件、查数据、订票等）
修改代码	操作外部系统（日历、文件、API）
验证语法/测试	验证任务完成状态
代码仓库	真实世界环境

4.3 扩展后的通用智能体原则

原则 1 扩展：Ask Before Assume

编程版： 不确定需求时提问，不要猜测。
通用版： 不确定用户意图或环境状态时，停下来问清楚再行动。

典型场景：

• 用户说"帮我约个会议室"，AI 不应该直接去查日历时瞎选时间
• 扩展版：先确认"什么时间？几人？需要设备吗？哪个办公室？"

原则 2 扩展：Do Minimum Viable Task

编程版： 最少代码解决问题。
通用版： 用最少步骤完成任务，不做额外动作。

典型场景：

• 用户要求"把这份报告发给老板"，AI 不应该自动压缩、转发、云备份
• 扩展版：只执行发邮件这一件事，把发件人/主题/正文确认好就够了

原则 3 扩展：Touch Only What Must Be Touched

编程版： 只改必要的代码。
通用版： 只操作必须操作的系统/文件，不碰无关的东西。

典型场景：

• 用户要求"整理桌面文件夹"，AI 不应该顺手改桌面壁纸或系统设置
• 扩展版：只操作指定的文件夹，其他一律不碰

原则 4 扩展：Define Verify Loop

编程版： 每步编码后验证。
通用版： 每个操作步骤后确认结果，再决定下一步。

典型场景：

• 用户要求"帮我买下周去上海的机票"，AI 应该：
  1. 查询航班 → 验证返回结果
  2. 筛选结果 → 验证符合时间/价格要求
  3. 打开订票页 → 验证页面可访问
  4. 确认下单 → 验证订单状态

---

五、通用智能体示例文本

5.1 场景一：日程管理助手

任务：帮用户安排下周一的团队周会

[Think Before Acting]
用户未明确：
1. 会议时间（上午/下午？）
2. 参会人员范围
3. 会议时长
4. 是否需要预订会议室

在确认以上信息前，我建议：
- 时间建议：周二上午 10:00（周一上午已有 Q4 复盘会）
- 时长建议：1 小时
- 如有需要，我可以先查会议室空余情况

请确认以上信息，我再执行预约操作。

5.2 场景二：邮件撰写助手

任务：回复客户投诉邮件

[Think Before Acting]
需要确认：
1. 投诉内容是否已解决？（未解决→道歉+说明，解决→确认+感谢）
2. 语气倾向：正式/友好/中性？
3. 是否需要抄送其他人？

[Do Minimum]
仅撰写正文，不自动：
- 更改邮件主题
- 添加附件（除非用户提供）
- 预设后续跟进任务

[Goal-Driven]
邮件发送成功后，以下指标应满足：
✓ 主题清晰（包含"回复：[原主题]"）
✓ 正文回应了投诉要点
✓ 落款信息完整

5.3 场景三：数据研究报告生成

任务：生成竞品分析报告

[Think Before Acting]
报告范围未明确：
1. 需要分析哪些竞品？
2. 数据来源偏好（官方财报/第三方数据/用户评价）？
3. 报告深度（1页摘要/10页详评）？
4. 截止日期？

[Do Minimum Viable]
- 只收集与竞品直接相关的数据
- 不延伸至行业整体趋势（除非明确要求）
- 不自动生成美化图表（数据本身足够）

[Surgical Changes]
- 只读取公开数据和用户提供材料
- 不修改任何本地文件
- 不在未授权系统创建草稿

[Goal-Driven Execution]
1. [收集竞品A数据] → verify: 数据量 ≥ 5个维度
2. [收集竞品B数据] → verify: 数据量 ≥ 5个维度
3. [对比分析] → verify: 包含价格/功能/市场份额对比表
4. [生成摘要] → verify: 100-200字，涵盖核心结论
5. [格式检查] → verify: 无格式错乱，表格可读

完成标志：报告包含所有主要竞品，数据来源可溯源，结论有数据支撑。

---

六、总结

Andrej Karpathy Skills 的四条原则，本质上是一套AI 行为规范集，针对的是 AI 在自主任务执行时的四大惯性缺陷：

1. 闷头执行 → 必须先问清楚
2. 过度工程 → 只做要求的最小集
3. 顺手乱改 → 严格限制改动范围
4. 一步到位 → 改为循环验证模式

这套原则从代码场景迁移到通用智能体，核心思路不变：约束 AI 的自主性，强制它对齐人类意图。区别只在于"代码"变成了"任务"，"编译器"变成了"真实世界环境"。

在 AI 能力越来越强、 autonomy 越来越高的今天，这类约束原则的重要性只会增加，不会减少。