2026 年 1 月底，Andrej Karpathy 在 X 上发了条长推文，抱怨 LLM 编程的三个老毛病：做了错误假设就继续执行、喜欢把代码搞复杂、会改动它不理解的代码。
两天后，GitHub 上出现了一个 15 万 star 的仓库，里面只有一个 65 行的配置文件，把这些抱怨提炼成了 4 条规则。
我用 Claude Code 开发了两个月，发现这 4 条规则确实管用。但先说清楚一件事：这份配置不是 Karpathy 写的。
这不是 Karpathy 的"官方配置"
很多人看到仓库名 andrej-karpathy-skills，以为是 Karpathy 本人的配置。
实际情况是这样的：作者叫 Forrest Chang，创建于 2026 年 1 月 27 日，只是把 Karpathy 前一天的长推文做了提炼和结构化。
这不是"官方认证"，是"社区最佳实践"。
但这不意味着它不好用。恰恰相反，正因为是从实战抱怨中提炼出来的，每一条规则都对应着真实的坑。
AI 编程最大的坑，不是你不会写代码了
很多人担心用 AI 编程会导致技能萎缩。确实会，就像用导航会忘路、用计算器会忘心算一样。
但这不是最致命的问题。
最致命的问题是：AI 写的代码质量不可控。
我用 Claude Code 重构一个老 Spring Boot 项目时，踩过不少这样的坑：
AI 会在不确定时静默猜测，然后自信地继续；会提前做用不上的抽象；会顺手改一些跟需求无关的代码；写完之后不会主动验证自己到底做对了没有。
这些问题，正是 Karpathy 抱怨的那三个。
而那 4 条规则，就是针对这些问题设计的第一道防线。
规则一：Think Before Coding — 别让 AI 静默猜测
规则原文很简单：
Before implementing: State your assumptions explicitly. If uncertain, ask. If multiple interpretations exist, present them — don't pick silently.
翻译成大白话就是：不确定的时候，停下来问，别自己瞎猜。
我踩过这个坑。
有一次让 Claude 给 User 实体类生成测试用的模拟数据。它生成了这样的代码：
User user = new User();
user.setUsername("testuser");
user.setEmail("test@example.com");
user.setStatus(1);
看起来没问题，跑测试也过了。
后来才发现 User 继承了 BaseEntity，里面有 createdBy、updatedBy 这些审计字段，AI 完全没设置。测试之所以过了，是因为我的测试用例只验证了业务字段，根本没验证审计字段。
AI 看到 User 类的定义，但没有读父类 BaseEntity。它自己假设只需要设置当前类的字段，没问："要不要设置父类字段？"
如果遵循"Think Before Coding"，AI 应该先问：
我看到 User 继承了 BaseEntity，里面有审计字段（createdBy、updatedBy、createdAt、updatedAt）。测试数据需要设置这些字段吗？
这条规则的价值，不是让 AI 变聪明，而是强制它把不确定性说出来。说出来，你才能纠正；不说出来，bug 就埋下了。
规则二：Simplicity First — 只写必要的代码
规则原文：
No features beyond what was asked. No abstractions for single-use code. If you write 200 lines and it could be 50, rewrite it.
大白话：没让你做的别做，能用 50 行写完的别写 200 行。
我也踩过这个坑。
让 Claude 写一个"导出用户列表到 Excel"的功能。我只说了一句话，它给了我这样的代码：
public interface ExcelExporter<T> {
void export(List<T> data, OutputStream out);
}
public class UserExcelExporter implements ExcelExporter<User> {
// 100+ 行的通用导出逻辑
}
public class ExcelExporterFactory {
public static <T> ExcelExporter<T> getExporter(Class<T> clazz) {
// 工厂模式
}
}
一套"可扩展的导出框架"，接口、工厂、策略模式全上了。
我就导出一个用户列表。
AI 看到"导出"两个字，联想到"未来可能导出订单、导出商品"，提前做了抽象。这些抽象在当前需求里是死代码，只会增加维护负担。
如果遵循"Simplicity First"，AI 应该直接写：
public void exportUsers(List<User> users, OutputStream out) {
// 50 行搞定
}
等真的需要导出第二个实体时，再抽象也不迟。提前优化的本质是浪费。
需要提醒的是：这条规则也有反面。有时候 AI 过于遵循"只改必要的"，会漏掉潜在的关联代码修改。比如你改了个方法签名，它可能不会主动提醒你还有哪些调用方需要同步修改。遇到这种情况，用完这条规则后要追问一句："还有哪些地方受影响？"
规则三：Surgical Changes — 只改你要求改的地方
规则原文：
When editing existing code: Don't "improve" adjacent code, comments, or formatting. Match existing style, even if you'd do it differently. The test: Every changed line should trace directly to the user's request.
大白话：让你改什么就改什么，别顺手"优化"旁边的东西。
我被这个坑坑得最狠。
让 Claude 给 UserService 加一个"根据邮箱查询用户"的方法。它改完之后，我看 diff 发现它顺手做了这些：
- 把原有方法的注释从中文改成了英文
- 把 findById 方法里的 Optional.orElse(null) 改成了 Optional.orElseThrow()
- 重新排列了方法顺序
这些改动和我的需求完全无关。
orElseThrow() 的改动尤其要命——原来返回 null，现在抛异常，调用方可能根本没处理这个情况。AI 看到"不够优雅"的代码就想顺手改，但这些"改进"没经过验证，可能引入 bug。
如果遵循"Surgical Changes"，AI 应该只加新方法，diff 里的每一行改动都应该能追溯到"加一个根据邮箱查询的方法"这个需求。
当然，规则也有例外：有时候现有代码风格本身就很糟糕，AI 严格遵循现有风格会导致新代码也不优雅。这时候需要权衡——小范围改动，忍一忍保持一致；大范围重构，单独开一个"统一代码风格"的任务来做。
规则四：Goal-Driven Execution — 用成功标准替代实现步骤
规则原文：
Transform tasks into verifiable goals: "Add validation" → "Write tests for invalid inputs, then make them pass" "Fix the bug" → "Write a test that reproduces it, then make it pass"
大白话：告诉 AI 什么是对的，让它自己循环验证。
以前我会说"给 User 的 email 字段加个格式校验"，AI 会直接加上 @Email 注解，然后说"完成了"。
但我不知道校验是否真的生效，也不知道边界情况（空字符串、null、格式错误）是否都覆盖了。
现在我换一种说法：
写个测试，验证 email 字段的格式校验： - 正常邮箱格式应该通过 - 空字符串应该报错 - null 应该报错 - 格式错误（缺少 @）应该报错
然后让这些测试通过。
AI 会先写测试，跑一遍——大概率失败，然后加校验注解，再跑一遍，直到全部通过。
第一种方式是告诉 AI 做什么，第二种方式是给 AI 成功标准让它自己循环。
后者利用了 LLM 的迭代能力，而我能通过测试结果验证它确实做对了。
这 4 条规则解决的是质量问题，不是技能萎缩
Karpathy 本人在采访里说了一句话很扎心：
"It hurts the ego, but too powerful to ignore."
他承认手工编程能力正在萎缩，自己的工作流在两个月内从 80% 手工编码变成了 80% AI Agent。
技能萎缩是大势所趋，不可逆，也不必恐慌。
但这 4 条规则解决的不是萎缩问题，是质量问题：让 AI 写出人类水准的代码。
没有这些规则，AI 会静默猜测、过度复杂化、顺手改无关代码。你的项目会充斥"看起来对但实际有坑"的代码。
有了这些规则，AI 会在不确定时停下来问你、只写必要的代码、只改你要求改的地方、用测试验证自己做对了。你的 diff 更干净，重写更少，翻车更少。
实操建议：四周时间养成习惯
如果你也在用 Claude Code 或其他 AI 编程工具，可以按这个节奏来：
第一周重点关注 Think Before Coding。每次 AI 给出方案时，看它有没有主动列出假设、有没有问你不确定的地方。没有的话，手动追问："你确定吗？有没有其他可能？"
第二周重点关注 Simplicity First。发现代码可以简化时，反问 AI"为什么没有遵循规则简化实现？"让它重写。
第三周重点关注 Surgical Changes。每次看 diff，检查变更是否都能关联到你的需求。无关改动直接拒绝。
第四周重点关注 Goal-Driven Execution。把"做什么"的指令改成"成功标准是什么"，让 AI 自己循环迭代。
一个月后，你会发现 AI 生成的代码质量明显提升，翻车次数明显减少。
写在最后
Anthropic 的一位工程师 Boris Cherny 分享过，他们团队 100% 的代码都是用 Claude Code 写的，持续两个月了。
AI 编程变革的关键，从来不是你还能不能手写代码，而是你能不能让 AI 写出你信任的代码。
这 4 条规则，就是那把尺子。