Omi 移动端 Feature Vector基于 Flow-Walker 的 E2E 测试覆盖优先级工程实践指南【免费下载链接】FriendAI that sees your screen, listens to your conversations and tells you what to do项目地址: https://gitcode.com/GitHub_Trending/fr/Friend导读本文围绕仓库 app/e2e/feature-vector.md 展开系统讲解 Omi 团队如何用特征向量Feature Vector这一可量化的优先级模型驱动移动端核心流程的端到端E2E测试覆盖。你将掌握其双层打分模型核心使命权重 × 会话频率、Walker 可自动化评分0-3、33 项核心功能的覆盖矩阵、缺口管理方法论以及如何与仓库内的 YAML 流程文件、Flow-Walker 流水线 和 agent-flutter 驱动工具 协同落地。读完后你可以直接复刻这套先排优先级、再分配覆盖、后持续追踪的 E2E 治理框架到任何移动应用中。一、Feature Vector 是什么为 E2E 覆盖排序的量化决策工具在大型移动应用中E2E 测试的成本远高于单元测试——每个流程都需要真实设备、真实登录态、真实后端与真实录制因此不可能也不应该对所有功能一视同仁。Omi 的解法是维护一张特征向量表feature-vector它本质上是一份经过优先级排序的功能地图用于指导 flow-walker E2E 覆盖哪些核心 Omi 移动端流程、以什么顺序覆盖、以及每个流程需要多高的自动化程度。该文档自身即定位为Prioritized feature map to guide flow-walker E2E coverage of core Omi mobile app flows用于指导 flow-walker E2E 覆盖核心 Omi 移动端流程的优先级功能地图。它借用了 Omi Issue Triage Guide问题分诊指南中的两个评分维度将产品直觉转化为可计算的优先级数值。二、评分模型两个维度量化一个优先级Feature Vector 的核心是三个可计算的指标全部定义在 app/e2e/feature-vector.md 的 Scoring Model 一节2.1 Combined Priority组合优先级Combined Priority layer_weight × session_frequency第一维Core-to-mission核心使命层权重 layer_weightOmi 的产品使命是AI that sees your screen, listens to your conversations and tells you what to do看见你的屏幕、听见你的对话、告诉你该做什么。据此将功能按对使命的贡献分层赋权层Layer权重含义capture捕获5录音、设备连接等听见能力的根基understand理解4转写、说话人识别、词汇等听懂能力memory记忆4记忆库、知识图谱等长期记忆intelligence智能3AI 聊天、摘要、任务提取等告诉你要做什么retrieval-action检索-行动3搜索、分享、文件夹、应用市场等检索与执行第二维Session frequency会话频率值含义daily3用户几乎每天使用weekly2每周级使用setup-only1仅在初始设置阶段使用示例会话列表与浏览属于 capture 层权重 5× daily 频率3 优先级 15是整张表中最高的而日历集成属于 retrieval-action 层权重 3× setup-only1 优先级 3排在最后。2.2 Walker Score流程可自动化程度0-3Walker Score 回答的是这个流程能不能交给 agent 自动跑分数含义3完全可自动化纯点击、结果确定2部分可自动化需要滚动或条件内容1需要先完成人工/物理设置之后 walker 可验证0不可达SMS 验证、外部 OAuth、真实支付关键演进2026-03-17BLE 设备流程原本被评分为 walker0不可达。团队在物理 Pixel 7a 真实 Omi 设备上验证后证明它可以通过 ADB agent-flutter 全流程驱动因此升级为 walker1需要物理设备设置之后 agent 可驱动完整流程。这说明Walker Score 不是静态属性而是随基础设施能力演进而动态修正的。三、特征向量总表33 项功能的三层覆盖矩阵Feature Vector 将 33 项核心功能划分为三个优先级梯队每项标注了所属层、优先级、Walker 分数和覆盖状态。以下完整继承原文档的核心要素3.1 CORE DAILY核心每日流程优先级 9-15walker 1-3#功能层优先级Walker覆盖状态1会话列表与浏览capture(5)153✅ conversations.yaml9 步2会话详情转写/摘要/行动项页签capture(5)152✅ conversations.yaml3会话录制手机麦克风capture(5)151✅ phone-capture.yaml9 步4会话录制Omi 设备capture(5)151✅ device-capture.yaml10 步5设备发现与连接BLEcapture(5)151✅ device-connect.yaml10 步6设备断开与重连capture(5)151✅ device-connect.yaml7记忆列表与浏览memory(4)122✅ memories.yaml6 步8记忆搜索memory(4)122✅ memories.yaml9AI 聊天开/关Ask Omiintelligence(3)92✅ ask-omi-chat.yaml9 步10行动项查看intelligence(3)92✅ action-items.yaml7 步11每日摘要/评分首页卡片intelligence(3)92✅ daily-summary.yamlstub12全局搜索retrieval-action(3)92✅ 已覆盖13任务管理FAB 创建、切换retrieval-action(3)92⚠️ 部分覆盖3.2 CORE WEEKLY核心每周流程优先级 6-12walker 1-2#功能层优先级Walker覆盖状态14记忆审核/批准memory(4)121⚠️无 UI——后端 API 存在但 Flutter 应用没有审核按钮user_review 字段在 UI 中未使用15记忆分类与筛选memory(4)82⚠️ 部分覆盖16手动添加/编辑记忆memory(4)82✅ add-edit-memory.yaml7 步17记忆图谱可视化memory(4)82✅ memory-graph.yamlstub18自定义词汇understand(4)82✅ custom-vocabulary.yaml7 步19说话人识别Peopleunderstand(4)81✅ speaker-identification.yaml9 步20目标追踪intelligence(3)62✅ goals-tracking.yaml7 步21会话分享/导出retrieval-action(3)62✅ conversation-sharing.yaml8 步22会话文件夹retrieval-action(3)62✅ conversation-folders.yaml10 步23应用市场浏览retrieval-action(3)62✅ apps-marketplace.yaml7 步24应用详情与安装retrieval-action(3)62✅ apps-marketplace.yaml25离线同步 UIcapture(5)102✅ 已覆盖3.3 SETUP AUTH设置与认证流程优先级 3-5#功能层优先级Walker覆盖状态26登录Google Sign-In—51✅ login.yaml5 步27退出登录—52✅ logout.yaml5 步28首次启动引导Onboarding—51✅ onboarding.yaml9 步29转写设置understand(4)42✅ 已覆盖30语言选择understand(4)42✅ 已覆盖31语音画像understand(4)41✅ 已覆盖32任务集成retrieval-action(3)31✅ task-integrations.yamlstub33日历集成retrieval-action(3)30⚠️ OAuth 受阻四、覆盖缺口管理三个未 100% 覆盖项及其根因Feature Vector 的价值不仅在于已覆盖更在于显式登记未覆盖项及其阻塞根因防止它们被遗忘排名功能优先级阻塞原因备注1记忆审核/批准12Flutter 无对应 UI后端有POST /v3/memories/{id}/review端点与 user_review 字段但 Flutter 应用没有任何批准/拒绝按钮。无法为不存在的 UI 编写流程。2记忆分类与筛选8部分覆盖memories.yaml 已覆盖但筛选开关未充分演练3任务管理FAB 创建9部分覆盖行动项列表已覆盖但任务创建表单需要文本输入4.1 源码佐证记忆审核是后端就绪、前端缺失的典型在 backend/routers/memories.py 中可以找到记忆审核端点POST /v3/memories/{memory_id}/review的完整实现它接收value: bool作为审核结论调用MemoryService.review()并注释明确指出Discarding a memory is this surfaces thumbs-down.user_reviewon the memory is a mutable flag with no timestamp, so the ledger row is what gives the verdict a time and lands it in the daily report丢弃一条记忆是该接口的踩memory 上的user_review是无时间戳的可变标志因此由账本行ledger row为判定打上时间并进入日报。这段源码精确印证了 feature-vector 的判断能力已完整存在于服务端审核、反馈、账本但移动端 UI 从未暴露入口。这正是后端 API 存在但 Flutter 应用无审核按钮的代码级证据——E2E 覆盖矩阵把它标记为缺口而不是硬写一个跑不通的流程体现了这套方法的严谨性。五、已发布 Flow-Walker 报告与覆盖率总结截至文档更新2026-03-18共有16 份已发布报告此前为 11 份全部在物理 Pixel 7a 设备上验证通过流程步骤结果login5/5PASSonboarding9/9PASSlogout5/5PASSask-omi-chat9/9PASSconversations9/9PASSapps-marketplace7/7PASSmemories6/6PASSaction-items7/7PASSphone-capture9/9PASSdevice-connect10/10PASSdevice-capture10/10PASSconversation-folders10/10PASSconversation-sharing8/8PASSadd-edit-memory7/7PASScustom-vocabulary7/7PASSspeaker-identification9/9PASS5.1 覆盖率汇总类别总功能已覆盖缺口核心每日capture、intelligence13121任务管理部分覆盖核心每周memory、understand、retrieval12111记忆审核——无 UI设置与认证871日历 OAuth总计33303覆盖率 30/33 ≈ 91%且剩余 3 项为部分覆盖/受阻而非可立即行动的缺口。六、版本演进史Feature Vector 如何随验证结果迭代Feature Vector 是一份活文档其三个更新记录完整展示了 E2E 治理的闭环迭代节奏6.1 2026-03-17 更新 #1BLE 流程晋级 认证流程入表BLE 设备流程从 CORE DAILY 之外升入核心每日梯队device-connect 与 device-capture 在物理 Pixel 7a 真实 Omi 设备上被证明可自动化walker 从 0 升至 1。新增 3 个流程phone-capture、device-capture、device-connect合计 29 个新步骤。认证流程login、logout、onboarding首次入表。6.2 2026-03-17 更新 #2补全全部可行动缺口新增 6 个流程关闭所有可行动缺口conversation-folders.yaml10 步、goals-tracking.yaml7 步、add-edit-memory.yaml7 步、custom-vocabulary.yaml7 步、conversation-sharing.yaml8 步、speaker-identification.yaml9 步。记忆审核/批准被重新归类不是缺口而是Flutter UI 功能缺失后端存在应用未暴露。覆盖率达成30/3391%。6.3 2026-03-18 更新5 份新报告 一个已知阻塞在物理 Pixel 7a 上新增发布 5 份报告add-edit-memory、custom-vocabulary、speaker-identification、conversation-folders、conversation-sharing。goals-tracking 流程受阻尽管偏好已启用DailyScoreWidget 在 Pixel 7a 上不渲染导致无目标存在时 Add Goal 入口不可用——这是一个真实的 UI 渲染缺陷被 E2E 流程捕获的实例。总报告数从 11 增至 16。七、与 Flow-Walker 流水线的协同从特征向量到可执行流程Feature Vector 是路线图而 app/e2e/FLOW-WALKER-SKILL.md 是施工队。两者的衔接点在app/e2e/flows/*.yaml。7.1 流程 YAML 的 v2 架构每个流程文件遵循 v2 schema示例见 conversations.yamlversion: 2 name: conversations description: 一句话描述该流程测试什么 app: com.friend.ios.dev evidence: video: true covers: # 该流程演练的源码文件——特征向量与代码的映射点 - app/lib/pages/conversations/conversations_page.dart - app/lib/providers/conversation_provider.dart preconditions: # 必须为真的真实用户状态 - auth_ready steps: - id: S1 name: 步骤标题 do: 详细操作说明——点什么、验证什么 verify: true expect: - kind: text_visible values: [Conversations] - kind: interactive_count min: 4 evidence: - screenshot: step-S1.webp note: 实现细节、代码路径、ADB 坐标、边界情况每个步骤支持两类断言text_visible断言指定文本出现在屏幕上与interactive_count断言至少 N 个可交互控件可见。preconditions字段强调用真实用户状态测试SKILL.md 中有完整的auth_ready、signed_out、microphone_permission、ble_on、omi_device_connected、phone_number_verified等前置条件定义表及依赖链。7.2 6 阶段流水线一条流程从 YAML 到公开报告需经过 6 个阶段详见 FLOW-WALKER-SKILL.md# 1. 初始化运行 INIT$(node $(which flow-walker) record init --flow $FLOW --output-dir app/e2e/runs/ --no-video --json) # 2. 逐步骤执行 流式写入 events.jsonl必须用真实墙钟时间戳 stream_event step_start S1 agent-flutter press 540 1200 adb exec-out screencap -p /tmp/raw.png \ cwebp -q 70 -resize 270 600 /tmp/raw.png -o $RUN_DIR/step-S1.webp stream_event step_end S1 ,\outcome\:\pass\ # 3. 结束录制自动保存 .snapshot.json 供回放 node $(which flow-walker) record finish --run-id $RUN_ID --run-dir $RUN_DIR --status pass --flow $FLOW --json # 4. 校验audit 模式下可能需要手动覆盖 outcome node $(which flow-walker) verify $FLOW --run-dir $RUN_DIR --mode audit --output $RUN_DIR/run.json --json # 5. 生成 HTML 报告 node $(which flow-walker) report $RUN_DIR --json # 6. 推送发布 PUSH$(node $(which flow-walker) push $RUN_DIR --json)7.3 agent-flutter 驱动与前置条件驱动层面SKILL.md 定义了 agent-flutter 命令集基于 Flutter Marionette 调试协议snapshot -i --json查看交互控件与 ref、press ref/press x y点击、fill ref text输入、scroll down/up滚动、find text X press按文本定位、screenshot PATH截图。核心规则包括Flutter 会激进重建 widget 树ref 极易过期——每次交互前必须重新 snapshotfind type X比硬编码 ref 更稳定。前置条件是 feature-vector 中 walker 分数1需人工/物理设置的具体落地。例如phone-capture.yaml的 preconditions 声明了microphone_permissionAndroid 可通过adb shell pm grant com.friend.ios.dev android.permission.RECORD_AUDIO预授权与no_omi_device无 BLE 设备配对时中央麦克风按钮才会出现device-connect.yaml则要求ble_on模拟器不支持 BLE必须使用物理设备与omi_device_powered物理 Omi 设备需开机、充电并在 BLE 范围内LED 闪烁蓝光表示可发现模式。八、实践要点与经验沉淀8.1 评分模型的可操作原则捕获能力权重最高capture5录音、设备连接是听见你对话的根基任何回归都直接伤害核心价值主张。walker0 不意味着放弃SMS 验证、外部 OAuth、真实支付等无法自动化要么登记为缺口并等待基础设施演进如 BLE 从 0 升级到 1要么依赖人工验证。为不存在的 UI 不写流程记忆审核的案例证明E2E 无法为不存在的前端入口编写流程——应记录为产品缺口而非测试缺口。8.2 从 YAML 到真实设备的坑位清单结合各流程文件的note字段可提炼出高频实操经验Action Items 页面禁用系统返回键action-items.yaml 的 S7KEYCODE_BACK会直接退出整个应用back-exits-app bug必须用底部导航 Home 页签返回。会话详情进入需注意时间字段conversations.yaml 的 S3startedAt与createdAt不一致的会话会抛Bad state: No valid conversation found应选取两者一致的会话如 Mastering Vocal Communication。设备录音是连续的device-capture.yaml 的 S8与手机麦克风的一次性录制不同Omi 设备按静音间隔自动切分会话默认静音超时 2 分钟处理完一段后立即开始下一段。BLE 电池读数节流device-connect.yaml 的 S5首次读取、变化 ≥5%、15 分钟间隔或穿越 20% 阈值时才会更新。时间戳必须真实FLOW-WALKER-SKILL.md伪造/相同时间戳会导致报告显示 2s 总时长schema 中步骤 outcome 误用status字段会导致报告显示 undefined。8.3 把 feature-vector 复用到你的项目按产品使命定义 5 个左右的功能层并赋权如 capture5、understand4…用层权重 × 会话频率计算每个功能的组合优先级为每个功能评估 walker 分数0-3标记不可达项按优先级 × walker_score排序为高优先可自动化项编写 YAML 流程维护一张覆盖矩阵显式登记缺口、阻塞根因与责任人随基础设施与产品演进周期性重评 walker 分数与优先级参考本文 6.1-6.3 的迭代节奏。结语Feature Vector 是 Omi 团队将我们该测什么从主观讨论转化为可计算、可追踪、可迭代的工程资产的关键。它以 91% 的覆盖率30/33验证了这套方法论的有效性并用三个显式缺口记忆审核无 UI、任务创建需文本输入、日历 OAuth 受阻展示了成熟团队的取舍智慧——好的 E2E 治理不是消灭所有缺口而是让每个缺口都有明确根因、优先级和演进路径。对于任何希望建立可持续移动端 E2E 覆盖体系的团队这份文档与其配套的流程 YAML、流水线脚本和驱动工具链都是可以直接借鉴的完整样板。【免费下载链接】FriendAI that sees your screen, listens to your conversations and tells you what to do项目地址: https://gitcode.com/GitHub_Trending/fr/Friend创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考