业务同事写的AI工具,上线前过三关

上个月，一家做办公家具地公司，行政用 AI 写了个查库存的小页面。挂在内部群里，二十几个人天天在用，比翻表格快多了。

上周他们老板突然问了一句：这个东西要是被公司外面的人打开，会怎么样？

群里安静了几分钟，没人答得上来。

不是因为大家不懂技术。是从把它挂上去那天起，就没有人问过这个问题。

误会在哪

大部分人对这类工具的判断标准，是「能不能跑」。跑得通、结果对、点着顺手，那就用。

这个标准在 AI 之前勉强成立。以前愿意写这种内部小工具的人，多少懂一点，知道密钥不能写在能被看到的地方，知道对外要加个登录。

现在不一样了。2026年一份行业调研里有个数字很说明问题：vibe coding 的用户中，63% 并不是开发者。市场、销售、运营岗位的人，正在和工程师一起往代码库里提交东西，而且往往没有任何评审环节。

这两拨人不是一回事。

Stack Overflow 2025年的开发者调查更直白：84% 的开发者在用 AI 写代码，只有 33% 信任它写出来的东西。

用的人最多，信的人最少。这就是当下的状态。

真正的风险不在「跑不通」

很多人以为 AI 代码的问题是写错、跑挂。其实跑挂是最温柔的一种失败，因为你当场就知道。

真正麻烦的是那种跑得特别顺、但底子是空的。Veracode 2025到2026年的报告里有个数字：约 45% 的 AI 生成代码带有 OWASP Top 10 那一类已知漏洞，而且两年过去，这个比例没有明显改善。模型换了一代又一代。语法越来越漂亮，安全性基本停在原地。

CodeRabbit 的研究给出过另一个角度：AI 生成代码出现漏洞的概率，大约是人工代码的 2.74 倍。

fig-1

所以判断标准得换。不是问「它跑得通吗」，是问「它凭什么敢上线」。

三层，第一层是闸门

我们给内部工具定了一份三层检查，按先后顺序走。

第一层是上线阻断项，不过就不给上，没得商量：

第一层是闸门，因为它决定的是「出事是不是立刻就出」。这三条里任何一条不满足，剩下的都不用查了，先修。

第二层是在给真实用户用之前：输入做了校验、依赖包检查过、关键接口有限流。这一层出问题不会立刻出事，但会积累。

第三层是长期的，也是大多数公司省掉的：每次改动自动跑一遍扫描和密钥检查，再配一个季度一次的人工复核。自动扫描能拦住大部分重复的错误，拦不住逻辑上的错。

fig-2

一个反直觉的例子

最值得说的是依赖包这个坑。

有研究专门测过一件事：AI 推荐的软件包里，约 19.7% 根本不存在。更麻烦的是，这些编出来的假名字里约 43% 会在多次运行里重复出现，同一个人问两遍，它可能给你同一个不存在的名字。

有人专门盯着这个。他们把这些名字批量注册下来，塞进真正的恶意代码，等你哪天照着 AI 给的命令去安装，就装上了。

我们自己的办法很土：AI 给出的安装命令，先去官方源站搜一遍这个包名，确认存在、确认维护者，再复制粘贴。多花二十秒。

还有一件反直觉的事是关于密钥的。很多人发现密钥写进代码里的第一反应是把它删掉，然后重新提交一次。没用。GitGuardian 2026年的数据说，2022年有效的那批密钥，到2026年还有约 64% 是可以用的。

删代码不会让已经泄露的密钥失效。得去后台吊销，再换新的。顺序别搞反。

什么时候不用查这么细

也得说清楚边界。

只在你自己电脑上跑一次、处理的是公开数据、用完就删的脚本，查一遍第一层就够了，不用上三层。

反过来，只要这个工具会被两个人以上长期使用，或者碰到了客户资料、价格、成本，三层都要过。中间没有模糊地带。

还有一类我们建议直接别自己写：涉及支付、登录、身份证号这类信息的。不是说 AI 写不好，是这类东西出了事，你连「谁来负责」都说不清。

回到那家办公家具公司

他们后来把那个页面下掉了，改成加一层内部登录之后再挂回去。整个改动不到半天。

真正花时间的是另一件事。行政把当时写页面用的那段提示词翻出来重新跑了一遍，发现 AI 给出的第一版里带着一个「方便调试」的开关，任何人访问某个地址，就能看到全部库存和进货价。

她当时觉得没用，顺手删掉了。

删掉是对的。但她自己说，删掉的原因是「看着碍事」。

后来他们把这份三层检查打印出来贴在工位上，第一层那三条用红笔圈了。现在公司内部再有人用 AI 写工具，必须先过红圈，才能往群里发链接。

※ 本文由 AI 辅助整理，案例与判断均来自一线实操，仅供参考；落地到具体业务请以专业意见为准。