7.4
深览指数
科技腾讯新闻·机器之心··AI 生成
大神Karpathy用Claude的方式，原来是这样的？
本文梳理了一份据称是AI大神Andrej Karpathy实际使用的CLAUDE.md文件，该文件实为社区根据Karpathy本人对LLM编程常见错误的吐槽与建议，提炼出的编程准则。内容聚焦于如何给AI写代码指令：核心原则包括写前先读代码库、保持简单、外科手术式修改、先写测试等，旨在解决当前大模型写代码时易犯的过度设计、隐形决策、风格漂移等问题。适合重度依赖AI编程助手且对代码质量有较高要求的开发者阅读，可将其作为调教AI协作者的方法论参考。原文 ↗
核心观点
- ▍大语言模型（LLM）在编程时犯的错误不是随机的，而是可预测的系统性问题，通过一份精确的CLAUDE.md规则文件可以显著降低错误率，社区实践表明错误率可从41%降至11%。
- ▍有效的AI编程协作核心在于用户必须承担‘管理者’角色，通过清晰的规则（如先读代码、最小改动、先写测试）来引导AI，而非放任其自动生成。
- 01LLM生成糟糕代码的首要原因是‘不读已有代码’，直接匹配训练数据模式生成代码，导致生成的代码虽能运行但与项目风格格格不入，必须重写。
- 02保持简单的原则包括拒绝过早抽象（如只需一个函数时创建策略模式类）、臆想式错误处理（try/catch不可能发生的错误）、不必要的可配置性（把不会变的值设成配置项）和没有生命力的灵活性（只有一个实现的接口）。
- 03外科手术式修改要求：不碰未被要求的代码，匹配现有代码风格（包括过时的习惯，如使用var），只清理自己造成的冗余，不重新格式化非格式化项目的代码，确保每一行改动都能找到与任务直接相关的理由。
- 04验证环节强调：修bug前先写测试复现，运行现有测试确认无回归，测试行为而非实现（如测试校验逻辑是否拒绝错误输入，而非测试构造函数是否设置属性）。
- 05添加依赖前必须自问：是否可用项目已有功能或标准库完成？依赖是否还在维护？包体是否过大？添加时需说明原因。
- 06沟通规则要求：说明改动目的与原因，主动指出实现方案中的潜在隐患，精确表达不确定性（‘我不确定这个库支持streaming’而非‘应该能工作’），根据对方水平调整解释深度。
- 07列举了六个常见失败模式：大杂烩（顺手重构整个代码库）、错误的抽象、隐形决策、乐观路径（仅处理happy path）、知识幻觉（幻想存在某个API）、风格漂移。
反方 / 局限
- — 作者自知这些规则的有效性最终取决于能否减少diff中的无关改动和因过度复杂导致的重写，但未深入讨论规则的时效性（未来模型能力提升后是否仍需要）或对非代码领域任务（如文档、分析）的适用性。
- — 虽然文章强调规则可以减少错误，但也揭示了当前LLM在编程协作中的根本局限——必须像管理初级实习生一样事无巨细地指导，工作流成本极高，这本身就是模型能力不足的体现。
16 分钟 · 4 卡片 · 7 资料
读原文 →