Claude Code 行为指南背景与问题Andrej Karpathy前 OpenAI 创始成员、前 Tesla AI 总监在社交媒体上分享了他对 LLM 编码行为的观察“模型会替你做出错误的假设并直接执行而不去验证。它们不管理自己的困惑不寻求澄清不暴露不一致性不展示权衡取舍在应该拒绝时也不拒绝。”“它们非常喜欢过度复杂化代码和 API膨胀抽象层不清理死代码…实现一个膨胀的结构超过 1000 行而实际上 100 行就够了。”“它们有时仍然会更改/删除它们不够理解的注释和代码作为副作用即使这些与任务无关。”解决方案四大原则本项目通过四大核心原则来解决这些问题原则解决的问题先思考后编码错误假设、隐藏困惑、缺失权衡简约优先过度复杂化、膨胀抽象精准修改无关编辑、触碰不该碰的代码目标驱动执行通过测试优先、可验证的成功标准原则详解1. 先思考后编码 (Think Before Coding)核心理念不要假设。不要隐藏困惑。展示权衡取舍。LLM 经常默默地选择一种解释然后执行。这个原则强制显式推理明确陈述假设— 如果不确定先问而不是猜呈现多种解释— 当存在歧义时不要默默选择适时拒绝— 如果存在更简单的方法说出来困惑时停止— 指出不清楚的地方请求澄清示例对比# 用户请求添加用户数据导出功能 # ❌ LLM 常见做法错误假设 # - 假设导出所有用户隐私问题 # - 假设文件位置 # - 假设包含哪些字段 # 直接开始写代码... # ✅ 正确做法展示假设 在实现之前我需要澄清 1. 范围导出所有用户还是筛选子集隐私影响 2. 格式您说的导出是指 - 浏览器下载文件 - 后台任务邮件通知 - API 端点返回数据 3. 字段包含哪些用户字段有些可能敏感 4. 数据量通常有多少用户影响实现方式 最简单的方案添加返回分页 JSON 的 API 端点。2. 简约优先 (Simplicity First)核心理念解决问题的最少代码。不做任何推测性设计。对抗过度工程化的倾向不添加超出需求的功能不为单次使用的代码创建抽象不添加未请求的灵活性或可配置性不处理不可能发生的错误场景如果 200 行代码可以写成 50 行就重写它测试标准高级工程师会认为这过度复杂吗如果是就简化。示例对比# 用户请求添加折扣计算函数# ❌ 过度工程化约60行fromabcimportABC,abstractmethodclassDiscountStrategy(ABC):abstractmethoddefcalculate(self,amount:float)-float:passclassPercentageDiscount(DiscountStrategy):# ... 更多代码classFixedDiscount(DiscountStrategy):# ... 更多代码classDiscountCalculator:# ... 更多代码# ✅ 简约方案5行defcalculate_discount(amount:float,percent:float)-float:计算折扣金额。percent 应为 0-100。returnamount*(percent/100)3. 精准修改 (Surgical Changes)核心理念只触碰必须触碰的。只清理自己制造的混乱。修改现有代码时不要改进相邻的代码、注释或格式不要重构没坏的东西匹配现有风格即使你会用不同的方式如果发现无关的死代码提一下 — 不要删除它测试标准每一行改动都应该能直接追溯到用户的请求。示例对比# 用户请求修复空邮箱导致验证器崩溃的 bug# ❌ 做得太多添加了未请求的用户名验证defvalidate_user(user_data):验证用户数据。# 添加了未请求的 docstringemailuser_data.get(email,).strip()# 验证邮箱ifnotemail:raiseValueError(Email required)ifnotinemailor.notinemail.split()[1]:# 增强了验证raiseValueError(Invalid email)# 验证用户名 ← 这是未请求的功能usernameuser_data.get(username,).strip()ifnotusername:raiseValueError(Username required)iflen(username)3:raiseValueError(Username too short)returnTrue# ✅ 精准修改只修复空邮箱问题defvalidate_user(user_data):# 检查邮箱格式emailuser_data.get(email,)# 只改了这里ifnotemailornotemail.strip():# 处理空字符串raiseValueError(Email required)ifnotinemail:# 保持原有验证逻辑raiseValueError(Invalid email)# 检查用户名保持原样ifnotuser_data.get(username):raiseValueError(Username required)returnTrue4. 目标驱动执行 (Goal-Driven Execution)核心理念定义成功标准。循环直到验证通过。将命令式任务转化为可验证的目标不要说…转化为…“添加验证”“为无效输入写测试然后让测试通过”“修复 bug”“写一个能复现它的测试然后让测试通过”“重构 X”“确保前后测试都通过”对于多步骤任务陈述简要计划1. [步骤] → 验证: [检查项] 2. [步骤] → 验证: [检查项] 3. [步骤] → 验证: [检查项]示例对比# 用户请求给 API 添加速率限制 # ❌ 一次性完成300行代码无验证步骤 # 实现完整的 Redis 速率限制、多种策略、配置系统... # ✅ 增量验证 API 速率限制实现计划 1. 添加基本的内存速率限制单个端点 验证 - 测试100次请求 → 前10次成功其余返回429 - 手动curl端点11次看到速率限制错误 2. 提取为中间件应用到所有端点 验证 - 测试速率限制应用到 /users 和 /posts - 现有端点测试仍然通过 3. 添加 Redis 后端支持多服务器 验证 - 测试应用重启后速率限制持久化 - 测试两个应用实例共享速率限制计数器 4. 添加配置每个端点的速率 验证 - 测试/search 允许 10/分钟/users 允许 100/分钟 每个步骤独立可验证、可部署。 从步骤1开始安装方式方式 AClaude Code 插件推荐在 Claude Code 中执行# 首先添加市场/plugin marketplaceaddforrestchang/andrej-karpathy-skills# 然后安装插件/plugininstallandrej-karpathy-skillskarpathy-skills这会将指南作为 Claude Code 插件安装在所有项目中都可用。方式 BCLAUDE.md每个项目新项目curl-oCLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md现有项目追加echoCLAUDE.mdcurlhttps://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.mdCLAUDE.md如何知道它在生效如果这些指南在起作用你会看到diff 中不必要的改动减少— 只出现请求的改动过度复杂化导致的重写减少— 代码第一次就很简单澄清问题在实现之前出现— 而不是在犯错之后干净、最小的 PR— 没有顺便重构或改进权衡说明这些指南偏向谨慎而非速度。对于琐碎任务简单的拼写修复、明显的单行修改请使用判断力 — 不是每个改动都需要完整的严谨流程。目标是减少非琐碎工作中的代价高昂的错误而不是减慢简单任务。核心洞见来自 Andrej“LLM 非常擅长循环直到满足特定目标…不要告诉它做什么给它成功标准然后看着它执行。”目标驱动执行原则捕捉了这一点将命令式指令转化为带有验证循环的声明式目标。好的代码是简单解决今天问题的代码而不是过早解决明天问题的代码。