Karpathy 四步 AI 编程协作准则手册：让 LLM 写码前先说出它的假设

Karpathy 四步 AI 编程协作准则手册让 LLM 写码前先说出它的假设【免费下载链接】andrej-karpathy-skillsA single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathys observations on LLM coding pitfalls.项目地址: https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills让 AI 助手给注册接口加个登录校验它加是加了但顺手把密码哈希算法也换了还把整个文件的注释重新排了一遍。这不是个例AI 编程协作的真相是代码写得快帮倒忙得也快。开源项目 andrej-karpathy-skills 把 Andrej Karpathy 对 LLM 编码陷阱的观察浓缩进一个 CLAUDE.md 文件本文把它拆成一条可以直接套用的四步工作流帮你把 AI 从代码生成器调教成靠谱的协作者。复盘一个翻车现场AI 编码快的另一面Karpathy 在原文中把 LLM 的毛病总结成三句话它会替你做出错误假设然后一路顺着跑下去从不求证它特别喜欢把代码和 API 搞复杂100 行能解决的事能写成 1000 行即使与任务无关它也会改掉自己并不理解的注释和代码。说人话就是一本正经地自信。这三个毛病恰好对应 AI 帮倒忙的三种来源不说的假设、堆上去的代码、管不住的手。四步准则分别给这三点上了护栏。把四条准则串成一条 Phase 1~4 工作流 Think Before Coding、Simplicity First、Surgical Changes、Goal-Driven Execution——仓库里的四条准则其实是同一次编码任务的完整生命周期动手前想、写的时候简、改的时候收、收工前验。Phase 1让 AI 在动手前列出假设做什么要求 AI 在写代码前列出我假设 X存在多种解读时全部摆出来让你选有困惑就停下、说出困惑、提问。为什么返工的根因是默默选一种解释然后一路跑。假设一旦说出口猜错的代价就从大段重写变成改一行字。反例一句话你说加用户校验它默默搭了整套 OAuth 集成而你其实只需要 5 行用户名检查。Phase 2把以防万一的功能从代码里剪掉这是防 AI 助手过度设计的关键一步。做什么只实现被要求的功能单次使用的代码不做抽象没人要的可配置性不加不可能发生的场景不写错误处理200 行能压到 50 行就重写。为什么过度设计不是加分项是给未来维护交的税。仓库给的自检标准很直接资深工程师会不会说这写复杂了反例一句话一个 50 行的文件上传功能被包装成抽象工厂加策略模式再加三层校验共 200 行。Phase 3变更只落在请求要求的行上防 LLM 修 bug 改坏别的代码做什么只改必须改的匹配现有代码风格哪怕你觉得它丑发现无关的死代码只提出来不删除只清理自己这次改动产生的孤儿代码。为什么每一行与任务无关的改动都是审查时要你多花十分钟确认、还可能引入回归的隐患。反例一句话修一个排序 bug顺手把相邻函数的命名风格也调了diff 里真假变更混在一起。Phase 4把任务变成可验证目标循环到通过做什么把指令式任务翻译成可验证目标——加校验变成为非法输入写测试然后让它们通过修 bug变成先写一个能复现问题的测试重构变成改前改后测试都通过。多步骤任务先列步骤 → 验证的简短计划。为什么Karpathy 观察到 LLM 特别擅长循环直到满足具体目标。成功标准强它能独立循环标准弱让它能跑它就得反复来找你确认。反例一句话你说优化性能它加了一整套缓存层却没有一个可对比的数字。对照速查表三种高频场景的各 Phase 要点场景Phase 1 想Phase 2 简Phase 3 收Phase 4 验开发新 API先确认要哪些端点、响应格式从最基础的实现开始不引额外框架只加请求的端点不重排现有路由每个端点配一个测试修 Bug先让 AI 说出根因分析最小化修复不趁机换整个模块只碰与 bug 相关的行先写复现测试修后确认无回归代码重构明确重构目标与风险边界小步走每步都能验证保持接口不变改前改后测试都通过✅ 落地三步从克隆仓库到用清单评审① CLAUDE.md 配置方法克隆仓库并放到项目根目录项目核心就是一个 CLAUDE.md完整版准则在 skills/karpathy-guidelines/SKILL.md。克隆后拷到项目根目录即可git clone https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills cp andrej-karpathy-skills/CLAUDE.md 你的项目/如果项目已有 CLAUDE.md把这四节准则追加到现有文件末尾也行两者不冲突。② 在 Prompt 里嵌入先列假设再动手的指令不想改项目配置的话把下面这段直接贴进对话开头效果与四条准则一致在动手前请先 1. 列出你对此需求做出的所有假设 2. 若需求有歧义列出所有可能的解读并问我选哪个 3. 不要添加我没要求的功能、抽象或可配置项 4. 只修改与本请求直接相关的行相邻问题只提出来、不修改 5. 把任务转成可验证的成功标准逐条验证后再交付。③ AI 编码前思考清单Code Review 加四条检查diff 里的每一行改动都能追溯到我的原始请求吗新增的抽象、参数、配置项是不是以防万一的AI 动手前是否列出了假设、问了歧义点成功标准是否具体可测试且测试真的跑过纠偏三条关于 LLM 编码规范的常识你以为规则越严AI 就越慢。实际上仓库开头就写明了权衡四条准则偏向谨慎高于速度但改错别字这类琐碎任务请自行裁量——目的不是拖慢简单工作而是减少非简单工作上的代价高昂的失误。你以为这套准则是给模型升级能力。实际上它是一套逼 AI 把不懂的说出来的协作习惯。模型没变强但错误模式从默默做错变成了先被确认你拦截问题的时机大幅前移。你以为 diff 改得越多产出越值。实际上项目给出的判断标准恰恰相反diff 中不必要的改动越少、因过度复杂导致的重写越少、澄清问题出现在实现之前而不是犯错之后——准则才算真正生效。收尾把准则用在下一个 AI 编码任务上AI 写代码快是事实但快必须跑在护栏上。先把假设说出口再写最少的代码再只改该改的行最后用测试收口——这四步就藏在一个文件里。想细看每条准则的应用场景与示例可以翻一翻仓库里的 skills/karpathy-guidelines/SKILL.md对照着你的下一个任务读一遍。【免费下载链接】andrej-karpathy-skillsA single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathys observations on LLM coding pitfalls.项目地址: https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考