Karpathy Skills：四条原则让AI编程助手告别过度工程化

AI编程助手为什么总是「用力过猛」

如果你用过AI编程工具做过真正的项目开发，你一定遇到过这些令人抓狂的场景：AI助手在没有充分理解需求的情况下就开始疯狂写代码，把一个简单的功能过度工程化成500行的庞大架构，甚至擅自修改了你根本没让它碰的文件。它听起来信心满满，但实际上可能完全搞错了方向。

这不是模型能力的问题，而是行为规范的问题。最近，一个名为 Andrej Karpathy Skills 的GitHub仓库引起了广泛关注。它看起来极其简单，但却可能是当前AI编程工作流中最实用的改进之一。

Karpathy Skills的核心理念：安装的不是功能，而是纪律

这个仓库的名字虽然叫"Skills"，但它并不是什么花哨的技能包或复杂的自动化工具。它的核心思想来源于Andrej Karpathy对AI编程助手常见失败模式的观察，本质上是一个轻量级的指令层，用来约束AI编程助手的行为方式。

关于Andrej Karpathy：他是OpenAI联合创始人之一，曾担任特斯拉AI总监，目前专注于AI教育与研究。他以深入浅出地解释复杂AI概念著称，其YouTube频道和开源项目在开发者社区中极具影响力。他对AI编程助手行为模式的观察来自大量实际使用经验，而非纯理论推导，这也是为什么他提出的原则具有很强的实践针对性。

整个仓库围绕四个核心原则构建：

原则一：先思考，再编码（Think Before Coding）

AI助手不应该默默猜测你的意图。当需求存在歧义时，它应该主动暴露这些模糊之处，提出正确的澄清问题，或者至少展示不同方案的权衡取舍，而不是一头扎进去就开始写代码。

原则二：简洁优先（Simplicity First）

这是整个方案中最有价值的部分之一。很多AI编程工具有一种奇怪的冲动——总想过度构建一切。这种倾向并非偶然：AI编程助手的训练数据大量来自开源项目和技术博客，这些内容天然偏向展示「完整解决方案」和「最佳实践架构」，而非最小可行实现。模型在RLHF（基于人类反馈的强化学习）阶段也可能因为「看起来更完整」的回答获得更高评分，从而强化了过度构建的倾向——这是一个系统性的训练偏差问题，而非单纯的模型能力缺陷。Karpathy Skills要求AI助手只写解决问题所需的最少代码：不做投机性的抽象，不为一个单函数任务搭建庞大框架，不为了炫技而增加不必要的复杂度。

原则三：精准修改（Surgical Changes）

这一点至关重要。AI助手应该只修改任务所需的部分，不应该随意清理无关代码、重写注释、重构相邻函数，或者"顺手改进"那些不在需求范围内的东西。每一次修改都应该是有目的的、最小化的。

原则四：目标驱动执行（Goal-Driven Execution）

将模糊的请求转化为可验证的结果。不是简单地说"修复了bug"然后期待一切顺利，而是按照明确的步骤执行：复现bug → 实施修复 → 验证修复有效 → 然后停下来。

安装与配置：两种方式快速上手

在实践层面，这个仓库的核心就是一个 claude.md 文件，加上一个Claude Code的插件安装路径。设置非常简单，有两种使用方式：

方式一：Claude Code插件路径（推荐）

通过Plugin marketplace添加并安装，使其作为Claude Code插件在所有项目中生效。

方式二：单项目配置

如果只想在某个特定项目中使用，直接将 claude.md 文件下载到项目目录即可。如果项目已有 claude.md，可以追加内容而非替换。

技术原理：claude.md 本质上是一种「持久化系统提示词」机制。在大语言模型的对话架构中，系统提示词（System Prompt）位于上下文窗口的最高优先级位置，对模型的整个对话行为具有全局约束力。Claude Code在启动时会自动读取项目目录中的 claude.md 文件，将其内容注入为系统级指令，从而在不修改模型权重的情况下改变模型的默认行为模式。这种「软约束」方式的优势在于可以随时调整、无需重新训练，是当前提示词工程（Prompt Engineering）领域的主流实践方向之一。

关键在于理解它的使用模式：你不需要每次都输入特殊命令来触发它。安装一次之后，它就会改变AI助手在日常工作中的默认行为方式。

实际效果对比：以「添加账单仪表板」为例

假设你要求AI助手"添加一个账单仪表板"。

没有行为规范时，很多AI助手会立即开始编码——创建数据表、API路由、Webhook、UI组件、验证逻辑，甚至一些设置页面，全部一次性生成。然后你不得不检查一个巨大的diff，试图搞清楚它到底做了什么。

有了Karpathy Skills之后，理想的行为模式完全不同：

1. 先澄清范围：是一次性支付还是订阅？用什么支付提供商？需要完整仪表板还是只读的账单摘要？当前最小可用版本是什么？
2. 保持方案简洁：只实现当前真正需要的功能
3. 只做必要的修改：不扩散到无关文件
4. 用具体标准验证结果：通过测试或明确的成功标准确认完成

如何判断行为规范是否生效

有几个明确的信号可以帮你判断这些行为规范是否在起作用：

• AI助手开始在写代码之前提出更好的澄清问题 — 好迹象
• 生成的diff变得更小、更聚焦 — 好迹象
• 不再随意重构与任务无关的相邻文件 — 非常好的迹象
• 开始用验证思维而非"我已经实现了，相信我"的态度 — 正是你想要的

这个方案的本质不是在通常意义上"增加能力