一份CLAUDE.md让LLM少犯四个编码错误-Seo优化-塔城地区网站建设公司

一份CLAUDE.md让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

你有没有遇到过这种情况：给 Claude Code 提了一个很小的需求，它交付的 diff 却混进了大量无关改动；或者你只想要一个 20 行的函数，它却搭起了抽象基类加策略模式。andrej-karpathy-skills 是一个把 Andrej Karpathy 对 LLM 编码通病的观察整理成行为的开源项目，核心就是一份 CLAUDE.md，用来约束 Claude Code 的编码习惯，让 AI 生成的代码更少跑偏。

🎬 三个让你头疼的典型场景

实际用起来你会发现，LLM 的麻烦往往不在"不会写代码"，而在"写代码的方式"。这个项目的出发点来自 Karpathy 的三句吐槽：

模型会替你做错误假设，然后一路狂奔，从不回头确认；它不管理自己的困惑、不主动澄清、不暴露矛盾、该反驳时不反驳。
模型偏爱过度复杂化：抽象膨胀、死代码不清理，100 行能解决的事堆出 1000 行的构造。
模型会顺手改动它并不真正理解的注释和代码，哪怕这些内容与当前任务毫无关系。

把这三句话翻译成日常场景就是：你说"导出用户数据"，它默默选了 CSV 格式直接开写，没人问你要不要 Excel；你说"修个 bug"，它改完 bug 还"顺手"重排了隔壁函数的缩进。这个项目的做法很直接：不训模型，而是用一份行为准则文件，把这四种毛病在流程上堵住。

🚀 三分钟上手：两种装法怎么选

整个项目最核心的文件只有一个：CLAUDE.md，其余都是说明文档。安装分两条路。

装法一：Claude Code 插件（推荐，全项目生效）

在 Claude Code 里先添加市场，再安装插件：

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

装完所有项目都能用这套准则，适合"装一次就忘"的场景。

装法二：把文件放进单个项目

新项目直接拉取：

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

已有 CLAUDE.md 的项目则追加合并：

echo "" >> CLAUDE.md curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

用 Cursor 的话，仓库里也带了项目规则文件，CURSOR.md 里写了具体的配置方法。

四条规则，对应四个检查点

准则不长，读完只要几分钟。它没有堆术语，而是把四条原则各自锚定到一个具体检查点上。

编码前先亮底牌。要求模型把假设明确说出来，不确定就问；存在多种解读时列出选项让你挑，而不是默默选一个开跑；有困惑就停下来，说清楚哪里不清楚。这一条针对的是"替你做假设"的毛病。

默认取简单解。只实现被要求的功能：不为单次使用建抽象层、不加没人要的"可配置性"、不为不可能发生的场景堆错误处理。还有一条很实用的自检：写出来 200 行而 50 行就够的，重写。判断标准也很朴素——资深工程师会不会说这写复杂了？

改动必须可追溯。每一行被修改的代码都应该能直接对应到你的请求。相邻代码哪怕写得再难看也不许"顺手改进"，注意到无关的死代码可以提一句，但不删。自己的改动造成的孤儿导入、废弃变量则必须清掉。

把指令翻译成可验证的目标。这是四条里最值钱的一条。模糊指令会让模型反复回头问你，可验证的标准则允许它自己循环验证直到通过："加验证"变成"先写无效输入的测试，再让它通过"；"修 bug"变成"先写能复现 bug 的测试，再修"。多步骤任务还要求先给出带验证点的简短计划。

🧪 效果对比：跑一遍会看到什么

看一个最典型的场景——"写个折扣计算"。没加准则前，你大概率收到这样的东西：

class DiscountStrategy(ABC): @abstractmethod def calculate(self, amount: float) -> float: ... class PercentageDiscount(DiscountStrategy): def __init__(self, percentage: float): ... def calculate(self, amount: float) -> float: return amount * (self.percentage / 100)

三十多行起步，抽象、枚举、协议一套配齐，而且说实话每一行都"不算错"——问题出在时机。加上准则后，产出通常是：

def calculate_discount(amount: float, percent: float) -> float: """计算折扣金额，percent 取 0-100""" return amount * (percent / 100)

三行，够用。等哪天真出现多种折扣类型，再抽象也不迟。更多真实场景的对照可以看 EXAMPLES.md，里面有"添加用户数据导出"这类需求的完整前后对比。

怎么判断它真的起作用了

效果不需要玄学判断，看四个可观察的信号就行：

diff 里只剩下你请求的改动，附带重构消失了
第一版代码就是简单的，不用为过度复杂化返工重写
澄清问题出现在动手之前，而不是犯错之后
PR 干净最小，没有"路过顺手改"的痕迹

准则文件里也写明了这个标准：diff 中的非必要改动变少，重写变少，问题前置。

边界在哪：什么时候可以放宽

这份准则明确偏"谨慎而非速度"，所以别指望它对每个任务都全套上。改个拼写错误、明显的一行修改，用判断力放行就好，不必让模型先声明假设再列验证点。它的设计目标是减少非平凡工作中的高代价错误，而不是拖慢简单任务。另外它是设计来与你自己的项目规则合并使用的，往现有 CLAUDE.md 里追加即可，两者不冲突。