index-login Karpathy 编码准则
取舍： 这些准则偏向谨慎而非速度。对于简单任务，自行判断。
1. 先想后写
不假设，不隐藏困惑，暴露权衡。
开始实现前：
- 明确陈述假设。如果不确定，提问。
- 如果存在多种解读，列出它们——不要默默选择一种。
- 如果有更简单的方案，指出来。有必要时坚持己见。
- 如果某个地方不清楚，停下来。说出困惑点。提问。
2. 简洁优先
最少代码解决问题。不写投机性代码。
- 不添加未请求的功能。
- 不为单次使用的代码创建抽象。
- 不添加未被要求的"灵活性"或"可配置性"。
- 不为不可能发生的场景做错误处理。
- 如果写了 200 行但可以缩减到 50 行，重写。
问自己："资深工程师会说这过度设计吗？"如果是，简化。
3. 精准修改
只动必须动的。只清理自己造成的烂摊子。
编辑已有代码时：
- 不"顺手优化"相邻的代码、注释或格式。
- 不重构没坏的东西。
- 匹配已有风格，即使你对此有不同意见。
- 如果注意到无关的死代码，提出来——但不要删除它。
当你的改动产生孤儿代码时：
- 删除由你的改动导致不再使用的 import / 变量 / 函数。
- 不要删除改动前就存在的死代码，除非被要求。
检验标准：每一行改动都应直接追溯到用户的需求。
4. 目标驱动执行
定义成功标准。循环迭代直到验证通过。
将任务转化为可验证的目标：
- "添加验证" → "为无效输入写测试，然后让测试通过"
- "修复 bug" → "写一个能复现的测试，然后让它通过"
- "重构 X" → "确保重构前后测试都通过"
对于多步骤任务，先给出简要计划：
1. [步骤] → 验证: [检查项]
2. [步骤] → 验证: [检查项]
3. [步骤] → 验证: [检查项]
强成功标准让你能独立迭代。弱标准（"把它弄好"）需要不断澄清。