逐字稿文字預覽
一句话就能让AI打开真实手机 跨应用查路线算时间播放音乐 最后自动提交测试报告 谷歌刚刚把这套系统开源 项目方还给出了99.1%的任务成功率 但先别急着把它理解成 安卓已经被AI彻底接管 因为那个数字背后还有一场关于 跑分代码来源和开源署名的争议 这套系统叫Artemis 它面对的是一台真实 Android手机或模拟器 网页和专门为AI准备 的演示界面都不够 开发者用自然语言描述任务 Athena观察屏幕 寻找控件 执行点击和输入 再根据界面变化决定下一步 一个典型任务可以这样写 打开Google Maps查询 三个地点的行车时间 把结果记录下来 再打开YouTube搜索Coldplay并播放歌曲 传统自动化需要工程师 逐个编写控件选择器 等待条件和异常处理 Artemis接到目标后 会自己拆解步骤 并在应用之间切换 这件事听上去只比 语音助手多了几次点击 底层难度却完全不同 语音助手通常调用预先接好的接口 能做什么早已写死 Automis面对的是不断变化的图形界面 按钮会移动 弹窗会突然出现 网络速度不稳定 应用更新以后控件名称也可能改变 传统移动测试因此很脆弱 一条脚本昨天还能运行 今天可能因为按钮换了位置就失败 测试工程师往往在维护 大量选择器和等待时间 业务逻辑反倒没有变化 产品功能没有变化 自动化脚本仍然要重写 Optimus尝试把这部分维护 工作交给多模态模型 它先读取Android的无障碍层级 获得界面中的文字 控件类型和可操作区域 能找到稳定元素时 它通过元素索引点击 界面结构不足时 再使用坐标OCR和视觉定位 这套组合很重要标准 Android应用通常会暴露清楚的控制树 AI可以知道哪个元素是按钮 哪个元素是输入框 flutter compose和CANVAS绘制的 界面可能只给出很少结构 游戏界面甚至完全没有可用控件 optimus遇到这种情况就 转向截图和视觉模型 纯视觉方案也有明显缺点 截图里的两个按钮可能长得很像 小图标不一定能准确识别 动画还会让坐标快速失效 Artemis没有把全部 希望放在视觉模型上 而是优先使用结构信息 视觉负责补位 这个选择降低了推理成本 也让操作更稳定 项目提供两套执行模式 Flash模式追求速度 采用观察一次 行动一次 再次观察的循环 readme给出的典型速度是每一步3-5秒 它不会先写一份庞大计划 也不会为每个动作生成长篇说明 适合目标清楚 流程较短的任务 打开设置并关闭蓝牙 Flash模式看到当前界面后 会直接寻找设置入口 如果已经位于快捷面板 它不必坚持原先设想的路径 反应式循环的好处是 灵活界面出现意外弹窗时 也能临时调整 速度的代价是缺少全局检查 任务变成长流程后 前面一个小错误可能一直带到最后 代理以为邮件已经发送 实际停在草稿页 他以为文件已经移动 实际只打开了目标文件夹 每一步看起来都合理 最终状态却不符合要求 Pro模式就是为这种任务准备的 他使用多代理图把职责 分给planner operator和Checker planner维护一份持续 更新的任务计划operator 操作设备checker在关键 节点和结束时检查结果 一次测试超过100步也可以 保留阶段状态继续执行 planner并不只是把 任务写成编号列表 计划里会标出需要验证的里程碑 例如联系人是否真的创建 文件是否已经出现在目标目录 设置开关是否保持正确状态 界面发生变化后 计划也能调整 而不是机械重复最初路线 operator拿到计划后调用完整工具集 它可以读取屏幕结构 查看截图 分析录屏 调用ADB诊断 也可以搜索此前 压缩保存的操作历史 遇到失败时 系统会创建一条执行事件 把失败原因保留在后续上下文中 直到某次操作真正恢复 checker保持只读 不负责替operator点击 这样设计是为了避免执行者 一边操作一边宣布自己成功 checker根据任务目标检查最终状态 也可以在中间里程碑做验证 用户还能选择关闭验证 只做最终验证 检查所有节点 或者使用更严格的模式 每个动作执行前还有一道safety net 系统优先根据XML界面树确认目标 结构信息不足时再检查像素按钮 在模型思考期间已经消失 操作就会被阻止并交回operator 移动界面中的状态变化很快 这道检查可以减少点 到错误位置的情况 Artemis还支持连续动作突发 某些菜单只会短暂显示 如果每点一次都等待模型重新观察 菜单早已关闭 系统可以把几个确定动作连续发出 缩短模型往返延迟 这类工程处理很少 出现在产品宣传中 却直接决定代理 能不能在真实应用里工作 Flash模式每步大约3-5秒 Pro模式通常需要15-40秒 速度差距提醒了一个现实 可靠性不是免费的 规划检查历史检索 和故障恢复都会增加模型调用 短任务追求速度 长任务追求结果 两种场景很难用同一套配置解决 项目最值得关注的用途是软件测试 普通人远程控制手机还排在后面 开发者完成一项功能后 可以让Artemis在真机上复现问题 收集Logcat日志和截图 再把结果交回编程代理 过去分开的写代码跑手机看日志 开始被串成同一条工作流 这里的关键接口是MCP Optimus自带MCP服务器 可以连接Antigravity Claude code Windsurf等支持MCP的开发工具 编程代理不再只能阅读代码仓库 他还可以看到应用 实际运行后的界面 并操作设备验证自己的修改 设想一个常见场景 用户报告结账按钮点了没有反应 开发者只拿到一句模糊描述 接入Artemis后 编程代理可以安装测试版本 按照用户路径进入商品页 触发结账 截取错误界面 再读取Logcat中的异常 它修改代码后还能 重新执行同一流程 这会改变修复完成的定义 很多AI编程工具生成代码后 只能运行单元测试 单元测试通过 不代表手机界面真的可用 按钮可能被遮挡 权限弹窗可能阻断流程 键盘弹出后布局也可能错位 Artemis把验证推进到设备层 项目还提供CLI Python SDK 和本地网页控制台 CLI适合在终端直接发起任务 Python SDK可以接入pytest 和CI流程网页控制台 则显示手机画面 推理轨迹和执行过程 失败任务可以回放 测试人员不必只看一句执行失败 快速启动脚本会准备ADB script ffpeg和Python依赖用户 可以连接开启USB 调试的实体Android设备 也可以使用模拟器 第一次运行时 系统会在设备上 安装Artemis accessibility helper 用它读取屏幕布局 这个辅助服务会出现在 Android的无障碍设置中 并显示一条运行通知 项目说明称 它只在手机本地监听 不会自行把数据发送到其他位置 如果辅助服务失效 系统还能回退到uiautomator 这里要分清本地 辅助服务和模型调用 前者可以本地通信 截图及界面信息是否离开 设备仍取决于模型供应商配置Athena 支持Gemini Claude GPT4O和千问VL等模型 它本身更接近一个代理框架 不是新的基础模型 实际表现会受到所选模型 网络设备性能和应用界面影响 换一个便宜模型 成本可能下降 定位和规划能力也可能变化 这也是99.1%跑分需要 谨慎理解的原因 项目宣称自己在Android world 达到99%以上任务完成率 图表给出的具体数字是99.1% Android world是Google research 推出的公开环境 包含116项手工设计任务 覆盖20个应用 并通过随机参数生成大量变化 任务包括创建联系人 发送短信 添加日历事件 调整亮度开关Wifi 移动文件和处理播放列表 任务程序会检查设备最终状态 不接受模型自己宣布完成了 这比依靠文字答案评分更可靠 也更接近真实操作 99.1%依然不等于现实手机上的99.1% Android world使用固定系统版本 预设应用和明确任务类型 真实手机有厂商定制界面 广告弹窗登录验证地区差异 和不断变化的第三方应用 测试集能衡量代理进步 无法覆盖开放世界的全部混乱 这项成绩目前也属于团队自曝 公开排行榜接受社区提交 并不会替每个项目 完整复现所有运行 Artemis仓库展示了对比图 却没有提供足够完整的第三方 审计材料来证明每一次任务如何 运行 99.1%可以称为公开的项目成绩 不能包装成已经独立认证的事实 基准测试还存在适配风险 团队知道全部116项任务后 可以针对常见应用和 失败模式优化提示词 恢复逻辑和工具 优化并不等于作弊 工程系统本来就该改进薄弱点 但一个系统在熟悉 测试集上接近满分 不代表面对从未见过 的应用也有同样表现 更敏感的问题来自项目的代码来源 Artemis公开后 minitab团队在Git Hub提出异议 称仓库包含其开源 项目mobileuse的代码 却没有在最初版本中清楚 保留来源和贡献者信息 minitype列出的证据很具体 早期PI project Tamo曾出现 Mobile use的版本号3.6.3 以及三位原作者姓名 后续提交替换了作者信息 其他大量文件保持不变 双方共享的内容涉及ADB隧道 规划辅助函数应用锁定 工具代理提示词和SDK示例 开源代码可以复用 但Apache2.0并不等于可以抹掉来源 许可证允许修改和商业使用 同时要求保留相应版权及许可说明 争议焦点不在Google 能不能使用这些代码 而在它是否完整履行了署名义务 以及发布过程为什么 先移除了原作者信息 当前仓库已经补充说明 明确写着项目包含 minitab开发的源代码 相关文件也增加了版权和来源标记 提出问题的Git Hub议题已经关闭 这解决了当前readme没有署名的问题 却无法抹去最初发布时发生过什么 这场争议让Artemis的 故事变得更有价值 大型公司开源项目时 外界往往默认代码已经 经过完善法务和来源审查 实际情况说明 即使仓库挂在Google组织名下 也需要查看提交记录 notice和文件头 品牌不能代替开源合规 跑分争议又让问题多了一层 Mini Tab表示自己的mobileuse 后来曾自测到更高层级 但公开榜单没有及时更新 Artemis的图表列出多个竞争项目 却没有清楚呈现双方最新可比结果 这里无法仅凭一方说法 判断榜单维护者的动机 但可以确认排行榜存在 更新和独立验证不足 这些问题不应被用来 否定Artemis的全部技术价值 仓库不是一个空壳 里面有完整的命令行工具 MCP服务器 设备驱动 网页控制台 测试目录和多代理流程 短时间获得大量关注 也说明开发者确实 需要更可靠的移动端 AI自动化 同样不能因为代码能 运行就忽略来源问题 技术能力和开源 合规是两条独立标准 一个项目可以有实用价值 同时在发布流程中犯下严重错误 把任何一边省略都会让判断失真 Artemis当前的成熟 边界也写在路线图里 Android studio原生插件仍未完成 ios扩展还在计划中 端侧轻量视觉模型和实时 双向语音控制也没有正式交付 现在可用的是Android设备自动化框架 不是覆盖所有移动平台的万能代理 ios迟早会成为重要方向 但难度不会只是把ADB 换成另一套命令 苹果系统对自动化后台 运行和权限控制更严格 实体设备与模拟器的行为也不同 项目路线图写了ios 不代表现有架构已经解决这些限制 端侧视觉模型同样值得关注 今天使用云端多模态模型 截图和界面信息 可能需要传到服务商 延迟和隐私都受影响 轻量模型如果能在手机 或开发机本地识别界面 可以减少数据外传 也能缩短每一步等待时间 代价是模型能力下降 复杂页面的识别可能不够稳定 Artemis要进入企业测试 还要解决权限和隔离 测试手机可能登录内部账号 包含未发布功能和真实业务数据 代理拥有ADB截图和日志读取能力 一旦配置错误 泄露范围会比普通测试脚本更大 企业需要限制模型端点 保存周期和可执行命令 提示词注入也是 移动代理绕不开的风险 应用页面可以显示 一段专门写给AI的文字 诱导它忽略测试目标 打开其他应用或泄露信息 人类测试员看到异常文字 会判断模型可能把它 当成高优先级指令 safety net能检查目标位置 未必能识别内容本身的恶意意图 持续集成环境还需要可复现性 同一个自然语言任务今天通过 明天失败 开发团队很难判断是代码 回归模型波动还是界面变化 Optimus必须记录模型版本提示 词截图动作轨迹和设备状态 才能让失败结果具有工程价值 成本也不能被99.1%的数字遮住 Pro模式每一步可能消耗15-40秒 还会调用规划视觉和检查模型 一次上百步的测试要 花多少时间和API费用 决定它能否替代传统自动化 高价值探索测试可以接受较高成本 大量重复回归测试未必划算 最合理的使用方式可能是混合测试 稳定高频的核心流程 继续使用传统脚本 速度快结果也容易复现 经常变化或难以维护 的界面交给Artemis探索 AI发现稳定路径后 还可以帮助生成更固定的测试用例 这样分工比AI取代所有 测试工程师更接近现实 测试人员需要定义风险准备 环境判断结果和处理异常 Artemis减少的是反复找按钮维护 选择器和手工复现的时间 并没有替团队决定什么功能最重要 也不能替公司承担发布责任 测试工程师的工作会随之变化 过去大量时间花在脚本维护 未来更多时间会用于设计任务 设置验证条件和分析失败轨迹 自然语言看似降低了门槛 准确描述目标反而更重要 含糊任务会让代理找到 一条看起来完成的路径 却漏掉真正的业务要求 开发流程也可能从提交代码后统一 测试变成编程代理边写边操作设备 它修改登录页面 立刻安装构建版本 走一遍登录和找回密码 再根据日志继续修改 设备不再是开发链 末端的人工检查站 而是AI编码循环的一部分 这会给小团队带来明显价值 没有专职移动测试工程师的团队 也能建立基本的真机回归流程 可规模扩大以后 设备农场账号管理和并发 调度仍然需要专业基础设施 optimus解决了操作智能 不会自动解决所有测试平台问题 设备管理是一项容易被忽略的成本 几十台手机同时测试 需要保持系统版本 屏幕分辨率和应用 数据处于可控状态 某项测试结束后还要清理 联系人短信文件和登录状态 否则下一次任务会 读取上一次留下的数据 Android world之所以能评测代理 正是因为它为任务 准备初始化和结束检查 企业自己的应用没有现成评测器 团队必须定义什么叫成功 页面出现提交完成 可能只是前端提示 后台订单未必真正创建 Optimus可以点击和观察 却需要业
本次執行流程與問題處理
下達指令
預期流程
- 採用來源字幕（略過語音辨識）
- 來源選擇與品質檢查
- 文字校正與句子單元
- 筆記與發布
- 公開網頁發布
1. 下載與語音辨識
工具：videonote-transcribe-url（主辨識管線：下載、Whisper 辨識與選稿）
處理：下載音訊、以 Whisper 辨識並選出最佳逐字稿
產出：yt_dlp_meta.json（影片元資料）、audio_16k_mono.wav（16kHz 單聲道音訊）、transcript.whisper.json（Whisper 辨識結果）、transcript.json（正式逐字稿）、transcript_selection_report.json（來源選擇報告）
耗時：14.3 秒
關係：依序執行
結果：完成
2. 全文快速校讀
工具：videonote_rapid_transcript_review.py
處理：先速讀完整逐字稿，再修正高可信突兀詞句並列出待確認項目
產出：rapid_transcript_review_report.json（產出檔案）
耗時：52.5 秒
關係：依序執行
結果：完成
3. 建立句子單元
工具：videonote-build-sentence-units
處理：將逐字稿切成帶時間軸的句子單元
產出：sentence_units.json（句子單元）
耗時：0.6 秒
關係：依序執行
結果：完成
4. 時間軸稽核
工具：videonote_timeline_audit.py
處理：檢查時間軸與音訊對齊
產出：timeline_audit_report.json（時間軸稽核）
耗時：0.6 秒
關係：依序執行
結果：完成
5. 品質檢查
工具：videonote_controlled_quality.py（檢查時間軸與品質）
處理：檢查語言、時間軸與可讀性品質
產出：controlled_quality_report.json（品質報告）、language_sanity_report.json（語言檢查）
耗時：0.6 秒
關係：依序執行
結果：完成
6. 播放時間軸回填
工具：videonote_rebase_display_timeline.py
處理：將網頁播放時間軸回填為校正字幕時間
產出：display_timeline_rebase_report.json（時間軸回填報告）
耗時：0.7 秒
關係：依序執行
結果：完成
7. 來源句整理
工具：videonote_prepare_source_entries.py
處理：整理來源句子供時間軸與頁面使用
產出：sentence_units.json（句子單元）
耗時：0.7 秒
關係：依序執行
結果：完成
8. 生成筆記摘要
工具：videonote-generate-note（生成筆記摘要）
處理：生成筆記摘要與重點
產出：note.md（筆記 Markdown）、note.html（筆記 HTML）
耗時：159.0 秒
關係：依序執行
結果：完成
9. 建立筆記頁面
工具：videonote-render-html（產生筆記 HTML）
處理：產生可閱讀的筆記 HTML 頁面
產出：note.html（筆記 HTML）
耗時：1.1 秒
關係：依序執行
結果：完成
10. 發布公開頁面
工具：videonote-publish（發布公開頁面）
處理：發布到公開網站與每日列表
產出：公開筆記網址、result.json（管線結果）
耗時：0.2 秒
關係：依序執行
結果：完成
手動來源字幕
自動來源字幕
Whisper 字幕
- 尚未產生
Qwen 字幕
- 尚未產生
Parakeet 字幕
- 尚未產生
MOSS 字幕
- 尚未產生
聲學時間證據（PyAnnote / WhisperX）
- 尚未產生
校正前後逐字稿
- 校正前 transcript.source.json 純文字 JSON
- 校正後 transcript.json 純文字 JSON
目前待解決問題與初步改善方向
- 逐字稿全文快速校讀未完成
已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。；RAPID_REVIEW_STATUS=REVIEW_REQUIRED_INVALID_OUTPUT
- Qwen3-ASR 未完成，需確認 qwen_asr_lab 環境與音訊後重試精進模式。
- 音訊下載不穩定，需更新 cookies / PO token 後重試精進模式。