LLM 辅助编程正在重塑软件开发的工作流，但伴随而来的并非全是效率提升。Andrej Karpathy 在 2025 年初的一系列观察中，精准指出了当前 LLM 在代码生成场景下的系统性缺陷：模型会替用户做出错误假设并继续执行，不会管理自身的困惑状态，不会主动寻求澄清，不会呈现设计权衡，也不会在必要时提出异议。这些行为模式导致代码库逐渐膨胀、抽象层过度复杂、无关代码被意外修改 —— 最终形成技术债务的隐性来源。
multica-ai 团队基于这些观察，将 Karpathy 的洞见转化为一份结构化的 CLAUDE.md 技能文件，用于校准 Claude Code 的行为模式。这份文件不是简单的提示词堆砌，而是一套可操作的工程原则，直接针对 LLM 编程中的四大核心陷阱。
四大陷阱：LLM 编程的系统性问题
Karpathy 指出的问题可以归纳为四个维度。首先是假设先行，模型面对模糊需求时会静默选择一个解释并执行，而非确认意图。这种 "猜测 - 执行" 模式在复杂业务逻辑中极易产生偏差，且偏差往往在代码审查阶段才被发现。
其次是过度工程化。LLM 倾向于创建不必要的抽象层、为单次使用场景设计通用接口、添加未请求的配置选项。结果是 100 行代码能解决的问题被扩展到 1000 行，引入认知负担的同时并未带来实际价值。
第三是副作用污染。模型在修改目标代码时，会顺带 "优化" 相邻的注释、调整未涉及的函数格式、甚至删除其不完全理解的代码片段。这些看似良性的 "改进" 实际上引入了不可控的变更风险。
最后是目标模糊。当指令停留在 "修复 bug" 或 "添加验证" 这类描述性层面时，模型缺乏明确的完成标准，容易陷入反复试探的循环，或在看似完成时留下隐患。
四大原则：从观察到工程实践
CLAUDE.md 文件将上述问题映射为四个可执行原则，每个原则都配有具体的操作指令和验证标准。
编码前思考（Think Before Coding） 要求模型在动手前显式陈述假设、呈现多种可能的解读方案、在存在更简单路径时主动提出。关键指令包括：若不确定则询问而非猜测；当存在歧义时列出多种解释；在感到困惑时暂停并请求澄清。这一原则直接对抗 "假设先行" 问题，将隐式决策转化为显式沟通。
简洁优先（Simplicity First） 设定明确的代码质量边界：不添加超出需求的功能；不为一次性代码创建抽象；不引入未请求的灵活性；不为不可能发生的场景编写错误处理；若 200 行代码可以压缩至 50 行则重写。验证标准是：资深工程师是否会认为这段代码过度复杂？若答案是肯定的，则简化。
精准修改（Surgical Changes） 划定修改边界：不 "优化" 相邻代码、注释或格式；不重构未损坏的部分；匹配现有代码风格即使个人偏好不同；若发现无关的死代码则提及而非删除。同时要求清理自身变更产生的孤儿代码（如删除因你的修改而不再使用的导入或变量）。核心测试是：每一行变更都应能直接追溯到用户的原始请求。
目标驱动执行（Goal-Driven Execution） 将描述性任务转化为可验证目标。例如将 "添加验证" 转化为 "为无效输入编写测试，然后使测试通过"；将 "修复 bug" 转化为 "编写重现测试，然后使测试通过"。对于多步骤任务，要求列出简短计划并标注每步的验证检查点。Karpathy 对此的核心洞见是："不要告诉它做什么，给它成功标准，然后看着它执行。"
工程落地：CLAUDE.md 的设计与使用
这份技能文件的设计体现了几个关键工程决策。首先是单一文件策略，将所有原则收敛到一个 CLAUDE.md 中，降低认知负担的同时确保原则间的协同。其次是可组合架构，文件明确建议与项目特定指令合并使用，例如添加 "使用 TypeScript 严格模式" 或 "所有 API 端点必须包含测试" 等本地化规则。
安装方式提供两种路径。对于 Claude Code 用户，可通过插件市场安装：/plugin marketplace add forrestchang/andrej-karpathy-skills 后执行 /plugin install andrej-karpathy-skills@karpathy-skills，使技能跨项目可用。对于需要项目级定制的场景，可直接下载 CLAUDE.md 文件到项目根目录或追加到现有文件。
Cursor 用户同样受益 —— 仓库包含 .cursor/rules/karpathy-guidelines.mdc 规则文件，打开项目时自动生效。这种跨编辑器的一致性确保了团队无论使用何种工具都能获得统一的行为校准。
效果评估与权衡考量
判断这些指南是否生效有几个直观指标：代码 diff 中出现的不必要变更减少；因过度复杂导致的重写次数下降；澄清问题出现在实现之前而非错误之后；Pull Request 保持干净、最小化，没有顺带的 "改进"。
需要承认的是，这些指南偏向谨慎而非速度。对于拼写修复、明显的一行修改等简单任务，应使用判断而非套用完整流程。目标是减少非平凡任务中的高成本错误，而非拖慢简单操作。
另一个关键权衡是上下文窗口的消耗。详细的原则说明会增加每次请求的 token 数量，对于大型项目或频繁交互的场景，需要监控成本效益比。建议的做法是将 CLAUDE.md 作为基础层，配合项目特定的精简指令，在原则完整性与上下文效率间取得平衡。
从个人观察到社区实践
Karpathy 的观察最初发布于社交媒体，multica-ai 团队的工作在于将其转化为可复用的工程资产。这种转化本身值得借鉴：识别 LLM 行为的系统性模式，将其编码为结构化指令，通过标准化文件格式实现跨项目、跨团队、跨工具的复用。
对于正在构建 AI 辅助开发工作流的团队，这份 CLAUDE.md 提供了一个经过验证的基线。它不仅可以直接采用，更可以作为模板，将团队自身的代码审查经验、架构规范、风格偏好编码为类似的技能文件，形成组织级的 AI 行为校准体系。
参考来源
- multica-ai/andrej-karpathy-skills: Karpathy-Inspired Claude Code Guidelines (GitHub)
- Andrej Karpathy 关于 LLM 编程陷阱的 Twitter/X 观察（2025 年）
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。