核心定位
Karpathy Guidelines 是一套由前特斯拉 AI 总监、OpenAI 创始成员 Andrej Karpathy 提炼的软件工程执行原则，旨在将复杂的开发任务转化为更小、更安全、更可验证的代码变更。
核心用法
该 skill 建立了一个六步默认操作循环：
1. 重述任务 — 用具体工程术语定义目标
2. 暴露假设 — 识别可能改变实现的不确定性
3. 最小可行方案 — 选择风险最低的实现路径
4. 精准执行 — 仅修改必要代码
5. 具体验证 — 用可检查的断言定义成功
6. 结构化汇报 — 说明变更内容、验证方式和剩余风险
四大核心规则
| 规则 | 要义 |
|------|------|
| **Think before coding** | 不明确时不猜测，显式陈述假设，优先低风险解释 |
| **Simplicity first** | 最小变更解决问题，拒绝过度设计，用「资深工程师是否会觉得过度工程」作为检验标准 |
| **Surgical changes** | 仅触碰请求要求的代码，不匹配局部风格时不主动重构相邻代码 |
| **Goal-driven execution** | 将模糊请求转化为可验证结果，拒绝「让它能跑」这类弱成功标准 |
场景化指导
- 实现代码：最小 diff、复用现有工具、不扩张 API 表面
- 调试：先缩小失败模式，用证据而非猜测驱动修复
- 代码审查：优先关注正确性、简洁性、范围控制和验证
- 任务规划：先提供最小可行计划，明确验证节点
显著优点
- 降低回归风险：通过「手术式变更」原则，大幅减少 unintended side effects
- 提升可审查性：结构化汇报使代码审查更高效
- 对抗过度工程：内置「过度工程检测器」有效遏制复杂化倾向
- 明确责任边界：假设显式化减少「我以为你意思是……」类沟通失败
潜在局限
- 认知开销：简单任务若严格遵循会显得仪式化（文档已提示「trivial edits 用判断，不增加 ceremony」）
- 团队共识依赖：若团队其他成员不认同「最小变更」哲学，可能产生摩擦
- 创新抑制风险：极端应用可能阻碍必要的架构演进（文档未明确界定「何时应该重构相邻代码」）
- 验证成本：「可验证结果」要求可能增加测试编写负担
适合人群
- 正在维护关键生产系统的工程师
- 需要频繁进行代码审查的技术负责人
- 希望减少技术债务累积的中大型项目团队
- 从原型阶段转向工程化阶段的团队
常规风险
- 误用于探索性编程：该 skill 针对「已知问题的优化执行」，不适合需求高度不确定的实验性开发
- 验证盲区：若验证步骤本身设计有缺陷，可能产生「通过测试但依然有问题」的 false confidence
- 渐进式复杂化：多次「最小变更」累积可能导致整体架构腐化，需周期性配合重构 skill 使用