这是一个 Claude Code 插件,把 Andrej Karpathy 对 LLM 编码陷阱的观察 整理成四条行为准则,注入到 AI 的系统上下文,让 AI 在每次编码任务中自动遵循这些规范。
解决了什么问题
Karpathy 观察到 AI 辅助编码时有几个典型毛病:
"模型会代你做错误假设,然后不假思索地执行。它们不管理自身的困惑,不寻求澄清,不呈现矛盾,不展示权衡,在应该提出异议时也不反驳。"
"它们真的很喜欢把代码和 API 搞复杂,堆砌抽象概念,不清理死代码……明明 100 行能搞定的事情,非要实现成 1000 行的臃肿架构。"
"它们有时仍会改动或删除自己理解不足的代码和注释,即使这些内容与任务本身无关。"
这个插件用四条准则直接对症这三个问题,减少返工和副作用。
四条核心准则
1. 先思考,再动手
不要凭假设行事,不要隐藏疑惑,要主动暴露权衡点。
明确说出假设。如果不确定,先问清楚。 如果一个需求有多种理解方式,把它们都列出来,不要自己悄悄选一个。 如果有更简单的方案,说出来,必要时要推回去。 如果有任何不清楚的地方,停下来,把困惑的点说清楚,然后问。
2. 简单优先
用最少的代码解决问题,不写投机性的代码。
不要添加没被要求的功能。 只用一次的代码不需要抽象。 没人要求的"灵活性"和"可配置性"不要加。 不可能发生的场景不需要错误处理。 写了 200 行但本可以 50 行搞定?重写。
自我检验:「一个资深工程师看到这段代码会说它过度设计吗?」如果是,简化。
3. 外科手术式修改
只改必须改的地方,只清理自己制造的烂摊子。
修改已有代码时:
不要"顺手优化"相邻的代码、注释或格式。 不要重构没坏的东西。 跟随现有风格,即使你有更好的写法。 发现了无关的死代码?提一句,但不要删。
你的改动产生孤儿代码时:
删掉你的改动造成的无用 import、变量、函数。 不要删除你改动之前就已存在的死代码(除非被明确要求)。
检验标准:每一行改动都应该能直接追溯到用户的需求。
4. 目标驱动执行
定义成功标准,循环验证直到达成。
把模糊任务转化为可验证的目标:
多步骤任务先列计划:
1. [步骤] → 验证:[检查点]2. [步骤] → 验证:[检查点]3. [步骤] → 验证:[检查点]清晰的成功标准让 AI 可以自主循环执行;模糊的标准("让它跑起来")则需要不断打断确认。
安装
方式 A:Claude Code 插件(推荐)
全局生效,覆盖所有项目。在 Claude Code 对话框中执行:
/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已有项目(追加到末尾):
echo"" >> CLAUDE.mdcurl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md工作原理
插件安装后会修改 ~/.claude/settings.json,新增两项配置:
{"enabledPlugins": {"andrej-karpathy-skills@karpathy-skills": true },"extraKnownMarketplaces": {"karpathy-skills": {"source": { "source": "git", "url": "https://github.com/multica-ai/andrej-karpathy-skills.git" } } }}插件文件缓存在:
~/.claude/plugins/cache/karpathy-skills/andrej-karpathy-skills/1.0.0/├── CLAUDE.md ← 核心规则,自动注入到每次对话的系统上下文├── skills/│ └── karpathy-guidelines/│ └── SKILL.md ← 可手动触发的 skill 定义└── .cursor/rules/ └── karpathy-guidelines.mdc ← Cursor 用的同一套规则自动生效:插件的 CLAUDE.md 会自动注入每次对话的系统上下文,无需手动触发,所有编码任务默认遵循四条准则。
手动触发:在开始复杂任务前,可以显式调用 skill 让 AI 重申准则:
/andrej-karpathy-skills:karpathy-guidelines如何判断它在生效
diff 更干净 — 只有请求的改动,没有顺带修改 更少的过度设计返工 — 代码第一次就写得简洁 澄清问题在实现前提出 — 而不是犯错之后 PR 精简 — 没有无关的重构或"改进"
👉 欢迎关注,学习更多ai知识,一起『向好慢慢行』
夜雨聆风