三步定制你的 LLM 编码指南让 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-skillsandrej-karpathy-skills 是一套基于 Andrej Karpathy 观察总结的 LLM 编码指南帮开发者减少 AI 写代码时常见的错误。开箱即用固然省事但真正让它贴合你团队的做法是把它定制成自己项目的编码纪律。这篇文章分享一条可落地的路径如何定制 AI 编码规则从诊断、改写到固化走完一遍大概一两个小时。AI 写代码最常翻车的三个场景如果你已经用 AI 辅助编码一段时间下面这几个瞬间大概率不陌生过度设计。你只是要个导出功能AI 顺手给你配了配置项、策略模式、三个抽象层。Karpathy 的吐槽很直接100 行能搞定的事AI 喜欢写成 1000 行的臃肿架构。顺手改了无关代码。修一个字段名diff 里冒出来一堆顺手优化的格式调整和注释润色review 时根本看不清真正的改动。没验证就当完成。改好了应该能用了——没有测试、没有复现步骤成功标准是让它工作这种弱目标。通用指南能拦住一部分这类问题但拦不全。原因很简单它不知道你的项目边界在哪。同样的简单优先原则一个小工具和一套百万行数据处理流水线的合理阈值完全不同。这就是编码指南定制要解决的事——把通用原则翻译成你项目的具体规则。三步定制工作流诊断、改造、固化第一步 诊断先用四个维度定位你的定制方向改造之前先花 10 分钟盘一下项目现状定制方向基本就清楚了维度问自己定制方向项目规模几百行还是几十万行小项目收紧简洁阈值大项目补充模块拆分和 API 规范团队结构一个人、小团队还是多人协作人越多精准修改和提交粒度规则越要写细技术栈前端、后端、数据还是全栈用本栈的具体工具名替换泛化表述如用项目已有的错误处理模块开发流程是否走 PR 评审、有没有 CI有评审就把 diff 规范写进指南没 CI 就强化先写验证再提交判断标准就一句话你的团队最痛的那个翻车点就该是定制的重点。第二步 改造按场景把原始原则改写成项目规则原始指南只有四条抽象原则编码前思考、简洁优先、精准修改、目标驱动执行见 skills/karpathy-guidelines/SKILL.md改造时不要重写原则本身而是在每条原则下补项目规则。几个场景的前后对照话术仅供参考请换成自己项目的口径场景一API 服务原始原则编码前思考——不要假设不确定就问。定制后动手前先回答三件事——接口路径和现有路由风格一致吗、错误响应用的是项目统一的错误码还是新造的、权限校验是复用中间件还是手写。答不上来就先问不要默默定。场景二数据处理原始原则简洁优先——最少的代码解决问题。定制后能一行内置函数解决的就不写循环数据量没到需要分片处理的程度前禁止引入分布式组件给脚本加日志和断点续跑逻辑只出现在任务明确提及时。场景三前端项目原始原则精准修改——只碰必须碰的代码。定制后新增组件一律放在对应页面目录不改公共样式文件复用组件前先查一遍components/下有没有现成的diff 里不允许出现与本次需求无关的格式重排。每条规则建议都带一个怎么判断违反了的可检查动作AI 和人都能执行而不是一句注意代码简洁。第三步 固化写进 SKILL.md按季度回看改出来的规则如果只留在聊天窗口里第二天就会丢失。固化动作有两个写回仓库。把定制规则追加到 skills/karpathy-guidelines/SKILL.md 的对应原则下Cursor 用户同步更新 CURSOR.md 对应的规则文件。新增的行为示例补充到 EXAMPLES.md让规则 → 反例/正例成对出现AI 照着示例执行比照着条款执行稳定得多。建立回顾机制。建议在日历里放一个季度提醒回看两个指标diff 里无关改动变少了没有因过度设计返工的次数变少了没有规则被实际引用或实际拦住了错误才保留从没生效过的规则直接删掉。一个最小可运行的起点直接 clone 下来改git clone https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills定制团队编码规范的五个常见误区改完之后如果 AI 行为没变化多半踩了下面这几个坑规则改得过细。写了三十条细则AI 注意力被稀释真正关键的两三条反而执行不到。每个原则下保留 3~5 条高优先级规则即可。规则与团队流程脱节。指南要求每个提交只解决一个问题但团队的分支策略就是大合并——规则和执行环境对着干形同虚设。只定制、不回顾。项目技术栈换了、人进来了旧规则没回看最后 CLAUDE.md 变成一份考古文档。规则不可验证。写出高质量代码没法检查接口必须有集成测试可以。每条规则尽量能回答怎么算违反了。对琐碎任务也全套流程。原指南自己就声明了倾向谨慎而非速度让 AI 改个错别字也走完整检查流程只会拖慢节奏。简单任务放开手就行。收尾最好的指南是团队愿意执行的指南编码指南定制不是把条款抄得更全而是让每一条规则都能对应到团队真实踩过的坑。花一个下午走完诊断、改造、固化三步下个季度回看时你会清楚地知道哪些规则真正拦住了错误。下一步很简单打开仓库把 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），仅供参考 三步定制你的 LLM 编码指南：让 AI 少犯错的实用指南
三步定制你的 LLM 编码指南让 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-skillsandrej-karpathy-skills 是一套基于 Andrej Karpathy 观察总结的 LLM 编码指南帮开发者减少 AI 写代码时常见的错误。开箱即用固然省事但真正让它贴合你团队的做法是把它定制成自己项目的编码纪律。这篇文章分享一条可落地的路径如何定制 AI 编码规则从诊断、改写到固化走完一遍大概一两个小时。AI 写代码最常翻车的三个场景如果你已经用 AI 辅助编码一段时间下面这几个瞬间大概率不陌生过度设计。你只是要个导出功能AI 顺手给你配了配置项、策略模式、三个抽象层。Karpathy 的吐槽很直接100 行能搞定的事AI 喜欢写成 1000 行的臃肿架构。顺手改了无关代码。修一个字段名diff 里冒出来一堆顺手优化的格式调整和注释润色review 时根本看不清真正的改动。没验证就当完成。改好了应该能用了——没有测试、没有复现步骤成功标准是让它工作这种弱目标。通用指南能拦住一部分这类问题但拦不全。原因很简单它不知道你的项目边界在哪。同样的简单优先原则一个小工具和一套百万行数据处理流水线的合理阈值完全不同。这就是编码指南定制要解决的事——把通用原则翻译成你项目的具体规则。三步定制工作流诊断、改造、固化第一步 诊断先用四个维度定位你的定制方向改造之前先花 10 分钟盘一下项目现状定制方向基本就清楚了维度问自己定制方向项目规模几百行还是几十万行小项目收紧简洁阈值大项目补充模块拆分和 API 规范团队结构一个人、小团队还是多人协作人越多精准修改和提交粒度规则越要写细技术栈前端、后端、数据还是全栈用本栈的具体工具名替换泛化表述如用项目已有的错误处理模块开发流程是否走 PR 评审、有没有 CI有评审就把 diff 规范写进指南没 CI 就强化先写验证再提交判断标准就一句话你的团队最痛的那个翻车点就该是定制的重点。第二步 改造按场景把原始原则改写成项目规则原始指南只有四条抽象原则编码前思考、简洁优先、精准修改、目标驱动执行见 skills/karpathy-guidelines/SKILL.md改造时不要重写原则本身而是在每条原则下补项目规则。几个场景的前后对照话术仅供参考请换成自己项目的口径场景一API 服务原始原则编码前思考——不要假设不确定就问。定制后动手前先回答三件事——接口路径和现有路由风格一致吗、错误响应用的是项目统一的错误码还是新造的、权限校验是复用中间件还是手写。答不上来就先问不要默默定。场景二数据处理原始原则简洁优先——最少的代码解决问题。定制后能一行内置函数解决的就不写循环数据量没到需要分片处理的程度前禁止引入分布式组件给脚本加日志和断点续跑逻辑只出现在任务明确提及时。场景三前端项目原始原则精准修改——只碰必须碰的代码。定制后新增组件一律放在对应页面目录不改公共样式文件复用组件前先查一遍components/下有没有现成的diff 里不允许出现与本次需求无关的格式重排。每条规则建议都带一个怎么判断违反了的可检查动作AI 和人都能执行而不是一句注意代码简洁。第三步 固化写进 SKILL.md按季度回看改出来的规则如果只留在聊天窗口里第二天就会丢失。固化动作有两个写回仓库。把定制规则追加到 skills/karpathy-guidelines/SKILL.md 的对应原则下Cursor 用户同步更新 CURSOR.md 对应的规则文件。新增的行为示例补充到 EXAMPLES.md让规则 → 反例/正例成对出现AI 照着示例执行比照着条款执行稳定得多。建立回顾机制。建议在日历里放一个季度提醒回看两个指标diff 里无关改动变少了没有因过度设计返工的次数变少了没有规则被实际引用或实际拦住了错误才保留从没生效过的规则直接删掉。一个最小可运行的起点直接 clone 下来改git clone https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills定制团队编码规范的五个常见误区改完之后如果 AI 行为没变化多半踩了下面这几个坑规则改得过细。写了三十条细则AI 注意力被稀释真正关键的两三条反而执行不到。每个原则下保留 3~5 条高优先级规则即可。规则与团队流程脱节。指南要求每个提交只解决一个问题但团队的分支策略就是大合并——规则和执行环境对着干形同虚设。只定制、不回顾。项目技术栈换了、人进来了旧规则没回看最后 CLAUDE.md 变成一份考古文档。规则不可验证。写出高质量代码没法检查接口必须有集成测试可以。每条规则尽量能回答怎么算违反了。对琐碎任务也全套流程。原指南自己就声明了倾向谨慎而非速度让 AI 改个错别字也走完整检查流程只会拖慢节奏。简单任务放开手就行。收尾最好的指南是团队愿意执行的指南编码指南定制不是把条款抄得更全而是让每一条规则都能对应到团队真实踩过的坑。花一个下午走完诊断、改造、固化三步下个季度回看时你会清楚地知道哪些规则真正拦住了错误。下一步很简单打开仓库把 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），仅供参考