最近科技圈出了个大新闻，看得我这做技术的心里直打鼓。

事情是这样的。亚马逊这几年不是一直在搞降本增效嘛，光今年1月就裁了1.6万人。裁员的同时，他们大力推行AI写代码——让内部那个叫Kiro的AI工具帮着工程师自动补全代码、自动生成函数，甚至直接修改系统配置。说白了就是想用AI顶上被裁掉的人。

一周之内，连续出了4起Sev1事故。我给大家解释一下什么叫Sev1事故：在亚马逊的事故分级里，Sev1就是最严重的那档，意味着核心系统宕机，关键功能全挂，用户没法买东西、没法查订单。这哪是Bug啊，这是直接砸饭碗。

其中最夸张的一起事故，网站和App瘫痪了将近6个小时。6个小时是什么概念？双十一要是崩6个小时，那损失得上亿。事后一查，说是部署了一个错误的代码——谁写的代码？AI辅助写的。

还有一起更吓人的。工程师让AI工具Kiro去修改系统环境，结果AI直接选了最狠的操作：把整个运行环境删了重建。虽然亚马逊后来解释说是工程师操作失误，不是AI的责任。但你细想，如果不是给了AI极高的权限，正常人谁敢点“删除重建”？

这事还没完。内部复盘会的材料里明明白白写着：过去几个季度，公司出现了一种“事故趋势”，其中一个因素就是“AI工具辅助的代码变更”。只不过开会前这条被删了，说是信息敏感。

肯定慌。他们紧急出了个新规定：以后AI写的代码，必须经过更高级别的工程师审批才能上线。说白了，就是给AI加了个“人工安全阀”。

但问题来了：如果每个AI写的代码都要高级工程师逐行审核，那AI带来的效率优势不就又还回去了吗？高工的时间全耗在“给AI擦屁股”上，哪还有精力干正事？

AI这东西，说白了就是个特别聪明但没有安全意识的孩子。它写代码快是真的快，改配置麻溜也是真的麻溜。但它压根不懂什么叫“核心系统不能动”，什么叫“这个变量改了会出事”。你让它写代码，它就拼命写；你让它改环境，它就往死里改。以前工程师写个错误代码，还得经过代码评审、测试环境、预发环境层层关卡，好几天才能上线。现在AI几秒钟就把错误怼到生产环境了——试错速度放大了100倍，出事的速度也放大了100倍。

更糟糕的是，亚马逊一边裁人一边推AI，团队被掏空了，剩下的人要处理比以前多得多的问题。以前出了事还有人盯着，现在人都没了，AI又跑得飞快，这不就恶性循环了吗？

所以我在想一个问题：既然AI写代码这么容易闯祸，那我们能不能换个思路——干脆别让AI写代码了行不行？

其实不是。问题的关键在于，AI的风险来自它直接操作那一行行裸露的代码。代码这玩意太灵活了，灵活到AI一不留神就能删库跑路。如果把代码封装起来，把那些危险的底层操作都锁进笼子里，让AI只能在笼子外面搭积木，是不是就安全多了？

这就是我最近在研究的一个方向。比如Eversheet这种平台，它的逻辑就是“用画表格代替编码”。你不需要写代码，只需要画画表格，把业务表单、流程节点拼起来就行。底层的数据库操作、系统环境配置、接口调用，全都被封装成现成的组件，你碰都碰不到。

你想想，在这种平台上，AI能干什么？它能帮你快速搭一个表单，能帮你优化一下流程顺序，但它能删掉整个运行环境吗？不可能，因为根本没那个按钮。能直接修改服务器配置吗？也碰不到，因为权限被平台锁死了。AI就算再“激进”，它的破坏力也被限制在业务层——最多就是某个页面配错了，不会让整个核心系统瘫痪。

这不就两全其美了吗？AI的“快”保住了，AI的“险”被平台封死了。而且不需要高级工程师逐行去审代码，因为没有代码可审，全是现成的组件。

亚马逊现在搞的那套“人工审核AI代码”，说白了还是在传统模式上打补丁。代码还是那些代码，风险还是那些风险，只是加了人工审核。但审核多了，效率没了；审核少了，事故又来了。

而像Eversheet这样的无代码平台，是从根子上把问题解决了——让AI根本没机会碰那些危险的东西。

亚马逊这次栽的跟头，对所有想用AI降本的企业都是一个提醒。AI是工具，不是万能药。你用对了，它是帮手；你用错了，它就是隐患。关键是别让它在核心系统里裸奔，给它画个圈，圈里随便跑，圈外别想碰。

这，或许才是AI落地的正确姿势。

对此，您怎么看？非常欢迎您在评论区补充观点或者干货。

文｜表妹