Andrej Karpathy编码原则:一份 CLAUDE.md 治好 AI 写码四大毛病
2026/9/16 8:54:23 网站建设 项目流程

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.mdskills/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),仅供参考

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询