让 AI 写蜂控脚本：先跑通一个小步骤，再整理成可复用流程

让 AI 一次写完一个很长的手机操作流程，往往很快就能得到代码。真正费时间的，是随后弄清：用到的函数蜂控是否支持？从哪个页面开始？哪个步骤没完成？重新运行会不会重复提交？

在蜂控里，更实用的做法是从一个很小的任务开始。例如先“读取当前前台应用”，确认输入、调用和返回都正确，再加页面判断与后续动作。

本文依据当前开发页面、已有脚本项目和 v1.2.105 相关实现整理。没有在本次写作中运行用户脚本；下面的检查流程是建议，不是跨机型实测结论。

第一步：把运行环境交代给 AI

蜂控的开发页面有代码编辑区、脚本助手，以及截图、OCR 等相关上下文入口。已有项目也会包含脚本配置与代码文件。写作时查看的项目列表里，就有读取前台包名等小工具型脚本：它们比一个包办所有事情的大脚本更适合作为起点。

需要特别告诉 AI：这是蜂控脚本运行时，不是网页里的 JavaScript，也不能默认当成 Node.js 项目。

可以这样开始：

请先读当前蜂控脚本文档和现有项目结构，列出本任务需要的函数及参数。只使用文档中存在的能力。先写读取前台应用并输出结果的最小版本，不操作其他页面，不直接执行。缺少资料先指出来，不编造函数名。

这一步的价值是把“模型熟悉的语法”和“蜂控实际提供的接口”对上。函数看起来很像，也可能参数、返回值完全不同。

第二步：先确定起点与终点

不要只给“自动完成页面检查”。至少补充下面几件事：

• 起点：设备已经解锁吗，应用是否已打开，当前在哪个页面？
• 输入：目标应用、查找内容等哪些值需要每次传入？
• 终点：看到什么或读到什么，才算完成？
• 停止条件：找不到目标、超时、出现登录或付费页面时怎么办？

例如把目标限定为“打开已安装应用，进入指定页面，读取一项状态并返回，不修改内容”。页面不存在就返回失败原因，而不是让脚本一路点下去。

对经常变化的值，要求 AI 按当前项目支持的参数机制处理，不要把私人账号、设备 ID 或素材路径散落在每个步骤里。

第三步：让失败能被看见

一个脚本只输出“开始”和“结束”，排障时几乎帮不上忙。可以要求 AI 给关键步骤加上明确记录：

每一步记录步骤名称和判断结果；超时要指出正在等待哪个条件。区分“没有找到目标”和“调用报错”。不要把异常吞掉后仍然输出成功。

这不是要求无限增加日志。能定位到“找页面”“读状态”“提交动作”中的哪一段就很有帮助。避免记录账号、令牌或整段私人消息。

运行前先检查代码；获准后在一台测试设备上试，再对照设备画面和返回结果。GitHub 对 AI 生成代码也明确提醒要审查、验证和测试，不能因为代码由 AI 给出就跳过这些步骤。GitHub 说明

第四步：出现问题，只修出错的那一段

把错误交给 AI 时，附上最小必要信息：

前台应用读取成功；进入目标页后等待条件超时。以下是相关代码、错误和当前页面信息。请先解释可能原因，只修改这一段，保留已经正常的步骤。不要重新生成整个项目。

如果修复理由是“多等几秒”，继续问：是在等页面出现，还是只是固定睡眠？固定延时可以应急，但不能证明页面已经准备好。更稳妥的方案通常是检查实际条件，并给等待设置上限；具体能用什么检测方法，要以蜂控当前文档为准。

第五步：复用前，补上几种不同情况

正常路径跑通以后，再检查：

1. 应用没有安装时，是否明确退出，而不是误点其他页面。
2. 起始页面不同，是否能够识别，或告诉用户需要先准备什么。
3. 上一次已经完成，再运行会不会重复发送、重复创建内容。
4. 某台设备失败时，是否能单独定位，而不是把整批都说成失败。

这些是验收项，不代表蜂控会自动替每个脚本实现。需要你和 AI 在流程里明确设计。

如果只是偶尔变化的任务，继续用 AI 对话也可以；当步骤逐渐稳定，再整理成脚本。两者的分工见AI、技能和脚本的配合方式。要周期调用时，先看定时任务的验收方法，不要在首次调试时就加上无限重复。

你也可以把相关文档交给自己的 AI 写代码，再回到蜂控验证。若还想让外部 AI 直接查询设备、提交运行任务，另看Local API 接入指南：写脚本与调用设备接口是两个需要分别核对的环节。