Karpathy 编码纪律

要解决的问题

让 LLM 写代码时，最常见的失败不是语法错误，而是擅自替你做假设：没问清楚需求就开工，把能装下的抽象全装进去，顺手重构了与任务无关的代码。Karpathy 总结的四类陷阱——不做澄清、过度设计、顺手乱改、目标模糊——正是这个技能要约束的。

核心能力

不只是一份原则文档，而是一条可执行的检查链：

• 四个原则：先想再写（暴露假设与分歧）、最小实现（只写被要求的代码）、外科手术式改动（每一行都能追溯到需求）、目标驱动执行（把任务改写成可验证的成功条件）
• Python 检查脚本（仅用标准库，均支持 --help）：

- complexity_checker.py — 检测过度工程：类过多、嵌套过深、圈复杂度过高、未使用参数、过早抽象
- diff_surgeon.py — 检测与目标无关的 diff 噪音：注释改动、风格漂移、顺手重构
- assumption_linter.py — 检查计划中隐藏的假设：擅自加功能、缺少澄清、静默选择某种解释
- goal_verifier.py — 检查成功标准是否可验证：计划模糊、缺少测试断言

• karpathy-reviewer 子代理：对 diff 跑完整的四原则审查
• /karpathy-check 命令：对暂存改动发起完整审查
• hooks/karpathy-gate.sh 预提交钩子：对暂存文件跑复杂度与 diff 检查，发现问题给出警告（不阻断提交），可接入 .claude/settings.json 或 Husky

典型工作流： 收到任务后先声明假设、列出多种解释与权衡；实现时只写最小代码；完成后把「修复 bug」这类指令转化为「先写复现测试再让它通过」；提交前由子代理或钩子审查 diff。references/ 下有原则出处、十余组 Python/TypeScript/shell 的正反例，以及 CI 集成与团队推广方式。

适用边界

这套原则偏向谨慎而非速度。拼写修正、一眼能改的单行改动不必走完整流程；它最适合改动超过 20 行、你没完全理解的代码、需求不清的多步任务，以及需要人工评审的产出。