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

bird034

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


Andrej Karpathy最近分享了他使用大模型编程的痛点观察，社区迅速将其提炼成一套实用指南。这套方法论值得每个用AI写代码的人认真看看。

Karpathy指出了三个核心问题：

第一，模型太喜欢自作主张。它们会默默做出假设然后一路狂奔，不管理自己的困惑，不寻求澄清，不暴露矛盾，不呈现权衡，该反驳的时候也不反驳。

第二，模型有过度工程化的倾向。它们热衷于把代码和接口搞复杂，堆砌抽象层，不清理死代码。明明100行能解决的问题，非要写成1000行的臃肿结构。

第三，模型会产生意外的副作用。它们有时会修改或删除自己不够理解的注释和代码，即使这些内容与当前任务毫无关系。

针对这些问题，社区总结出四条原则：

原则一：先思考再动手

不要假设，不要隐藏困惑，要把权衡摆到台面上。具体做法是：明确陈述假设，不确定就问而不是猜；当存在歧义时呈现多种解读，不要默默选一个；如果有更简单的方案，大胆说出来；遇到困惑就停下来，说清楚哪里不明白。

原则二：简洁优先

用最少的代码解决问题，不做任何投机性的事情。不加没被要求的功能，不为只用一次的代码建抽象，不加没被要求的灵活性或可配置性，不为不可能发生的场景写错误处理。如果200行能缩成50行，就重写它。检验标准很简单：一个资深工程师会不会觉得这代码过度复杂？如果会，就简化。

原则三：外科手术式修改

只动必须动的地方，只清理自己制造的混乱。编辑现有代码时，不要顺手改进相邻的代码、注释或格式，不要重构没坏的东西，即使你有不同偏好也要匹配现有风格。如果发现无关的死代码，提一嘴就好，别删。当你的修改产生了孤立代码时，移除你的修改导致不再使用的导入、变量和函数，但不要动原本就存在的死代码。检验标准：每一行改动都应该能直接追溯到用户的请求。

原则四：目标驱动执行

定义成功标准，循环验证直到达成。把命令式任务转化为可验证的目标。比如把添加验证改成先写无效输入的测试再让测试通过，把修复bug改成先写复现bug的测试再让测试通过，把重构X改成确保重构前后测试都能通过。

Karpathy有一个关键洞察：大模型特别擅长循环执行直到达成特定目标。不要告诉它做什么，给它成功标准然后看它发挥。

这套指南生效的标志是：代码差异中不再出现不必要的修改，代码第一次就写得简洁不用反复重写，澄清问题出现在实现之前而不是犯错之后，提交的代码干净精简没有顺手重构。

有人评论说，当构建和编码正在变成一种商品化能力时，品味变得至关重要。还有人调侃：Karpathy一发布这些观点，所有框架瞬间都成了对比图里的反面教材。用AI和用好AI之间的差距，正在变得越来越残酷。

这套方法论偏向谨慎而非速度。对于简单任务不必完全照搬，但在非平凡的工作上，它能有效减少代价高昂的错误。

#How I AI#

github.com/forrestchang/andrej-karpathy-skills