企业官网建设流程全解析

andrej-karpathy-skills 深度拆解：4 条行为准则如何纠正 LLM 编码习惯

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

andrej-karpathy-skills 把 Andrej Karpathy 对 LLM 编码陷阱的观察压缩成一个包含 4 条行为准则的 CLAUDE.md 文件——编码前思考、简单优先、手术式修改、目标驱动执行，对准过度复杂化、隐藏假设、无关重构三大毛病。

给 LLM 写规则，为什么比继续训练它更划算

先讲一个你可能也经历过的现场。

你让 AI 修一个空指针异常，十分钟后打开 diff：异常确实没了，但整个 Service 层的方法签名变了，文件里的引号被统一成双引号，每个方法还都被加上了类型标注。

这就是 LLM 编码最典型的行为：它会顺着自己的假设一路跑下去，还"好心"地越界。AI 专家 Andrej Karpathy 说过，模型不会管理自己的困惑，不寻求澄清，不暴露不一致，该反驳时也不反驳。

修模型行为的常规路线是加数据、继续训练。这条路贵、慢，而且只对特定模型版本生效。andrej-karpathy-skills 换了个思路：把规则直接写进上下文。一份 Markdown 文件装下 4 条准则，加载即生效，随时可撤，还能跟着代码一起进 git 做评审。

和别的 prompt 手法比一下：堆砌 system prompt 是临时的，few-shot 例子只服务特定任务，只有 CLAUDE.md 配置既持久又通用。它本质做三件事——减少模型要自己拍板的决策、让行为可预测、把"看起来对"变成可验证的条目。工程里的 YAGNI、KISS 这些常识，都能装进这一个文件。

🔒 4 条准则的机制拆解：它们锁成一条链

打开 CLAUDE.md，乍看是四条并列戒律，其实藏着一条链：先问清楚，再决定怎么写，再限定改动范围，最后定义什么叫做完。1 给 2 供信息，2 给 3 划边界，4 决定前三者能否自我验证。

准则一：先开口，再动手

机制一句话：不让假设自由生长。模型遇到模糊需求时，默认动作是挑一个解释跑下去；这条准则逼它在实现前把假设摆上台面，有多种解释时全部列出，遇到不懂就停下提问。

EXAMPLES.md 里有个"导出用户数据"的例子。没准则时，模型会默默导出全部用户、全部字段、JSON 格式、存到当前目录。有准则后，它先问的是一批问题：全量还是筛选？哪些字段？文件还是接口？数据量多大？区别在于：前者替用户做了决策，后者只是减少了决策空间。

准则二：能用 50 行解决，就别写 200

这条开出的禁令清单很具体：没人要的功能不写、一次性代码不做抽象、没人要的"灵活性"不加、不可能出现的场景不做异常处理。写了 200 行而 50 行能搞定，就重写。

EXAMPLES.md 里有个折扣计算案例，同一需求两种形态：

前者不算错，设计模式都用得对。问题出在时机：复杂度在没被需要时就被引进来，代码更难懂、更容易藏 bug、更难测试。所以准则给模型配了一个能随时自检的问题："一个高级工程师会说这过度复杂吗？"会，就简化。

准则三：每行改动都要能追溯到请求

这条专治"顺手重构"，判据锋利：每一行改动必须能直接追溯到用户的请求。

EXAMPLES.md 里"给上传函数加日志"的例子很有代表性。模型实际交付：引号从单引号改双引号、补类型标注、加 docstring、重排空白、改写布尔返回逻辑。用户要的只是三行日志。准则把行为劈成两半：动过的代码要匹配现有风格，哪怕你个人不认同；看到无关死代码，提一句，但别删——决定权留给人。只有你自己改动制造出的孤儿导入和变量才需要清理。

准则四：不说"去做"，说"做到什么程度算完"

Karpathy 的原话：LLM 特别擅长朝着具体目标循环——别告诉它做什么，给它成功标准。

"修复认证系统"是没有方向的指令。这条准则把它翻译成可验证目标：先写一个能复现问题的测试，再让它通过，最后确认老测试套件全绿。多步任务要求列出计划，每步配一个验证动作。强的成功标准让模型能独立循环；"让它能用"这种弱标准，会让每一步都变成一轮澄清提问。

效果对比：怎么判断准则在起作用

别凭感觉。项目文档列了四个可观察信号：

这里有个代价要说清楚：模型学会先提问后，和人的往返轮次会变多。这不是失灵，是把试错从 diff 环节挪回了需求环节。

🧭 适用边界：什么时候用，什么时候别用

文档自己承认：这些准则偏向谨慎而非速度。不是每个任务都要全套严谨。

适合用的：需要深入理解的非平凡任务、修改现有代码库、要求精确控制输出的场合、需要统一标准的团队。

该跳过的：修个拼写错误、明显的一行改动。对这种任务让模型先列假设，纯属白拖慢速度。

还有两个容易踩的坑：

1. 准则间优先级冲突。比如"简单优先"和用户隐性的"顺手加点灵活性"打架时，准则给的是默认值：只实现被请求的部分，其余礼貌顶回去。你不同意可以覆盖——准则是默认姿态，不是法律。
2. 与项目规范的冲突。这份准则明确设计为"与项目特定指令合并使用"。如果只丢文件不合并，通用层可能和项目自己的约定打架。把它追加到现有 CLAUDE.md 里，项目级规则写在后面，冲突时以项目层为准。

接入成本：两条路，都接近于零

集成方式只有两种，都是文件级的。

方式一：Claude Code 插件（全项目生效）。在 Claude Code 里跑两条命令：

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

方式二：CLAUDE.md 文件（按项目配置）。这个项目本体就是一个文件，从仓库取 CLAUDE.md 即可：新项目直接放根目录，老项目追加进现有 CLAUDE.md，留出和自己指令合并的空间。插件装的其实是 skills/karpathy-guidelines/SKILL.md 这同一份准则；同一套规则也能配成 Cursor 项目规则，见 CURSOR.md。

成本就是一份文件和两分钟阅读。

这个项目的价值不在于让模型变聪明，而在于让模型的行为可预期、可审查。下次打开 diff 时问自己一个问题：每一行改动，我都能追溯到我的请求吗？如果不能，这份文件值得放进你的项目。

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