不只用内置 AI：把蜂控开发文档交给自己的 AI，让它操作设备

可以。蜂控不要求所有设备任务都只能由内置 AI 发起。你也可以把客户端的开发文档交给自己的 AI 助手，让它通过蜂控 Local API 查询设备、调用已支持的操作，或提交脚本运行任务。

前提是这个 AI 的工作环境能够读取文档，并在蜂控所在电脑上发起所需请求。例如使用 Codex 这类 AI 助手时，要确认当前环境实际具备这些工具能力。仅能聊天、不能访问本机的 AI，不会因为拿到一份文档就获得设备控制能力。

第一步：从当前客户端导出文档

在蜂控桌面端右上角用户菜单中打开“开发文档”，等待接口内容加载后，点击“导出 AI 文档”。当前导出的 Markdown 文件名为 swarmbot-local-api-v1.md。

这份文档不是简单的接口名称清单，还包含当前 Local API 地址、请求方法、路径、参数、请求体与响应结构，方便 AI 对照真实定义编写调用。界面也提供复制 OpenAPI JSON 等入口。

本文核对了 v1.2.105 的相关页面实现；后续版本菜单位置可能调整，请以所安装客户端为准。升级后若涉及新接口，重新导出，不要一直沿用旧文件。

OpenAPI 是用机器可读形式描述 HTTP API 的规范，作用是让人和工具理解服务提供什么，而不是授予操作权限。OpenAPI 官方介绍

第二步：告诉 AI 用哪份文档做哪件事

蜂控有两类容易混淆的开发资料：

资料	用在什么时候
Local API 开发文档	外部程序或 AI 查询设备、提交操作、读取任务结果
蜂控脚本文档	编写在蜂控脚本运行时执行的代码

如果目标是“让我的 AI 看看当前接了哪些手机”，先给 Local API 文档。如果目标是“写一段在蜂控里执行的流程”，还需要脚本文档和当前项目结构。

官网的文章发布接口不是设备 Local API；发文章用的密钥也不是设备控制凭证。不要把不同系统的地址或认证方式混用。

蜂控的两套开发能力概览可在开发者页面查看，具体函数和参数以客户端当前文档为准。

第三步：先让 AI 只读查一次设备

把导出的文件提供给自己的 AI，再附上这样的指令：

请先读取我提供的蜂控 Local API 文档。使用文档中当前地址、真实路径和参数，不要猜接口。
本次只查询设备列表，返回显示编号、内部设备 ID、型号及连接状态。不要安装应用、执行 Shell、运行脚本或修改设备。
如果环境不能访问本机服务，先报告具体错误，不要尝试把接口暴露到公网。

这里先查列表，不是为了多走一步。它可以验证文档是否适用、请求是否到达正确电脑，以及后续要操作的设备到底是哪一台。

如果 AI 在远程容器或另一台电脑运行，它看到的 localhost 不是你的电脑。应先解决执行环境和受控访问方式，不要把“文档写着本机地址”误解成“任何云端 AI 都能访问”。这个问题在Local API 与外部系统集成中有更详细的说明。

第四步：再给一项明确授权的操作

确认设备对应关系后，再逐步加权限。例如：

只处理刚才确认的测试设备。允许查询它的详情；如果需要打开应用，请先说明操作并等待我确认。每次操作后按文档读取结果。请求超时先查状态，不要直接重复执行。

这是一段权限边界示例，可以按自己的业务修改。提示词不是技术隔离措施：AI 工具权限、运行环境和你给它的访问范围仍然需要控制。不要把完整聊天、私人截图、凭证或不必要的文件一起交出去。

对于安装或较长的脚本任务，如果接口返回任务标识，要继续查询任务状态与结果。收到“已接受”不代表已经完成，AI 说“完成”也应有对应结果。

写脚本与操作设备，可以逐步衔接

你可以先让外部 AI 阅读文档、编写一个小脚本，审查后再在蜂控里试运行；也可以在明确授权后，让它通过 Local API 提交当前版本支持的脚本任务并核对结果。不需要为了使用自己的 AI，把所有逻辑搬进蜂控内置聊天。

但不要把一份通用 JavaScript 代码直接当成蜂控脚本。运行时、函数和项目结构都要核对。具体写法见让 AI 写蜂控脚本的分步方法。

如果你只记住一件事：先下载当前文档，让 AI 做一次只读查询，再逐步开放具体操作。 蜂控提供设备执行入口，你可以选择适合自己的 AI；实际能做什么，则由当前接口、设备状态和明确授权共同决定。