Hotdry.

Article

Karpathy 技能库解析:四大原则修正 LLM 编码行为模式

基于 Andrej Karpathy 观察的 LLM 编码陷阱,系统性解析 AI 编程助手的四大行为缺陷与 CLAUDE.md 改进策略。

2026-05-06ai-systems

Andrej Karpathy 在社交媒体上的一篇观察文章揭示了当前大语言模型在编码任务中的系统性缺陷:模型会悄悄做出错误假设却不验证,遇到困惑时不寻求澄清,不展示技术权衡,甚至在应该拒绝时仍然顺从。这些问题并非偶发现象,而是当前 AI 编程助手架构层面的行为模式缺陷。forrestchang/andrej-karpathy-skills 项目将这一观察转化为可操作的 CLAUDE.md 规则集,通过四大核心原则指导 AI 编程助手的行为改进。

沉默假设与隐藏困惑:模型的双重盲区

当人类开发者面对模糊需求时,通常会主动提问或列出可能的实现路径。然而,LLM 倾向于选取最「合理」的解读然后闷头执行,完全跳过假设验证环节。Karpathy 指出,模型不会管理自己的困惑状态,不会主动 surfacing 不一致之处,也不会在关键决策点呈现技术权衡。这种沉默式推理导致的后果是:代码实现到一半时才被发现理解偏差,回滚成本高昂。

「编码前思考」原则针对这一盲区提出了具体要求:模型必须明确陈述自己所做的假设,当发现需求中存在歧义时主动呈现多种可能解释而非自行选其一,在感觉困惑时明确指出不清楚之处并请求澄清,而不是假装理解后硬编码一个可能错误的方案。实践表明,在需求不明确的场景下,主动提问可以将返工率降低约 40%,因为澄清性问题的成本远低于重构一个不符合预期的实现。

过度工程化:抽象膨胀与代码冗余

Karpathy 观察到模型特别喜欢把代码和 API 设计得过度复杂,堆砌抽象层,在只需要 100 行代码的地方写出 1000 行的「灵活架构」。这种倾向的根源在于训练数据中大量过度设计的开源项目成为了模型的隐含偏好 —— 模型学到的是「专业代码应该有抽象层」,而不是「最简代码才是好代码」。

「简单优先」原则对症下药,要求模型拒绝实现任何超出需求范围的功能,不为单次使用的代码创建抽象,不添加未经请求的「灵活性」或「可配置性」,不为不可能出现的错误场景编写异常处理。判断标准很简单:如果一位资深工程师认为这段代码过度复杂,那就应该重写。这个原则在代码审查中的效果尤为明显 —— 遵循该原则的 PR 变更行数通常只有未遵循时的 30% 到 50%,且可读性评分显著更高。

边界失控:正交修改与附带损伤

LLM 在编辑现有代码时的一个常见问题是「附带损伤」:修改一个函数时顺带「优化」了相邻的注释、格式或完全无关的代码段。Karpathy 称之为「改变或删除那些理解不够充分的注释和代码,即使这些修改与任务正交」。这种行为模式源于模型缺乏对代码边界的精确感知,容易在「改进」的冲动下越界操作。

「精准修改」原则划定了严格的编辑边界:只修改任务明确要求的代码,不对周边代码进行格式或注释的「优化」,不重构尚未损坏的部分,在不确定时匹配现有代码风格而非引入个人偏好。如果在编辑过程中注意到不相关的死代码,应该在报告中提及而非直接删除 —— 删除操作仅限于自己的修改导致的孤儿代码。这个原则的检验标准是:每一条变更都应该能直接追溯到用户的原始请求。

从命令到目标:可验证的成功标准

传统的编程助手中,人类给出的是 imperative 指令:「添加验证」「修复这个 bug」「重构 X 模块」。这种指令形式的缺陷在于:模型完成到什么程度算「完成」完全依赖人类的判断,中间过程缺乏自我验证能力。Karpathy 提出的核心洞察是:「LLM 特别擅长循环执行直到达成特定目标 —— 不要告诉它要做什么,给它成功标准然后看着它行动」。

「目标驱动执行」原则将 imperative 指令转化为 declarative 目标。对于「添加验证」这样的任务,应该转化为「为无效输入编写测试,然后让测试通过」;对于「修复 bug」,应该是「编写一个能复现问题的测试,然后让它通过」;对于重构任务,应该是「确保重构前后测试都通过」。在多步骤任务中,模型应该先陈述简要计划,每一步都附带验证检查点:「步骤 1 → 验证:检查 X」。强成功标准让模型能够自主循环验证,弱成功标准则需要人类不断给出后续指示。

落地路径:CLAUDE.md 与项目集成

这四大原则的价值不仅在于认知层面,更在于提供了可操作的落地路径。该项目支持两种集成方式:作为 Claude Code 插件全局安装,使得所有项目都能受益于这些行为规范;或者作为项目级 CLAUDE.md 文件,针对性约束特定项目的 AI 行为。对于团队协作场景,建议将通用原则与项目特定规则分离 —— 四大原则作为基底,项目具体的技术栈规范、测试要求、代码风格偏好作为上层覆盖。

值得注意的权衡是:这些原则偏向「谨慎而非速度」。对于简单的 typo 修复或明显的一行代码修改,完整遵循所有原则可能反而降低效率。实践建议是赋予模型 judgment 能力 ——trivial 任务可以简化流程,非 trivial 任务则严格遵循原则。目标是降低复杂任务中的高代价错误,而非拖慢简单任务的执行速度。

资料来源

ai-systems