--- title: "Karpathy's LLM Coding Principles: Four Rules for Better AI-Generated Code" route: "/posts/2026/04/10/karpathy-llm-coding-principles/" canonical_path: "/posts/2026/04/10/karpathy-llm-coding-principles/" canonical_url: "https://blog2.hotdry.top/posts/2026/04/10/karpathy-llm-coding-principles/" markdown_path: "/agent/posts/2026/04/10/karpathy-llm-coding-principles/index.md" markdown_url: "https://blog2.hotdry.top/agent/posts/2026/04/10/karpathy-llm-coding-principles/index.md" agent_public_path: "/agent/posts/2026/04/10/karpathy-llm-coding-principles/" agent_public_url: "https://blog2.hotdry.top/agent/posts/2026/04/10/karpathy-llm-coding-principles/" kind: "research" generated_at: "2026-04-10T19:18:13.998Z" version: "1" slug: "2026/04/10/karpathy-llm-coding-principles" date: "2026-04-10T09:49:49+08:00" category: "ai-systems" year: "2026" month: "04" day: "10" --- # Karpathy's LLM Coding Principles: Four Rules for Better AI-Generated Code > 解析 Andrej Karpathy 提出的 LLM 编码四大原则：从「先思考再编码」到「目标驱动执行」，提供可落地的工程参数与实践检查清单。 ## 元数据 - Canonical: /posts/2026/04/10/karpathy-llm-coding-principles/ - Agent Snapshot: /agent/posts/2026/04/10/karpathy-llm-coding-principles/index.md - 发布时间: 2026-04-10T09:49:49+08:00 - 分类: [ai-systems](/agent/categories/ai-systems/index.md) - 站点: https://blog2.hotdry.top ## 正文 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% ## 资料来源 - GitHub 项目 forrestchang/andrej-karpathy-skills：https://github.com/forrestchang/andrej-karpathy-skills - Andrej Karpathy 关于 LLM 编码缺陷的原始推文：https://x.com/karpathy/status/2015883857489522876 ## 同分类近期文章 ### [YC S25 新星 Twill.ai：云端 Agent 众包与 PR 自动化的工程实践](/agent/posts/2026/04/11/twill-ai-cloud-agent-delegation-pr-automation/index.md) - 日期: 2026-04-11T02:50:57+08:00 - 分类: [ai-systems](/agent/categories/ai-systems/index.md) - 摘要: 解析 YC S25 支持的 Twill.ai 如何通过云端 AI agent 众包与结构化工作流实现代码任务委托与 PR 自动化评审，帮助团队提升工程效率。 ### [Rowboat 持久记忆架构解析：知识图谱驱动的 AI 协作者设计](/agent/posts/2026/04/11/rowboat-persistent-memory-architecture/index.md) - 日期: 2026-04-11T02:01:53+08:00 - 分类: [ai-systems](/agent/categories/ai-systems/index.md) - 摘要: 深入解析 Rowboat 作为 AI coworker 的持久记忆架构，涵盖知识图谱构建、Markdown 持久化、跨会话状态管理及工程实现参数。 ### [从规则到扩散：生成式艺术的 GPU 驱动范式转移](/agent/posts/2026/04/10/generative-art-gpu-diffusion-paradigm-shift/index.md) - 日期: 2026-04-10T21:50:46+08:00 - 分类: [ai-systems](/agent/categories/ai-systems/index.md) - 摘要: 解析生成式艺术从算法规则到扩散模型的演进路径，重点落在 GPU 可编程性与采样算法如何重塑创作工作流。 ### [构建响应式 Python Notebook 环境：Marimo 的多 Agent 协作与计算图重构机制](/agent/posts/2026/04/10/building-reactive-python-notebook-multi-agent-collaboration/index.md) - 日期: 2026-04-10T21:25:51+08:00 - 分类: [ai-systems](/agent/categories/ai-systems/index.md) - 摘要: 深入解析 Marimo 响应式执行模型与 marimo pair 如何为多 Agent 协作提供状态管理与计算图重构的工程化方案。 ### [MarkItDown 多格式文档转 Markdown：插件化架构与可扩展设计实践](/agent/posts/2026/04/10/markitdown-document-conversion-architecture-analysis/index.md) - 日期: 2026-04-10T21:02:27+08:00 - 分类: [ai-systems](/agent/categories/ai-systems/index.md) - 摘要: 深入解析 Microsoft MarkItDown 的三层架构设计、插件系统与转换管道，探讨异构文档格式统一转 Markdown 的工程实践。