Karpathy的四条黄金法则：让AI编程助手真正好用起来

Andrej Karpathy近期分享了其针对运用大模型编程时所遭遇痛点的观察，归纳出三个核心问题：

其一，模型过于擅作主张。它们常常暗自做出假设，然后一路盲目推进，既不顾及自身的困惑，也不寻求澄清，既不暴露矛盾之处，也不呈现不同方案的权衡，即便到了该反驳的时候也选择沉默。

其二，模型存在过度工程化的趋势。它们热衷于将代码与接口复杂化，不断堆砌抽象层，且不清理无效代码。明明只需100行代码就能解决的问题，却非要构建成1000行的臃肿结构。

其三，模型会产生意想不到的副作用。它们有时会对自己尚未充分理解的注释和代码进行修改或删除，即便这些内容与当前任务毫无关联。

针对上述问题，社区总结出四条原则：

原则一：深思而后行

切勿盲目假设，不要隐藏困惑，要将各种权衡清晰地摆在台面上。具体而言，需明确陈述假设，若有不确定之处，应主动询问而非自行猜测；当存在歧义时，要呈现多种解读方式，切勿暗自选定一种；若有更为简单的方案，要大胆提出；一旦遇到困惑，就应即刻停下，明确说明不明白的地方。

原则二：简洁至上

以最少的代码解决问题，不做任何投机取巧之事。不添加未被要求的功能，不为仅使用一次的代码构建抽象层，不增加未被要求的灵活性或可配置性，不为几乎不可能发生的场景编写错误处理代码。若200行代码能精简至50行，那就重新编写。检验标准极为简单：一位资深工程师是否会认为此代码过度复杂？若答案是肯定的，就进行简化。

原则三：精准式修改

仅对必须改动的地方进行操作，只清理自己造成的混乱。在编辑现有代码时，不要顺带改进相邻的代码、注释或格式，不要重构尚未出现问题的部分，即便个人有不同偏好，也要与现有风格相匹配。若发现无关的无效代码，提及即可，切勿删除。当修改产生孤立代码时，移除因修改而不再使用的导入、变量和函数，但不要触碰原本就存在的无效代码。检验标准为：每一行改动都应能直接追溯到用户的请求。

原则四：目标导向执行

明确成功的标准，并通过循环验证直至达成目标。将命令式任务转化为可验证的目标。例如，将添加验证改为先编写针对无效输入的测试，再让测试通过；把修复bug改为先编写复现bug的测试，再让测试通过；把重构X改为确保重构前后测试均能通过。

Karpathy有一个关键的洞察：大模型尤其擅长循环执行直至达成特定目标。不要直接告知它要做什么，而是给它设定成功标准，然后静观其发挥。

这套指南生效的标志为：代码差异中不再出现不必要的修改，代码首次编写就简洁明了，无需反复重写，澄清问题在实现之前完成，而非在犯错之后，提交的代码干净精简，没有随意进行重构。

这套方法论更倾向于谨慎行事而非追求速度。对于简单任务，无需完全遵循，但在较为复杂的工作中，它能有效减少代价高昂的错误。