用 AI 写代码一年多，交出去的比例一直在涨。但有三类工作我始终自己做，不是还没轮到它们，是明确不交。
这条线比"AI 能干什么"更值得写。能力清单每隔几个月就过期一次，而边界为什么在这里，理由是稳定的。
第一类：架构设计
不是说 AI 给不出架构方案——它给得出，而且通常看起来很合理：分层清晰、职责分明、扩展点齐全。
问题在于合理的方案可能是错的。
架构决策依赖两样东西：对业务往哪走的判断，以及对历史包袱的了解。前者在我脑子里都未必清楚，更不在上下文里；后者是一堆"当初为什么这么做"的历史，散落在几年的提交记录、废弃的分支、和某次线上事故之后加的一个 workaround 里。这些东西没法塞进对话。
于是会得到一个技术上自洽、但在具体处境里错误的方案。它不违反任何原则，只是不适合这个项目。而这类错误的代价是最高的——写错的函数改起来是几十行，选错的架构改起来是几个月。
我的做法是：架构自己定，定完让 AI 挑毛病。让它扮演一个不了解历史的新人来审——它确实就是。它提的问题里，一部分是我已经权衡过的（那说明我的文档没写清），一部分是我真的漏了。这个用法比让它出方案有价值得多。
第二类：它试了几轮还没解决的问题
这一类不是按任务性质划的，是按过程判定的。
同样是"修一个 bug"，有时候 AI 两三轮就搞定，有时候十轮还在原地打转。而事前看不出区别——难点常常不在描述里。所以先验分类没什么用，我改用一个事后判据：给它固定几轮，不收敛就自己接手。
不收敛的样子挺好认：反复改同一处、每轮都给一个新解释但都不对、或者开始建议重写一些明明无关的代码。最后那个信号最明确——它在扩大搜索范围，因为在原范围里已经找不到解了。
这时候接手，第一件事不是自己从头写，而是找它缺的那条信息。多轮不收敛几乎总意味着关键事实不在它能看到的范围内：一个没被提及的环境差异、一份没给它的日志、一个只有我知道的历史约定。补上那一条，往往剩下的它自己就能做完。
真正需要我从头写的情况很少。绝大多数"AI 搞不定"其实是"我没给够"。
第三类：极高风险操作
发版、删数据、改生产配置。
这三件事的共同点不是难，是不可逆且影响面大。判断的依据不该是 AI 做得对不对——它大概率做得对——而是做错一次的代价。一个函数写错，测试会拦住，最差是回滚一个提交。一次删错数据，回滚的对象是用户的东西。
这里面的不对称很关键：AI 在这类操作上的正确率可能比我高（它不会漏步骤、不会记错顺序、不会因为做过一百遍就跳过检查）。但正确率高不代表可以授权，因为失败的代价不由它承担。
我确实有过一次事故：AI 删掉了数据。恢复它靠的是备份——我一直在做大量备份，那次照常有一份可用的。
事后我想的不是"以后要更小心"，而是另一件事：如果那次没有备份，这个边界就根本不存在。我之所以敢把大部分工作交出去，前提是错了能回来。没有兜底的授权不是信任，是赌博——而赌赢过几次的人最容易把它误认为信任。
所以这条边界真正的支撑不是我不让 AI 碰这些操作，而是我在它碰得到的地方都留了退路。前者是纪律，后者是基础设施。纪律会松，基础设施不会。
三条线的共同点
回头看这三类，划线的依据其实是同一个问题：出错的时候，谁能发现，以及能不能回来。
- 架构错误：很晚才能发现，而且几乎回不来
- 多轮不收敛：立刻能发现（它自己在原地转圈），随时能回来
- 高风险操作：可能立刻发现，但回不回来取决于有没有备份
中间那一类之所以可以交给 AI 试，正是因为它失败得很明显、很便宜。而另外两类，一个是发现得太晚，一个是回不了头。
这个判据比"哪些任务适合 AI"更耐用。任务类型会变，模型能力会涨，但"错了能不能发现、能不能回来"这两个问题永远得先答。
■