Andrej Karpathy 在近期关于大语言模型编程行为的观察中，指出了四个核心缺陷：模型会基于错误假设默默推进而不加验证、不善于管理自身的困惑状态、倾向于过度设计代码与抽象、以及对不理解的内容进行副作用修改。这些问题在 Claude Code 等 AI 编程代理的实际使用中同样存在，而一份精心设计的 CLAUDE.md 文件可以作为项目级的行为约束层，引导代理遵循更稳健的推理模式。
Karpathy 揭示的 LLM 编码缺陷
Karpathy 的核心观察可以归纳为四个方面。第一，模型经常做出错误假设并直接执行，而不会主动验证这些假设是否成立。第二，模型不善于管理自己的困惑，当遇到不明确的需求时会选择猜测而不是请求澄清。第三，模型表现出明显的过度工程化倾向，喜欢创建复杂的抽象层和冗余的功能，即使简单实现就足以解决问题。第四，模型有时会意外修改或删除与当前任务正交但未充分理解的代码和注释。
这些问题在实际的代码生成场景中会产生显著的工程成本。过度设计的代码难以维护，意外的副作用修改会导致难以追踪的回归问题，而缺乏验证的假设则可能让代理在错误的方向上走得更远。针对这些缺陷，社区已经探索出通过 CLAUDE.md 文件来约束代理行为的工程化方案。
四大原则的工程化实现
解决上述问题的核心思路是将抽象的行为准则转化为可执行的检查点。karpathy-skills 项目提炼出的四大原则分别对应不同的缺陷，每个原则都配有具体的可操作指引。
Think Before Coding 原则要求代理在编码前明确陈述假设。具体实现包括：当需求存在多种合理解释时，代理应当列出这些可能性而非默认选择其一；当遇到不明确的技术细节时，应当明确指出困惑点并请求澄清而非自行假设；当识别到方案存在明显的 tradeoff 时，应当主动呈现而非默默选择然后执行。这一原则通过在代理的思考过程中增加显式的假设声明环节，降低了错误假设被忽视的风险。
Simplicity First 原则直接对抗过度工程化的倾向。该原则要求代理仅实现明确要求的功能，拒绝添加任何推测性的抽象层或配置选项。具体标准包括：不为单一使用场景创建通用抽象、不实现超出需求范围的灵活性、避免为不可能的场景添加错误处理、如果 200 行代码可以压缩到 50 行则应当重写。在工程实践中，这一原则可以通过在代码审查时增加一个简单的检验问题「一位资深工程师会认为这过度复杂吗」来落地。
Surgical Changes 原则解决副作用修改的问题。该原则的核心是「只碰必须碰的」，具体要求包括：修改现有代码时不顺便改善相邻代码的格式或注释、不对未出现问题的代码进行重构、严格匹配项目现有的代码风格、如果注意到不相关的死代码应当报告而非直接删除。当代理的修改产生了孤儿代码如未使用的导入变量时，应当清理这些由自身修改产生的废弃物，但不主动清理之前就存在的死代码。
Goal-Driven Execution 原则将指令性任务转换为可验证的目标声明。传统的做法是告诉代理「添加验证」或「修复这个 bug」，而更优的做法是将其转化为「为无效输入编写测试然后让测试通过」或「编写能复现 bug 的测试然后修复」。对于多步骤任务，代理应当生成包含验证点的执行计划，格式类似于「步骤 1 → 验证：检查项」。这种方式将成功的定义外化，让代理能够在没有持续人工干预的情况下自主迭代。
CLAUDE.md 的安装与配置
项目提供了两种安装方式。第一种是通过 Claude Code 的插件系统，这会使得行为准则在所有项目中生效。首先需要在 Claude Code 中添加插件市场「/plugin marketplace add forrestchang/andrej-karpathy-skills」，然后安装插件「/plugin install andrej-karpathy-skills@karpathy-skills」。第二种方式是针对单个项目，将 CLAUDE.md 文件下载到项目根目录，新项目可以直接 curl 下载，现有的项目可以选择追加内容。
这种安装方式的设计体现了工程实践中的分层思想。插件方式提供了全局默认行为，适合希望在任何项目中都遵循这些原则的开发者；而项目级的 CLAUDE.md 则允许团队根据具体项目的需求添加定制化规则，例如指定使用 TypeScript 严格模式、要求所有 API 端点必须有测试、或要求遵循特定错误处理模式。
效果评估与定制化边界
判断 CLAUDE.md 是否生效可以通过几个直观的指标。首先，检查 PR 的 diff 规模是否精简 —— 只有真正需要的修改会出现。其次，观察代码是否在首次实现时就足够简单，不再需要多次重写。第三，代理在实现之前是否会先提出澄清问题，而不是在出错后补救。第四，PR 中是否消除了「顺带改进」类型的修改。
值得注意的是，这些原则存在一个内置的权衡：它们偏向于谨慎而非速度。对于简单的任务如修改 typo 或明显的一行代码修复，不应当套用完整的严格流程。目标是在非平凡的工作上减少代价高昂的错误，而非拖慢简单任务的速度。
在实际应用中可以进一步定制。例如在追求迭代速度的原型阶段可以临时放宽 Simplicity First 原则，在需要严格审计的模块可以加强 Surgical Changes 的检查力度。关键是将这些原则作为可调节的行为参数而非不可变教条，根据具体场景动态适配。
资料来源：本方案基于 Karpathy 的 LLM 编程行为观察，核心实现来自 forrestchang 维护的 andrej-karpathy-skills 项目。