给 AI 一份“规则文件“,它就不再写臃肿代码:andrej-karpathy-skills 完整指南

发布时间:2026/8/28 12:11:11
给 AI 一份“规则文件“,它就不再写臃肿代码:andrej-karpathy-skills 完整指南 给 AI 一份规则文件它就不再写臃肿代码andrej-karpathy-skills 完整指南【免费下载链接】andrej-karpathy-skillsA single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathys observations on LLM coding pitfalls.项目地址: https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills你让 AI 修一个 3 行的 bug它回你一个 200 行的 diff顺手优化了旁边的函数改写了注释统一了格式。这种过度工程是 AI 编程最让人头疼的问题之一。andrej-karpathy-skills 用一份 CLAUDE.md 文件解决这个问题它是一份给 AI 编码助手的行为指南靠 4 条原则让 AI 写出更简洁的代码停止过度工程化。 一个 CLAUDE.md 文件到底是什么没有框架没有依赖这个项目的全部交付物就是一个 markdown 文件。它针对 Andrej Karpathy 观察到的 LLM 编码通病写成模型会默默做出错误假设然后一路狂奔100 行能搞定的事写成 1000 行的架构还会顺手改动它并不理解、与任务无关的代码。CLAUDE.md 就是针对这三条的处方分四个小节每节一条原则配一句话口号和几条可执行条款。全文 5 分钟能读完别被讲原则的包装吓到。想看每条原则在真实代码里怎么落地翻一翻仓库里的EXAMPLES.md里面全是AI 常犯的错误 → 应该怎么改的对照。 怎么判断 AI 开始守规矩了先别急着背四条原则给你一套验收标准。规则文件落到项目里之后如果陆续出现这四个信号说明指南在起作用diff 里无关改动变少只有你要求的修改出现不再有顺手重构。返工变少代码第一次就写得简单不用先删掉 200 行再写成 50 行。提问提前AI 在动手之前提出澄清问题而不是写坏了再补救。PR 变干净每一处改动都能对应到你的一条具体请求。这跟带新同事是一个道理你不考核他背没背文化手册你看产出。如果 AI 修完 bug 还会热心地改一堆引号风格那是规则没生效不是偶发失误。四条原则怎么给 AI 的毛病踩刹车四条原则各对应一种失败模式。先记住失败模式原则本身就好记了。原则一编码前思考。失败模式是 AI 默默选一种解释就开写。你说让搜索变快它直接上缓存层、数据库索引、异步处理——而你可能只是想让首屏结果快半秒。这条原则要求它把几种解释都摆出来让你挑是响应时间、吞吐量还是感知速度每条路的工作量都不一样。就像装修队进场你还没说预算它已经抡起电钻了。原则二简单优先。失败模式是过度抽象。任务只是算个折扣AI 却爱写策略模式class DiscountStrategy(ABC): # 抽象基类 abstractmethod def calculate(self, amount): ... class PercentageDiscount(DiscountStrategy): # 百分比策略 def calculate(self, amount): ... class FixedDiscount(DiscountStrategy): # 固定金额策略 def calculate(self, amount): ... class DiscountCalculator: # 外加配置类、上限、起购门槛 def apply_discount(self, amount): ...实际需要的只有一个函数def calculate_discount(amount, percent): 计算折扣金额percent 为 0-100 return amount * (percent / 100)给一次性用途上抽象层等于给单行道修高速收费站——不是收费站不好是路还没到那个量级。文件里给了个很实用的自检200 行能压到 50 行就重写资深工程师看了说过度设计了就简化。原则三精准修改。失败模式是修空邮箱导致崩溃时它顺手加上用户名长度校验、改写注释、统一引号。错误示范重写整个校验函数加一堆没人要的新规则。正确做法只动处理空邮箱的 2-3 行其余字节都不变。判定标准很硬每一行改动都必须能直接追溯到你的请求。唯一例外是你改动制造的孤儿——因此变得无用的导入和变量该清理但原有的死代码只提一句别擅自删。原则四目标驱动执行。失败模式是你说修这个 bug它直接改代码然后告诉你已完成——无从证明修好了也无从证明没改坏别的。这条原则要求把任务翻译成可验证的目标修 bug变成先写一个能复现 bug 的测试再让测试通过最后确认没有回归。这正是 Karpathy 的核心洞察别告诉 AI 该做什么给它成功标准让它自己循环。强的成功标准让它独立跑让它能跑这种弱标准会让你全程陪跑确认。 怎么把规则装进你的项目规则本质是一个文本文件装起来很简单分三种情况Claude Code 用户推荐终端里先执行插件命令/plugin marketplace add forrestchang/andrej-karpathy-skills再/plugin install andrej-karpathy-skillskarpathy-skills规则会在你所有项目里生效。已有项目执行git clone https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills把仓库拉下来把CLAUDE.md拷到项目根目录即可。项目里已有 CLAUDE.md 就别覆盖把这几条原则追加合并进去——文件本来就是这么设计的。Cursor 用户注意 Cursor 默认不读 CLAUDE.md。把仓库里的.cursor/rules/karpathy-guidelines.mdc拷进你项目的.cursor/rules/目录开箱即用。装完之后让规则长出适配你项目的那部分有两个地方值得调。加上自己的项目条款。四条原则之后你可以在 CLAUDE.md 里补一段项目专属指南比如TypeScript 必须开严格模式所有 API 端点都要有测试。写得越具体越好AI 只会执行条款不会替你猜。保留分寸感。文件开头就声明了它的取向谨慎优先于速度。目的是减少非琐碎工作中的昂贵错误不是拖慢小改动。如果 AI 改一行拼写错误也走完整验证流程说明规则被误读了直接告诉它这个任务很琐碎直接改。下一步今晚就能做完打开你改动最频繁的那个项目把规则文件放进去装插件或拷 CLAUDE.md 都行然后给 AI 一个带明确验收标准的小任务比如先写测试复现这个 bug再修它做完后检查 diff——任何改到你请求之外的行就是规则需要补强的地方。把这个循环跑顺一次四条原则就会变成你和 AI 协作的默认方式。【免费下载链接】andrej-karpathy-skillsA single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathys observations on LLM coding pitfalls.项目地址: https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考