为什么AI生成的代码必须有人审？没事儿，这很正常

现在软件开发进入了一个超酷的时代。Claude、ChatGPT这些工具，还有专为AI设计的IDE，能让你几天内就把想法变成能跑的代码。从前得花好几周。现在你描述需求，接受diff，迭代几下，就能上线。速度真心飞起。

但有个坑。

前阵子我花一下午审了个这样的代码。一个内部小工具，不算核心业务，但挺能代表2024年大家怎么快速出活儿的。问题不是AI失控那种吓人的事儿。而是超级接地气的毛病：28个问题，大多安全漏洞，全是OWASP Top 10里从2000年初就挂着的旧账。

这不是AI危险的故事。这是速度太猛，安全思考跟不上的故事。

问题不在AI，而在你没问的问题

实话实说，那代码写得还行。架构靠谱，模块拆得好，库选得对。要是我周末自己搞，乍一看也差不多。

区别在更深层。就是写第一行代码前该想的事儿。

AI超棒地执行你的指令。你说“给我搞个用户管理系统”，它就给你整出来了。但它不会主动问：谁能访问？哪些数据敏感？认证放哪儿？前端被绕过咋办？

AI出功能，不出让你睡得香的安全架构。

真实案例：没防护的Admin接口

想象下：你app有个serverless函数，管admin操作——建用户、重置密码、删账号。常规操作。团队聪明地把强权限藏服务器端，没露给浏览器。

结果？这函数压根没认证。

不是认证弱，也不是认证错。就是零认证。谁打开DevTools，找到endpoint URL，发个POST，就能建admin账号、重置密码、炸用户库。

前端权限检查完美，非admin看不到按钮。设计时真心想安全。但没用——靠UI藏东西是假安全。

这是教科书级的授权绕过，2003年就上榜了。AI为啥没提？因为prompt是“给admin建用户功能的函数”。它建了，但没说非admin不能用，因为你没明确说不让。

核心点：AI不知道你忘了问啥。

数据库纸面上安全，实际漏风

再看个常见坑。你数据库支持row-level security（RLS），根据用户身份限读写行。靠谱模型，尤其前端JS里带API key时。

工程师让AI加多用户支持。AI写了migration，新表加了RLS。棒！

但五个老表——你的核心业务数据——没动。RLS开没开？migration没查、没开、没提。

新环境跑npm run db:push，新表铁板一块，老表随便谁上网知道API endpoint就能读。

AI没错。ただ不全。它只解窄问题（新认证表加RLS），没问你（全都要安全吗？）。

对你开发流程的启发

这不是反对AI开发。速度宝贵，快速迭代上线超值。但得有人审架构，不是只看语法。

有效做法：

先列安全清单。 问：谁能调这endpoint？没权限调咋办？数据能全世界读？每表都要RLS？写下来，别等到审代码才发现。

资深工程师做threat modeling，别一行行审。 我那28个问题不是打字错，是架构盲区。AI生代码，人想安全。

prompt里明确认证授权。 别说“用户管理endpoint”，说“只限登录admin用的用户管理endpoint，文档你的认证假设”。逼AI说出思路。

授权测试单独搞。 测非认证用户真做不了，不是只测认证用户能行。

关键模式要get

AI不生不安全代码。它超会按你说的生代码，烂在不提醒你忘问的。

这其实是优点——工具听话，不乱加需求。但责任推给你。你不是雇AI想安全，是雇它大规模执行你的安全设计。

我审的代码，就差人说一句“这个endpoint要认证”。说了，修几分钟搞定。20年老漏洞碰上2024快节奏，靠人盯着才赢。

未来几年模式：AI冲速度，人管架构。缺一不可。

想避开这些坑？ 在NameOcean，我们帮不少快长 startup 踩过快速上线的技术债坑。我们cloud hosting平台内置结构性安全——rate limiting、API key管理、audit logging，随用随有，不用你记着问。团队飞速ship时，一件少操心的事儿。