同一个 Claude Code，有人一天翻十次车，有人拿它一个人干一个团队的活。
差别几乎不在工具本身，在你怎么“驾驭”它。
上一篇我写了 AI 编程工具最坑人的那句「改好了」（其实它根本没验证）。这篇是反面——半年里我几乎全程用 AI 做站，从前端、后端到运维一个人扛，踩了无数坑，也总结出一套「让它真帮上忙」的法则。不玄，全是能立刻上手的。
一、先摆正心态：它是”超自信的实习生”，不是”资深工程师”
这是所有法则的地基。AI 编程助手手很快、见识广，但它会一脸笃定地把”看起来对”的东西交给你——至于在你的真实环境里对不对，它没验证过。
所以你的角色不是”把活甩给专家”，而是“带一个手极快、但需要盯的实习生”。带得好，产出惊人；甩手不管，它坑你没商量。下面的法则，本质都是”怎么带好这个实习生”。
二、给活之前：三件事决定成败
大部分翻车，不是它能力不行，是你给的活本身就没说清楚。动手前先做三件事：
- 给足上下文，别让它猜。它看不到你的屏幕、数据库、线上环境——你不给相关文件、项目约定、完整报错，它就”合理猜测”，然后自信地错。实操：建一个项目说明文件（目录结构、约定、已知的坑），每次让它先读。
- 一次一个明确目标。别一句话塞五个需求。拆开，一个一个来，每个都能单独验证。
- 先要计划，别急着让它写代码。“先别动手，告诉我你打算改哪几个文件、为什么”——这一步能在写第一行代码之前，就拦下大量”方向就错了”的返工。
图1：一次交互的正确姿势——最后两步（绿）最常被人跳过
三、给活之中：把”结论”逼成”证据”
- 证据式验收。别接受”改好了 / 测试通过了”，让它给你能复现的证据：”curl 返回 200″”数据库那个值从 0 变成了 2″”日志里真有这一条”。（这点我上一篇专门写过，是防翻车的第一道闸。）
- 清缓存、重启，再看。opcache、fastcgi、CDN——多少”假成功”是环境挡着：代码改了，页面没变，它却报”完成”。改代码 → 清缓存 / 重启 → 复验，是铁律。（我这台服务器 opcache 关了时间戳检查，不重启 php-fpm，改了跟没改一样。）
- 报错要给全，尤其别漏 stderr。它常常只看了 stdout、没看到 stderr 里的报错，就以为成功了。你把完整报错贴给它，命中率立刻翻倍。
四、这些坑，我替你踩过了
- 别让它并发跑重活。我有次让它并发起一堆后台进程去批量处理，结果把整台服务器活活压崩——网页、SSH、连 ping 都没了。重活要串行、要限量，尤其在生产机上。
- 改线上文件前，先留逃生备份。动手前
cp 一份。它改坏了，你能一键 cp 回去。（配合上面那条：opcache 不重启看不出改动，排查更痛，备份就是你的后悔药。）
- 危险操作，让它先确认再做。删除、改权限、任何线上生效的改动——让它先说清楚”要干嘛、影响什么、怎么回滚”，你点头，它再动手。
五、长期：把坑变成”它下次不会再犯”
这是复利所在。每踩一个坑、每纠正它一个错，就写进那个项目说明 / 记忆文件。下次它先读，同样的错就不再犯。
时间拉长，你会发现：你带它花的力气越来越少，它对你项目的”懂”越来越多。这套积累，才是”一个人干出团队产出”的真正杠杆——不是它多聪明，是你把它调教得越来越贴合你的活。
六、一张分工地图：什么放心交给它，什么必须你把关
用了半年，我心里有了这样一张清单：
图2：分工地图——左边尽管放手，右边必须盯住
说到底，AI 编程工具的上限，其实是你”提问和验收能力”的上限。它把”写代码”的成本降到几乎为零，于是瓶颈从”你会不会写”变成了”你能不能说清楚要什么、能不能验出真假”。
把它当实习生带——给足上下文、逼它拿证据、把坑写成约定——你一个人，真能干出一个小团队的活。我就是这么过来的。
如果你也在用 AI 做产品、做站，想少翻车、把它用出团队级产出——可以找我聊。这套”驾驭 AI 编程”的法则，是我一天翻好几次车换来的，也真的把我一个人的产能撑起来了。
