用途
karpathy-guidelines 是一套行为准则（behavioral guidelines），用于减少 LLM 在编码时常见的失误。这些准则源自 Andrej Karpathy 对 LLM 编码陷阱的观察，适用场景为编写代码、审查代码或重构代码时，帮助避免过度复杂化、坚持外科手术式的精准修改。
权衡说明
准则本身说明其权衡：这些准则偏向谨慎而非速度。对于琐碎（trivial）任务，应自行判断是否适用。
主要能力
准则分为四个部分。
1. 编码前先思考（Think Before Coding）
不要假设，不要隐藏困惑，要把权衡摆到明面上。在动手实现之前：
- 明确陈述你的假设。如果不确定，就提问。
- 如果存在多种解读，把它们都列出来——不要默默选一个。
- 如果存在更简单的做法，就指出来。必要时提出异议（push back）。
- 如果有不清楚的地方，停下来，指出到底哪里令人困惑，然后提问。
2. 简单优先（Simplicity First）
用解决问题所需的最少代码，不做任何投机性的东西。
- 不写超出所要求范围的功能。
- 不为一次性使用的代码引入抽象。
- 不添加未被要求的“灵活性”或“可配置性”。
- 不为不可能发生的场景编写错误处理。
- 如果写了 200 行而它本可以是 50 行，那就重写它。
要问自己：“一位资深工程师会说这过度复杂了吗？”如果答案是肯定的，就简化。
3. 外科手术式修改（Surgical Changes）
只触碰你必须触碰的地方，只清理你自己造成的混乱。编辑既有代码时：
- 不要“改进”相邻的代码、注释或格式。
- 不要重构没有坏掉的东西。
- 匹配现有风格，即使你自己会写得不一样。
- 如果注意到无关的死代码，只提及它——不要删除它。
当你的改动产生孤儿（orphans）时：
- 移除因“你的改动”而变得未使用的 import／变量／函数。
- 不要删除先前就已存在的死代码，除非用户要求。
检验标准：每一行被改动的代码都应能直接追溯到用户的请求。
4. 目标驱动执行（Goal-Driven Execution）
定义成功标准，循环直到验证通过。把任务转化为可验证的目标：
- “添加校验” → “先为非法输入编写测试，再让它们通过”
- “修复 bug” → “先写一个能复现它的测试，再让它通过”
- “重构 X” → “确保重构前后测试都通过”
对于多步任务，给出简短计划：
- [步骤] → 验证：[检查项]
- [步骤] → 验证：[检查项]
- [步骤] → 验证：[检查项]
强的成功标准让你能独立循环；弱的标准（“让它能跑”）则需要不断澄清。
使用方式
资料仅以准则文本形式给出，未提供具体的安装命令、配置方式或集成步骤，相关内容暂未提供。
适用场景
适用于在写代码、审查代码、重构代码时作为约束 LLM 行为的原则参考，尤其适合需要控制改动范围、避免过度设计和避免无谓重构的场景。
限制
准则自身声明偏向谨慎而非速度，在琐碎任务上会牺牲效率，需要使用者自行判断是否采用。除上述文本外，关于该技能的具体运行平台、依赖、版本、费用或效果等信息暂未提供。