AI 编程的禁区：什么绝不能交给 AI？

系列导读：本篇是「AI 编程进化论」系列的第五篇，也是第一部分的终章。前四部分我们探讨了思维转换、工具挑选、工作习惯及团队实施，至此，我愈发想将焦点收回： 了解 AI 的能力固然关键，但明确它**不该**做什么，更为重要。

第一篇我们谈论了 Vibe Coding，描述了一种强烈的体验：当编程不再总是依赖“痛苦思考”，许多实现变得前所未有地迅速。这无疑是进步。

然而，在系列结尾，我意识到真正的问题已不再是：AI 能否编写代码？而是：什么任务**不能**放心交给 AI？因为“能写出来”与“能承担责任”是两码事。“能生成”并不等同于“能理解”。若边界不清，AI 越强大，团队越容易遭遇事故。

如今的 AI 编写 CRUD、补充测试、修改组件或附带文档已不罕见。核心问题不在于它“能不能写”，而在于它能否承载代码背后的实质。我认为至少有四件事是当前 AI 无法稳稳接住的。

AI 可以写出代码，但它并不真正理解：为何选择此方案而非彼方案。要求其编写密码校验函数，它虽能完成。但若追问原因，其回答往往只是“像答案”，而非深思熟虑的判断。因此，AI 可以实现逻辑，但不能替你对设计决策负责。

许多人被“长上下文”迷惑，以为窗口足够大就等于模型记住了整个项目。其实不然。现实中常见的是：...（保留原文省略号逻辑，或流畅过渡）。不要指望 AI 承担长期连续的项目记忆。主动管理上下文仍然是人类的责任。

AI 很擅长解决局部问题。例如，让其优化 API，它会建议增加缓存、修改查询或更换数据结构。这些建议本身或许正确。但系统的难点从来不仅仅是局部最优，而是全局权衡：此类问题不仅是技术问题，还涉及技术、业务、组织和成本的交织。而这正是当前 AI 很难真正接住的部分。

这是最核心的一条。AI 可以写代码，但它不能：归根结底，工程不仅仅是“写出代码”。它还包括风险判断、上线责任、安全兜底和长期维护。这些，AI 都无法接手。因此，真正的边界不在于 AI 能否编写，而在于：它能否对后果负责。答案很明确：不能。

如果将上述边界具体化，我会将“AI 禁区”分为三类。这些任务并非不能让 AI 参与，而是不能将主导权交给它。例如：支付、结算、对账、计费、退款。此处哪怕微小的 bug 都可能直接导致经济损失。

例如：密码存储、权限验证、Token 验证、加密解密。AI 可以生成“可运行”的代码，但“可运行”与“安全”之间差距甚远。例如：隐私数据处理、日志留存、数据访问控制。这些地方不仅需要技术正确，还涉及制度与法律责任。

例如：医疗、航空、军工、自动驾驶、高危工业控制。在这些领域，AI 仅能起辅助作用，不应成为主导。此类任务并非完全不能触碰，而是必须明确：AI 提供的是初稿，而非定稿。

例如：复杂的业务逻辑、高度定制的系统架构、维护成本极高的项目。在此处，真正决定质量的不只是代码实现，而是业务逻辑、系统设计和长期维护成本。这些场景，我认为非常适合让 AI 多做些工作：

关键不在于一刀切地问“该不该用 AI”，而在于分清：何处可以大胆借助力量，何处必须亲力亲为。如果说前面讲的是“什么不该交给 AI”，那么再深入一点，其实就是另一个问题：AI 越强，人类究竟该守住什么？我越来越倾向于一个判断：AI 不会彻底剥夺程序员的价值，但会改变...