尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

用 andrej-karpathy-skills 约束 AI 编码行为:少改错行代码,多写有用注释

用 andrej-karpathy-skills 约束 AI 编码行为:少改错行代码,多写有用注释 用 andrej-karpathy-skills 约束 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 修一个拼写错误它顺手重排了整份文件的引号风格让它加个导出功能它自作主张假设了文件格式和字段范围。用 AI 编码工具的人几乎都踩过这类坑。andrej-karpathy-skills 是一个开源项目把 Andrej Karpathy 对 LLM 编码陷阱的观察整理成一份行为准则文件用来约束 AI 编码代理写码、改码和重构的方式。它适合刚使用 Claude Code 等工具的新手也适合想让 AI 输出更可控、代码文档更干净的普通开发者。1. 你遇到过哪些 LLM 编码陷阱项目源自 Karpathy 对大模型的三段观察可以对照检查你的日常模型会替你做出错误假设然后顺着假设一路写下去从不确认。模型喜欢过度设计100 行能解决的事它能堆出 1000 行的灵活架构。模型会顺手改动、甚至删除它并不充分理解的注释和代码哪怕这些内容与当前任务无关。落到实际开发里后果很具体diff 里混进大量没要求过的改动review 成本翻倍原有注释被悄悄改掉接手的人分不清哪些行为变了AI 沉默地替你做决定假设要等 bug 暴露才浮出水面生成的代码偏复杂配套文档还得人工重写一遍。2. 项目机制一份文件四条行为规则andrej-karpathy-skills 的核心就是一个 CLAUDE.md 文件。它不是 linter也不是格式化器而是一份在 AI 编码工具启动任务时被读入的指令。文件里定义四条规则动手前先声明假设不确定就问存在多种解读时摆出来让你选只写解决问题的最小代码不加没被要求的功能、抽象和配置项精准修改只碰必须碰的行每一处改动都能追溯到你的请求把任务转成可验证的目标比如写一个复现 bug 的测试然后让它通过循环到验证为止。仓库里还有配套内容skills/karpathy-guidelines/SKILL.md是可分发的技能版本CURSOR.md说明如何在 Cursor 中启用同款规则EXAMPLES.md则用真实代码对比了AI 常犯的错误写法和改法可以直接当参考标准读。需要知道的一点权衡这套规则偏向谨慎而非速度。改错别字这类小事不必走完整流程项目本身也明确说了简单任务凭判断。3. 如何接入 andrej-karpathy-skills 3.1 用 Claude Code 插件全局启用适合在多个项目里都用 Claude Code 的场景一次接入所有项目生效。在 Claude Code 内依次执行/plugin marketplace add forrestchang/andrej-karpathy-skills /plugin install andrej-karpathy-skillskarpathy-skills安装后四条准则作为技能在所有项目中可用不需要再往单个项目里放文件。3.2 用 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.md把配套规则文件拷入目标项目即可。4. 如何用它改进代码注释与文档质量4.1 先定义注释写给谁看同一份代码不同读者需要的信息粒度不同调用方关心怎么调用、返回值是什么格式后续维护者关心设计意图和已知限制AI 编码代理需要知道哪些区域不要动。写注释前先回答这段注释写给谁再决定写什么。4.2 用可验证的说明替代模糊解释处理数据、工具函数这类注释没有信息量。一份合格的说明应覆盖输入、输出、限制、副作用、失败场景。这里可以借用第一条规则的思路——让 AI 在动手前把假设列出来确认无误的假设就是注释最好的素材。4.3 控制注释长度与信息密度短说明优先。复杂逻辑可以编号分步但不要逐行复述代码本身。判断标准很简单注释应帮读者回答能不能用、怎么用、不能怎么用这三个问题。如果注释比函数体还长通常说明函数该拆了而不是注释写得好。4.4 让 AI 按规则生成和更新注释接入后可以在任务里补一句短要求例如改动函数行为时同步更新其 docstring 写明输入输出、限制和失败场景每段不超过 3 行。同时精准修改这条规则会阻止 AI顺手改进它并不理解的注释——这正是针对 Karpathy 观察到的第三类问题。5. 常见误区与排错 装完插件没生效插件改动通常在新的会话中生效。重开对话并确认插件处于启用状态。CLAUDE.md 内容重复追加到已有项目前先检查文件。四条规则已存在就不要再贴第二份保留一份并合并项目规则。AI 仍改无关代码通用规则覆盖不了所有场景。在 CLAUDE.md 中加一节项目专属规则例如不改动 xxx 目录外的文件、遵循现有的错误处理写法。简单任务变慢在文件里明确写出拼写修正、单行改动可跳过完整流程保留项目自带的权衡说明。把它当成分析工具它不运行、不扫描、不出报告。它只是一段被载入 AI 上下文的自然语言约束效果通过 AI 的行为体现。6. 下一步建议挑 3 到 5 个你负责的核心函数按 4.2 的标准让 AI 补注释再人工检查每条说明是否可验证、可执行。先在一个非核心项目接入插件或 CLAUDE.md观察几天 diff确认没要求过的改动是否真的减少。效果确认后把你的项目专属规则合并进 CLAUDE.md让它成为团队 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),仅供参考
返回列表