AI 编程指南：4 条准则让 AI 助手少犯常见错误-二趣网

AI 编程指南：4 条准则让 AI 助手少犯常见错误

【免费下载链接】andrej-karpathy-skillsA single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathy's observations on LLM coding pitfalls.项目地址: https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills

如果你让 AI 助手修两行的 bug，它却交回三百行抽象类，或把没人要的改动画进改动文件里，问题通常不在模型，而在缺少一份行为准则。这份开源 AI 编程指南把四个高频坑整理成可勾选的规则，读完十分钟即可落地。

AI 助手最容易翻车的四种场景

先对照检查，看你是否命中过以下情况：

只让它"导出接口加个字段"，它却交回一套含策略模式、配置类和缓存的完整方案。
修 bug 本身修对了，但顺手重排了引号、加了类型标注、改写了相邻注释。
它对格式和范围默默做了假设，直到你 review 时发现它一直在猜。
你只说"修一下"，它修完你也不确定是真修好了，还是只是不崩了。

这些不是偶发事故，而是会重复出现的固定模式。堵法也是固定的。

四条可勾选的 AI 编程准则

下面四条全部来自这份 AI 编程指南，可逐条当作清单使用。

写代码前先确认范围

现象：需求有歧义时，AI 默默挑一种解释直接开工。
原因：大语言模型（LLM）没有主动停下确认的动力，猜一个解释比发问更快。
做法：实现前列出假设清单；存在多种解释就全部摆出来再问；不确定就停，直接提问。
验证信号：它的第一条回复是假设与问题清单，而不是一堆代码。

只写最短实现

现象：一个简单的计算被包上抽象基类、配置类和策略模式。
原因：模型见过太多"最佳实践"样例，倾向为未来的需求提前设计。
做法：只解决当前请求，不加未要求的功能，不做单次使用的抽象；200 行能写成 50 行就重写。
验证信号：一位资深工程师不会评价"这写复杂了"。

改动只限于问题本身

现象：修一个 bug，却动了无关注释、引号风格、格式，还加了没人要的校验。
原因：模型倾向于顺手"改进"它没有完全理解的部分。
做法：只改与请求直接相关的行；沿用现有风格，哪怕你不喜欢；只清理自己改动产生的无用引用；发现无关死代码只指出、不删除。
验证信号：每一行变更都能追溯到这次请求。

把任务变成可验证目标

现象：你说"加个校验"，它回复"已完成"，你却无从判断是否真的完成。
原因：模糊任务没有停止条件，模型只能猜"差不多就行"。
做法：把任务改写成可运行验证的目标，如"加校验"→"先写无效输入的测试，再让它通过"；多步任务每步都写清验证方式，例如"第 1 步：单端点内存限流→验证：100 个请求，前 10 个成功，其余 429"。
验证信号：任务做完后，跑一次测试或命令就能判断成败，不靠人肉判断。

空值崩溃的最小修复：一个完整示例

以"验证器在空电子邮件时崩溃"为例。

错误示范：常见错法是顺手重写整个函数——加文档字符串、强化邮箱规则、再补上用户名的长度和字符校验，全都与崩溃本身无关。

修正后的处理：只改读取邮箱的那几行，用户名校验和原有风格保持不动：

def validate_user(user_data): # 检查电子邮件格式 email = user_data.get('email', '') if not email or not email.strip(): raise ValueError("Email required") # 基本电子邮件验证 if '@' not in email: raise ValueError("Invalid email") # 检查用户名（保持不变） if not user_data.get('username'): raise ValueError("Username required") return True

为什么这样更稳：改动面只在空值分支上，评审者一眼能看完；用户名逻辑没被碰，不引入新故障面；发现的其他问题写进回复由人来定夺，下一次任务不会被上一次污染。

两条安装路线：新项目和已有项目

这份 AI 编程指南提供两条安装路线，按你的情况选，命令在目标项目目录执行。

用 Claude Code（在命令行运行的 AI 编程工具）且希望规则在所有项目生效：装插件。

/plugin marketplace add forrestchang/andrej-karpathy-skills /plugin install andrej-karpathy-skills@karpathy-skills

不想装插件，或只在单个项目用：先克隆仓库。

git clone https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills

cp andrej-karpathy-skills/CLAUDE.md CLAUDE.md

已有项目已有 CLAUDE.md：追加到文件末尾，保留原内容。

cat andrej-karpathy-skills/CLAUDE.md >> CLAUDE.md

CLAUDE.md 是 Claude Code 启动会话时自动加载的 markdown 文件，写进其中的规则会约束该项目里 AI 的行为。通用规则之后可以追加自己的项目小节，例如 TypeScript 严格模式、测试约定。

新手和进阶：两级上手

新手：本周就做三件事

把 CLAUDE.md 放进手头项目，挑一个小任务，观察 AI 是否先问再做。
通读 EXAMPLES.md，对照每组"错误对照修正"的示例，建立"什么算过多"的手感。
每次任务先写出一句"完成标准"，再交给 AI。

进阶：把规则变成团队习惯

在 CLAUDE.md 里追加项目特定规则（命名、错误处理模式、测试约定），并像维护代码一样维护它。
把"每行变更可追溯到请求"写进代码审查检查清单。
若你用 Cursor，仓库自带对应的规则文件与技能定义文件，配置方法见 CURSOR.md。

判断方法是否生效的四个信号

使用约两周后逐条核对，命中三条以上即算生效：

✅ 变更文件里只有被要求的改动，没有顺手重构。
✅ 第一版实现就是简单的，没有因过度复杂而返工。
✅ 澄清性问题出现在实现之前，而不是出错之后。
✅ PR 小而聚焦，评审能快速通过。

适用边界：修拼写错误、明显的一行改动这类简单任务不必走完整流程，凭判断即可；这套规则的目的是减少非平凡工作上的高代价错误，而不是拖慢简单任务。完整内容见仓库中的 CLAUDE.md（规则正文）、EXAMPLES.md（案例对照）、CURSOR.md（Cursor 配置说明），技能定义文件位于 skills/karpathy-guidelines/SKILL.md。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析