核心定位
Karpathy Guidelines 是一套面向非平凡软件工程任务的执行 guardrails，由前 Tesla AI 总监、OpenAI 创始成员 Andrej Karpathy 的工程哲学提炼而成。该 skill 强制 ChatGPT 在编码、修 bug、调试、代码审查、重构等场景下，遵循「最小有效变更」原则，避免过度工程化与隐性假设。
显著优点
1. 假设显性化
要求在执行前明确列出「什么必须为真」，将隐性认知负担转化为可讨论、可质疑的显性陈述，大幅降低沟通摩擦与返工概率。
2. 变更范围极致收缩
「Surgical changes」规则禁止触碰与请求无关的代码，包括邻接重构、格式调整、风格统一等「顺手改进」，确保 diff 的可审计性与回滚安全性。
3. 验证驱动
拒绝「make it work」式模糊成功标准，强制定义 concrete checks（测试、构建、日志、最小复现），使每个步骤的结果可被独立验证。
4. 反过度工程机制
内置「strong senior engineer 测试」——若资深工程师会认为方案 overbuilt，则必须简化；禁止为未来需求预置抽象、配置点或扩展接口。
5. 结构化输出
要求最终响应包含：变更内容、关键假设/权衡、验证方式、剩余风险，形成可存档的工程决策记录。
潜在局限
- 仪式成本：对真正 trivial 的修改（单字符 typo、机械重命名），规则建议「用判断免除仪式」，但实际执行中仍可能产生过度文档化。
- 上下文依赖：「最小可行方案」的判断高度依赖对现有代码库的熟悉程度，在陌生代码库中可能误估依赖范围。
- 创新抑制：极端简化倾向可能压制合理的超前设计，特别是在需要为未来 6-12 个月架构演进预留接口的场景。
- 验证瓶颈：若用户环境缺乏测试覆盖或构建系统，「concrete checks」的要求可能难以落地。
适用场景
- 生产代码的 bug 修复与 feature 实现
- 代码审查中的系统性反馈
- 多步骤重构的路径规划
- 调试过程中的假设管理与证据收集
- 需要向团队透明传达工程决策的场景
风险提示
- 误伤简单任务：用户若未明确声明任务 trivial，可能触发不必要的完整流程。
- 假设遗漏：显性化假设依赖于执行者的认知边界，系统性盲区仍可能存在。
- 验证伪造：在无实际运行环境时，可能生成看似合理但无法执行的验证步骤。