不是AI不够聪明，是我还没资格当它的甲方

外包给AI，我也短暂做过这个梦。

程序员圈子有个流传很广的段子：美国程序员把活儿按三分之一的价钱转包给国内同行，自己躺着拿走剩下三分之二。前阵子我盯着手头一堆自动化任务，数据整理、脚本调试、公众号选题这类活，也冒出过类似念头：既然AI能写代码、能查资料、能给建议，那我是不是可以把自己从干活的挪到甲方的位置，喂给它任务，自己收钱就完了。

真正试了才发现，卡住我的不是AI给不出建议，是它给出的建议根本不是一条，是一堆，而且经常互相打架。

今年8月初一个晚上，我照例打开个人知识库的后台想核对当天的入库记录，扫了两眼日志就愣住了：同一条内容被重复写了好几遍。顺着代码往回查才发现，判重逻辑依赖一个检索端点，这个端点会偶尔返回404。系统当时的处理方式是"查不到就当没重复，允许写入"，一个听起来很稳妥的容错设计。但这条降级不阻断的默认结论，恰好是最宽松的那条路：端点一旦失效，所有内容都会被判定成可以新写，于是同一批内容被连续好几周重复写进库里，系统全程返回200，没有一次报错，直到手动核对才发现问题。

这件事让我想明白一点：AI（或者任何自动化系统）给你的从来不是一句话的答案，是一整套彼此制约的建议。"容错优先，别让系统一上线就动不了"和"精确判断，别让降级路径变成新的默认坑"这两条建议本身都没错，只是适用的时间点不一样。前者该用在系统刚跑起来、边界还没摸清的阶段；后者该在系统跑稳之后立刻补上，去检查那条容错路径有没有偷偷变成谁都不用负责的兜底。把该用在后面的那条，当成现在就能一劳永逸的答案，问题一个都不会少，只是延后爆发。

真正能把活儿甩给AI、自己腾出手的人，差的不是技术比我硬，是他们养成了一个习惯：收到两条互相冲突的建议时，先不选，先把它们摆到时间轴上——这条解决眼前这个报错，那条留着系统跑稳以后再处理，分开落地，而不是照单全收，也不是干脆都不信。少了这一步，给再多AI，也只是让手忙脚乱来得更快一点。

我现在改自动化脚本，多了一个笨办法：AI给出建议时，先写一行注释标上"现在改"还是"以后改"，再动手。不优雅，但至少不会再把一个容错设计的默认结论，当成问题已经解决的终点。

下次AI甩给你一堆互相矛盾的建议时，先按时间标好这条现在用、那条以后用，再动手改——比纠结这个建议靠不靠谱管用得多。