GitHub Security Lab 研究者 Kevin Stubbings 介绍，他用开源 Taskflow Agent 为 Android 应用设计分步审计任务流，先辨认移动端入口点，再针对组件检查相应漏洞类型。截至文章写作时，团队称已发现并报告 24 个 Android 应用漏洞。文中展示的 OsmAnd 和维基百科 Android 应用案例，分别涉及导出组件处理外部传入参数，以及深链和 WebView 的逻辑问题。

这不是让模型独立给漏洞定论的流程。作者指出，模型会报告现实中很难触发或严重性较低的问题，也可能忽略缓解因素而误判影响，因此每项发现仍需熟悉移动应用的安全研究者复核。运行任务流还需要 GitHub Copilot 许可证，会消耗高级模型请求；对中等规模代码库，文章给出的运行时间约为一到两小时。

X 用户 Khazix0918 自称是“纯外行”，表示折腾三天后完成 AIHOT 重写并上线。他描述的过程不是把旧代码一次性交给模型：先用两个模型整理旧项目功能与交接资料，再用另一个模型对照旧代码找遗漏；重写后，又让模型审查新旧项目的功能、逻辑和用户体验差异，并继续修复。

上线前，作者称导出了旧项目数据库，进行了线上服务器彩排和六小时影子系统并行，之后做端到端测试、切换上线与持续监控。这是一位项目作者对自身小项目的流程记录；帖文没有提供独立测试结果、故障率或长期运行数据，不能据此认定重写已完整复现旧系统，也不能推广为普遍适用的交付周期。

Perplexity CEO Aravind Srinivas 在 X 上介绍公司对 SPACE 沙箱的红队自测：团队让九个模型取得虚拟机内的 root 权限，部分运行还提供沙箱源代码，并尝试逃到宿主机或访问网络策略封锁的网址。他称，108 次运行中没有模型逃出虚拟机；但当测试允许连接 PyPI 和 Ubuntu 镜像以安装软件包后，四个模型成功触及被封锁的网址。

帖子描述了 DNS 响应与共享 IP、借外部图片抓取服务访问目标两类路径，并称团队已修复、复测。这里要区分两种边界：没有观察到 VM 逃逸，不等于网络访问策略同样守住了。以上均为公司负责人对其测试的表述；所链接研究未核读，不能据此评价所有部署环境或其他沙箱提供商的安全性。