企业官网建设流程全解析

Claude Code 自定义规则插件完整指南：从装上 Karpathy 行为准则到写出你的第一条规则

【免费下载链接】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

如果你也被 AI 改代码时的"惊喜"折腾过——顺手重构了没让它碰的文件、给一个简单功能套上三层抽象——这篇教程会用 andrej-karpathy-skills 这个开源项目，带你从零搭一个自定义规则插件。读完你不仅能把它装起来，还能照着项目里的现成结构，写出适合自己团队的规则文件。

这个项目本身很轻：它的核心就是用一个行为准则文件来约束 Claude Code 这类编码助手的做事方式，灵感来自 Andrej Karpathy 对大模型写代码常见毛病的总结。规则不复杂，但它把"AI 爱犯的错"一条条翻译成了可执行的约束。

⚡️ 三分钟装好：让 Claude Code 先守上规矩

先让东西跑起来，原理我们回头再拆。项目提供了两条安装路线，按你的使用习惯选一条。

装成 Claude Code 插件：所有项目一次生效

在 Claude Code 里依次输入两行命令，先添加插件市场，再安装：

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

装完后这套准则会变成你的全局技能，之后打开任何项目都会自动带着这些约束。这是官方推荐的方式。

放进单个项目：一个 CLAUDE.md 搞定

如果你只想在某个项目里生效，可以把仓库克隆下来：

git clone https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills

然后把仓库里的CLAUDE.md复制到你的项目根目录即可。如果项目里已经有自己的CLAUDE.md，把内容追加合并进去，不要直接覆盖。

Cursor 用户怎么接

用 Cursor 的话，把.cursor/rules/karpathy-guidelines.mdc复制到目标项目的.cursor/rules/目录（没有就新建），规则即自动生效；在Settings → Rules里能看到karpathy-guidelines就说明接上了。项目里附带的CURSOR.md把这套流程写得更细，可以对照着看。

装好后先别急着写自定义规则。花两分钟读一遍项目里的CLAUDE.md，你会发现全文其实只有四个原则，每条都用几行要点写完——这正是稍后你要模仿的写法。

它到底在约束 AI 什么：换个角度读四个原则

原文按"原则"分章，这里我们按编码的生命周期重排一遍：写之前、写新代码时、改老代码时、收尾时。这样你会发现规则其实就是在四个节点上各踩了一脚刹车。

动手写之前：把它脑内的假设逼出来

大模型最常见的毛病是"替你拍板"：需求模糊时它不问你，自己默默选一种理解然后一路跑到底。这条原则要求它在实现之前先做四件事：不确定就问、有多种理解就摆出来让你选、有简单方案就直说、真的看不懂就停下来指明困惑点。

对应的正确行为长这样：你让它"加个用户数据导出功能"，它应该先问导出范围、文件格式、字段清单，而不是直接假设"导出全部用户到 json 文件"然后开写。

写新代码时：只写够用的行数

这条专治过度工程。它的口径很硬：没要求的功能不加，单次使用的代码不抽抽象，没人要的"灵活性"不做，不可能发生的场景不写错误处理。判断标准也给了你——一个资深工程师会不会说这段代码写复杂了？会，就重写。200 行能压到 50 行的，直接重写。

注意它打击的是"时机"而不是"能力"：策略模式本身没错，错在你只有一个折扣类型时就用上了。

改老代码时：像外科手术一样下刀

这条约束的是 diff 的边界。规则要求：不"顺手改进"相邻代码、注释和格式，不重构没坏的东西，风格跟着现有代码走——哪怕你有更喜欢的写法。发现无关的死代码可以提一句，但别删。唯一要主动清理的，是你自己的改动导致不再被使用的导入、变量和函数。

自查口径同样干脆：每一行改动都应该能直接追溯到你的需求。追溯不到的，就是扩散。

收尾时：给成功标准，让它自己闭环

这是整个项目最有意思的一条。Karpathy 的观察是：大模型特别擅长"朝着明确目标循环"，所以别告诉它"把验证加上"，而是给它"为非法输入写测试，然后让测试通过"。模糊指令（"修好这个 bug"）会换来需要反复澄清的执行；可验证的目标则能让 AI 独立跑完整个循环。多步任务则先列一个简短计划，每步都带一个"验证：怎么检查"。

🔧 实战：从零写一个自定义规则插件

规则生效的前提是你先知道它该管什么。下面这套流程，每步都给你"做什么 → 怎么做 → 怎么算过"。

定目标：你的规则要管住哪个毛病

先想清楚一个具体问题，比如：

• 团队里接口命名风格混乱，想统一成"动词开头"；
• AI 总在你的项目里加没人要的配置项；
• 每次提交都混入格式化和顺手重构。

检查标准：你能用一句话说明"装了这条规则后，AI 的哪类行为会变"。说不出来，就还没想清楚。

搭骨架：照着 SKILL.md 的结构来

打开项目里的skills/karpathy-guidelines/SKILL.md，这就是一个最小可用的规则文件：开头一段 frontmatter 元信息，正文按主题分小节，每节几句要点，全文不过百行。你自己的规则文件照这个骨架写就行：

--- name: my-team-rules description: 团队代码规范，写代码、改代码、重构时使用。 license: MIT --- # 团队规则 ## 命名 - API 路由一律动词开头：create-user，不写 user-create ## 提交 - 每次提交只包含当前任务相关的改动，不夹带格式化

frontmatter 里的description不是摆设，它决定 AI 在什么场景下想起用这条规则，写清"什么时候用"比写"这文件是什么"更有用。

检查标准：全文不超过一页，每条规则都能对应一个具体的错误行为，没有任何"原则上""尽量"这类无法执行的措辞。

落地：放进你的 Claude Code

两种接法，和装官方规则时一样：新项目把规则内容合并进CLAUDE.md；多项目通用就按 SKILL.md 的方式放进技能目录。项目官方的规则也是这么"可合并"设计的，CLAUDE.md和SKILL.md内容刻意保持一致，就是方便你挑一份用。

检查标准：新开一个会话，问 AI"你现在的代码规范是什么"，它能复述出你的规则要点。

验收：怎么证明规则真的生效

别用"看起来变乖了"当标准，用两个可观察的信号验收：

• 看 diff：让 AI 做一个小改动（比如修一个空指针判断），检查改动是否只落在该落的行上，没有夹带格式化和"顺手优化"；
• 看提问时机：给一个模糊需求（"把搜索做快一点"），看它在动手前是否先列出可能的理解让你选。

检查标准：diff 干净、澄清问题出现在实现之前而不是翻车之后，规则就算活了。

❓ 规则写废了？四类高频坑自查

规则越写越长，AI 还会认真读吗

不会。规则文件不是论文，每条规则对应一个具体错误，控制在一页以内。你写的规则本身也该遵守"少即是多"，否则 AI 会在几十条约束里挑软柿子捏。

规则和现有 CLAUDE.md 冲突了听谁的

先合并、后生效。合并时手动对齐措辞，别留两条打架的条款。改过规则后记得同步检查CLAUDE.md、Cursor 规则和 SKILL.md 这几份副本，项目贡献指南里也特别强调了多份文件要保持一致。

为什么小改动也被这套流程拖慢了

这是官方自己写明的取舍：这套规则偏向谨慎而不是速度。改个错别字、写个明显的一行函数，别走完整流程，用常识。规则的目标是压住非平凡任务上的高成本错误，不是给所有操作加税。

怎么判断规则在起作用，而不是装了个摆设

持续观察三个信号：diff 里的无关改动变少了；因为写复杂而返工的次数降下来了；澄清问题从"出错之后补救"变成了"动手之前确认"。三个信号都朝着好的方向走，说明你的自定义规则插件真的在干活。

写在最后：你的下一步

回看一遍：装好官方规则只要两行命令，理解它等于理解"四个节点各踩一脚刹车"，写自己的规则就是照着SKILL.md的骨架填上你团队的毛病。

建议的动手顺序：今天把插件装上跑一两个任务，感受 diff 的变化；本周挑一个你被 AI 反复得罪过的场景，按"目标 → 骨架 → 落地 → 验收"写出你的第一条自定义规则。规则不需要一步到位，像项目推崇的那样——够用就行，后面再迭代。

【免费下载链接】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