结论先行：10 月中旬公开的一起事件里，一支正在被持续攻击的团队用前沿模型协助调查，模型帮了一段之后开始拒绝处理他们提交的攻击材料。这件事值得记住的不是「模型不听话」，而是它暴露了一个设计缺口：把 AI 放进应急流程时，多数团队只设计了它正常工作的那条路，没有设计它不工作时怎么走完。

本文只谈应急响应里 AI 工具的可用性与退路，不谈攻击成本怎么算、也不谈暴露面怎么排序，那两件另文讨论。

那天卡住的不是网络，是流程

按公开披露的顺序：10 月 18 日，一家小型 AI 开发工具团队的联合创始人确认，团队在调查一起持续 48 小时的攻击时，用前沿模型分析攻击痕迹，模型先帮了不少忙，随后开始拒绝部分请求。他同时说明，团队当时刚拿到一个面向受审核防守团队开放的专门通道权限——几天前提交申请，前一天获批。

这不是孤立的一次。同一年的 7 月，另一起入侵事件的受害方在官方复盘里记录了几乎相同的过程：最初使用的模型拒绝了大量分析请求，连查看攻击日志都会触发限制；团队后来改为在自己的基础设施上部署开源模型，才把分析继续下去。

两件事合起来说明一个规律：越靠近原始攻击材料，越容易撞上限制。这不是谁的模型更好或更差的问题。

拒答不是故障，是产品行为

把这两类情况分开处理，后面的事才顺：

现象本质该怎么接
超时、限流、服务不可用工程问题重试、切换、降级，按可用性指标处理
拒答、要求补充说明、只给结论不给细节产品行为，由内容判定触发重试无效，只能换路径或换工具

为什么会被拦？原因不复杂：同一段攻击代码，防守方拿去分析漏洞，攻击方拿去谋划下一次入侵。只看这段代码本身，模型很难判断你是哪一种。一家头部模型供应商的开发者文档里也写明，合法的安全研究或防守工作，偶尔会被系统标记。

所以遇到拒答，下意识的动作不该是「再问一遍」。第二遍、第三遍得到的是同一个结果，而应急窗口里的时间正在流失。

应急路径里要有一条不依赖 AI 的走法

可行的设计是把应急动作分成两类，并保证每一类都有一条不依赖模型的通路。

其一，先把不需要模型的动作做完。确认受影响的账号与凭据范围、完成轮换、把原始记录与样本按时间线留存下来、把入口的应用与端口列出来。这几件事在任何时候都能做，而且做完之后，后面用不用得上模型都不影响基本盘。

其二，把「换个模型」当成一项预案，而不是临时找办法。上面的复盘里，团队最终是自己部署开源模型把分析做完的。这条路的前提是提前想过：有没有能自建的环境、算力够不够、谁能批、多久能起。临时找，至少要花掉半天。

其三，把长任务拆开，让模型少碰原始载荷。整段恶意代码直接贴进去，触发限制的概率最高。可行的做法是先在本地做摘要——哪些进程启动了什么、连了哪个地址、改了哪些文件——把结构化结论交给模型做归并与判断。既降低触发概率，也让结果更容易复核。

把「紧急时能不能用」写进评测项

选购阶段大家比的是能力上限，实际出事时决定成败的往往是能否在最需要的那一刻调用。建议在评测表里加三栏：

  • 内容判定触发的边界在哪，有没有面向防守场景的申请通道，申请周期多长。
  • 被拦之后可用的替代方式：是否有可私有化部署的版本、是否支持本地数据不出域。
  • 被拦时的提示是否明确——能看出「被拦」还是只能看出「没答」。这一项直接决定值班的人会不会反复重试。

三栏都不难问，难的是在没有事件的时候问。等攻击来了再问，问到的答案也用不上。

边界与前提

三点说明。其一，本文所述事件与过程取自公开披露（一家开源 AI 开发工具团队的联合创始人公开确认，以及同期另一家受害方发布的官方复盘），已隐去全部主体名称；其中关于触发原因的分析属编辑判断，不代表披露方立场。其二，文中未对任何模型或产品的安全性作评价，也未讨论安全护栏是否应该存在——那是另一个议题。其三，各平台的判定规则与申诉通道随时会变，具体以使用当时的官方文档为准。

深圳市奇摩计算机有限公司在为企业落 AI 办公与安全运营场景时，把「能力不可用时怎么办」作为上线前的交付件之一：哪些动作必须留人工通路、哪些能力要有本地替代、被拦之后由谁判断是否继续，都事先写清并演练一遍。预约咨询，可以先从你现有流程里最依赖 AI 的那一步开始盘。