AI 深度解析

Andrej Karpathy Skills(GitHub):安装方法与四大原则

andrej-karpathy-skills 是一个 GitHub 仓库,把 Andrej Karpathy 在 2026 年 1 月对 LLM 编程 Agent 的批评整理成一个只有四条规则的 CLAUDE.md。本文说明仓库里有什么、如何在 Claude Code 中安装、如何在其他 Agent 中改用 AGENTS.md,以及它能做什么、不能做什么。

andrej-karpathy-skills 仓库(最初发布为 forrestchang/andrej-karpathy-skills,现在位于 multica-ai GitHub 组织下)把 Andrej Karpathy 2026 年 1 月的一条帖子整理成一个 CLAUDE.md 文件。我们在 2026 年 10 月 30 日核对了仓库文件、GitHub API、Karpathy 的原帖,以及 Claude Code、Cursor、Codex 和 Antigravity 的官方文档,下文内容均已按这些来源重新验证。

Andrej Karpathy Skills 是什么?快速回答

Andrej Karpathy Skills 是一个社区 GitHub 仓库,并非 Karpathy 或 Anthropic 的官方发布。它包含一个 65 行的 CLAUDE.md、一个提供 karpathy-guidelines 技能的 Claude Code 插件,以及一条 Cursor 规则。三者承载同样的四条原则,README 称这些原则来自 Karpathy 2026 年 1 月 26 日的帖子中对 LLM 编程错误的观察:

  1. 编码前先思考(Think Before Coding):说明假设,不清楚就问,列出权衡
  2. 简单至上(Simplicity First):用最少的代码解决问题
  3. 精准修改(Surgical Changes):只改需求要求的部分
  4. 目标驱动执行(Goal-Driven Execution):先定义成功标准,循环到验证通过

在 Claude Code 中安装(命令来自仓库 README,详见安装步骤):

/plugin marketplace add forrestchang/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills

仓库数据(2026 年 10 月 30 日通过 GitHub API 查询):226,645 个 Star,22,632 个 Fork,创建于 2026 年 1 月 27 日,最后一次推送在 2026 年 4 月 20 日。README、plugin.json 和 SKILL.md 都写明 MIT,但 GitHub 没有在仓库中检测到 LICENSE 文件。

Get the latest on AI, LLMs & developer tools

New MCP servers, model updates, and guides like this one — delivered weekly.

🎬 观看视频解析

喜欢阅读?继续向下滚动查看包含代码示例的完整文字指南。

1. 为什么它会走红

该仓库创建于 2026 年 1 月 27 日,也就是 Karpathy 发帖的后一天。截至 2026 年 10 月 30 日,GitHub API 显示它有 226,645 个 Star 和 22,632 个 Fork,而它的内容基本上只是 一个 65 行的文件。最后一次推送是 2026 年 4 月 20 日(同步 README 翻译),所以内容已经稳定了好几个月。

不是框架,不是库,也不是应用,只是一套面向 AI 编程 Agent 的行为准则。README、plugin.json 和 SKILL.md 都声明使用 MIT 许可证,但仓库里没有 LICENSE 文件,所以 GitHub 的许可证检测显示为空。如果你打算把它放进自己的产品里再分发,请先联系维护者确认。

为什么这很重要

这个仓库没有可运行的代码,也没有运行时依赖。它的价值在于 想法,Star 数更多反映了市场对 Agent 护栏的需求,而不是这个文件本身有多好。Star 不能证明这些规则会改善输出,详见下文关于证据的部分。

2. 起源故事

该仓库可以直接追溯到一条爆火的推文,作者是 Andrej Karpathy — OpenAI 联合创始人、前特斯拉 AI 负责人,也是 “vibe coding” 一词的创造者。在他的帖子中,Karpathy 并没有分享工具或仓库。他分享的是 观察心得 — 一系列关于 LLM 在编写代码时表现出的痛点清单。

仓库的插件清单署名作者为 forrestchang。它最初发布在 github.com/forrestchang/andrej-karpathy-skills,现在位于 github.com/multica-ai/andrej-karpathy-skills;旧地址仍会跳转到新地址(2026 年 10 月 30 日核实),README 开头还带有维护者自己项目 Multica 的推广。作者把 Karpathy 的观察整理成结构化的 CLAUDE.md,Claude Code 会在每次会话开始时读取这类文件。

Karpathy 分享的是观察,他并没有发布这个仓库,仓库也未获得他或 Anthropic 的认可。Karpathy 的帖子里甚至说,“a few simple attempts to fix it via instructions in CLAUDE.md”(在 CLAUDE.md 里写几条简单指令的尝试)并没有解决这些问题,所以请把这个文件当作缓解手段,而不是根治办法。

3. Karpathy 发现的问题

Karpathy's 的观察并非含糊的抱怨。它们是每个使用 AI 编程智能体的开发者都经历过的、具体的、可复现的模式。以下是他的原话:

问题 1:隐藏的假设

“模型会代表你做出错误的假设,并在不进行检查的情况下直接执行。它们不处理自己的困惑,不寻求澄清,不揭示不一致之处,不权衡利弊,也不在应该拒绝时提出异议。”

问题 2:过度工程

“它们非常喜欢把代码和 API 复杂化,让抽象变得臃肿,不清理废弃代码……在 100 行就能搞定的情况下,非要实现一个超过 1000 行的臃肿结构。”

问题 3:意外的副作用

“作为副作用,它们有时仍会修改或删除自己并不充分理解的注释和代码,即使这些内容与当前任务无关。”

如果你使用过 Claude Code、Copilot、Cursor 或任何 AI 编程智能体,你一定深有体会。你让智能体修复一个 Bug,它却重写了半个文件。你让它添加一个功能,它却构建了一个完整的抽象层。你向它寻求帮助,它却带着错误的假设自信地盲目推进。

Reddit 社区(尤其是 r/ClaudeAI 和 r/ClaudeCode)对这种行为有一个广泛使用的术语: “自信的初级开发人员。” AI 速度快、知识广,但如果无人监管,就容易犯天真的错误。它才华横溢但不可靠 — 正是那种需要明确护栏的工程师。

4. 四项原则

仓库作者将 Karpathy 的观察提炼为四项原则。每一项都直接针对特定类别的 LLM 失败案例:

原则解决的问题
编码前先思考错误的假设、隐藏的困惑、缺失的权衡
简单至上过度复杂化、臃肿的抽象、投机性的功能
精准变更正交编辑、触碰不该改动的代码、风格偏离
目标驱动执行模糊的实现、缺乏验证、薄弱的成功标准

让我们逐一分解。

原则 1:编码前先思考

“不要假设。不要隐藏困惑。明确权衡。”

这是最基本的原则。LLM 往往会默默选择一种解释并直接执行。这一原则强制进行显式推理:

  • 明确陈述假设 — 如果不确定,请询问而不是猜测
  • 提供多种解释 — 存在歧义时,不要默默做决定
  • 在必要时提出异议 — 如果存在更简单的方法,请直说
  • 困惑时请停下 — 指出不明确之处并寻求澄清

示例:隐藏假设陷阱

用户请求: “Add a feature to export user data”

❌ LLM 的做法(错误假设)

def export_users(format='json'):
    users = User.query.all()
    # 假设了所有用户、文件位置、字段,
    # CSV 字段名 —— 且未进行任何询问
✅ 应该发生的行为(明确假设)

在实现之前,我需要明确:

1. 范围:导出所有用户还是过滤后的子集?
   (涉及隐私影响)
2. 格式:下载文件?还是后台任务?
   API 端点?
3. 字段:哪些用户字段?
   (部分可能涉及敏感信息)
4. 数据量:通常有多少用户?

最简单的方法:添加一个 API 端点,用于
返回分页的 JSON。你更倾向于哪种方式?

原则 2:简单至上

“用最少的代码解决问题。不进行任何推测性开发。”

这可以抑制 LLM 过度设计的倾向。规则非常严格:

  • 不提供需求之外的功能
  • 不对仅使用一次的代码进行抽象
  • 不提供未经要求的“灵活性”或“可配置性”
  • 不对不可能发生的场景进行错误处理
  • 如果 200 行代码能缩减到 50 行,就重写它

测试标准: 资深工程师会觉得这太复杂了吗?如果是,请简化。

示例:过度抽象的陷阱

用户请求: “添加一个计算折扣的函数”

❌ LLM 的做法(过度设计)

class DiscountStrategy(ABC):
    @abstractmethod
    def calculate(self, amount): ...

class PercentageDiscount(DiscountStrategy): ...
class FixedDiscount(DiscountStrategy): ...
class DiscountConfig:
class DiscountCalculator:

# 单次计算需要 50+ 行代码
# 使用前需要 30+ 行的初始化设置
✅ 理想情况(简单明了)

def calculate_discount(amount, percent):
    """计算折扣。percent 取值范围为 0-100。"""
    return amount * (percent / 100)

# 使用示例
discount = calculate_discount(100.0, 10.0) # 优惠 10 美元

来自该仓库的核心洞察

“那些‘过度复杂’的例子并非显而易见的错误 — 它们遵循了设计模式和最佳实践。问题在于 时机:它们在需要之前增加了复杂性。” 好的代码应该简单地解决今天的问题,而不是过早地解决明天的问题。

原则 3:外科手术式的改动

“只动必须动的地方。只清理你自己留下的烂摊子。”

这一原则最直接地解决了 Karpathy 对 LLM 进行正交改动(无关改动)的挫败感。在编辑现有代码时:

  • 不要“改进”相邻的代码、注释或格式
  • 不要重构没有损坏的部分
  • 即使你有不同的做法,也要匹配现有的风格
  • 如果你发现了无关的死代码,请提及它 —— 不要直接删除

当你的改动产生了孤立项时:

  • 删除那些由 你的改动 导致的不再使用的 imports/变量/函数
  • 除非被要求,否则不要删除预先存在的死代码

测试标准: 每一行改动的代码都应该能直接追溯到用户的需求。

示例:“顺便重构”的陷阱

用户需求: “修复空电子邮件导致验证器崩溃的 bug”

❌ LLM 的做法(用力过猛)

修改了 15 行:
- 添加了 docstring(未要求)
- 添加了用户名校验(未要求)
- 修改了注释(未要求)
- “改进”了邮箱校验逻辑(未要求)
- 在各处添加了 .strip() 调用(未要求)
✅ 理想情况(精准修改)

修改了 3 行:
- 为邮箱添加了空字符串保护
- 修改了变量引用以避免崩溃
- 未改动其他任何内容。

示例:风格偏移陷阱

用户请求: “为上传函数添加日志记录”

The LLM adds logging — but also changes single quotes to double quotes, adds type hints nobody asked for, adds a docstring, reformats whitespace, and restructures the boolean return logic. The correct approach: add 仅 日志相关行,并使用 现有风格 (single quotes, no type hints, same spacing).

原则 4:目标驱动执行

“定义成功标准。循环执行直至验证通过。”

这一原则捕捉到了 Karpathy 认为的在使用 LLM 时最具杠杆效应的见解:

Karpathy's 核心见解

“LLM 非常擅长不断迭代直到达成特定目标……不要告诉它该做什么,给它成功标准,然后看它发挥。”

这一原则将命令式任务转变为声明式目标:

与其……不如转变为……
“添加校验”“为无效输入编写测试,然后让它们通过”
“修复 Bug”“编写一个能复现该问题的测试,然后让它通过”
“重构 X”“确保重构前后的测试都能通过”

对于多步骤任务,模型应当陈述一个简要计划:

目标驱动型计划格式

1. [步骤] → 验证:[检查项]
2. [步骤] → 验证:[检查项]
3. [步骤] → 验证:[检查项]

Strong success criteria let the LLM loop
独立地。模糊的标准(“让它能跑通”)
需要不断的澄清。

5. 实际的 CLAUDE.md 文件

下面是仓库 CLAUDE.md 的精简展示(真实文件共 65 行,这里有些条目做了缩写,并省略了结尾的 “These guidelines are working if” 一行)。复制之前请先阅读 GitHub 上的完整文件:

# CLAUDE.md

旨在减少常见 LLM 编码
错误的行为准则。请根据需要与项目特定的指令
合并。

权衡: 这些准则倾向于谨慎
而非速度。对于琐碎的任务,请自行判断。

## 1. 编码前先思考
不要臆断。不要隐藏困惑。明确权衡。

在实现之前:
- 明确说明你的假设。如果不确定,请询问。
- 如果存在多种解释,请一一列出。
- 如果存在更简单的方法,请说明。
- 如果有不清楚的地方,请停止。指出令人困惑之处。

## 2. 简单至上
用最少的代码解决问题。不要进行推测性编码。

- 不要提供超出要求的特性。
- 不要为仅使用一次的代码进行抽象。
- 不要提供未经要求的 “灵活性”。
- 不要为不可能发生的场景编写错误处理。
- 如果 200 行代码能精简到 50 行,那就重写它。

## 3. 精准修改
只触碰必须修改的部分。只清理你自己留下的烂摊子。

- 不要 “改进” 相邻的代码或格式。
- 不要重构没有问题的代码。
- 遵循现有风格,即使你会有不同的做法。
- 如果发现死代码,请指出 — 不要直接删除。

## 4. 目标驱动执行
定义成功标准。循环执行直到验证通过。

将任务转化为可验证的目标:
- “添加校验” → “编写测试,然后使其通过”
- “修复 Bug” → “在测试中复现它,然后修复”
- “重构 X” → “确保重构前后的测试都能通过”

真实文件足够短,可以放进 Agent 的上下文而不挤占项目特定的指令。同样的文本还以 skills/karpathy-guidelines/SKILL.md(带 name、description 和 license: MIT 前置信息)以及 .cursor/rules/karpathy-guidelines.mdc(带 alwaysApply: true)的形式提供。

仓库里有什么(文件清单,2026 年 10 月 30 日)

文件用途
CLAUDE.md四条原则,用于单个项目
.claude-plugin/marketplace.json名为 karpathy-skills 的插件市场,只列出一个插件
.claude-plugin/plugin.json插件 andrej-karpathy-skills v1.0.0,指向 ./skills/karpathy-guidelines
skills/karpathy-guidelines/SKILL.md技能(karpathy-guidelines),Claude 在相关时加载
.cursor/rules/karpathy-guidelines.mdc 和 CURSOR.mdCursor 项目规则与设置说明
EXAMPLES.md每条原则的修改前后示例
README.md、README.zh.md英文与中文 README

6. 真实世界示例

该仓库包含一个 EXAMPLES.md 包含详细前后对比的文件。以下是该文件中的核心“反模式总结”:

原则反模式修复方案
编码前先思考默认假设文件格式、字段和范围明确列出假设,并请求澄清
简单至上为单一的折扣计算使用策略模式在真正需要复杂性之前,只使用一个函数
精准修改Reformats quotes, adds type hints while fixing a bug仅修改修复报告问题所需的行
目标驱动“我将审查并改进代码”“为 Bug X 编写测试 → 使其通过 → 验证无回归”

7. 如何安装 Andrej Karpathy Skills(在 Claude Code 中)

README 列出了两种方法。下面的命令都抄自 2026 年 10 月 30 日的仓库 README。Claude Code 官方文档描述的也是同样的两步流程:先添加插件市场,再安装插件。

选项 A:Claude Code 插件(推荐)

  1. 在任意项目中启动 Claude Code(claude)。
  2. 用下面第一条命令添加插件市场。这一步只是登记目录,还没有安装任何东西。
  3. 用第二条命令安装插件,之后这个技能在 你所有的项目 中都可用。
  4. 运行 /plugin 确认它已列出。如果提示无法识别 /plugin,请升级 Claude Code 并重启(Anthropic 官方排错建议)。

插件市场名为 karpathy-skills,插件名为 andrej-karpathy-skills,所以安装命令是 andrej-karpathy-skills@karpathy-skills。Anthropic 提醒过,插件可以用你的用户权限运行任意代码,所以请先看一下仓库内容。这个插件只指向一个 Markdown 技能文件。

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

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

选项 B:CLAUDE.md(针对单个项目)

只想用在单个项目时:

# 新项目
curl -o CLAUDE.md https://raw.githubusercontent.com/
  forrestchang/andrej-karpathy-skills/main/CLAUDE.md

README 中的 forrestchang 地址仍然有效(GitHub 会跳转到 multica-ai/andrej-karpathy-skills),原始 CLAUDE.md 链接在 2026 年 10 月 30 日返回 HTTP 200。如果不想依赖跳转,可以直接改用 multica-ai/andrej-karpathy-skills。

# 现有项目(追加)
echo "" >> CLAUDE.md
curl https://raw.githubusercontent.com/forrestchang/
  andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

自定义

这些指南是用来 与项目自己的指令合并 的。你可以加上自己的章节,例如 TypeScript 配置、API 规范、测试约定等。这四项原则只是行为底线,项目规则在其上叠加。

确认 Claude 已加载

选择单项目方式时,在 Claude Code 会话里运行 /memory,在列表中查找你的 CLAUDE.md 路径(Anthropic 文档说明 /memory 用来查看已加载的指令文件)。选择插件方式时,运行 /plugin。然后让 Claude “总结你的项目指令”,看它是否提到了这四条原则。

在其他 Agent 中使用:AGENTS.md、Cursor、Codex、Antigravity

四条原则只是普通 Markdown,凡是会读取 Markdown 指令文件的地方都能用,变化的只有文件名和加载规则。仓库本身只提供了 Claude Code 和 Cursor 的打包,下面的 AGENTS.md 步骤是我们自己的改法,并不是仓库的官方功能。

Agent规则放在哪里来源
Claude CodeCLAUDE.md,或使用插件。Claude Code 也可以直接读取 AGENTS.md,但只在工作目录及其上级没有 CLAUDE.md 时才会这样做(v2.1.277+)。否则请在 CLAUDE.md 中写入 @AGENTS.md。Claude Code 记忆文档
Cursor把仓库里的 .cursor/rules/karpathy-guidelines.mdc 复制到你项目的 .cursor/rules/,或者使用根目录的 AGENTS.md(也支持嵌套的)。根据仓库 CURSOR.md,Cursor 默认不读取 CLAUDE.md。Cursor 规则文档
OpenAI Codex CLI仓库根目录的 AGENTS.md,或 ~/.codex/AGENTS.md(对所有仓库生效)。合并大小默认上限为 32 KiB。Codex AGENTS.md 指南
Google Antigravity工作区根目录的 AGENTS.md 或 GEMINI.md(无需前置信息,始终生效),或全局的 ~/.gemini/AGENTS.md。单个文件上限 24 KB。Antigravity 规则文档

步骤:把四条原则变成 AGENTS.md

  1. 下载文件:curl -o AGENTS.md https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md
  2. 打开 AGENTS.md,把第一行标题里的 CLAUDE.md 改成 AGENTS.md。正文不用再改,因为规则没有提到 Claude 专有功能。
  3. 按 README 的建议,在 ## Project-Specific Guidelines 标题下追加你的项目规则(技术栈、命令、约定)。
  4. 如果你同时使用 Claude Code,新建一个只含一行 @AGENTS.md 的 CLAUDE.md,这样两个工具读取同一份内容(该导入写法见 Anthropic 文档)。
  5. 在你的 Agent 中开启新会话,让它列出已加载的指令。

我们的配套指南介绍了 Antigravity 的规则写法:用 AGENTS.md 编写 Antigravity 用户规则和可直接复制的 Antigravity 规则示例。

8. 什么是 CLAUDE.md?

对于那些不熟悉该概念的人: CLAUDE.md 是一个 项目记忆卡 专为 AI 编程智能体设计。Claude Code 会在每次会话开始时自动读取它,提供跨对话的持久上下文。

可以将其视为面向新开发者的入职文档的 AI 版本 — 只是阅读者变成了 AI 就在每一次 它开始处理你的项目时。

CLAUDE.md 最佳实践 (2026)

章节内容
项目概览用 2-3 句话简述项目的功能
技术栈语言、框架、核心库
架构代码库地图(源码、组件、配置)
命令dev, build, test, lint 命令
编码规范命名约定、模式、风格规则
安全规则“切勿硬编码 API 密钥,” “不要修改 /config”

层级结构

  • CLAUDE.md (项目根目录) — 共享上下文,已提交至 Git
  • CLAUDE.local.md (项目根目录) — 个人开发专用笔记(需添加到 .gitignore)
  • ~/.claude/CLAUDE.md — 跨所有项目的全局偏好设置
  • 子目录 CLAUDE.md 文件 — 仅在对应目录下工作时提取的上下文

经验法则: 如果你在对话中必须重复某条指令超过两次,请将其提升至你的 CLAUDE.md.

9. 社区反响

我们调研了以下平台的讨论: Reddit (r/ClaudeAI, r/ClaudeCode)、Twitter/X 以及技术博客。以下是社区的看法:

“自信的初级开发人员”共识

Reddit 社区经常将 Claude Code 描述为一个才华横溢但有时不太可靠的 “初级开发者。” 它速度快且知识渊博,但如果无人监督,就容易采取危险的捷径、产生幻觉或犯下幼稚的错误。Karpathy 的 skills 文件通过添加初级开发者所需的护栏直接解决了这个问题。

“技术水平问题”之争

Reddit 上流行的一种观点是:AI 生成代码的质量 与用户自身的工程判断力直接成正比 以及“上下文工程”能力。掌握了提示词结构、上下文管理和验证循环的高级用户报告的成功率显著更高。Karpathy 的 skills 文件是最受欢迎的“上下文工程”工具之一。

“AI 精神病”辩论

Karpathy 对“永久性 AI 精神病”的描述 — 一种持续处于高产但令人精疲力竭的 Agent 引导状态 — 引起了深度共鸣。有些人将 AI Agent 视为不容忽视的竞争优势。另一些人则称之为“生产力剧场” — 感觉很快,却产出了难以维护的代码。该 skills 文件介于两者之间:它承认 AI Agent 的强大,但认为它们需要 严格的约束。

人类瓶颈的转移

社区共识:AI 降低了 编写 代码的门槛。但真正的瓶颈已从实现转移到了 架构和评估。挑战不再是“我该怎么写这个?”而是“我是否足够了解 Agent 刚刚构建的内容,以便对其进行维护?”

10. 宏观图景

从“氛围编程”到“智能体工程”

当 Karpathy 在 2025 年初提出“氛围编程”时,它描述的是一种松散的、对话式的 AI 提示方式。到 2026 年,社区已将其演进为 “智能体工程” — 在这一准则中,开发者将 AI 视为合作伙伴,需要明确的目标、清晰的边界和严格的测试。

这个 andrej-karpathy-skills 仓库代表了这种演进。这并不是要限制 AI 的能力,而是关于 引导其发挥能力 通过能够产生更好结果的原则。

“想法文件”模式

这个仓库也体现了 Karpathy 所称的 “想法文件” 模式 — 分享想法而非具体实现。这个 CLAUDE.md 文件并不是任何人都可以导入的库。它是一套任何人都可以采用的原则。接收者的智能体会根据其特定需求进行定制。这是一种新型的开源:不是代码开源,而是 想法开源。

如何判断其是否奏效

根据仓库的 README,如果你看到以下情况,说明这些指南正在发挥作用:

  • diff 中不必要的更改更少 — 仅出现请求的更改
  • 因过度复杂化而导致的重写更少 — 代码在初次编写时就保持简洁
  • 澄清问题应先于代码实现 — 而不是在出错之后
  • 保持 PR 简洁且最小化 — 拒绝顺带的重构或所谓的“改进”

权衡说明

该仓库对权衡取舍直言不讳: “这些准则更倾向于谨慎,而非速度。” 对于琐碎任务(如简单的拼写修复、显而易见的一行代码修改),请自行斟酌 — 并非所有变更都需要如此严苛。其目标是减少非琐碎工作中的代价昂贵的错误,而非拖慢简单任务的进度。

有比 Karpathy 的更好的 CLAUDE.md 吗?

目前没有任何基准测试给 CLAUDE.md 文件排名,所以我们无法指出哪一个更好。根据已核实的来源,可以说的是:

  • 仓库没有公布测试结果。README 只说明了应该观察什么(diff 更小、重写更少、先提问再写代码),并没有给出测量数据。任何关于它的“错误减少 X%”的说法,包括第三方的,在作者给出方法和数据之前都应视为未经证实。
  • 它是通用的行为层,不是项目文件。它没有提到你的技术栈、测试命令或架构。Anthropic 文档说 CLAUDE.md 应该写项目上下文,例如构建命令和约定,所以你仍需要在它之上加自己的章节。
  • Karpathy 本人也提到了局限。他的帖子说,在 CLAUDE.md 里写几条简单指令并不能单独解决这些行为问题。计划模式、测试和代码审查依然重要。
  • Anthropic 提供了检查自己文件的办法。/doctor prompt-audit 会检查 CLAUDE.md、AGENTS.md 和技能里是否有过时或相互冲突的指令。粘贴任何第三方规则之后都建议运行一次。

如果想要比四条更多的规则,请看我们的Karpathy CLAUDE.md 扩展版(12 条规则)。背后的 idea file 概念见Karpathy 的 LLM Wiki idea file。

12. 常见问题

Andrej Karpathy Skills 是什么?

它是 andrej-karpathy-skills 这个 GitHub 仓库,现位于 github.com/multica-ai/andrej-karpathy-skills(最初是 forrestchang/andrej-karpathy-skills)。仓库包含一个 CLAUDE.md、一个名为 karpathy-guidelines 的 Claude Code 插件与技能,以及一条 Cursor 规则,核心都是四条原则:编码前先思考、简单至上、精准修改、目标驱动执行。截至 2026 年 10 月 30 日,它有 226,645 个 Star。

Karpathy skills 文件是官方的吗?

不是。这是社区项目,插件清单中的作者署名为 forrestchang。README 说明规则来自 Andrej Karpathy 2026 年 1 月 26 日的帖子,但 Karpathy 分享的只是观察,并没有发布这个仓库,Anthropic 和 Karpathy 都不发布也不维护它。README、plugin.json 和 SKILL.md 均声明 MIT 许可证,但 GitHub 没有检测到 LICENSE 文件。

如何在 Claude Code 中安装 Karpathy skills?

先运行 /plugin marketplace add forrestchang/andrej-karpathy-skills,再运行 /plugin install andrej-karpathy-skills@karpathy-skills。如果只想用于单个项目,可以改用 curl 把仓库的 CLAUDE.md 下载到项目根目录。两种方法都来自仓库 README。

Karpathy guidelines(karpathy-guidelines skill)是什么?

karpathy-guidelines 是插件里那个技能的名字,包含四部分:编码前先思考、简单至上、精准修改、目标驱动执行。技能描述让 Claude 在编写、审查或重构代码时使用它。

能在 Cursor、Codex 或 Antigravity 中把它当作 AGENTS.md 使用吗?

可以,但需要我们自己做一点改动,因为仓库并没有提供 AGENTS.md。把指南保存为项目根目录下的 AGENTS.md 即可。Cursor、OpenAI Codex CLI 和 Google Antigravity 的官方文档都说明支持 AGENTS.md。Claude Code 只有在没有 CLAUDE.md 时才会直接读取 AGENTS.md,所以如果两者都用,请新建一个内容为 @AGENTS.md 的 CLAUDE.md。

CLAUDE.md 和 AGENTS.md 有什么区别?

CLAUDE.md 是 Claude Code 自己的指令文件。AGENTS.md 是多个工具共同读取的纯 Markdown 约定。GEMINI.md 是 Antigravity 额外加载的文件。内容可以完全相同,不同的只是文件名和各工具的加载规则。

有比 Karpathy 的更好的 CLAUDE.md 吗?

目前没有公开基准可以给 CLAUDE.md 排名。Karpathy 的四条规则是一个小而流行的行为层,但不能替代项目自己的指令,仓库也没有公布实测结果。请参阅上一节了解该检查什么。

11. 所有来源与链接(原第 11 节,现排在常见问题之后)

本文的研究基于 多渠道调研 涵盖 GitHub, Twitter/X, Reddit, 网络文章以及源代码本身。以下是所有主要来源:

主要来源

社区讨论

  • Reddit r/ClaudeAI — 关于 Claude Code 工作流以及“自信的初级开发人员”共识的社区讨论
  • Reddit r/ClaudeCode — 关于 CLAUDE.md 最佳实践和规范系统的讨论帖
  • Twitter/X — 开发者反馈、工作流分享及采用报告

网络资源

  • Medium — 技术评论与实现指南
  • dev.to — 开发者社区教程
  • Forbes — 关于从“vibe coding”向“agentic engineering”演进的报道
  • VentureBeat — 分析 Karpathy 将上下文管理比作“编译器”的类比
  • Analytics Vidhya — 对 skills 文件处理方式的技术分析

文档

本站相关文章