AI 写代码的适用边界
AI 适合写样板代码、一次性脚本、测试用例、已知模式的 CRUD，这些错了容易发现、后果可控。但代码世界里有几类「不该」交给 AI 直接写，不是它写不出，而是写错了你未必看得出，等看出时已经出事。把场景分清楚，比一味追「全交给 AI」安全得多。
不该让 AI 写的情况一：安全相关逻辑
鉴权、加密、签名校验、权限判断这类代码，一处疏漏就是整个系统的后门。AI 生成的代码往往「能跑」但未必「正确」，比如少验一个签名、把密钥写进日志，肉眼不仔细看根本发现不了。安全逻辑必须经人逐项审，不能让 AI 一把梭，这是底线中的底线。
不该让 AI 写的情况二：你不懂的业务核心算法
如果一段算法你自己都讲不清原理，就别让 AI 写然后直接上线。你没法审，等于把正确性完全押在 AI 不犯错上。正确做法是：先自己搞懂，再让 AI 辅助实现，或者请懂的人 review。用 AI 补你懂的部分省力，用它补你不懂的部分埋雷。
不该让 AI 写的情况三：需长期维护的底层架构
AI 给的代码片段常能跑，但不一定符合你项目的整体架构与演进方向，堆积多了技术债沉重。底层架构、公共模块这类「写好要管很久」的东西，该人定方向、AI 填细节，而不是让 AI 凭空决定结构。否则半年后没人看得懂当初为什么这么写。
不该让 AI 写的情况四：合规敏感的数据处理
涉及个人隐私、支付、医疗健康的数据处理，错一处就可能是合规事故。这类代码对准确性、合法性要求极高，AI 不知道你的合规约束，生成的写法可能踩线。敏感数据处理必须人把关，把规则写进代码并留审计，不能交给黑盒生成。
判断标准：你会不会审
一条最实用的准则：这段代码如果出 bug，你能不能自己发现并定位？能审，就敢用 AI 提效；不能审，就自己写或请人写。AI 是放大镜不是替身，它放大你的能力，也放大你的盲区，盲区那部分必须由人来填。
一个翻车案例
某团队让 AI 写支付回调处理，AI 给的代码漏了回调验签、默认 trusts 请求来源，上线后一段时间静默丢单、对账才发现有异常，回溯发现是验签那行被简化掉了。事故不轰轰烈烈，但每一笔丢单都是真金白银。如果当时让人审一遍安全逻辑，这一行本该被拦下。省下的那点写码时间，赔进去的是客诉和信任。
边界：不是不用，是分场景
说「不该」不是反对用 AI 写代码，恰恰相反——低风险、模式化、你能审的，放心交给它提速；高风险、你不懂、合规敏感的，自己或请人把关。把 AI 当实习生用：交代清楚、审一遍产出、关键处复核，它极有价值；当甩手掌柜，它就变成风险源。分场景用，才既快又稳。
实操：AI 写码的安全护栏
真要 AI 辅助写敏感代码，加三道护栏：一是分层，安全核心人写、周边 AI 填；二是强制 review，AI 产出一律过第二双眼睛，尤其验签、鉴权、异常处理这三处；三是补测试，把边界条件写成测试用例跑一遍，让 bug 在提交前暴露。护栏不是不信任 AI，是把它的不确定关进可验证的笼子里，既享受提速又兜住底线，团队越大这道栏越不能省。
局限声明
代码安全责任因项目、行业、合规要求而异，本文基于通用工程经验。涉及金融、医疗、政务等高合规领域，关键代码请以团队规范与专业评审为准，AI 生成代码务必经人工安全 review，本文不替代安全审计流程。