用 andrej-karpathy-skills 让 LLM 代码更可靠：从确认到验证的三步流程-平芜编程栈

用 andrej-karpathy-skills 让 LLM 代码更可靠：从确认到验证的三步流程

【免费下载链接】andrej-karpathy-skillsA single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathy's observations on LLM coding pitfalls.项目地址: https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills

只让 AI 加一个小导出按钮，却换回 300 行 diff：它"顺手"重构了旁边的代码，还加了个没人要的缓存层。如果你也被这类 AI 编程翻车折磨过，可以试试 andrej-karpathy-skills——一套基于 Andrej Karpathy 对 LLM 写代码观察整理出的开源技能包，用 4 条原则约束 AI 编码行为，文末会讲如何配置。

🩺 先诊断：LLM 写代码的三类毛病

LLM 生成的代码问题看似零散，其实能归并成三类根因：

擅自假设：指令有歧义时，它挑一个自己认为最可能的解释，闷头写下去，从不回头确认。这是返工的最大来源。
过度设计：爱给一次性代码套抽象层、加"灵活性"和"可配置性"，100 行能写完的事写成 1000 行。
改动范围失控：顺手改与任务无关的代码和注释，甚至删掉自己都没完全理解的逻辑。

按时间线设置的三道护栏

动手前：让 AI 先列出假设

写码之前，先要求它做到四点：把假设明说，不确定就问而不是猜；存在多种理解时列出来，不要悄悄选一个；有更简单的做法时直接提醒；遇到没把握的地方停下，说清哪里不清楚。以"加个导出用户数据的功能"为例，合格的反应是先追问：导出全部还是筛选后的？什么格式？包含哪些字段？仓库里的 EXAMPLES.md 给出了这类场景的完整对照案例，值得细看。

编码中：最小改动的边界

写码过程中，把 AI 限制在最小改动的框里：

不做：

不添加没被要求的功能、"灵活性"和"配置项"
不为只用一次的代码创建抽象层
不"顺手改进"相邻代码、注释或格式
不删除原本就存在的死代码

要做：

用解决问题所需的最少代码，200 行能压到 50 行就重写
匹配现有代码风格，不引入新写法
只清理自己这次改动导致冗余的导入和变量
自检一句：资深工程师会嫌这段代码复杂吗？

完成后：把模糊指令变成可验证目标

模糊的验收标准产出模糊的结果。任务收尾时，把要求转成可验证的形式：

"修复这个 bug" → 先写出能复现它的测试，再让它通过
"加上参数校验" → 为非法输入写测试，并全部跑绿
"重构模块 X" → 现有测试在改动前后都保持通过

多步骤任务则让它先给出"步骤 → 验证点"的清单，逐项推进。强成功标准能支撑 AI 独立循环直到完成；"让它能跑就行"这种弱标准，只会换来反复追问。

常见坑速查表

典型场景	常见坑	该怎么做
新增功能	默认按自己猜的理解写完整套	要求先列出假设和歧义，确认后再动手
写工具函数	50 行逻辑被包上类和抽象层	先写函数，出现第二个调用方再重构
修改现有代码	连带改了格式和相邻函数命名	逐行核对：每处改动能否对应你的请求
修 bug	症状消失了，但无法证明已修复	先写一个失败的复现测试，再改到通过
重构	改完测试全红，不知道哪步改坏的	改动前后各跑一遍现有测试

两种 30 秒落地的方式

方式一：Claude Code 插件（推荐）。在 Claude Code 里执行两条命令，规则对所有项目全局生效：

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

适合：希望统一约束自己所有项目的场景。

方式二：按项目放配置文件。把仓库克隆下来，将 CLAUDE.md 放进项目根目录即可：

git clone https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills

新项目直接用作 CLAUDE.md；已有项目把它追加到原文件末尾，还可以续写项目专属规则。适合只约束单个项目、或需要混合自定义规则的场景。用 Cursor 的话，可参考仓库里的 CURSOR.md 配置对应规则，原则定义在 skills/karpathy-guidelines/SKILL.md 中。