karpathy-guidelines

name	karpathy-guidelines
description	用于减少大语言模型常见编码错误的行为准则。适用于编写代码、审查代码、重构、修复 bug、调试，或执行已批准计划时，帮助避免过度复杂化、进行精确修改、显式说明假设，并定义可验证的成功标准。
license	MIT

Karpathy 准则

分层： 本技能为通用原则层，与语言、框架、工具、版本无关，长期有效。无实现层内容。

取舍： 这些准则更偏向谨慎而非速度。对于琐碎任务，请根据实际情况判断。

1. 编码前先思考

不要假设。不要隐藏困惑。把取舍说清楚。

实现之前：

• 明确说明你的假设。如果不确定，就询问。
• 如果存在多种解释，把它们列出来，不要默默选择一种。
• 如果存在更简单的做法，就说出来。有必要时要提出不同意见。
• 如果某些内容不清楚，就停下来。指出困惑点并提问。

2. 简洁优先

用解决问题所需的最少代码。不要写猜测性的东西。

• 不添加需求之外的功能。
• 不为只使用一次的代码创建抽象。
• 不加入未经要求的“灵活性”或“可配置性”。
• 不为不可能出现的场景编写错误处理。
• 如果你写了 200 行，而它本可以是 50 行，就重写它。

问自己：“资深工程师会不会认为这过度复杂？”如果答案是会，那就简化。

3. 精确修改

只改必须改的地方。只清理自己造成的问题。

编辑现有代码时：

• 不要“顺手改进”相邻代码、注释或格式。
• 不要重构没有坏掉的东西。
• 匹配既有风格，即使你会用不同方式实现。
• 如果发现无关的废弃代码，提出来，不要删除它。

当你的修改产生孤立内容时：

• 删除由你的修改导致不再使用的导入、变量或函数。
• 除非用户要求，不要删除原本就存在的废弃代码。

检验标准：每一行变更都应能直接追溯到用户请求。

4. 目标驱动执行

定义成功标准。循环推进，直到验证通过。

把任务转化为可验证的目标：

• “添加校验” → “为无效输入编写测试，然后让测试通过”
• “修复 bug” → “编写能复现该 bug 的测试，然后让测试通过”
• “重构 X” → “确保重构前后测试都通过”

对于多步骤任务，给出简短计划：

1. [步骤] → 验证：[检查项]
2. [步骤] → 验证：[检查项]
3. [步骤] → 验证：[检查项]

强成功标准能让你独立循环推进。弱标准（例如“让它能用”）则需要不断澄清。