把 AI 当实习生，不是当神仙

一个比喻

Karpathy 有个说法很准：把 AI 当成一个「读过所有书、但过分自信的实习生」。

拆开看：

第三条是所有麻烦的来源。它不会说「我不确定」，它会直接给你一个能跑但是错的东西。

这四条不依赖任何具体工具，换 Cursor、换 Claude Code、换国产工具都成立。

不要一上来就说「帮我实现 X」。先说：

我想做 X。先别写代码，告诉我你打算怎么做、分几步、会动哪些文件，我确认了你再动手。

为什么：方案错了，代码写得再漂亮也是白写。而且看方案比看代码快十倍——你能看懂方案，不一定看得懂代码。

一次只让它做一件事，做完确认，再做下一件。

反例：「帮我加登录、加数据库、再把页面美化一下」 → 三件事搅在一起，出问题你不知道是哪一件搞砸的。

正例：先加登录 → 跑一下 → 好了 → 再加数据库。

每次它改完、你验证过能跑，立刻提交一次。

git add -A && git commit -m "登录能用了"

这样任何时候改坏了，一条命令回到上一个能跑的状态：

git reset --hard HEAD

不要转述、不要总结、不要只贴最后一行。整段复制，整段粘贴。

报错信息里那些你觉得是废话的部分（文件路径、行号、调用栈），恰恰是 AI 定位问题最需要的东西。

一个足够好的需求，包含这四样：

要素	例子
目标	我要让用户能上传头像
上下文	项目用的是 Next.js，图片想存在本地 public 目录
边界	只改上传相关的代码，别动我现有的登录逻辑
验收	做完之后，我上传一张图，刷新页面还能看到它

最后一条最容易被忘，也最重要——没有验收标准，它说「做完了」你就只能信。这个话题在 L5 展开。

上面四条是不依赖工具的通用法则。具体到某个工具怎么写提示词、怎么管理上下文、有哪些技巧，转载区里有写得非常好的现成内容：

那是别人写的（MIT 许可，署名在页脚），比我们重写一遍强。