在 AI 辅助编程场景中，LLM 生成代码的质量与行为模式直接受限于系统提示的配置方式。Andrej Karpathy 在其关于 LLM 编码陷阱的观察中指出，模型常常做出错误假设却不去验证，管理不好自身的困惑，不寻求澄清，不暴露不一致性，不呈现权衡方案代码，且倾向于过度复杂化实现。这一诊断催生了 andrej-karpathy-skills 项目 —— 一个通过单一 CLAUDE.md 文件改进 Claude Code 行为的工程实践。
问题根源与工程挑战
Karpathy 的观察揭示了 LLM 在代码生成任务中的系统性缺陷。当模型接收到模糊或不完整的指令时，它倾向于 silently pick an interpretation 并直接执行，而非显式陈述假设或询问澄清。这种行为在工程层面会导致几个可观测的后果：diff 中出现用户未请求的改动、代码过度设计超过实际需求、边界情况处理不当、以及对既有代码的意外修改。这些问题的根本原因在于模型的目标函数偏向于「完成指令」而非「正确理解指令」。
从工程角度解决这一问题，需要在提示层面构建约束机制。CLAUDE.md 正是这种约束的具体载体 —— 它不是简单的规则列表，而是一套行为改变协议。
四个核心工程原则的实践参数
原则一：编码前思考（Think Before Coding）。该原则要求模型显式陈述假设而非默认推断。具体实施参数包括：当任务存在多种合理解释时，必须在行动前以列表形式呈现每个选项及其 Trade-off；当不确定需求时，直接输出「我需要澄清以下问题：...」而非猜测；每当模型感到困惑时，命名具体的困惑点而非绕过。该原则可将澄清问题的时机从「实现后返工」前移至「编码前确认」。
原则二：简单性优先（Simplicity First）。这是对抗过度工程化的核心防线。工程参数设定为：不实现任何未被明确请求的功能；不为单次使用的代码创建抽象层；不添加未经请求的「灵活性」或「配置性」；不为不可能的场景添加错误处理；当 200 行代码可以压缩至 50 行时，必须重构。这一原则通过将代码复杂度的评判标准外化为「高级工程师是否会认为这过度复杂」来量化。
原则三：外科手术式改动（Surgical Changes）。该原则控制修改边界，参数包括：仅修改直接服务于用户请求的代码行；不「改进」相邻代码、注释或格式；不重构未损坏的部分；匹配既有代码风格而非按个人偏好重写；如果注意到无关的死代码，提及但不删除；当自己的改动产生孤儿代码时，清理这些孤儿但保留既有死代码。这些参数通过「每一行变更都必须追溯至用户请求」这一检验标准来落地。
原则四：目标驱动执行（Goal-Driven Execution）。这是将 imperative 指令转换为 declarative 目标的关键机制。具体参数：将「添加验证」转化为「先为无效输入编写测试，再让测试通过」；将「修复 Bug」转化为「先编写复现 Bug 的测试，再让测试通过」；对于多步骤任务，以「步骤 → 验证方式」的表格形式陈述计划。这种模式使 LLM 能够在明确成功标准下自主循环，而非依赖持续的人工干预。
CLAUDE.md 的部署路径与监控指标
项目提供了两种部署路径。插件模式通过 plugin marketplace add forrestchang/andrej-karpathy-skills 添加市场，然后 plugin install andrej-karpathy-skills@karpathy-skills 安装，使指南全局生效。独立模式则通过 curl 下载 CLAUDE.md 到项目根目录，或追加至现有 CLAUDE.md 末尾。对于团队协作场景，建议采用 per-project 模式以结合项目特定规范。
衡量这些原则是否生效的监控指标包括：diff 中的非请求改动占比应降至零或接近零；首次提交的代码复杂度和行数应与实际需求匹配；澄清问题应出现在编码前而非编码后；PR 应保持干净，不包含附带重构或「改进」。
这些原则的代价是偏向「谨慎」而非「速度」。对于简单任务（如修复明显拼写错误），应允许模型使用判断力跳过完整流程。工程实践表明，这种方式在非平凡工作上显著降低了返工成本，同时不显著影响简单任务的处理效率。
资料来源：本文核心内容来自 GitHub 项目 forrestchang/andrej-karpathy-skills，该项目基于 Andrej Karpathy 在 X 平台关于 LLM 编码陷阱的观察整理而成。