夜雨聆风用AI助手写代码，你是不是也经常遇到这种情况：让它实现一个简单功能，结果它给你生成一堆过度设计的复杂架构，或者自作主张地乱改注释，甚至“脑补”出一些你根本没提的需求？看着满屏看似“智能”实则难以维护的代码，修复它可能比从头手写更费时间。
这真不是你的错觉。当前的大语言模型在编程时，确实有一些顽固的“坏习惯”。OpenAI的联合创始人、AI科学家Andrej Karpathy最近就一针见血地指出了这些问题：
“模型会替你做出错误的假设，并且不加验证地一路执行下去。它们不管理自己的困惑，不寻求澄清，不揭示不一致性，不展示权衡利弊，在该提出异议时却保持沉默。”
“它们非常喜欢过度复杂化代码和API，堆砌抽象，不清理死代码……用1000行臃肿的结构来实现一个100行就能搞定的事情。”
“它们有时仍会作为副作用，更改或删除自己并未充分理解的注释和代码，即使这些内容与手头任务毫不相干。”
听起来是不是特别熟悉？现在有个挺巧妙的开源方案，能系统性地“调教”AI编码助手的这些行为。它不是什么复杂的插件，只是一个叫 CLAUDE.md 的纯文本文件。
这个名为 “Karpathy-Inspired Claude Code Guidelines” 的项目，把Karpathy的观察总结成了一套清晰、能直接用的指导原则。你只要把这个文件放到项目里，Claude Code就能从一个“爱自说自话的实习生”，变成一个“严谨审慎的资深搭档”。
四大核心原则：给AI编程定规矩
这个项目的精华，在于四条直接针对痛点的原则。它们写得很简单，但用起来效果明显。
原则一：想清楚再动手
核心就是：别瞎猜、别隐瞒、把利弊摊开说
这条原则专门治AI“脑补”的毛病。它要求AI在写代码之前，必须把思考过程明明白白地展示出来：
- 把假设说清楚
：要是对需求拿不准，先提问，别自己猜。 - 列出多种可能性
：碰到模糊的地方，别悄默声地选一种理解，把几种可能的解读都列出来。 - 该反对时就反对
：如果有更简单的方案，直接指出来。 - 不懂就停
：明确告诉用户哪里没搞明白，要求进一步澄清。
带来的直接变化是：在生成代码之前，你会先看到AI提出的问题或者几个方案的对比，从一开始就避免因为误解而产生的返工。
原则二：越简单越好
核心就是：用最少的代码搞定问题，别加戏
这是对付“过度设计”和“炫技”倾向的利器。原则要求死磕简洁：
不加没要求的功能。 不为只用一次的代码搞什么抽象层。 不引入没提过的“灵活性”或“可配置性”。 不为那些几乎不可能发生的场景加错误处理。 50行能写完的，绝不拉长到200行。
检验方法很简单：你想象一下，一个经验丰富的工程师看到这段代码，会不会觉得“这搞复杂了”？如果会，那就简化它。
原则三：只动该动的地方
核心就是：精确修改，只收拾自己弄乱的摊子
这条是为了防止AI“好心办坏事”、乱动无关代码。当需要编辑现有代码时：
别“顺手”改进旁边无关的代码、注释或者格式。 别去重构那些本来就没问题的部分。 匹配项目现有的代码风格，哪怕你自己更喜欢另一种。 如果注意到无关的死代码，可以提一嘴——但别自己删掉。
如果你的修改产生了“孤儿代码”（比如没用的导入或变量）：
清理掉因为你的修改而变得没用的部分。 别动修改之前就已经存在的死代码，除非用户明确要求。
检验标准：每一处被修改的代码行，都应该能直接对应到用户提出的需求上。
原则四：盯着目标干
核心就是：定义清楚什么叫成功，反复验证直到达标
这条是Karpathy核心观察的实践：“大语言模型非常擅长反复执行直到满足特定目标……别总告诉它具体每一步怎么做，给它一个成功的标准，然后让它自己去干。” 这条原则把命令式的指令，转成了可以验证的声明式目标：
对于多步骤的任务，可以要求AI先给出一个简要计划：
1. [步骤一] → 验证：[检查点]
2. [步骤二] → 验证：[检查点]
3. [步骤三] → 验证：[检查点]
清晰有力的成功标准，能让AI自己循环工作。而模糊的标准（比如“让它能跑就行”），只会导致后续不停地澄清和返工。
怎么用？一分钟搞定
用起来特别简单，有两种方式可选：
方案A：安装Claude Code插件（最省事）
这样安装后，对所有项目都有效。
在Claude Code里，先添加插件市场： /plugin marketplace add forrestchang/andrej-karpathy-skills然后安装这个插件： /plugin install andrej-karpathy-skills@karpathy-skills
方案B：在项目里加个CLAUDE.md文件（按项目控制）
如果只想在某个特定项目里用，就在项目根目录放一个CLAUDE.md文件。
- 新项目：
curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md - 已有项目（把内容追加到现有的CLAUDE.md文件末尾）：
echo "" >> CLAUDE.md
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md
装好之后，你用Claude Code时，它就会自动遵守这四大原则。你也可以在 CLAUDE.md 里加上你自己项目的特定要求，比如：
## 项目特定指南
- 使用TypeScript严格模式
- 所有API端点必须有测试
- 遵循 `src/utils/errors.ts` 中现有的错误处理模式
效果怎么样？你的代码提交会清爽很多
怎么知道这个“指南”起作用了？看看是不是有这些变化：
- 提交的代码差异（Diff）里，那些没必要的修改变少了
——只出现你要求改的内容。 - 因为代码过于复杂而需要重写的情况变少了
——第一次生成的代码就足够简洁可用。 - 问题澄清发生在写代码之前
——而不是等代码写错了再返工。 - 提交的代码变更（PR）变得干净、聚焦
——没有那些“顺手”做的重构或“改进”。
为什么说它有用？从“用工具”到“管搭档”
这个项目的妙处在于它极其简单。它没想去重新训练模型，也没搞复杂的规则引擎，而是巧妙地利用了LLM本身会遵循指令的特性，通过一份精心写好的“行为准则”来引导它。
这其实代表了一种和AI协作思路的转变：我们不再是那个输入模糊指令、然后被动接收一堆不确定结果的“用户”；而是变成了设定清晰目标、验收明确成果的“管理者”或“审核者”。AI则从一个可能会犯各种“想当然”错误的“黑箱工具”，变成了一个会主动沟通、做事谨慎、追求简洁可验证结果的“可靠搭档”。
当然，作者也说了，这套指南更偏向谨慎，而不是追求速度。对于改个拼写错误或者明显的一行代码修改，没必要每次都走一遍完整严格的流程。它的核心价值是减少在那些不那么简单的任务上犯下代价高昂的错误，而不是拖慢所有简单操作。
把这个 CLAUDE.md 文件放到你的下一个项目里试试，体验一次和AI编程助手之间清晰、高效、没有“意外惊喜”的协作。这或许就是你告别AI生成代码的混乱，走向人机精准协同编程的第一步。
项目地址：https://github.com/forrestchang/andrej-karpathy-skills[1]
（有时候，改变一切，只需要一个文件。）
📎 脚注链接
[1] https://github.com/forrestchang/andrej-karpathy-skills：https://github.com/forrestchang/andrej-karpathy-skills
