当AI编程助手开始＂自作聪明＂:我把Karpathy的忠告变成了一份提示词

如果你用Claude Code、Cursor这类AI编程工具写代码，你一定遇到过这些场景：

• • AI擅自假设你的需求，生成一堆你根本不需要的功能
• • 它用企业级架构解决一个简单脚本的问题，代码臃肿到离谱
• • 它顺手把不相关的代码也改了，导致整个项目风格混乱
• • 你让它修一个bug，它顺带重构了半个项目

这些问题，Andrej Karpathy也注意到了。

作为OpenAI的创始成员、被誉为”AI教父”的顶级工程师，Karpathy在多次分享中详细剖析了AI编程的常见陷阱。而最近，一份把这些观察整理成”AI编程行为准则”的内容在开发者圈子里疯传——

因为这份规则，可以直接放进你的项目里。

01 Karpathy看到了什么？

Karpathy在观察大量开发者使用AI编程工具时，发现了几个典型问题：

AI太喜欢”自作主张”了。

它不会先确认你的需求，而是直接猜、直接做。等你发现的时候，代码已经写了一百行，而方向完全跑偏。

AI喜欢”过度设计”。

哪怕只是一个简单脚本，它也要搞一套抽象层、配置项、扩展接口，仿佛在解决一个百亿级系统的问题。

AI会”顺手”改很多不相关的东西。

你让它改一个函数，它把整个项目的注释风格、命名规范都统一了一遍——按它自己的喜好。

这些问题导致的结果是：AI编程的效率被大量浪费在返工和纠偏上。

02 一份给AI的”工作指南”

我把Karpathy的观察整理成了一份完整的行为准则，覆盖四个核心原则：

🎯 一、编码前先思考——不确定就必须问

如果对需求、上下文存在任何不明确，不要自行猜测，立刻停下来向用户确认。

这个原则解决的是”AI擅自假设需求”的问题。

具体做法：

• • 如果需求有多种合理的解读方向，主动列出所有选项，请用户选择后再开始
• • 如果发现比当前需求更简单的方案，主动提出来，不要直接按复杂的执行

✂️ 二、简约至上——拒绝过度设计

只做用户明确要求的内容，不额外添加未提及的功能。

这个原则解决的是”用牛刀杀鸡”的问题。

Karpathy给出了非常具体的边界：

• • 单次使用的代码不需要建立抽象层
• • 用户没要求的可配置性、扩展性不要加
• • 不会发生的异常不需要处理

验收标准： 资深工程师看到代码不会觉得”过度设计”，如果不符合就主动简化。

🔍 三、精确编辑——严格控制改动范围

只修改要求改动的部分，不要扩大修改范围。

这个原则解决的是”顺手改一堆”的问题。

关键规则：

• • 匹配现有代码风格，哪怕AI觉得自己的风格更好
• • 无关问题只提不改
• • 只清理AI自己导致的冗余代码，项目原本的未使用代码不要动

✅ 四、目标驱动——用验收标准替代执行步骤

不要依赖用户一步步指挥，根据最终验收标准自主循环迭代直到满足要求。

这个原则让AI可以更长时间独立工作，减少人工介入频率。

具体方法：

• • 新增功能先写测试，修复bug先写能复现的测试
• • 复杂任务先输出分步计划，分步执行、分步验证

03 怎么用？——直接保存为项目配置文件

这份规则最实用的地方在于：你可以直接把它保存为项目配置文件，让AI自动读取遵守。

Claude Code → 保存为 CLAUDE.md
Cursor → 保存为 CURSOR.md

把文件放在项目根目录，AI编程工具会自动读取其中的行为准则，就像一个隐形的工作助手在时刻监督。

04 一个真实案例

我自己在用Claude Code写一个小脚本时，按照这份准则做了测试：

没有准则时：

我：写一个读取CSV文件的脚本
AI：好的，我先建一个数据模型类、配置解析器、错误处理模块、日志系统…

加上准则后：

我：写一个读取CSV文件的脚本（附上行为准则）
AI：好的，先确认一下，文件格式是标准的CSV吗？需要做什么数据处理还是直接读取就行？

效率差异巨大。

05 写在最后

AI编程工具的能力已经非常强大，但它们缺的不是技术，而是边界感。

这份行为准则的本质，是给AI一个明确的工作边界——

让它知道什么时候该停、什么时候该问、什么时候该克制。

好东西值得分享。

如果你身边有朋友在用AI编程工具，或者你在管理一个开发团队，不妨把这份准则分享出去——

也许你会发现，AI编程的效率，从这一刻开始悄然提升。