Karpathy 教你调教 AI 助手：一个文件，四个原则，告别无效返工

用 AI 做事的人，大概率都遇到过同一种抓狂：你让它帮你改个东西，它不只改了你说的那个点，还顺手把你之前写的内容也改了。你要检查半天才能搞清楚它到底动了哪些地方。更离谱的是，你让它做一个简单的功能，它给你整了一大套花里胡哨的架构，明明几步就能搞定的事，它硬是绕了一大圈。

这些不是你的提示词写得不好。是 AI 智能体的通病。

Andrej Karpathy 是 AI 行业最著名的技术专家之一，前特斯拉 AI 负责人、OpenAI 创始团队成员，现 Claude 公司研究员，他之前在推特上发了一条长文，把这些问题吐槽得明明白白。他总结了三个核心问题：

第一，模型会替你做出错误假设，然后不假思索地执行。 它们不管理自己的困惑，不寻求澄清，不呈现权衡，在应该提出异议时也不反驳。你跟它说「帮我优化一下这个流程」，它不问你到底哪里不满意，直接就动手改。

第二，它们真的特别喜欢把事情搞复杂。 堆砌抽象、不清理冗余，简简单单的事非要整出一套庞杂的方案。

第三，它们有时候会改动或删除自己理解不足的内容。 哪怕这些内容跟当前任务毫无关系。你让它改 A，它顺手把 B 和 C 也改了，还觉得自己在帮你「优化」。

这三条吐槽，说到了所有用 AI 干活的人心坎里。

然后有人把这些观察变成了一个可落地的解决方案。一个叫 forrestchang 的开发者在 GitHub 上开源了一个项目，叫 andrej-karpathy-skills。核心就一个文件，里面只有四个原则。每一个都直击 AI 协作的痛点。

今天就拆开看看，这四个原则到底是什么，你又怎么用它们让 AI 变得更靠谱。

原则一：编码前思考

这个原则的核心就一句话：不要假设，不要隐藏困惑，把权衡摆到台面上。

AI 智能体经常犯一个错误：你的指令有歧义，它不会问，而是默默选一个理解然后直接执行。结果做出的东西跟你想要的根本不是一回事。

这个原则要求智能体在动手之前，必须做三件事：

第一，明确说出自己的假设。如果不确定，必须问，不能猜。

第二，如果指令存在多种理解方式，必须把这些可能性列出来，让用户选，而不是自己默默挑一个。

第三，如果发现用户想要的东西有不合理的地方，或者有更简单的实现方式，必须说出来。

最后一点特别重要。其实很多时候我们自己也没想得很清楚。一个敢于提出异议的智能体，比一个你说什么它就干什么的智能体有价值得多。

举个例子。你让它「帮我写一个周报模板」。没有这个原则的智能体会怎么做？它会假设你是程序员、要写技术周报、用 Markdown 格式、包含代码进展和 bug 修复。但实际上你可能是个运营、要写业务周报、需要 Word 格式、关注的是数据和转化率。

有「编码前思考」原则的智能体，会先问你：什么岗位？周报给谁看？需要包含哪些模块？有没有现成的模板可以参考？

你看，几个问题下来，方向就清晰了，后面做出来的东西不会跑偏。

原则二：简洁优先

这个原则说的是：用最少的代码解决问题，不要做任何推测性的设计。

AI 智能体有个坏习惯，特别喜欢过度设计。你跟它说「帮我把这段文字里的关键信息提取出来」，它给你整出一个五层架构的处理流程：先分词、再实体识别、再关系抽取、再摘要、再格式化……而你其实只需要它把重点句子挑出来列一下。

为什么会这样？因为 AI 的训练数据里有大量「最佳实践」式的复杂方案。它学到的模式是「复杂的才是专业的」，但现实是「能解决问题的才是好的」。

简洁优先原则有几条硬规矩。

不添加你没要求的功能。别猜你「可能还需要什么」，你没说的就别加。

不为只用一次的东西创建抽象。如果一个功能只在一个地方出现，别拆成函数、别搞继承，直接写就行。

不添加没被要求的「灵活性」或「可配置性」。别自作主张把写死的值变成配置文件。

不为不会发生的场景做错误处理。别什么事都预设一万种意外情况。

最后一条最狠：如果写了 200 行发现 50 行就能搞定，重写。