AI 星朋友 E2E 测试体系优化与可信性建设

导读

我们应用 的 E2E 测试从单页 BDD 自动化起步，如今已经长成一套同时覆盖 H5、App、小程序的跨端验收体系。随之而来的核心问题变成了：

怎么证明一条测试结果可信？

我们的做法是让 Agent 生成测试计划，再由确定性代码核对被测对象、业务断言和现场证据，把结果分成通过、失败、阻塞、不适用四种。本文结合线上真实故障，说明信任边界、跨端执行和证据留存的设计，并梳理可复用的故障模式。

当前能力面向单人本地真机验收，平台接入方案、真机结果同步机制、发布状态打通能力均不在本文讨论范围内，将另行撰文说明。

开篇 从业务目标理解 E2E 验收

应用包含聊天、角色、好感度等业务。每次功能调整后，验收需要回答一个具体问题：用户在约定条件下，能否完成预期操作，并得到符合需求的结果。个人页的昵称是否正确、加载失败后能否恢复访问、聊天语音能否播放，都是业务目标的具体表达。

先把业务结果说清楚

个人信息展示。用户打开「我的」页面，昵称应与当前账号一致。文中已有用例曾只检查昵称文本非空，这会把错误昵称也判为通过。验收需要核对具体信息是否符合预期。

页面加载恢复。用户遇到加载失败，恢复网络并点击重试后，应能继续访问目标页面。已有恢复样本确认了异常层消失，并取得恢复后的页面观测；要证明首页业务可用，还需要补齐具体区域和交互的检查。

聊天语音播放。用户点选语音后，需要能够听到内容。本文以语音播放异常上报用例，说明数据条件不足时如何界定验收结果。验收要有能触发目标行为的真实语音数据。文中的严格音频用例曾因没有合适语音而记为不适用；这次记录没有验证播放结果，不能当作播放功能通过。

让验收结论支持下一步处理

一份验收结果需要说明：检查了哪项需求，在哪个平台和版本上执行，哪些行为已有证据，哪些部分仍未验证。业务结果不符合预期，需要定位和修复；环境未就绪，需要先解决执行条件；当前数据不适用，需要准备符合条件的数据。不同情况应分别记录，避免把尚未验证的功能算作通过。

后文的技术设计围绕这些问题展开：业务场景定义验收要求，跨端执行落实用户操作，判定规则核对业务结果，身份与证据记录限定结论适用的版本和范围。读者可以结合自己的业务，检查每项机制帮助确认了哪些要求，以及还有哪些要求需要继续验证。

01 当前整体架构

要判断昵称是否正确、页面是否恢复，需要先明确业务预期，再执行操作、取得观测并核对结果。下面的架构将这些职责分开，确保每个“通过”都能追溯到具体要求和证据。

模型可以参与生成测试内容，但最终结果只由可复核的规则计算得出。

图 1：执行器负责操作和观测，内核负责核验，证据层保存本次判断的依据；发布检查位于业务验收之后。

Agent 结合业务目标、源码和设备快照产出 Issue 与 Plan；ProofKernel 校验执行范围、授权信息和被测对象，再把任务下发给执行器。执行器回报动作状态、逐条断言结果和对应证据，内核据此给出判定，证据层则完整保存判定所依赖的材料。

1.1 五条关键架构边界

• 控制面与执行面分离：ProjectProfile、catalog、脚本和策略属于控制面；Runner 只能在授权范围内执行，并返回结构化观测，不能自行声明业务用例通过。
• 计划面与判定面分离：Agent 生成 IssueContract 与 VerificationPlan；ProofKernel 独立核对验收项、能力、授权、观测结果和证据材料。模型的输出不会直接改写最终执行状态。
• 身份链分段证明：sourcefingerprint → Artifact Manifest → Install Receipt → RuntimeContext。每一段只证明相邻两个对象的关联，不能把“代码身份”直接等同于“设备二进制身份”。
• 授权链逐层收窄：ProjectPolicy→ RunSpec → Intent → refframe。下层只能收窄项目授予的权限，不能扩大；页面一变，旧引用立即失效，必须重新观测。
• 证据生命周期可审计：临时 attempt→ 第一轮材料核验→ run-result→ 第二轮材料核验→ evidence-index→ 原子 rename。外部消费方只认索引记录的状态，不直接采信执行器输出的原始结果。

对已纳入校验范围的配置、身份、执行和证据异常，系统会按规则判为 blocked 或 failed；判定依据本身是否正确，仍需独立复核。

1.2 项目知识与平台执行分别维护

ProjectProfile 负责维护项目相关知识：源码采集、结束时的复查、测试目录管理。平台执行器负责实际跑测试，并按统一协议返回观测结果。我们应用 通过 createAipbRunnerRegistry 完成注册，登记了三类执行能力：

新增测试时，要完成登记并与 case/oracle 建立关联，保证计划里的场景和判定依据能对上。新增执行器，则要实现观测协议、异常处理和资源清理。接口接通之后还得跑真实用例，确认它确实能完成对应平台的验收。

日常开发仍保留短路径反馈：先读相关源码，跑对应的单元、集成测试；只有明确要做平台回归时才调用 e2e:issue。每次小改动都拉起设备、准备 App、收集平台材料，等待成本太高。统一协议的价值是让不同路径都返回可核对的结果，完整流程只留给真正需要它的场景。

1.3 发布门禁还要检查哪些条件

单条设备用例跑通，离发布还差几件事：测试对象必须是目标产物，判定规则必须受保护，证据必须满足对应平台的要求。

ReleaseGate 的策略签名和平台证据校验逻辑已经写完，但截至本文记录的时间尚未启用。回执接入已覆盖 Android、iOS、小程序；配置层面可以声明 H5 平台，实际接入时会被直接拒绝。installed-app 模式跑出来的功能结果，不进发布验收。

图 2：先验证发布策略的来源，再核验平台子证据和通过次数；配额不足时拒绝。签名保护发布策略，证据包另行校验。

ReleaseGate 第一步校验策略来源。策略证明用 Ed25519 签名保护，把策略摘要与签发者 issuer、来源引用 reference、签发时间、审批名称 approvals 绑定在一起。验签公钥还要和 CI 给出的固定公钥摘要比对；证明里带有效期，用来约束授权时间；预期控制面指纹用来限定允许的执行规则。

来源校验通过后，门禁读取平台子证据，核对终态、业务标志、控制面指纹、产物清单、安装回执和运行平台。只有合格记录才计入平台通过次数。平台接口连通、业务验收通过、发布条件达成，这三件事各自需要对应的证据。

这套实现仍有明确的信任边界。

• 签名只保护发布策略证明，证据包本身没有独立签名。对证据文件做摘要校验，替代不了来源认证。
• approvals 只是签名证明里的一个名称集合，代码不会去查真实审批系统。签发脚本会校验 CI=true，但保护分支、私钥、注入变量能不能隔离，仍取决于 CI 配置本身。
• 门禁会累加 evidenceDirectories，既没按路径去重，也没按 runId/attemptId 去重。同一份证据重复输入，就可能重复占用配额。这个计数缺陷要在门禁正式启用前修掉。

02 三个有意的取舍

只对外开放两条命令

命令面由 package.json#aipbE2E 定义成机器可读契约，并配套测试，防止 test:h5、test:android 这类旧命令重新露头；平台层面的命令则降级为 exact-case 的内部适配细节。出口越少，“绕过内核直接跑脚本、再宣称用例通过”的路子就越少，Agent 需要理解的命令集合也跟着变小。

坚持使用真实业务数据

• 范围说明：语义设备用例跑在真实账号、真实聊天数据之上，不注入 token，不自动创建角色，也不切换账号。
• 代价：部分用例的前置条件可能不满足。音频 APM 那次出现 blocked，就是因为真实聊天列表里找不到唯一会话。
• 理由：我们要验的恰恰是真实用户链路能不能走通，而登录状态、列表加载、会话唯一性正是容易出 bug 的地方。
• 边界：真实环境并非完全不可控。可以依托真实业务链路准备可重复、可清理的数据，但不能用 Mock 替换被测链路；环境或执行条件不满足时直接返回 blocked，当前业务数据导致某条用例不适用时返回 skipped。两种状态都不计入通过，也不会伪造前置条件硬跑下去。

不让模型参与结果判定。项目给 AI 划的边界是：可以浏览页面、生成待审核用例、聚类失败原因；但不能找到一个替代元素就把失败改成通过，也不能凭“置信度高”跳过检查文件。ProofKernel 只收结构化观测和证据，模型输出最多停在“计划”这一层。

03 代码生成加快后的验收问题

图 3：测试体系的演进阶段。各阶段的能力建设与平台运行结果分别记录。

上图是完整的演进路线。看清现状和取舍之后，我们回到 2026 年 3 月，按时间顺序看这套体系怎么搭起来：从早期 BDD 试点，到跨端执行、测试对象识别、语义设备操作、证据封存；10 月完成的兼容治理和结果归因修改，对应两类更细的故障场景。

这套体系最初并不复杂。项目早期，Codex、ClaudeCode 这类工具把代码生成速度提了上来，但需求理解、环境准备、结果复核不会跟着自动解决。应用的聊天、角色、好感度等模块各有业务规则，光看页面名称，大模型推不出完整的验收要求。动手设计测试之前，仍要先把业务预期理清，再挑合适的验证手段。

测试本身也会把错误实现判成通过。大模型读源码生成用例时，很容易把代码当前的行为直接当成预期；如果实现本身就误解了需求，用例会继承这份误解。项目需要从需求规格和已确认的业务实例里提炼预期，再与实现对照。业务变更之后，还要回头检查用例是否过期、断言能否识别目标故障。

不同问题要匹配不同的验证方式。规则计算可以用单元测试隔离输入；原生容器与 H5 之间的 Bridge 接口，用契约测试校验双方约定；原生异常页与 WebView 的衔接，则要在 App 内部观测两层怎么配合。单靠堆设备用例，补不上规则层缺少边界输入的漏洞。行为驱动开发（BDD）的价值，是让团队基于业务实例对齐验收标准，再交给对应层级执行：日常开发优先用单元、集成测试拿反馈，涉及真实页面和跨层交互时才启用 E2E。

单次运行成功，只能说明这次被检查到的行为符合预期。某个页面恢复场景跑通，不代表所有页面都能恢复；浏览器里通过，也不代表原生容器同样正常。

尤其要警惕批量生成带来的批量误判：把进程正常退出当成业务通过、只凭包名和版本号认定安装包出自当前源码、页面更新后继续沿用旧连接，这些都是真实运行中出现过的问题。后面补业务断言、核对测试对象、校验证据，针对的正是这几类问题。

04 让业务场景可以自动执行

本章讲业务描述怎么变成可执行用例，也解释“能跑”和“断言有效”为什么必须分开确认。

4.1 将业务描述接入测试执行

2026 年 3 月，「我的」页面的用户故事（Story）已经用 Given/When/Then 写好了验收场景，分别定义前置条件、用户动作和预期结果，覆盖用户信息、按钮、空状态、客服相关行为。但当时的 TDD 流程读的是另一份验收规格，这些业务场景还没接进自动化执行。

项目引入 playwright-bdd，把业务场景转成 Playwright 原生用例，既保留可读的场景描述，又复用 Playwright 的执行和报告能力。首批 6 个场景、共 12 个 Step 全部跑通；3 月 20 日的记录显示，无头模式耗时约 7.7 秒，带界面模式约 11.1 秒。这只是早期单个 H5 页面的运行记录，App 回归的耗时后来需要单独测量。

业务描述放在.feature 文件里，步骤实现把每条描述映射到数据准备、页面操作或结果检查。FE 侧的 playwright.config.ts 通过 defineBddConfig 指定 Feature 和 Step 文件，步骤代码调用 createBdd()注册 Given/When/Then。生成器把场景和步骤实现转成 Playwrightspec，输出到.features-gen 目录；Playwright 按项目配置执行，JSONreporter 输出结构化结果，供上层汇总。

图 4：业务场景与步骤实现共同生成可执行用例；复用生成物后仍需重新运行测试。

4.2 场景描述与断言需要表达同一项要求

场景能自动跑之后，场景描述和实际断言对不上的问题也暴露了出来。my-page.steps.ts 里有一条昵称步骤：场景要求展示固定昵称，断言却只校验去掉空白后文本长度大于 0。这样一来，页面显示了错误昵称也照样判成功，只要文本不为空。另一条身份标签步骤，也只校验了用户信息区域可见。

处理这类问题，先要明确验收的真实诉求。如果验收只要求区域里有内容，场景描述就该照实写；如果要校验特定昵称或身份，就得准备可控的账号数据，并校验具体字段值。Given/When/Then 能把团队讨论出的业务实例转成可执行场景，但 Then 里的检查够不够，取决于业务预期和步骤实现。

4.3 缓存生成用例，业务变化后仍重新执行

场景转换不必每次都重做。h5-bdd-cache.ts 读取 Feature、Step、Playwright 配置、包配置和锁文件，算出输入摘要；摘要没变且生成目录里已有 spec 文件，就直接复用，否则重新生成。业务代码改动不一定改变转换结果，所以复用生成物可以，但测试必须重跑，不能把上一轮的业务验证结论直接搬过来。

这份摘要只回答“生成输入有没有变”；生成目录里的文件有没有被其他进程改过，需要另加校验。

至此，业务验收描述已经可以自动执行。下一步要解决的是：同一个业务目标，怎么在不同运行环境里验证。

05 在 App 中验证同一个业务目标

本章说明同一个业务目标怎么分配到 H5、Android、iOS 和小程序，以及哪些逻辑没法跨平台共享。

应用初期基于 uni-app 复用业务代码，但浏览器、AppWebView 和小程序运行环境本身有差异。浏览器端可以断言 DOM 节点状态；原生权限、系统交互、桥接调用，则要各平台分别实现验证逻辑。以加载失败恢复为例，异常页由 Android 原生层渲染，恢复完成后内容由 H5 加载。只跑浏览器用例，观测不到两层之间完整的交互过程。

5.1 共享业务目标，各平台实现具体操作

7 月落地跨端设计，可共享的部分限定在业务意图、动作标识和后置条件。后置条件是动作完成后业务必须达成的结果，比如点击重试之后目标页面恢复。各平台围绕同一个业务目标完成验收；元素怎么定位、动作怎么执行、结果从哪里读，由各平台自己实现。

H5 继续用 Playwright；Android、iOS 接入 Appium 和对应驱动；小程序对接开发者工具的自动化能力。7 月 28 日的架构记录显示，H5 已有 16 个 BDD 场景，设备端先落地会员页一个场景，验证平台动作和业务目标能否对上。页面结构或驱动能力一变，对应平台的定位和观测逻辑就要跟着调整；共享业务目标之后，这部分维护量仍由各平台分担。

执行侧随后分成两条路径：跑提前写好的固定用例；读取当前界面节点，在计划限定的步骤内完成操作。两条路径都通过平台执行器接入同一套验收流程。

图 5：固定跨端用例与语义设备任务分别接入；指定执行器缺失时阻塞，不切换平台。

5.2 用统一接口调度，并分别保留观测结果

平台执行器（Runner）用四个接口接入统一流程：supports 声明能处理的任务范围，preflight 校验启动前置条件，run 执行场景，cleanup 释放资源。RunnerContext 向下传递本次授权、源码状态、尝试材料目录、剩余时间预算和取消信号。各平台仍可保留自己的准备和执行逻辑。

RunnerRegistry 按 ID 精确查找执行器，注册阶段禁止重复 ID。找不到指定实现，直接停止并返回 blocked，不会自动切到别的平台。每次 attempt 有独立材料目录，重跑生成全新的尝试记录，失败步骤的材料和后来跑通的材料可以分别留存。

不同执行器从各自的底层工具取结果：H5 的 ManagedCaseRunner 读 PlaywrightJSON 报告；Android、iOS、小程序适配器读内部执行器状态和平台证据包；AgentDeviceRunner 对接基于界面节点识别目标的设备步骤，返回每一步的观测。

环境是否就绪、动作是否完成、业务结果是否满足验收，要分开记录。统一返回格式便于上层汇总核对，但每个平台得输出足以判断后置条件的证据，上层才能汇总。最终能验到什么，受平台自身观测能力限制。

平台越接越多，前置准备也跟着变重。修局部问题的开发流程，仍要保留一条轻快的验证路径。

06 日常开发怎样减少重复准备

本章讲怎么避免微小改动每次都拉起完整设备链路，同时留一条可核对的回归入口。

8 月初，项目调整了默认开发路径：改代码时先定位对应源码，跑针对性的单元或集成测试；要看界面就直接操作当前平台窗口；只有明确需要自动化回归时才进 E2E 流程。resolveVerificationRoute 根据当前请求选一条路径，三条互斥。环境条件不达标，本次验证直接停止并返回 blocked，不让局部检查顺势扩展成装新包、切平台、跑整套回归。

图 6：本次目标只选择一条验证路径。精确用例在设备准备前解析，匹配零个或多个实例时停止。

6.1 先选定唯一用例，再准备设备

进入 E2E 流程后，交互式回归会绑定一个稳定的用例 ID，例如 Android 主文档恢复场景对应 android-h5-main-frame-recovery。localCaseCatalogBlocker 借助 Cucumber 源码解析器展开可执行场景，强制这个 ID 只能对应一个执行实例。它只读场景定义，不加载步骤钩子，也不连设备，所以能在初始化设备之前就发现用例选错、一次匹配到多个实例这类问题。

ScenarioOutline 模板的 Examples 表格，每一行参数都会生成一条独立执行实例。标签匹配到多行就会选中多个实例，即使模板标题相同也不能合并处理。匹配不到任何用例，或者匹配到多条实例，都直接终止执行。

H5 还会校验登记的场景文件和标题，标记 @skip 的场景直接跳过。公开的精确执行固定使用 mobile-414 这套 Playwright 配置组，worker 数为 1，关闭重试，报告里只有单次执行。mobile-414 属于 Playwright 配置，稳定用例 ID 标识具体场景，两者分开校验。

6.2 分别复用驱动连接和已准备的产物

缓存复用的是生成出来的用例，会话池复用的是驱动连接。DriverSessionPool 保存尚未完成的初始化 Promise，后续请求等同一个 Promise 完成，避免并发创建多套连接。驱动初始化完成后，在同一个池的生命周期内可以复用；池退出时统一关闭连接；初始化失败也要尝试清理已创建的资源。

驱动连接能复用，业务前置条件仍要逐条确认。会话池不会自动重置账号和页面，下一条场景还得自己确认前置条件，避免继承上一条用例留下的业务状态。用例范围不唯一，就在筛选阶段停下；驱动初始化失败，记为连接层面的问题。只有拿到对应的业务观测，才能判断场景的验收预期是否达成。

构建、安装、执行被拆成独立阶段。验收源码产物时，默认复用已经准备好的产物和安装记录，只有明确要求全新安装包才走独立构建安装。产物关联信息有效、设备与运行环境匹配，才允许复用；复用之后，当前用例的断言仍要照跑。

每次回归都配时间预算和清理逻辑。遇到确定性阻塞，记录原因后直接停止，避免单条用例反复重试、演变成没有边界的排查。接下来要核对两件事：业务断言是否成立；测试跑的那个包，是不是本次待验收源码编译出来的。

07 Proof Kernel 如何判定验收结果

本章介绍结果的判定主体、判定依据，以及 passed、failed、blocked、skipped 各自的含义。

举个例子：业务要求“网络恢复之后能重新进入首页”。App 启动命令正常结束，只说明命令跑完了，首页有没有真正恢复得单独检查。旧入口曾把退出码 0 直接当成全部验收项通过，用例缺断言也能汇总成通过；V3 改造移除了这条默认通过逻辑。

验收请求（Issue）描述业务目标、执行范围和验收条件。VerificationPlan 把每条验收条件分给一条登记过的测试，同时指定判定依据，也就是代码里的 oracle。ProofKernel（下文简称内核）校验计划和执行条件，再调用平台执行器 Runner；Runner 操作页面，返回观测结果和证据材料。Agent 可以参与分析、生成计划，但用例是否通过，完全由内核按统一规则算出。

图 7：内核先校验计划，再执行任务，按逐项断言和必要证据判定结果，最后封存材料。

7.1 让每条验收条件都有明确的判定依据

Issue 里不存 Shell 命令、XPath 和屏幕坐标；Plan 只能选用已登记的能力，不能把任意 Shell 命令带进执行流程。验收项写的是「首页恢复」，判定依据就必须是针对首页恢复的检查记录，光有“启动 App”这条动作记录判不了通过。

runIssueVerification 入口先解析输入格式。解析失败就不生成执行记录；解析通过才创建独立的临时目录 attempt。后面的配置、身份校验即便阻塞，审计材料照样留得下来。

内核分两轮校验计划。纯配置阶段，靠 accountingErrors 检查 Plan 内部的 issueId：每条验收条件必须恰好分给一个任务，oracle 必须和选中的能力匹配。出现未知验收项、能力未实现、unresolved 字段非空，直接阻塞本次验收。任务涉及平台或外部影响时，还要同时满足 Issue 声明范围和本次运行授权。拿到源码信息后，内核继续检查变更文件和验证任务之间的对应关系。

这套文件检查能发现“改动没有分配验证任务”的情况。语句覆盖率、用例发现缺陷的能力、判定依据和业务需求是否匹配，得另行评估。

7.2 正常返回、异常与提前阻塞分别怎样处理

每个任务依次执行 preflight→ run → validateRunnerProof →cleanup。正常路径逻辑简单，真正决定结果可信度的是异常路径：预检失败就不能继续操作页面；运行流程已中断，就不能拿残缺观测判通过；即便前面阶段失败，清理逻辑也应尽量执行。

图 8：预检不满足、运行异常或取消，都会跳过后续环节：前者跳过运行与证据核对，后者跳过证据核对。这些路径仍在尝试清理，提前阻塞则保留最小审计包。

前面的任务停止后，尚未启动的后续任务写入 skippedTaskIds。10 月 29 日又补了一类场景：某条精确用例受当前数据条件限制、本就不适用，任务直接返回 skipped。两种情况下业务都不算通过，区别在于前者完全没运行，后者做完了限定范围内的前置条件检查，并产出证据证明当前条件不适合执行。Runner 正常返回时，内核依旧分开校验环境、动作、逐条断言和证据文件。

如果在业务动作之前就发生基础设施阻塞，内核只校验现有材料，不会要求提供理论上产不出的业务截图。只要有一个任务返回 businessActionCompleted=true，流程结束时内核会复查源码上下文；源码漂移或复查失败，整轮验收优先置为 blocked。

以首页恢复用例为例：设备连接失败记为 blocked；拿到有效页面观测但首页没恢复，记为 failed；预定动作执行完成、首页断言成立、必需证据齐全，三者同时满足才标 passed。当前业务数据不足且用例允许该场景不适用，标 skipped。skipped 不等于通过；缺必需证据会降级为 blocked。汇总时，内核先处理计划错误、阻塞和源码漂移，再处理业务失败与不适用场景，最终状态以证据索引为准。

索引写完文件清单和状态后，材料整包原子封存。重跑会生成新的 attemptId，旧的失败记录完整保留。翻历史报告时，要把原因码、发生阶段和最后一条可靠观测放在一起看。

7.3 缺少可用夹具时怎样判 skipped

音频 APM 用例依赖当前聊天窗口里已读取或本人发送、尚未播放的语音。2026 年 9 月的一次真机运行没找到符合条件的语音，而旧逻辑把进入会话这类安全 UI 动作也算作业务动作，结果被归为 blocked。

10 月 29 日修改后，businessActionWasExecuted 只统计 external-consequence 类型动作：这类动作真正执行了，或者动作发出后业务后置条件失败，才算发生过业务动作。打开页面、进入会话这类 safe-ui-change 操作不再改变这个标记。

ManagedCaseRunner 也没有把所有夹具缺失场景一刀切成 skipped。只有 Android 的 chat-audio-playback-failure-apm 这条精确用例，同时满足固定原因码、证据策略版本>=3、探针记录完整、session 清理确认完成、未执行外部后果动作、证据包完整，才返回 CHAT_AUDIO_APM_FIXTURE_NOT_APPLICABLE。

内核复核后保留 skipped，验收项的 met 仍为 false；进程零退出也不会把结果算成 passed。

三次关键真机运行分别澄清了一个问题：9 月 20 日暴露旧归因逻辑会把安全页面动作统计成业务动作；10 月 28 日确认真机执行链路和夹具识别可用，但严格用例没有触发真实播放；10 月 29 日修正归因，同一条用例以 skipped 状态封存。这组记录验证的是安全动作边界和结果分类逻辑，音频播放业务本身是否通过，不在它们的证明范围内。关键耗时、产物版本与复核线索见附录。

7.4 超时后怎样停止，而不只是返回一个超时结果

准备阶段和业务执行阶段分别计时，停止与清理另有独立配额。withinBudget 超时后发送 AbortSignal，最多等 3 秒确认底层结束；清理用独立信号，预算 3 秒。runManagedProcess 向子进程组发 SIGTERM，等 250ms 后升级为 SIGKILL，再检查终止状态。底层动作能不能真的停下来，取决于执行器有没有正确实现取消和进程管理。

独立超时包装已经覆盖准备、预检、运行和清理。配置身份采集、证据核对、源码复查和封存逻辑还没做同等包装。源码复查完成后内核仍会检查截止时间，超时可以转 blocked。只在入口设一个总预算，保证不了每个阶段都能及时终止。

7.5 内核能检查什么，仍然信任什么

内核能识别断言缺失、证据为空、对应关系错乱。截图是不是对应目标页面，用例对「首页恢复」的判断逻辑是否匹配业务要求，仍依赖 Runner 和用例实现，需要独立评审。

登记用例、执行脚本、判定规则和关键配置共同决定一次验收怎么跑，本文把这套执行规则和配置统称为控制面。控制面本身也要留版本记录。AipbProjectProfile 针对 catalog/features/scripts/src、关键配置和锁文件生成按路径排序的内容摘要，拒绝符号链接和特殊文件。catalog/release-policy*.json 不纳入这份摘要，走独立签名校验；外部工具和依赖版本另需维护。

只有传入 expectedControlPlaneFingerprint，内核才比对实际摘要和预期摘要；不传就只做记录。结束阶段的源码复查不会重新计算控制面摘要。记录下来的摘要证明不了规则来源可信；预期值怎么来、规则怎么受保护、执行器和判定依据是否正确，仍要靠独立评审和 CI 管控。

08 明确测试对象与 App 身份

本章讲怎么证明：设备上被测的 App 确实来自本次源码的构建产物，而不是旧包或错误页面。

逐条断言全过之后，还有一类常见问题：手机上装的 App，是不是刚改完代码编译出来的那版。工作区源码已经变了，设备上可能还跑着旧安装包；包名和版本号完全一致，也可能对应不同的构建输出。分别记录源码、安装包、设备安装信息和运行页面，用来确认被测对象。

产物清单（ArtifactManifest）记录声明的构建输入与输出包之间的关联；安装回执（InstallReceipt）记录本地产物与设备侧安装信息之间的关联；运行记录（RuntimeContext）描述当前测试连接的 App、WebView 和页面环境。构建、安装、执行是三个独立步骤，日常回归可以复用已准备好的安装包。

图 9：源码、产物、安装信息和运行页面分别关联。安装回执只证明元数据关联。

8.1 从哪些输入计算源码身份

源码身份校验要同时采集两类输入：Git 状态指纹和选中文件的内容摘要。同一批文件加入暂存区或提交之后，git 记录会变，文件内容却可能一字未改，两者必须分开看。

catalog/source-inputs.json 按平台声明 repository/include/exclude，限定采集范围。Android 包含相关根仓配置、前端和原生壳输入；iOS 分别采集前端仓与原生仓，排除生成产物、依赖包和构建输出目录。采集会沿选中的 gitlink 递归。子模块未初始化或存在冲突时，strict 模式直接阻塞；已初始化的仓库允许记录未提交源码和 dirty 状态。

几种记录用途不同，不能互相替代。

输入清单要跟随构建流程维护，目前没有自动推导完整依赖图。外部工具链、忽略文件和服务端配置没有全部纳入，清单只能说明声明范围内的输入。

8.2 构建前后怎样核对，哪些变化可以接受

单独生成 Manifest，只能把当前输入快照和已有文件关联起来。受控构建会在构建前后各采集一次输入，保存构建命令和采集记录，再比对输入指纹；不匹配就拒绝生成清单。

Android 开发构建有个特例：Git 指纹变了，分支没变，文件内容完全一致，只是暂存或提交状态变了。这种情况下会继续比对文件内容，确认一致后允许更新记录；内容一旦有改动，直接丢弃新产物；写 Manifest 阶段还会再复核一次。这是 Android 开发构建的特例，不要当成通用构建规则，更不能理解成通用构建只比对文件内容。

图 10：通用构建比较输入指纹，Android 开发构建另有内容相同的状态变更特例。图中执行前的窗口核对以 Hybrid 页面为例，原生页面按 App 标识及任务要求校验。

输出包单独计算 SHA-256，避免把同名文件当成目标产物。Android 保存的 APK 副本以 SHA-256 命名；目标文件已存在时，摘要必须和待保存的 APK 完全一致。普通文件产物直接算内容摘要；目录产物按排序后的路径、类型、长度和内容计算，并拒绝符号链接。

Manifestv4 把环境、配置、严格模式和 sourceInputs 放进 build 段；源码身份放在 source 段；产物路径、SHA-256、字节数放在 artifact 段。生成 manifestId 时，会对除该字段外的全部对象算摘要，其中包含生成时间，所以同一份产物也可能得到不同 ID。自身摘要只能校验清单内容；发行者身份和签名来源另需校验。

Android 公开入口会在 source-artifact 准备阶段生成 artifact-verification.json，每次最多一份回执，把 Manifest、源码、产物摘要、验证时间和控制面指纹关联起来，减少下层重复扫描。下层优先校验这份回执的字节摘要，再核对本地产物；没有回执文件就直接校验 Manifest。它属于本次运行的校验回执，和下文说的安装回执用途不同。

这些检查仍不足以证明构建可复现。构建环境没有完全隔离，构建过程中改文件再改回来，也可能绕过前后快照比对。要进一步提高证明强度，得固定环境、锁定外部依赖。

8.3 安装回执与运行记录能证明到哪一步

Android 安装回执包含设备、App、Manifest、本地产物摘要、版本和 lastUpdateTime。执行前会重新读取设备安装元数据比对；靠安装更新时间，可以识别同版本覆盖安装。iOS 记录 BundleID、版本和 buildnumber，没有等价的更新时间字段，相同版本加构建号的覆盖安装仍有识别盲区。

Android、iOS 都不会读取设备上已安装的二进制文件重新算哈希。回执里的包哈希取自本地文件，证明范围明确标为 metadata-correlation-not-binary-proof，也就是只证明元数据之间存在关联。这个限制影响结论可信度，报告里不能省。

核对完安装信息，还要选定唯一的运行窗口。Android 从包名匹配的 WebView 候选集里，结合 PID、自动化 context、窗口句柄和 URL 筛选；候选唯一且观测稳定，才建立连接；连上之后重新读取 window.location.href，确认目标页面和运行环境。iOS 的枚举逻辑不同，没有 PID 等价证明，同样要校验窗口和 URL。

驱动记录保留 WebViewprovider、浏览器版本、ChromeDriver 版本和文件摘要。Chrome115 及以上比对前三段版本号，旧版本比对 major 版本号。这一步只做兼容性校验，不要求版本号完全一致。

包摘要证明不了远端 H5 有没有更新，同一个 URL 返回的内容也可能变。运行 URL 用来确认被测对象和运行环境；远端 H5 还得有额外的资源版本记录，才能对应到具体部署版本。

8.4 根据验证目标选择执行方式

9 月 16 日新增了两类验证目标，各自回答不同的问题。

Issue 和命令行传入的 verificationTarget 冲突时，内核停止执行。source-artifact 材料不足，也不会自动降级到 installed-app 接着跑。

测试对象身份和验收范围要分开判断。即使用 source-artifact 模式跑功能回归，也仍是 acceptance-only；要验收整套代码改动，得用 change-verification 模式，核对变更文件与验证任务之间的对应关系。

09 用 aipb-chat-device 观测和操作当前界面

确定测试对象之后，Agent 还要拿到页面控件、找出可操作的节点，并明确本次任务允许做哪些动作。aipb-chat-device 读取界面节点树，把控件整理成带角色、标签、文本的语义快照，给每个节点分配 @ref 短引用。调用方从本次快照里挑目标，设备层在执行动作前校验引用和授权。

aipb-chat-device 是独立维护的设备操作工具，以 MIT 许可发布，通过插件接入 我们应用 E2E。对外提供 iOS、Android、Web、桌面和 TV 接口，这里只讲和本仓库直接相关的三个后端。接口能调通，不等于业务用例通过；业务是否达标，要看平台的完整执行记录。

为什么自研中间层，而不是直接用现成工具？

• computer-use 管的是 Mac 桌面窗口；USB 连接的真机 Android 不属于 macOS 的可访问性对象；靠截图模拟点击，也拿不到 HybridWebView 完整的 DOM 状态。
• Maestro 的 YAML 配置和自动等待适合给冒烟测试做补充，但项目里大量使用 HybridWebView，官方文档也说明 WebView 元素不一定能靠系统可访问性树完整拿到。

所以确定性回归仍交给 Appium 和 Playwright，中间层只做一件事：把“设备当前界面”转成 Agent 能消费的语义快照，同时提供统一 CLI、常驻进程和可复核的运行记录。

9.1 用常驻服务保存连接和界面状态

设备操作常常要连着执行多条指令：读页面、点控件、读执行后的结果。每条命令都重连设备，会反复重建连接和界面状态。aipb-chat-device 把 CLI 客户端和设备连接逻辑拆开：daemon 常驻进程保存连接、会话和界面状态；平台后端负责读取控件和注入输入。一条 CLI 命令结束，下一条可以复用已有连接。

图 11：aipb-chat-device 完整结构：命令投影、统一传输、daemon 路由与常驻状态、授权和 refframe 安全面，以及本地平台与云 provider 执行分派。

CLI 解析参数，提交请求，输出 JSON。和 daemon 默认走 127.0.0.1TCP，传输换行分隔的 JSON；也支持 HTTP 入口 POST/rpc，遵循 JSON-RPC2.0。RequestRouter 校验连接 token；服务靠会话锁和设备锁管控请求，换个会话名也绕不开单台设备的并发限制。

命令和执行规则通过 CommandDescriptor 注册，路由和请求策略从声明推导。获取快照、点击、输入这些操作，交给 Interactor 或专用处理器，再由对应后端完成。

Android、iOS 的原生路径不依赖 Appium；只有启用了 WebDriverprovider 才会用到 Appium/WebDriver。iOS 的 POST/command 和 CLI 的/rpc 是两段不同协议，不能混为一谈。

各后端保留平台原生的采集与输入逻辑，异常处理区分读取失败和输入失败。Android 快照采集失败时，可以退回 helper 的一次性读取；手势一旦下发就不会自动重放，因为上一轮可能已经执行了一部分事件。

9.2 让每次操作受本次任务约束

连接 token 只能确认请求来源，不能授权任意业务操作。设备层还得知道本次任务被测的 App、允许的动作集合和授权到期时间，这些约束来自项目策略 ProjectPolicy，再叠加本次任务的 RunSpec。

图 12：请求准入先于设备发现；WebURL 与动作引用在处理器中校验，原生不逐动作读取前台 App 身份。

ProjectPolicy 声明允许的平台、App、环境和预算；RunSpec 进一步限定本次目标、动作目的（Intent）和有效期，不能放大项目授予的权限。请求准入阶段校验字段、目标 App、有效期和 Intent；打开会话时校验 appId，把授权摘要绑到会话上。后续命令不能删除或修改授权，也不能把无保护会话临时提权；预算检查发生在调用命令处理器之前。后续兼容迭代补齐了业务 Intent 授权和到期清理边界，相关验证在后文展开。

本仓库 E2E 内部的 executeDeviceAction 会为每个任务生成独立会话、project-policy.json 和 run-spec.json。平台、App、环境取自控制面已校验完成的授权；Intent 取自步骤的 id/action/target/purpose。适配器不会直接读仓库全局策略，控制面策略文件的保护由接入方自行保障。

处理受保护动作时，设备层核对当前引用、节点和 Intent 是否匹配，不会降级到坐标或选择器定位。Web 分支还会读取 window.location.href，校验来源、路径和环境。

原生后端有明确局限：不会每执行一个动作就重读前台包名或 BundleID。会话打开时锁定目标 App，但保证不了每一步动作执行时前台仍是它。任务可以配置 expectedEnv 或校验 URL，可原生后端拿不到可信 URL，于是受保护的修改操作直接停止。

9.3 中间层 Agent 更新后的兼容治理

本节解释两件事：为什么全量回归全绿，安全关键字段仍可能丢；以及如何靠跨层契约测试补上这个缺口。

2026 年 10 月 14 日，aipb-chat-device 完成了一次大规模 Agent 层代码更新，目标是在保留 AIPB 策略边界的前提下，把多平台设备能力、语义解析和安装源安全检查并入同一套执行模型。本次改动涉及 1239 个文件，新增 68481 行，删除 20566 行。

更新带来三点直接收益：设备层增加 HarmonyOS 支持；多节点匹配返回 ambiguous，不再默认选第一个；安装源网络入口拒绝 URL 凭据、本机地址、非公网地址和异常 DNS 结果。三者分别加强了跨平台覆盖、语义动作确定性和安装链路安全。

AIPB 守卫信息要穿过多层边界：rawCLI 解析参数，commandgrammar 控制允许的 flag，commandschema 约束结构化输入，commonToClientOptions 组装 client 参数，daemon 再做请求准入、会话绑定和预算校验。大规模改动只要漏掉其中一层，CLI 参数显示正常，守卫却已经失效。

这次更新的验证回执记录了静态检查、构建和 TypeScript 校验，750 个测试文件共 6291 项测试全部通过。可后续兼容复核仍发现安全字段在跨层传递时被漏掉。这说明：全量回归通过只代表当次回归范围内没发现失败；安全关键字段从输入到 daemon 准入的逐层契约测试，是另一项替代不了的工作。

兼容复核发现 commonToClientOptions 不再透传 runSpec、projectPolicy 和 intentId，commonProperties 也没有声明这三个字段。前者导致已经读到的守卫信息在组装 clientoptions 时直接丢失；后者配合 additionalProperties:false，会把携带这几个字段的结构化输入直接拒掉。

10 月 15 日完成兼容修复，恢复了 client 字段投影和结构化 schema，新增 72 行回归测试，覆盖 press、click、fill、longpress 四条 CLI 命令的字段投影与 schema 校验，同时验证无守卫兼容和拒绝非字符串字段，共生成 12 个 case。10 月 29 日定向复跑，12 项全部通过。

这个缺陷不是守卫算法算错，而是安全字段跨层传递少了一段逻辑。它也改变了回归策略：关键安全字段不能只验证某一层读到了参数，要从命令输入、schema、clientoptions 一路校验到 daemon 准入，避免界面参数看着正常、实际约束已经失效。

9.4 后续兼容收紧授权和清理边界

后续兼容迭代继续收紧守卫语义：不再靠关键词统一拦截消息发送、删除、下单、支付、隐私同意类操作；只有 RunSpec 显式声明了对应业务 Intent，动作才允许执行。完整用例授权本身已包含用例需要的业务动作，不需要每一步再确认一次。

取消关键词拦截之后，边界仍完整保留：动作要匹配当前 Intent 和语义节点；ref 必须来自当前 refframe；会话、App、环境、有效期和预算全部继续校验。RunSpec 没声明的动作和目标，照样不能执行。

同一批改动还处理了 RunSpec 到期的资源清理。expiresAt 是绝对截止时间，不会因为排队或 open 操作延迟而顺延；只有原 RunSpec 绑定的现存 session，可以在到期后最多 2 秒执行 close。宽限期内禁止 app-onlyclose、shutdown、save-script 和脚本发布；拿到会话锁后还要再校验一次身份和时间边界。

这批工作区兼容改动已完成定向验证：字段投影、请求执行范围、业务 Intent 授权、到期 close、租约清理、脚本发布清理和 daemonclient，共 7 个文件、201 项用例全部通过。单元和契约边界已经锁住授权逻辑与到期清理逻辑；但代码有没有跟随目标版本发布，要和验证结果分开看。

9.5 动作发出前，旧引用就要过期

点击可能触发页面跳转，而响应返回超时。调用方不能仅凭超时就断定动作没执行，更不能继续用上一页的节点引用，否则会误点新页面的其他控件。

图 13：引用在副作用发送前失效；响应成功或超时都不会恢复旧引用，后续动作需重新观测。

实现上，最新观测树 session.snapshot 和动作引用集合 refframe 分开存储。refframe 保存生成引用那一刻的节点树、代次、有效状态和本次返回给调用方的节点范围。内部只读采集可以更新观测树，但不会自动恢复旧引用的授权。

完整快照可以授权快照里的全部节点引用；find 查询和动作后的差异观测只返回部分节点，那就只授权这一部分。例如 @e12~s42 表示 s42 代观测生成的节点引用，e12 不能当成跨页面稳定的元素 ID。admitRefMutation 校验引用集合的有效性、代次匹配以及节点是否属于本次返回范围；局部结果必须带上带代次的引用。

expireRefFrame 在设备副作用发出前同步把引用标记为失效，然后才等待设备响应。哪怕点击超时，旧引用也不会恢复。要继续执行需要节点引用的受保护动作，必须重新观测，拿新快照对应的引用。

这套逻辑会增加读取次数，但把动作的执行范围限定在刚刚观测过的界面节点上，避免页面跳转或请求超时后误用过期节点。

10 E2E 执行固定步骤，并在本地判断断言

Agent 可以交互式读快照、挑下一步，用来做页面探索。本仓库的 E2E 适配器只执行 Plan 预先写好的 deviceSteps，循环过程不交给模型决定下一步；固定跨端用例仍由 Playwright/Appium 这类执行器承担。

语义适配器默认加载 Frontend/aipb-chat-device/bin/aipb-chat-device.mjs，也可以从 AIPB_CHAT_DEVICE_BIN 或 PATH 环境变量读取；找不到 CLI 直接返回 blocked。每一步都会重新采集界面：动作类命令用-i 交互快照，把节点引用 refsGeneration 一起提交；断言读普通快照，由执行器在本地判断。Plan 里的动作名 long-press 由适配器映射为设备 CLI 的 longpress。

图 14：固定步骤循环分为动作和断言两类。正常执行后先尝试关闭会话，再整理证据并关联验收项；阻塞异常单独返回，不组装验收断言。

这些断言没有内置的自动轮询等待。匹配到一个节点，不等于像素级可见；文本出现，也不等于后端业务已经处理完。动作之后的 verify/settle 只观测界面变化，界面稳定和业务验收通过要分开判断。

执行步骤和验收项靠 acceptanceId→ oracle.ref → postconditionId 建立映射。执行器产出步骤后置条件的观测，Runner 按标识组装验收断言；缺少指定观测，默认判不通过。这条映射能核对观测对应的是哪条验收需求，但断言本身够不够证明业务正确，仍需评审。探索中跑通的操作，必须明确动作约束、后置条件和证据要求之后，才能纳入回归计划。

执行器区分正常完成和执行阻塞两条路径。步骤阻塞时，executeDeviceAction 抛出异常，finally 块只尝试关闭会话，不再汇总证据引用，也不返回 postconditions。步骤正常完成，先尝试关闭会话，再整理证据、映射验收项；关闭会话失败同样抛出异常。已经产生的阻塞异常不会被后来的关闭错误覆盖。

任务预算 120 秒，最多 8 次动作、24 次观测，不配重试；RunSpec10 分钟后过期。每条 CLI 命令同时受 ProofKernel 的剩余预算和取消信号管控。材料保存在<taskId>.agent-device/，包含前后截图、driver.log、策略和 RunSpec；快照 JSON 写入日志。RunSummary 会话摘要记录耗时、动作次数、观测次数、重试、停止原因和未验证项。completed 字段只代表会话执行结束；E2E 最终是否通过，仍要看断言和证据要求。

11 用一次断网恢复检验这套架构

前面讲了各项机制，下面用一次真实运行把整套逻辑串起来。Android 断网恢复用例同时覆盖网页和原生两层：H5 主文档加载失败，App 展示原生异常页；离线点击重试，仍会触发重试；网络恢复后再点，异常层消失，H5 页面正常加载。这个用例能同时检验执行器的故障注入能力、两层界面的观测能力，以及页面重建之后的证据获取能力。

图 15：恢复后重新发现目标页面并建立连接，取得 DOM 断言；两次尝试分别保留。

11.1 先证明失败的是主文档

用例只让目标 WebView 进入离线，整机网络保持连通；借助网页调试协议 CDP 关闭缓存、绕过 ServiceWorker，并在 URL 上追加本次恢复标记。这里不模拟整机断网，也不注入全部资源类型的故障。

图片加载失败不等于主文档加载失败。观测器要在导航发起前注册，从 Network.requestWillBeSent 里筛出目标 DocumentURL 并记录 requestId，只接受同一个 requestId 对应的 Network.loadingFailed 事件。首次导航和离线重试各存一份这样的关联记录，同时校验原生异常标题和重试按钮。这样才能确认异常页来自本次主文档失败，而不是某个子资源报错。

11.2 页面恢复了，自动化连接却没有恢复

9 月 17 日那次运行，前四步全部成功：网络恢复后点击重试，异常层消失，截图和原生页面树里都能看到 H5 首页。但测试流程调用 Appium 重新绑定 WebView 时超时了。证据确认页面已经渲染，自动化却拿不到恢复后的 DOM 断言；缺少最后一步断言，本次结果标为 failed。

排查方向锁定在一个假设：页面完整重建后，旧的 Appium/ChromeDriver 连接仍指向旧的 DevTools 窗口。修改后的步骤逻辑是：异常层隐藏后，重新从目标 App 的 DevTools 端口查找页面；候选页面必须和初始页面同源、路径一致、环境匹配，且候选唯一，才建立全新的 CDP 会话，读取实际 URL 和正文容器 uni-page-body。

9 月 18 日的新尝试，1 个场景、5 个步骤全部通过，总耗时约 54 秒。证据包里保存了两次主文档 net::ERR_INTERNET_DISCONNECTED 的失败记录；恢复完成后，正文容器包含 4 个直接子元素。新的通过记录不覆盖旧的失败记录：失败尝试 60a7f0e1、通过尝试 30a95002，两份材料都在.aqe-output/e2e/目录下，可以对照确认修改点在测试连接和取证逻辑。

历史记录和当前规则要分开看。9 月 17 日的绑定超时保留当时的 failed 结果；按现在的规则，恢复步骤找不到或连不上目标页面会归为 blocked。只看最终状态定位不了责任，得结合原因码、失败阶段和最后一次有效观测，区分“产品没恢复”和“测试链路断了”。

11.3 这次通过证明了什么

唯一候选检查和真实 URL 比对，避免了读到错误页面；正文容器子元素非空，排除了完全空白页。这些条件满足了本次加载恢复的验收要求。但 4 个子元素也可能只是骨架屏或错误内容，要完整验收首页业务可用，还得补上对应区域和交互逻辑的断言。

当前观测能确认：重试前异常层可见，重试后异常层隐藏且能读到 DOM。要证明“正文先就绪、异常层后隐藏”，需要把同一次加载的就绪事件和隐藏事件关联起来，光靠两张截图推不出事件顺序。

用例结束后，把 WebView 恢复在线，尽量还原缓存和 ServiceWorker 设置，关闭 CDP 会话，移除端口转发。部分设置只能尽力恢复，清理残留单独记录，避免下一条用例继承离线状态。

12 证据留存与阶段成果

本章解释为什么同一次验收的失败记录和通过记录都要保留，以及怎么核验一份证据包。

恢复案例要同时保存失败和通过记录，其他验收场景同理。源码、安装版本或观测逻辑一变，重跑得到的就是新条件下的判定。只留最后一次通过记录，复盘时说不清上一轮失败在哪一步、后来改了什么。框架把每轮执行记为独立尝试，用 runId 和 attemptId 关联整套材料。

图 16：材料先隔离写入，再核验、生成索引并整包发布；读取时重新校验。封存完成不等于业务通过。

12.1 每次尝试独立写入，再发布完整证据包

createEvidenceAttempt 生成 runId，对应一次验收；每次重试生成新的 attemptId，临时目录再加随机后缀。截图、日志这类运行中产生的材料，和正式发布记录隔离开。运行过程中可以更新 run-state.json，已发布的历史记录不会被改动；重跑生成全新 attempt。

Issue 入口的目录结构如下，执行器原始材料和任务子目录省略。核验一次尝试时，要确认结果文件和证据索引属于同一组 runId/attemptId。

<issueId>/
  .tmp/<runId>-<attemptId>-<nonce>/
  <runId>/<attemptId>/
    issue-contract.json
    run-authorization.json
    source-context.json
    control-plane.json
    verification-plan.json
    task-results.json
    blocker-resolution.json
    run-result.json
    evidence-index.json
    #Runner 原始材料与任务子目录省略

JSON 文件、结果和索引都用 wx 模式创建：只新建文件，同名文件已存在就报错，防止旧记录被覆盖重写。wx 不改变目录权限，也不提供写完之后防篡改的保护。

12.2 执行结果与材料完整性分别判定

sealEvidenceAttempt 第一步校验执行结果与材料属于同一次验收：核对运行、尝试身份、用例、验证目标和证据策略。必需文件必须存在且内容非空；设备子包额外校验 RunSpec、前后观测和执行状态；场景数量、唯一键和观测顺序要保持一致。判 passed 之前，还要确认业务动作已完成、场景后置条件已满足。

封存过程有两轮材料校验，三个状态字段分别保存各阶段的结论。

图 17：第一轮核验后写结果，二次核验后写索引；最终以索引状态为准。恢复只接受唯一且为 blocked 的链末端。

二次遍历读取文件内容，计算 SHA-256 和字节大小，记录步骤与工具版本，补充材料一并纳入摘要集合。全部完成后输出 evidence-index.json，外部消费方采信索引里的 finalStatus。证据错误单独记录；即便最后因材料不全变成 blocked，已经观测到的业务失败和原因也会保留。

执行前置阶段就阻塞的情况不会产生设备截图和业务观测。框架会生成最小审计包，保存 Issue、授权、源码、控制面、Plan、任务结果、阻塞处理和结果文件。显式配置选项时，设备子包也可以封存不完整的 blocked 材料，但这类记录不满足业务通过或业务失败的完整证据要求。

12.3 发布与读取各检查一次

结果、材料、状态都就绪后，靠文件系统 rename 原子发布，外部消费方不会看到文件分批移入正式目录的中间状态。

读取证据包时，validateEvidenceBundle 重新枚举全部文件，要求磁盘实际文件集合与索引完全匹配，复算 SHA-256 并核对字节数。新增、删除、改内容、用符号链接，一律拒绝。随后核对结果、索引的 runId/attemptId、状态和策略版本，并基于代码重建通用与当前用例的必需文件策略。删掉索引条目，也绕不开必需材料校验。

这套检查仍有边界：封存没有文件系统快照隔离；二次枚举不能保证目录全程没有并发写入；证据包本身没有独立签名；目录不是只读；也没有 fsync 保障断电持久化。如果主体能同时改写文件和索引，校验基准照样被篡改。要更强的留存保障，得额外保护存储权限和校验基准，不能只靠一句“已封存”。

12.4 恢复会创建新尝试，不接着操作旧设备状态

resume 时先校验同一 runId 下已封存的证据包，再用 resumedFromAttemptId 找到没被后续恢复引用的链路末端。末端必须唯一且状态为 blocked；出现分叉、审计记录异常或末端状态不匹配，直接拒绝，也不看文件修改时间。

恢复复用 runId，生成全新 attemptId，重新读取 Issue、Plan 和本次授权，从头完整执行；不会从上次的设备步骤断点接着跑，旧证据包完整保留。阻塞记录保存发生阶段、原因码、责任方和处理动作，用于复盘当时为什么阻塞、修复后执行了哪些逻辑。

12.5 阶段成果要按验证对象分别看

2026 年 8 月 13 日的发布加固验收，记录了实现层面的改动。改造之后，源码、产物、安装、运行分别留存证据，验收也有了明确的拒绝条件。

本次验收基于 catalog/fault-injection-cases.json 登记的 13 类故障，逐条比对预期状态和实际运行状态：业务后置条件失败输出 failed；源码、产物、驱动、证据等前置问题输出 blocked。该样本中没有观测到假通过，结论也仅限于登记的故障清单和本次验收。同期 Android/iOS 还没有大规模真机运行；小程序做了 6 次调试和验收尝试，均未通过。

其余阶段样本各自验证不同能力，需要分开解读。

各阶段回答的问题不同，不能合并成一个笼统的总通过率；规模统计只代表验证范围，不等于测试覆盖率。

汇总起来，机制层面已经得到验证：进程零退出但业务实际不通过，会判 failed；安装包和源码对不上，不计入本次验收；环境阻塞、数据不适用、业务失败各有独立状态，都不算 passed；13 类登记故障注入场景里，没有观测到假通过。

成本口径也补一句：整套体系由单人维护，没有设备农场，也没有 CI 集群；本地 catalog 类验收是秒级，真机涉及安装和执行，是分钟级。还有几项指标暂无数据：缺陷拦截率、长期假通过率、用例维护成本对发布质量的量化影响，都要靠更长周期的样本积累，见后续改进计划。

12.6 统计口径怎样避免误读

runtime-summary.ts 只用于内部复核：同一个逻辑请求区分首次尝试和后续重试分别统计；skipped 从各通过率的分母里剔除。环境阻塞修好后跑通的用例仍会被统计，所以这些指标不能直接当成产品的随机失败率。

耗时记录保存样本数量、最小值、P50、P95 和最大值；没有样本时，比例字段等于零并不代表系统稳定。

falsePasses 只检查内部一致性：终态标成 passed，但基础设施、动作、后置条件或证据标志不满足通过条件。它识别不出 oracle 和业务逻辑同时出错的情况，也不能凭一次零假通过推导长期假通过率，仍需独立复核、故障注入和线上缺陷反馈。

一次请求包含 2037 条不匹配改动，优化后耗时约 14.6 秒，标准输出约 968token；优化前同类路径超过 30 秒、约 87142token。完整文件清单写入证据包，控制面只接收摘要。这一轮没有执行业务任务，这组数据代表的是入口处理和输出开销，不能证明平台用例执行变快了。

13 后续改进计划

后续重点推进以下工作，都还不算已完成的结论。

业务验收：补齐断网恢复的业务断言，准备可重复、可清理的真实语音数据，验证音频 APM 的播放失败与旧 APK 兼容上报链路。

运行度量：积累首次结果、阻塞原因和分阶段耗时，评估用例维护成本，补齐入口全阶段的硬时限。

发布门禁：补齐目标平台的真机样本，校验产物与受保护策略，接入 H5 发布证据，修复证据配额重复计数，并在目标版本复核设备授权与清理。

证据留存：持续维护构建输入与远端 H5 身份；按需增强签名、只读存储和持久化，并用反例验证消费端确实会拒绝错误记录。签名替代不了 CI 的权限隔离。

14 可迁移的五条经验

这些经验不用照搬现有的工具和目录结构。它们回答的是同一个问题：AI 参与测试时，怎么让结果可核对、可追责、可复现。

1. 优先划分信任边界，再追求自动化率。模型负责理解和生成内容，确定性代码负责判定与证据封存。凡是“模型自称执行正确”的结论，都必须有一条不经过模型的校验路径。自动化率越高，缺了这条校验，误判扩散得越快。
2. 把“无法开展测试”当作一等结果。环境不就绪、用例前置条件不足、缺少指定执行器，都返回 blocked，不要自动换平台、换选择器接着跑；skipped 不计入通过。否则就会出现这种情况（以下数字仅为示例）：报表显示 16/16 全部通过，实际上大部分用例根本没跑。
3. 执行器可以替换，证据契约不能改。H5、App、小程序统一观测和证据契约，执行器内部实现可以自由调整。跨端真正复用的是业务意图、caseID 和证据格式，而不是把脚本复制一份。
4. 界面引用要有代次管理。凡是“先定位元素、过一会儿再操作”的逻辑，都得回答一个问题：定位那一刻和点击那一刻之间，界面变了没有。refframe 失效强制重新观测，比各种重试策略更能避免误操作。
5. 保守约束要落在数据结构上，而不只是报告措辞。别只在报告里写“可能”“大致”，要让结果结构本身只能表达已经证明的范围。证据状态字段区分 requestedStatus、provisionalStatus、finalStatus；Issue 写明 coverageClaim；被测对象区分 installed-app 和 source-artifact。

如果只能选一个起步点，不必先搭完整平台。第一步，挑一条高价值的真实业务链路，把“通过”定义为动作完成、业务断言成立、证据齐全三者同时满足，环境阻塞和数据不适用各自输出独立状态。这个可信闭环，少数几个开发者就能落地。第二步，为被测对象搭“源码→产物→安装→运行”的分段身份证明，让证据有完整可审计的生命周期。第三步，按需扩展平台执行器，再考虑发布门禁。

也要认清反向边界：如果目标是多团队共享设备、并发调度、CI 高频触发，本文这套单人真机模式就不够用了，需要另搭设备池、调度和隔离系统，属于另一套架构，本文没有覆盖。

附录 A 工程记录与复核线索

术语速查

术语表供阅读时查阅，无需预先记忆。