AI产品核心功能跑通后，做好这3件事才能上线！

一、全文速览图

现在很多 AI 产品的首页，看上去都差不多：中间放一个大输入框。

用户输入一句话，挂一张图片或者一份文件，剩下的事情交给 AI 完成。这种交互有个名字，叫 LUI，也就是 Language User Interface。

即梦现在的创作页就是一个很典型的例子。

站在用户这边看，它就是一个上传入口加一个输入框。只把这个界面画出来，代码可能并不多。真要放到线上，麻烦的全在后面。

最后到底是七八百行还是上千行，取决于框架和实现方式。但增加出来的大部分东西并不是这个框，而是后面那一堆用户看不见的判断。

上传一张 21:1 的图片，接不接？

图片很模糊，还能不能进入后面的生成任务？

上传的是 PDF，系统能不能解析？

文件有 10GB 怎么办？

一次上传几十份文件怎么办？

内容涉及色情、暴力或者其他违规信息，又应该在哪一层拦住？

这里面至少有格式、大小、比例、分辨率、清晰度、数量、内容安全和解析状态等多层校验。后面还连接着文件存储、内容审核、模型调用、失败重试和费用计算。

所以输入框变简单了，不代表产品也变简单了。很多原来能写在页面上的限制，现在全被推到了后台。

用户看到的是“我可以让它做什么”。

产品团队还要回答另一半：什么情况下，系统必须拒绝。

二、产品面对的，从来不只是预期用户

我们之前做一款模拟面试产品时，设计的流程很清楚：用户选择岗位，AI 提问，用户回答，系统继续追问，最后生成评价。

把这条核心链路跑通，产品看上去就已经能用了。

真正交给用户后，有人一上来就试探系统提示词，有人根本不面试，直接和 AI 聊失恋，还有人发送色情内容，看模型会怎样回答。

这些行为不全是攻击。

聊失恋是偏离场景，发送违规内容是内容安全问题，套取系统提示词更接近对模型边界的试探。

它们不是一类问题。

但最后都会把产品逼到同一个问题上：我们只设计了用户应该怎样使用，却没有想清楚用户不这样使用时，系统怎么办。

还是拿上传来说。

一个正常用户上传了不符合要求的大文件，可能只是一次产品异常。有人连续上传几百个超大文件，不断触发解析和模型任务，就是在滥用正常功能。如果提交的是专门构造的恶意文件，目的是寻找解析漏洞，这就不是异常处理了，而是主动攻击。

所以不一定要多出一个新入口才会有危险。同一个正常功能，换个频率、规模和意图，风险就完全不一样了。

我上一篇写 0-1 和 1-N，重点是产品上线以后怎样持续迭代，怎样继续变好。

这一篇其实是往 1-N 里面再拆一层：产品得先扛过这些事，才有机会进入第二版。

而且安全、限损和恢复也不是做完 1-N 以后再补。产品准备公开内测时就要开始做，后面还得一直补。

三、产品还没几个用户，攻击已经先到了

我们在做 Lollipop 时，从刚开始内测就持续遭受扫描和攻击。

产品还没赚到钱，也没抢谁的生意，为什么会有人盯着它？

后来我们回查了一台对外服务器大约 32 天的认证日志和访问日志，重新统计出约 125 万条与连接探测、密码尝试和 Web 扫描有关的日志事件。

这个数据我稍微解释一下啊。

125 万不是 125 万个攻击者，也不能直接理解成 125 万次相互独立的攻击。一次 SSH 连接可能同时留下连接探测、密码失败和无效用户名等多条记录。它证明不了有 125 万人在盯着我们的产品。

所以并不是说一个产品做成功了才会有人攻击。

你的产品可能还在起步阶段，甚至都没有用户，扫描和攻击就已经来了。

日志里既有大量 SSH 连接探测和密码爆破失败，也有对.env、.git、各类.php 路径的探测，还有带着常见扫描工具特征的访问。

对方未必知道 Lollipop 是什么，也不关心它有没有收入。很多攻击本来就是自动化的：扫描一批 IP 和域名，寻找开放端口、弱密码、暴露文件和已知路径，撞不中就换下一个，撞中了再决定这台机器能拿来做什么。

一台机器一旦被拿下来，可以用来拿数据，也可以用来偷算力、继续扫描，或者成为下一次攻击的跳板。

所以，“我这么小，谁会攻击我”这个问题本身就不太成立。

自动化程序不会先研究你的产品值不值得攻击。只要服务暴露在公网，它就可能被塞进同一批扫描任务里。

后来我们确实一直在打补丁、加强防火墙。但回头看，补丁和防火墙只解决了其中一层。网络入口挡住了一部分流量，产品内部的权限、资源和模型动作，仍然要靠业务自己定义。

四、攻击借用的，往往就是产品自己的能力

有些攻击甚至都不会进入产品逻辑，它们先在外面批量试门。

它们寻找的是开放端口、常见后台、暴露配置、弱密码和已知漏洞。这类问题通常发生在服务器和网络层，也是防火墙、WAF、补丁和安全配置最先处理的地方。

再往里，是绕过页面直接调用接口。

页面上没有按钮，不代表能力不存在。普通用户只能查看自己的任务，如果修改一个任务 ID 就能读取别人的数据，问题不在页面有没有藏好，而在服务端没有再次确认：当前账号是谁，这份数据属于谁，他有没有资格执行这个动作。

还有一些攻击根本不需要拿下服务器。它只要把产品的正常能力用到失控。

AI 产品的一次请求，后面可能连着文件解析、向量检索、模型推理、图片生成和第三方服务。有人批量创建任务、提交超长内容或者反复触发重试，最后不一定偷走数据，却可能让模型费用持续上涨、队列被占满，正常用户反而用不了。

OWASP 把这类问题称为“不受限制的资源消耗”。它特别提醒，上传大小、执行时间、单次操作数量和第三方服务支出都需要限制，因为简单的 API 请求就可能被并发放大。

到了 AI 产品这里，还得多防一件事：模型手里开始有工具了。

当模型可以读取网页、文档和知识库，还能发送消息、修改数据或者调用内部工具时，恶意指令可能藏在用户输入或外部内容里。问题也不再只是模型答错一句话，它可能真的替用户做了原本不该做的事。

OWASP 把这种情况叫作“过度代理权”，常见原因就三个：

功能给得太多，权限给得太大，模型自己决定的空间太宽。

放到产品里，就是模型不需要读的内容不要给，不需要调用的工具不要挂，高影响动作不要只靠模型自己决定。

五、你能用 AI 做产品，别人也能用 AI 提高攻击的试错速度

其实网络攻击早就自动化了。扫描、撞库、漏洞探测和蠕虫传播，一直都可以按预设规则批量运行。

AI 现在又让这套流程多了一点判断和调整能力。

最近的预印本《AI Agents Enable Adaptive Computer Worms》把本地开放权重模型、Agent 工具链和传统网络蠕虫组合到了一起。

程序可以观察目标环境，选择攻击路径，失败以后读取反馈，再调整下一步。

研究团队在一个由 33 台 Linux、Windows 和 IoT 设备组成的隔离网络里做了 15 次实验。

每次让系统自主运行 7 天，平均取得 23.1 台主机的高权限，并传播到 20.4 台主机。

不过，这个实验不能直接套到现实互联网。

实验环境里的每台目标都预先存在至少一个可利用问题，没有部署 EDR 等主动端点防御，脆弱主机的密度也高于真实生产网络。所以我不会把它写成“AI 蠕虫已经在现实里大规模传播”。它至少说明，这种“观察、执行、反馈、再调整”的组合已经可以跑起来了。

我觉得产品团队更应该警惕的是，攻击者反复尝试的成本还在下降。

以前脚本遇到不同系统、不同报错和不同配置，可能只能停止，或者等人重新改规则。接入模型以后，其中一部分环境理解、方案生成和失败调整可以继续自动运行。

你能用 AI 更快地做产品，攻击者也能用 AI 更便宜地理解入口、生成变体和反复试错。

六、防守不是多装一道墙，而是把拒绝条件写进产品

很多团队谈到安全，第一反应是加强防火墙。

防火墙和 WAF 当然重要。我们自己遇到攻击以后，也确实做了这类加强。但它们主要处理网络连接、异常流量、扫描和一部分已知攻击。

它们不知道一个模拟面试用户为什么连续创建几百场面试，不知道当前账号有没有资格查看某份报告，也不知道模型能不能读取一段内部资料、调用某个工具。

防火墙处理的是流量，产品仍然要回答自己的业务规则。

如果只能做一轮检查，我会先从产品里找三类动作：

1. 最贵的动作：模型生成、文件解析、图片和视频处理、付费第三方调用；
2. 最敏感的动作：读取用户数据、下载报告、访问内部资料；
3. 最难撤回的动作：发送消息、修改数据、支付和删除内容。

同一个动作可能同时属于三类。越贵、越敏感、越难撤回，越应该优先检查。

找到关键动作以后，不需要先背完所有攻击名称。对着每一个动作，问清三个问题就够了：边界在哪里，上限在哪里，退路在哪里。

七、边界在哪里：什么能进入，谁能让系统做什么

先看输入。

文件格式、大小、数量、比例、分辨率和内容审核，应该尽量发生在昂贵处理之前。不符合要求的内容，能在上传或解析前拒绝，就不要等文件存完、模型跑完、费用产生以后再报错。

再看身份、对象和动作。

一次读取报告的请求，至少要检查当前账号是谁、报告属于谁、当前账号能不能读取，以及他要执行的是查看、下载还是修改。页面把别人的报告藏起来，只能说明界面没展示。权限一定要在服务端再校验一次，不能只靠前端藏按钮。

模型和工具也一样。

模型不需要读的数据，不要塞进上下文；不需要调用的工具，不要挂给它。系统提示词也不应该被当成存放密钥、内部地址和敏感规则的保险箱。

即使模型判断应该调用某个工具，服务端仍然要重新校验这次动作是否被允许。模型可以提出动作，不应该成为最终的权限系统。涉及发送、修改、支付和删除时，还要根据影响增加用户确认或人工审批。

边界是否生效，不能靠“页面上已经没有入口”来验收。要用低权限测试账号绕过页面直接请求接口，确认服务端确实拒绝、响应里没有目标数据，日志还能记录拒绝原因。

八、上限在哪里：一次异常最多能造成多大损失

每一个昂贵动作都应该有上限。

上传入口要限制单个文件大小、文件数量和单次处理量；接口要限制一定时间内的调用频率；模型要有 Token、次数和费用额度；任务队列要限制同一账号的并发数；失败重试也要有次数和总时长，不能无限循环。

这些阈值不能靠“正常用户应该不会这样用”来决定。它们要结合真实使用基线、套餐权益、单次成本和系统容量设置，再随着上线后的数据调整。

上限也不一定只有一个数字。接近阈值时可以提醒，继续增加时可以排队或者降级，达到硬上限后必须停止。

验收时要确认，超过测试阈值以后，系统是在模型或第三方服务调用之前停下来的，调用次数和费用不再继续增长；一个测试账号持续创建任务，也不能拖慢其他正常账号。

限损不是保证异常永远不发生，而是先把一次异常最多能吃掉多少资源定下来。

九、退路在哪里：出事以后能不能看见、停住并恢复

校验做得再细，也不可能提前覆盖所有问题。

第三方模型会超时，密钥可能泄露，新版本可能带来新的权限问题，原本正常的功能也可能突然被批量滥用。

所以日志至少要能回答：谁在什么时间发起了请求，访问了什么对象，执行了什么动作，消耗了多少资源，最后是否成功。

告警不能只负责“发出来”，还要明确谁来接、什么情况下升级、负责人不在线时谁接手。

模型调用、文件解析、工具调用和第三方服务最好能够独立暂停。出现问题时先关掉风险最大的能力，不要让整个产品只能一起下线。

费用也要有告警和熔断。密钥泄露后要能及时撤销并替换。涉及数据修改的动作，还要提前考虑怎样回滚，恢复服务以后怎样避免重复执行、重复计费和数据错乱。

这些东西都要演练。

测试告警能不能真的找到负责人，功能开关能不能停止新任务，权限能不能撤销，错误数据能不能回滚。没有被实际按过的紧急开关，只是一份心理安慰。

十、把三个问题写进一张行动卡

这张卡不是让产品经理自己去做渗透测试，更不是让人越过安全边界去测试别人的系统。产品经理要做的是把边界、上限、退路和通过标准写进需求与验收，再和开发、测试、运维、安全一起把它们做出来。

如果团队没有现成的安全检查流程，可以从一张空白卡开始。对产品里每一个最贵、最敏感或者最难撤回的动作，填一张。

关键动作
它为什么需要优先检查：最贵／最敏感／最难撤回

边界
什么输入可以进入，什么必须拒绝
谁可以发起
可以访问什么数据、操作什么对象
身份、对象和动作由哪一层校验

上限
单次、并发、频率、重试和费用上限
接近上限时怎样处理
达到硬上限后在哪里停止

退路
需要记录哪些日志
什么情况触发告警，由谁处理
怎样单独关闭这项能力
怎样撤销权限、替换密钥并恢复服务

验收
用什么测试账号、合成数据和临时阈值验证
什么证据能够证明控制已经生效

这些测试只应该在团队自己的测试环境中进行，使用测试账号、合成数据和临时阈值。不要拿生产用户数据验证风险，也不要把主动攻击别人的系统理解成“做一下产品验收”。

上一篇文章最后问，产品有没有第二个版本。

这一篇想补上前面那个问题：它有没有机会活到第二个版本？

现在用 AI 做出一款产品越来越快，但跑通只代表成功路径有了。错误输入能不能拒绝，恶意调用能不能限住，真的出事以后还能不能停下来、恢复，才决定它能不能上线。

做出来已经越来越便宜了。

一个产品能活下来，本身就是门槛。