Karpathy 编程指南：避免 LLM 编码常见错误的四大原则

Andrej Karpathy，前特斯拉 AI 总监、OpenAI 联合创始人之一，近期在社交媒体上分享了他对 LLM（大语言模型）编码常见陷阱的观察。社区开发者据此整理出了一套行为准则——Karpathy Guidelines，旨在帮助开发者在使用 AI 辅助编程时减少过度设计、做到精准修改、明确成功标准。

本文源自 GitHub 开源项目 andrej-karpathy-skills，以下是完整中文解读。

核心理念：谨慎优于速度

这套准则明确指出：宁可慢一点，也不要写出过度复杂的代码。对于简单任务，可酌情灵活处理；但对于正式项目，遵循以下四大原则将显著提升代码质量。

原则一：先思考，再编码

不要假设。不要隐藏困惑。主动呈现取舍。

• 在动手实现之前，明确陈述你的假设。如果不确定，就主动提问。
• 如果存在多种理解方式，全部列出来——不要悄悄选一个。
• 如果有更简单的方案，说出来。该反驳时就反驳。
• 如果某处不清楚，停下来。说出困惑之处，然后提问。

原则二：简单至上

只写能解决问题的最少量代码，不做任何推测性设计。

• 不添加用户没要求的功能。
• 不给只用一次的代码做抽象。
• 不添加没人要求的「灵活性」或「可配置性」。
• 不为不可能发生的场景写错误处理。
• 如果你写了 200 行但 50 行就能搞定——重写它。

问自己：「一个资深工程师会认为这太复杂了吗？」如果是，就简化。

原则三：精准修改，外科手术式操作

只改你必须改的。只清理你自己制造的混乱。

修改已有代码时：

• 不要顺手「改进」相邻的代码、注释或格式。
• 不要重构没坏的东西。
• 匹配已有代码风格，即使你自己会写得更不同。
• 如果发现了无关的死代码，提一句就好——不要删它。

当你的修改产生了孤立代码时：

• 删除因你的修改而变得无用的 import、变量、函数。
• 不要删除原本就存在的死代码，除非被要求。

检验标准：每一行修改都应该能追溯到用户的原始需求。

原则四：目标驱动，循环验证

定义成功标准，循环直到验证通过。

将任务转化为可验证的目标：

• 「添加验证」→「为无效输入编写测试，然后让它们通过」
• 「修复 Bug」→「写一个能复现 Bug 的测试，然后让它通过」
• 「重构 X」→「确保重构前后测试都能通过」

对于多步骤任务，列出简要计划：

• 步骤 1 → 验证：[检查项]
• 步骤 2 → 验证：[检查项]
• 步骤 3 → 验证：[检查项]

强有力的成功标准让你能独立循环推进。模糊的标准（「让它能跑就行」）则需要不断沟通确认。

总结

Karpathy Guidelines 的核心可以概括为四句话：

• 先想清楚再动手——别假设，别隐藏困惑
• 能简单就简单——最少量代码解决问题
• 精准修改——只动该动的代码
• 用目标驱动——定义可验证的成功标准

在 AI 辅助编程日益普及的今天，这套准则不仅适用于 LLM，也是每一位开发者在日常编码中值得遵循的实践。无论你是使用 ChatGPT、Claude、Cursor 还是其他 AI 编程工具，这些原则都能帮助你获得更高质量的代码输出。

参考来源：Andrej Karpathy 原始推文 | GitHub 项目地址（MIT License）