Andrej Karpathy 在 2025 年的一条推文中直指当前大语言模型在编码任务中的核心缺陷：「模型会替用户做出错误假设，然后顺着这些假设一路跑下去。它们不管理自己的困惑，不寻求澄清，不暴露不一致性，不呈现权衡，也不应该在拒绝时拒绝。」这番话揭示了 AI 辅助编程面临的系统性挑战：一个看似「智能」的助手，实际上可能因为过度自信而引入隐蔽的技术债务。

围绕这一观察，GitHub 项目 forrestchang/andrej-karpathy-skills 将 Karpathy 的洞见编译成一份 CLAUDE.md 指南，提炼出四大可操作原则。这份指南的核心理念不是限制 AI 的能力，而是通过显式的行为约束，让 AI 成为更可靠的编码伙伴。本文将逐一拆解这四大原则，并给出工程团队可直接落地的实践参数。

原则一：先思考再编码（Think Before Coding）

核心主张：不要假设。不要隐藏困惑。呈现权衡。

当 LLM 面对模糊需求时，常见的做法是 pick 一个 interpretation 然后闷头实现。这种行为模式的风险在于：即使需求存在多种合理理解，模型也会默认选择了其中一种，导致后续返工。正确的做法是将推理过程外显化，让人类确认后再推进。

具体工程实践中，建议在任务启动阶段增加以下检查节点：

  • 假设声明：在编写任何代码前，以注释形式列出「如果以下假设不成立，方案需要重大调整」的条目
  • 歧义暴露：当需求存在多种解释时，用列表形式呈现每种方案的优劣，并明确请求用户确认
  • 拒绝条件：当信息不足以做出合理决策时，明确输出「以下信息缺失：XXX，请补充后重新开始」，而不是基于猜测继续

这项原则的度量标准是：首次交付的修改率。如果 AI 在第一轮代码中就能准确理解需求，后续因「理解偏差」导致的返工应该接近于零。

原则二：简单性优先（Simplicity First）

核心主张：最小代码解决问题。不做 speculative 的设计。

Karpathy 指出，LLM 极度喜欢过度工程化：引入不必要的抽象层、预留「未来可能用到」的可配置项、为单一使用场景创建通用模板。这种倾向在代码审查中表现为「 1000 行可以解决的问题硬是用 2000 行实现」。

简单性优先原则要求在实现时主动做减法：

  • 功能边界：严格限定在用户明确要求的范围内，不添加「锦上添花」的功能
  • 抽象阈值：只有当代码出现至少两次相同模式时，才考虑抽取为函数或类
  • 配置谨慎：用户未要求的「灵活性」或「可配置性」一律不添加
  • 防御性边界：仅处理真实可行的错误场景，不为不可能发生的情况编写异常处理

一个实用的检验标准是：让一位 senior 工程师阅读代码，如果对方评价「这有点 overcomplicated」，则应该立即重构。工程参数上，建议单函数不超过 50 行，单文件不超过 300 行，超出时应主动拆分而非因为「逻辑相关」而强行合并。

原则三：外科手术式修改（Surgical Changes）

核心主张：只碰必须碰的。清理自己留下的烂摊子，但不碰原有的脏乱。

当 AI 被要求修改现有代码时，一个常见的副作用是「顺便优化」—— 改一行代码的同时顺便调整了相邻的注释格式、重构了看起来类似的代码、甚至删除了「看起来没用」的函数。这种 orthogonal editing 往往会引入意外的回归 bug。

外科手术式修改原则要求：

  • 编辑边界：每一次提交（commit）或 PR 中的修改行必须能直接追溯到用户的原始需求
  • 不改动原则：对于需求之外的代码，即使风格不理想也不做「顺手改进」
  • 风格适配：修改既有代码时，主动匹配目标文件的风格规范，而非按照自己的偏好重写
  • 自我清理：如果你的修改导致某个 import、变量或函数变为 unused，应该主动删除；但不要删除修改前就已存在的 dead code，除非用户明确要求

这项原则的工程检验方式是 diff 审查：reviewer 应该能在 30 秒内说清「每一行改动为什么存在」。如果存在解释不清楚的改动，说明违反了外科手术原则。

原则四：目标驱动执行（Goal-Driven Execution）

核心主张：定义成功标准。循环验证直到达成。

Karpathy 的关键洞察是：LLM 极其擅长在明确目标下进行循环迭代，但人类的指令往往是 imperati 的（「去修复这个 bug」「添加验证」），而非 declarative 的（「让无效输入在 3 种场景下触发明确的错误提示」）。

目标驱动执行原则要求将任务重新表述为可验证的目标：

常见 imperative 指令 转换后的 goal-driven 表述
「添加输入验证」 「编写针对空字符串、超长输入、非 ASCII 字符的测试用例，使其触发明确的验证错误」
「修复这个 bug」 「编写一个能够稳定复现该 bug 的测试用例，然后修复代码使其通过」
「重构 X 模块」 「确保重构前后所有现有测试用例保持通过」

对于多步骤任务，建议使用带验证节点的计划格式：

1. [实现用户认证] → verify: [未登录用户访问受保护路由返回 401]
2. [添加速率限制] → verify: [同一 IP 发送 100 次请求后返回 429]
3. [集成日志系统] → verify: [关键操作写入日志文件且格式正确]

这种结构的优势在于：AI 可以在没有人类持续干预的情况下自主完成完整闭环。每个 verify 节点都是一次自我检查的机会。

落地实践参数

将上述四大原则转化为工程实践，建议团队在 AI 辅助开发工作流中加入以下参数配置：

  • 需求澄清阶段：强制要求 AI 输出「假设清单」和「歧义列表」，人类确认后方可进入实现阶段
  • 代码复杂度阈值：单函数行数上限 50 行，单文件 300 行，超出提示重构
  • PR diff 审查：设置「每行改动必须有明确需求对应」的 CI 检查
  • 测试先行率：要求 80% 的功能修改通过「先写测试→再写实现」的流程完成
  • 返工率监控：跟踪第一轮提交的通过率，目标设为高于 85%

资料来源