ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

让 AI 少写废代码:andrej-karpathy-skills 快速上手指南

让 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-skillsandrej-karpathy-skills 是一个只有一份CLAUDE.md的开源项目它把 Andrej Karpathy 对 LLM 编码陷阱的观察浓缩成四条行为准则用来改善 Claude Code 等 AI 编码助手在真实项目中的表现——不再乱猜、不再乱加功能、不再顺手乱改别人没要求改的代码。这篇文章带你从零看懂它解决什么问题以及如何三步接入自己的项目。一、先聊一个你一定踩过的坑你让 AI 修复空邮箱会导致校验器崩溃的 bug结果拿回的 diff 里除了真正修 bug 的两行还混进了新加的用户名校验规则、被顺便改写的注释、统一成另一种引号风格的代码、一段没人要的 docstring。或者你只说了句加个导出数据功能AI 就默认导出全部用户、默认写到某个文件、默认带上某些敏感字段——所有假设它都没告诉你直接开干。这类问题不是模型笨而是它默认了两种危险行为默默选定一种理解往下跑以及把手头的活扩大成一场重构。andrej-karpathy-skills 要解决的就是这件事。二、一句话定位一份文件给 AI 立四条规矩项目本体就是一个CLAUDE.md文件正文见 CLAUDE.md放进项目根目录或装成 Claude Code 插件AI 每次干活前都会读到它。四条原则可以概括成一句话先想清楚再动手动手时写最少的代码、改最少的行收尾时必须有可验证的标准。三、核心概念拆解把四条原则放到写代码的三个时刻原文按四条原则平铺对新手不太友好。其实换个切法更好记——按动手前 / 动手中 / 动手后三个阶段来看动手前把假设摆到桌面上Think Before Coding常见失误AI 面对歧义需求时静默选一种解释继续做。比如让搜索更快——更快是指响应时间、并发量还是加载体验它不会问直接给你上一套 200 行的缓存异步方案。正确姿势把假设逐条列出来有多种解释就都摆出来让你选觉得有更简单的做法直接说出来真看不懂就停下说出哪里困惑。动手中写最少的代码改最少的行Simplicity First Surgical Changes常见失误为一次性的折扣计算搭策略模式抽象基类配置对象30 多行起步修 bug 时顺手重构相邻代码、改格式、删无用注释。正确姿势没有要求的功能不加单次使用不建抽象不为以后可能预留灵活性改现有代码时匹配它已有的风格无关的死代码提一句就行别删。自检问题一个资深工程师会说这段代码写复杂了吗每一行改动都能追溯到需求本身吗动手后用可验证的目标收尾Goal-Driven Execution常见失误我会审查代码并做改进——这种说法没法验收等于让 AI 自己判断差不多行了。正确姿势把任务改写成可验证的目标。修复 bug → 先写一个能复现 bug 的测试让它通过再确认原有测试没挂多步任务则每步都标注验证方式。标准定得清楚AI 才能自己循环验证而不是一直来回问你。阶段对应原则一句话自检动手前先想清楚再编码我的假设都列出来了吗动手中简单优先 外科手术式修改这行改动是需求直接要求的吗动手后目标驱动执行怎么证明它做完了、做对了四、三步接入最短路径让 CLAUDE.md 生效方式一装成 Claude Code 插件推荐在 Claude Code 里执行两条命令指南即可在所有项目中生效/plugin marketplace add forrestchang/andrej-karpathy-skills /plugin install andrej-karpathy-skillskarpathy-skills方式二把 CLAUDE.md 放进单个项目适合只想先在一个项目里试试的情况git clone https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills cp andrej-karpathy-skills/CLAUDE.md 你的项目目录/CLAUDE.md如果项目里已有CLAUDE.md直接把它追加到文件末尾即可指南本身就设计为可与项目自定义规则合并。用 Cursor 的话仓库里已附带对应的 Cursor 规则文件具体配置见 CURSOR.md。五、一个小场景走查同一个 bug两种 diff需求修复空邮箱让校验器崩溃的 bug。没上指南时AI 的典型产出节选# 修 bug 的同时顺手 if len(username) 3: raise ValueError(...) # 没人要的用户名校验 # 注释措辞被改写、引号风格被统一、还加了 docstring上了指南之后diff 只包含真正修 bug 的几行- if not user_data.get(email): email user_data.get(email, ) if not email or not email.strip(): raise ValueError(Email required)对比很直观前者每次合并都要花额外时间分辨哪些是我要的、哪些是它自作主张的后者一眼就能过。仓库的 EXAMPLES.md 里还有用户导出搜索提速日志功能等一组同类前后对比值得翻一遍。六、如何判断它已经生效不用看指标问自己四个问题就行最近几次 PR 里被改动的行数是不是明显收敛到了需求范围内AI 是动手前来问澄清问题还是搞砸之后才解释新写的代码是不是第一版就比较短而不是写完之后又推倒重写提交流里是不是没有附带改进和顺手重构了四个问题如果三个以上答案是肯定的说明这套准则已经在起作用。七、常见误区什么时候不用这么较真误区一把准则当教条简单任务也走全套流程。官方明确说了这套指南偏向谨慎而非速度。改个拼写错误、明显的一行修改直接改就行——目标是减少非平凡工作里的高价错误不是拖慢小事。误区二认为过度复杂的写法是错的。那些 30 行的策略模式并不违反设计原则错的是时机——在需要之前就加复杂性会让代码更难理解、更难测试、写起来更慢。简单版本的优势恰恰在于等真正需要多种折扣类型的那一天再重构不迟。八、下一步今晚就能做的两件事把你最活跃的那个项目的CLAUDE.md补上或装好插件十分钟以内。明天挑一个小 bug 让 AI 修然后对比一下这次的 diff 和你上周见过的有多大差别——这就是最直接的验收方式。如果想系统看四类陷阱的完整案例对照从 EXAMPLES.md 开始读插件用户可以把 skills/karpathy-guidelines/SKILL.md 当作准则原文随时查阅。【免费下载链接】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),仅供参考
返回列表