把重复性的技术活交给 AI 助手之后，我踩的坑比过去一年加起来都多。这篇文章把它们整理成 12 条纪律 —— 每一条背后都有一次真实的翻车。
为什么要让 AI 做重复劳动
不是偷懒。真实原因是：日常技术工作里有太多「一次性但记不住」的操作 —— 改一段配置、查一个状态、跑一次数据清洗、验证一个假设。这些事单看都简单，但上下文切换成本极高，而且做完就忘。
AI 助手的价值在于：它能读文件、看日志、跑命令、写文档，把这一串动作串成一条可复现的流水线。但前提是 —— 你得先教会它「不要怎么干」。
下面这 12 条，全部来自真实事故。
一、先给它一张「禁止清单」，再给任务
大多数人给 AI 下指令是「帮我做 X」。更有效的是先说「做 X 的时候不要 Y」。
因为 AI 的失败模式通常是过度执行：你让它清理临时文件，它可能顺手把配置也删了。负向约束比正向指令更能兜住底。
我的习惯是先写清边界：哪些目录不能碰、哪些操作必须先问我、哪些命令只能只读。先划禁区，再给任务。
二、多行脚本别硬塞进一行命令
把一段带循环、带引号、带变量的脚本塞进 ssh host "..." 或者一个 -c 参数里，会直接进入转义地狱 —— 你会花二十分钟调引号，而不是解决真正的问题。
解法：本地写脚本文件 → base64 编码 → 传输 → 远端解码执行：
B64=$(base64 -w0 deploy.sh)
remote-exec "echo $B64 | base64 -d > /tmp/deploy.sh && bash /tmp/deploy.sh"
base64 的字符集是 A-Za-z0-9+/=，不含任何 shell 元字符，绝对不会被二次解释。
附赠一个坑：很多远程执行通道对单条命令有长度上限。脚本一大就会被截断，现象是「命令明明执行了，却什么都没发生」。这时候要改成分片推送，而不是继续加长命令。
三、验证网络行为，先确认本地没有中间人
本机装了代理、沙箱或者某个"安全网络组件"时，一次普通的 HTTP 请求可能返回一个假的错误码 —— 请求压根没出你的机器，是本地代理在瞎回。
这会把「网络其实通着」误判成「服务挂了」。
解法：探测外部可达性时显式绕过代理，并且看响应里的对端 IP 是不是你预期的那个：
curl --noproxy '*' -sI https://your-endpoint/
判据是「对端 IP 对不对」，不是「状态码好不好」。 只要 IP 是本地回环或内网地址，这次结果就无效。
四、判断成败，别让退出码被管道吃掉
下面这行看起来没问题，其实是个定时炸弹：
cmd | sed 's/^/ /' && do_next_step
cmd 失败时，管道整体的退出码仍然是 sed 的（几乎总是 0），后续步骤照跑不误 —— 于是你把一次失败当成成功，继续往下走了。
解法：先落盘，再判断：
cmd > /tmp/out.log 2>&1
if [ $? -ne 0 ]; then cat /tmp/out.log; exit 1; fi
顺带一个好处：失败时的原始输出被完整保留，而不是被格式化器吃掉一半。
五、「重载 / 重启」是异步的，验证要留生效窗口
无论是配置重载还是服务重启，返回成功 ≠ 新状态已经生效。旧进程往往要处理完手头的活才退出，在这个窗口期内，新请求可能被旧进程接走。
表现就是：你检查发现「新配置明明已经加载了」，但实际操作还是旧行为 —— 然后开始怀疑自己的配置写错了。
解法：重载之后留一个短暂的生效窗口再验证；并且用「读回当前实际生效的状态」来判断，而不是靠一次即时请求。
一条可迁移的结论：把「异步动作之后的即时验证」整体归入「不可信观测」。
六、动手前先做「零改动探针」
要让 AI 改一个你没完全搞懂的配置或工具，先让它原样写回一遍，然后比对：
备份原文件 → 读取 → 原样写回 → diff 备份与新文件
如果 diff 为空，说明「读 — 改 — 写」这条链路是可靠的，可以放心改。如果 diff 有差异（常见于换行符、编码、字段顺序），先解决这个差异 —— 否则你改 A 字段时可能顺手把 B 字段弄丢。
这一条救过我一次：某个工具会把文件重新序列化，顺手抹掉所有注释。如果不做探针，我会以为「只改了一个字段」。
七、验证状态，只认权威来源
查任何带缓存的状态（域名解析、CDN、应用内存缓存），本机查询的结果都可能是中间缓存的旧值。
我曾经因为本机查询返回旧值，误判「对方没改」而白折腾半小时。清掉本地缓存之后，一切正常。
解法：直接问权威来源；本地与权威不一致时，以权威为准，问题在缓存不在事实。
八、报错先找「同源对照组」
看到报错的第一反应不该是「去修目标」，而是先问：是我的目标坏了，还是我的尺子坏了？
方法：拿一个已知正常的同类对象，在同一台机器、同一个 shell 里测一遍。如果它也报同样的错，那问题在观测端，不在目标。
这一步能省掉大量「修一个根本没坏的东西」的时间。
九、危险操作先备份，并分清「停止」与「销毁」
改配置、改数据、删文件之前，一句话备份：
tar czf /root/backup-$(date +%F).tgz -C /where target-dir
并且要分清：「停止」通常是可逆的，「销毁」通常不可逆。很多时候你以为在重启，其实在重建 —— 而重建会带走一切没落盘的东西。
十、先勘察，再动手
最坏的工作流是：「说要 X → 直接改 → 出事」。
正确的工作流是四步：
- 读现状（配置、状态、日志）
- 复述问题（我理解你要的是 X，当前是 Y，差异在 Z）
- 给方案与代价（几个选项、各自的副作用）
- 动手 + 验证（改完立刻验证，不留「待观察」）
勘察看起来慢，其实是唯一快的方式。
十一、长任务放后台，别阻塞
装依赖、拉镜像、跑全量扫描这类操作动辄几分钟。阻塞等待只会让会话超时、丢掉中间输出。
解法：后台执行 + 完成通知，把「等待」变成「并发」。同时要求它在任务结束时把关键结论写进日志文件 —— 这样即使中间输出丢了，也能回查结果。
十二、踩过的坑，必须写下来
这一条最重要。
AI 助手没有跨会话记忆。这次它花了三十分钟摸清「某个设置存在数据库而不是配置文件里」，下次它还会从头摸一遍 —— 除非你把它写成文档或流程。
我的做法：每个项目维护一份「为什么这么做 + 踩过什么坑」的记录，并把可复用的操作固化成脚本。一次踩坑，永久免疫。
小结
让 AI 做重复劳动，最大的风险不是「它不会」，而是「它太快了」—— 快到在你反应过来之前，就已经把错误操作执行完了。
上面 12 条，本质上都在做同一件事：给速度装上刹车和仪表盘。先勘察、先备份、先验证，再动手；改完必验，验完必记。
把这套纪律跑顺之后，效率提升是数量级的 —— 前提是你得先让它慢下来。