Andrej Karpathy编码原则:一份 CLAUDE.md 治好 AI 写码四大毛病
【免费下载链接】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 修个统计 bug,它顺手重写了三个函数。andrej-karpathy-skills 就为治这种事故:一个 CLAUDE.md、四条行为准则,让 AI 先说假设、只改该改的、按可验证的目标收尾。
这套 Karpathy 编码原则源自 Andrej Karpathy 对大模型写代码常见错误的观察,完整清单就在仓库根目录的CLAUDE.md(skills/karpathy-guidelines/SKILL.md里有一份带元数据的同名版本)。它偏向"稳"而不是"快":改个错别字不用上全套,但稍微费事的活儿,值得按下面这条工作流走一遍。
按任务流走一遍:四个阶段的固定动作
接需求时:先把假设摊到桌面
返工的种子多半在敲下第一行代码前就埋下了。你只说了"统计全班平均分",AI 默默假设缺考按 0 分、只统计必修课、输出成表格——写完发现全反了,推倒重来。
写码前,用一两句话列出你(或 AI)依赖的假设;有歧义就停下来问。
- ❌ 直接开写:缺考按 0 分计,只算必修课,直接输出表格。
- ✅ 先回一句:"我假设缺考按 0 分计、只统计必修课,对吗?"拿到确认再动手。
小动作:在任务描述下写下三条假设,任何一条说不出口就去问 TA。
写第一行代码前:只实现刚好够用的
统计脚本跑通了,你说"再加个等级分桶",AI 先建了抽象基类、枚举和配置对象——200 行代码统计 30 个分数。问题不在模式本身,而在时机:复杂度在需要之前就塞进来了。
实现只覆盖当前需求,砍掉一切"以防万一"。
# ❌ 先建抽象再开算 class GradingStrategy(ABC): @abstractmethod def grade(self, scores): ... # ✅ 现在只需要平均分,一个函数就够 def average(scores): return sum(scores) / len(scores)小动作:写完自问"资深工程师会说这过度复杂吗?"200 行能压到 50 行的,直接重写。
改小组仓库:让每一行 diff 都能交代
在课程小组仓库修一个判空 bug,diff 一拉出来:引号风格全变了,顺手还加了类型注解和文档字符串,队友根本看不懂你改了什么。
只碰必须碰的行,样式跟旧代码走;顺手发现的死代码,提一句就好,别删。
- ❌ 修 None 崩溃时,把整个函数的引号、空格和布尔返回逻辑一起重排。
- ✅ diff 里只有这几行:
def check_score(s): + if s is None: + return 0 return int(s)小动作:提交前逐行过一遍 diff,某行改动对不上任务描述就还原。
收尾验证:把"修好了"翻译成一条测试
"排序偶发错乱,改完手点两下没复现,就交了"——这种自证最不可靠。模糊目标("我会优化排序")没法验证,可验证的目标才能让你循环到真的通过。
先把目标翻译成测试:让它复现 bug、先红,再修到绿。
- ❌ "我会改进排序逻辑"——没有验收标准,只能靠手点确认。
- ✅ 先写一条含并列分数的用例跑出错误,改完让它稳定通过,再跑全量测试确认没弄坏别的。
def test_tied_scores_stable(): data = [("a", 90), ("b", 90), ("c", 85)] assert [n for n, _ in sort_scores(data)] == ["a", "b", "c"]小动作:给任务写下"输入 X 时,输出应是 Y";说不出 Y,说明你还没想清楚。
完整工作流一张图:验证不过就回炉
任何一环掉链子就退回上一环——这个回炉的闭环,正是 Karpathy 编码原则和"差不多得了"的分界线。
速查卡:贴在屏幕边自查
| 容易踩的坑 | 标准动作 | 验证信号 |
|---|---|---|
| 不问就动手,默认补全模糊需求 | 写码前列假设,歧义当场问 | 澄清问题出现在实现之前,而不是报错之后 |
| 一个循环能干的活搭了三层抽象 | 只实现当前需求,砍掉推测性功能 | 行数接近最小解,没有没人用的配置项 |
| diff 混进格式重排和顺手重构 | 每行改动对应任务,样式跟旧代码 | 逐行 diff 都能追溯到需求描述 |
| "修好了"靠手点两下确认 | 先写复现用例,红转绿再全量回归 | 有测试从红变绿,其余用例保持全绿 |
三个场景里的第一步
- 课程作业:拿到题目先写下三条假设,问完老师再开文件。
- 团队项目:动手前把要动的行写进 PR 描述,diff 出现圈外内容就先还原。
- 修 bug:先写一条能稳定复现的测试,看到它变红,再碰代码。
这套准则不是一叠要背的规则,而是一种先想清楚再动手的思维方式。
git clone https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills拿到CLAUDE.md放进项目根目录,下次任务先问它一句:你的假设是什么?
【免费下载链接】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辅助生成(AIGC),仅供参考