图片：METAL
摘要
- multica-ai仓库根据Andrej Karpathy对LLM编程问题的观察制作了CLAUDE.md指导文件，最近登上GitHub趋势榜
- CLAUDE.md的核心由四条原则组成：禁止臆测、最小代码量、最小改动范围、明确成功标准
- 将其安装为Claude Code插件或Cursor规则文件后，就能在多个项目中沿用同一套指导原则
卡帕西的观察，浓缩成一份文件
Andrej Karpathy在X上发文，指出了LLM编程智能体反复出现的一些毛病。multica-ai仓库以这一观察为基础，制作了一份可以放进Claude Code的指导文件，并以"andrej-karpathy-skills"为名发布。这个创建于2026年1月的仓库最近登上了GitHub趋势榜。核心指导内容浓缩在一份CLAUDE.md文件里，但仓库中还附带了README、CURSOR.md、SKILL.md、插件以及供其他工具使用的Cursor规则文件，方便安装和跨工具接入。CLAUDE.md中包含四条原则，分别对应卡帕西指出的三个问题。
卡帕西指出的三个毛病
卡帕西指出，LLM在写代码时会反复出现三种问题。"模型会替用户做出错误的假设，然后不加确认就直接推进。"他的意思是，模型不会去管理混乱之处，不会主动请求澄清,也不会把矛盾或权衡摆出来讲清楚。第二个问题是过度设计：本来100行就能搞定的事，模型会写出上千行代码，而且不会清理无用的死代码。第三个问题是副作用：模型会在没有充分理解的情况下，修改或删除与需求无关的注释或代码。
CLAUDE.md的四条原则
该仓库针对这三个问题，提出了四条应对原则。
| 原则 | 核心语句 | 内容 |
|---|---|---|
| 禁止臆测 | "Don't assume. Don't hide confusion. Surface tradeoffs." | 不让模型悄悄自行解读后就往下推进,而是先把不确定的部分和权衡摆出来 |
| 最小代码量 | "Minimum code that solves the problem." | 用来遏制过度设计的原则，给出的判断标准是"如果一名资深工程师看了会觉得多余,那就该简化" |
| 最小改动范围 | "Touch only what you must. Clean up only your own mess." | 只让模型改动必须改动的部分,不去动无关代码,并要求每处改动都能对应到具体的需求 |
| 成功标准 | "Define success criteria. Loop until verified." | 把命令式的指示转化为可验证的目标,让模型能够自行反复迭代、对照标准进行确认 |
第四条原则与卡帕西的另一个观察相呼应：只要把目标讲清楚，模型就会自己反复调整、朝目标靠拢；但如果给出"make it work"这类模糊标准，就得不断反问澄清。
如何使用
multica-ai/andrej-karpathy-skills仓库介绍了两种安装方式。推荐方式是作为Claude Code插件安装：先在Claude Code里添加对应的market place，指导原则就会以插件形式安装上去，之后不局限于某个特定项目，而是在Claude Code打开的所有项目中都能使用这套技能。第二种方式是Cursor：仓库中附带了.cursor/rules/karpathy-guidelines.mdc规则文件，只要在Cursor中打开项目，同样的原则就会自动生效。针对Cursor的具体设置方法，仓库中的CURSOR.md文档里有单独说明。
如果项目本身已经有CLAUDE.md文件，可以把这四条原则合并进去；如果某个项目还有其他专属规则，也可以在这些指导原则下面另加一个章节补充说明。仓库方面解释称，这套指导原则的目的并不是要把修改错别字这类小事也搞得很沉重，而是重点减少那些难以撤销的失误。
制作规则文件、在多个编程智能体之间共用的做法，好处在于不必绑定某个特定模型,团队的工作原则可以反复复用。
在发布该仓库的文章中，同一位作者还顺带介绍了自己做的另一个独立开源项目Multica。据介绍，这是一个通过可复用技能来运行和管理编程智能体的平台，与CLAUDE.md仓库是两个不同的项目。
编辑视角
这个仓库有意思的地方，不在于它把卡帕西个人的观察直接变成了规则，而在于它揭示出一个事实：实际在工作中使用编程智能体的人们，遇到的问题惊人地相似。无论是Claude Code还是Cursor，换了模型，"悄悄做假设然后一意孤行"或者"本该100行的东西硬是写成1000行"这类抱怨随处可见。这更像是LLM编程智能体这个品类共有的习性，而不是某个特定模型的bug——而这次的案例说明，仅凭一份指导文件就能在一定程度上纠正这种习性,这正是它的价值所在。
把类似规模的编程智能体用到实际工作中，得出的结论往往大同小异。如果把目标定得很模糊,比如"让它跑起来就行"，智能体不会反问确认,而是按自己的理解一路做下去，结果反而要花更多时间去检查它做出来的东西。反过来，如果给出可验证的标准——比如"这个函数在这个输入下得到这个输出就算成功"——就能看到智能体自己反复迭代、朝着标准靠拢。这次CLAUDE.md的第四条原则，恰好点中了这一点。
对国内用Claude Code或Cursor写代码的团队来说，把这类指导文件加入项目几乎没有成本。不过要想真正见效，还是得先梳理清楚团队里实际反复出现的问题——比如死代码不清理、动了不相关的文件等等——再据此调整这些原则。如果只是把别人写好的规则原封不动照搬过来，效果只能打个对折。
未来几周内，这种把某个人的观察或团队经验浓缩成CLAUDE.md、技能文件后拿出来分享的做法，很可能会越来越多。一旦开源社区形成用规则文件而不是提示词互相交流的风气，最终很可能会走向Anthropic这类开发商把这些经过验证的规则吸收进默认系统提示词的方向。
更正 (2026-08-24) — 最初的报道将这份指导文件描述成本次新发布的内容。该仓库实际创建于2026年1月27日。已对导语和摘要进行更正。
评论