特斯拉前AI总监自曝:用Claude写代码后,手艺废了

前几天刷Twitter，看到Karpathy发了一串推文，讲他最近疯狂用Claude写代码的心得。说实话，看完我有点复杂的感觉。

Karpathy是谁？特斯拉前AI总监，OpenAI早期成员，算得上AI圈的顶流了。连他都在用Claude写代码，还写了一大堆使用心得。这事本身就挺有意思。

他管这叫"Vibe Coding"

Karpathy造了个词：Vibe Coding，大概可以翻译成"凭感觉编程"。

意思是你不用再一行行敲代码了。跟AI说说你想要什么效果，它替你写。语法？API细节？不用记，AI搞定。

听着挺爽的。

但他话锋一转，说了句让我印象很深的话：他发现自己手写代码的能力在退化。

我仔细想了想，这确实是个问题。就像开惯了自动挡，突然让你开手动挡，可能还真有点生疏。

四条规矩

Karpathy总结了四条和Claude协作的原则。他甚至整理成一个叫CLAUDE.md的文件，扔到项目里让AI每次都先读一遍。

第一条：别急着让它写代码

常见的用法是直接甩个问题给AI，等它吐代码。Karpathy不这么干。他先让AI把需求复述一遍，问问有没有不清楚的地方，列几个可能的方案。

这样有个好处：在AI开始疯狂输出之前，你能先确认它懂你的意思。省得写了一堆才发现方向不对。

第二条：代码越短越好

AI有个毛病，喜欢写过度设计的代码。什么"以防万一"的功能、三层抽象封装、未来可能用到的扩展接口。

Karpathy的做法是直接告诉AI：只写解决当前问题的代码，不要多。

第三条：改代码要像做手术

用AI改bug的时候，它经常会"顺手"改点别的。可能觉得你原来的代码风格不好看，帮你重构一下；可能觉得某个地方可以优化，就动了。

问题是你让它改A，它把B也改了，很容易埋雷。所以要明确告诉它：只动需要动的地方，其他别碰。

第四条：用测试来驱动

与其说"帮我写个函数"，不如说"帮我写个函数，让这个测试能跑通"。

AI很擅长这种模式。它可以反复试，试到测试通过为止。

HN上吵得挺热闹

这几条推文在Hacker News上火了，500多个赞，评论区也很精彩。

有人搬出苏格拉底。说当年苏格拉底批评文字会让人变笨，因为不用记东西了。现在AI是不是同样的问题？

一个开发者说了个很形象的比喻：用AI写代码像在刷短视频。明知道自己可以更有创造力，但AI太方便了，门槛太低，就一直让它写下去。

还有人说，管AI就像管人。你知道最优解是什么，但它有自己的"想法"。折腾几轮，你就学会妥协了——测试过了就行，别太纠结细节。

有个观察我觉得挺值得警惕：现在好多开发者遇到问题不看文档了，直接问AI。AI不知道？算了，换个方案。可AI的训练数据是有截止日期的，新出的库它真不知道。

Karpathy的预言

他对今年做了个预测，叫Slopacolypse。

大意是：AI生成内容的成本太低了，GitHub、学术网站、社交媒体会被大量低质量内容淹没。想找高质量的原创内容会越来越难。

不光是代码。文章、论文、评论，到处都是AI生成的。你以为在看人的观点，可能是AI的输出。

所以他的意思是：光会用AI不够，得有能力判断AI产出的质量。

我琢磨出来的几点

看完Karpathy的分享，再加上HN的讨论，我自己总结了几条。

写个CLAUDE.md放项目里

把项目的设计原则、代码风格、禁忌事项写清楚。每次跟AI对话前先让它读这个文件，相当于提前对齐。

偶尔脱离AI写写代码

就像锻炼一样，不用就生疏。建议每周留几个小时，纯手写，不靠AI。

Code Review不能省

AI写的代码必须仔细看。检查它理解对了没有，有没有多余的东西，有没有偷偷改了不该动的地方。

学学怎么跟AI说话

提示词的质量直接影响产出。花点时间研究怎么表达需求，会省很多事。

该学的还得学

AI不能替你理解原理。算法、系统设计、底层知识，这些东西AI帮不了你。

最后

Karpathy这事让我觉得挺有意思的。他算是AI圈的大佬了，结果用AI编程也遇到各种问题：代码质量参差不齐，AI有自己的"习惯"很难改，还担心自己手艺退化。

看来AI确实是个好工具，但也就是工具而已。它不是魔法，不会因为你用了AI就自动变成更好的程序员。

HN有个评论说得挺好：AI is just another tool. You still need to be a good programmer.

差不多就是这个意思。

来源：Karpathy Twitter、Hacker News讨论