Hotdry.

Article

基于Karpathy观察构建CLAUDE.md:校准Claude Code行为模式的四大原则

从Andrej Karpathy对LLM编码陷阱的观察出发,构建CLAUDE.md配置文件的四大核心原则与可落地参数,解决隐藏假设、过度工程、附带修改和目标缺失问题。

2026-05-25ai-systems

AI 辅助编码已成为开发工作流的标准配置,但 LLM 在代码生成过程中暴露出的系统性行为偏差却常被忽视。Andrej Karpathy 在 X 平台的一系列观察直指核心问题:模型会在未经确认的情况下替你做出假设,不会管理自身的困惑状态,不会主动呈现权衡方案,也不会在应该反驳时提出异议。

这些观察被 multica-ai 团队整理为一份可直接落地的 CLAUDE.md 配置文件,通过四大行为校准原则,将抽象的 "提示工程" 转化为可版本化、可复用的项目级规范。

四大编码陷阱的本质

Karpathy 总结的 LLM 编码陷阱可归纳为四个维度。第一,隐藏假设与沉默运行—— 模型在存在歧义时不寻求澄清,而是选择一种解释并继续执行,导致后续代码建立在错误前提之上。第二,过度工程与抽象膨胀—— 模型倾向于用 1000 行代码解决本可用 100 行完成的问题,引入未请求的 "灵活性" 和 "可配置性"。第三,正交代码的附带修改—— 即使任务与某段代码无关,模型也可能 "优化" 注释、调整格式或删除看似无用的代码。第四,缺乏目标驱动验证—— 模型接收指令而非目标,无法自我验证完成质量。

这些陷阱并非模型能力缺陷,而是行为模式问题。正如 Karpathy 所言:"LLMs are exceptionally good at looping until they meet specific goals... Don't tell it what to do, give it success criteria and watch it go."

CLAUDE.md 的四大校准原则

基于上述观察,CLAUDE.md 配置文件通过结构化指令重塑 Claude Code 的行为模式。

原则一:编码前思考(Think Before Coding)

该原则强制模型在生成代码前显式陈述假设。配置要求模型在不确定时主动询问而非猜测,在存在多种解释时呈现所有可能而非静默选择,在发现更简单方案时提出反驳,在感到困惑时停止并命名困惑点。这一原则直接针对 "隐藏假设" 陷阱,将隐式推理转化为显式沟通。

原则二:简洁优先(Simplicity First)

配置明确禁止超出请求范围的功能、单次使用代码的抽象、未请求的 "灵活性" 设计,以及针对不可能场景的错误处理。核心检验标准是:如果资深工程师会认为这段代码过度复杂,则必须简化。该原则通过硬性约束对抗模型的过度工程倾向。

原则三:精准修改(Surgical Changes)

该原则划定修改边界:不 "改进" 相邻代码、注释或格式,不重构未损坏的代码,即使风格偏好不同也要匹配现有风格。对于代码孤儿(因本次修改而变得无用的导入、变量、函数),仅清理由本次变更造成的,不触碰既有的死代码。检验标准简单明确:每一行变更都必须能追溯到用户的具体请求。

原则四:目标驱动执行(Goal-Driven Execution)

此原则将指令式任务转化为可验证目标。例如,将 "添加验证" 转化为 "为无效输入编写测试,然后使测试通过";将 "修复 bug" 转化为 "编写复现测试,然后使其通过"。多步骤任务需以 "步骤 → 验证" 格式呈现计划。强成功标准使模型能够独立循环验证,弱标准(如 "让它工作")则导致持续的人工澄清。

可落地的配置参数

CLAUDE.md 的配置结构遵循 "问题 - 原则 - 行为指令" 三层模型。在行为指令层,可配置以下具体参数:

  • 假设陈述阈值:当置信度低于明确阈值时强制提问
  • 代码行数预算:对简单任务设置硬性行数上限(如 "不超过 50 行")
  • 修改范围白名单:显式列出允许修改的文件路径或代码区域
  • 成功标准模板:为常见任务类型(bug 修复、功能添加、重构)预设验证清单
  • 风格匹配规则:引用项目中现有代码作为风格基准

配置支持两种部署模式:项目级(将 CLAUDE.md 置于项目根目录)和全局级(通过 Claude Code 插件市场安装)。对于使用 Cursor 的团队,仓库提供了兼容的 .cursor/rules 配置。

验证校准效果的指标

校准是否生效可通过以下指标判断:代码 diff 中非必要变更减少;因过度复杂导致的重写次数下降;澄清问题出现在实现前而非错误后;PR 保持简洁,无 "顺便" 重构。这些指标从结果层面验证了行为模式的成功调整。

局限与权衡

该配置偏向谨慎而非速度。对于简单任务(如明显的拼写错误、单行修复),完整遵循四大原则可能产生过度开销。建议对此类任务使用判断而非僵化执行 —— 目标是减少非平凡工作的昂贵错误,而非拖慢简单任务。

此外,CLAUDE.md 需要与项目特定规则合并。例如,TypeScript 严格模式要求、API 端点测试规范、错误处理模式等项目级约定,应作为独立章节追加到配置文件末尾。

资料来源

  • multica-ai/andrej-karpathy-skills: Karpathy-Inspired Claude Code Guidelines - GitHub
  • Andrej Karpathy on X: LLM coding pitfalls observations

ai-systems

内容声明:本文无广告投放、无付费植入。

如有事实性问题,欢迎发送勘误至 i@hotdrydog.com