【关键词】
AI 自动化测试、质量闭环、AI 协同、产品设计、可追溯、制造数字化

【摘要】
测试平台引入 AI 后，如何保证质量结论可信？本文复盘精工智能 AI 自动化软件测试平台的设计过程：先划清责任边界，再设计判定与执行；让 AI 缩短认知链路而不替代质量责任，用权限、证据和审计守住质量闭环，让每个结论可执行、可验证、可追溯。

阅读导览

本文不是功能说明书，而是对产品设计过程的结构化复盘：为什么这样划分产品边界，为什么让 AI 参与草稿和规划，为什么必须把执行、证据和最终判定留在平台控制之内，以及这些选择对后续建设意味着什么。

编号	复盘主题	核心问题
01	设计起点	从角色、风险和产品边界开始
02	先设计判定	把结果、状态和最终质量结论分开
03	AI 的正确位置	让 AI 缩短认知链路，而不是替代责任
04	确定性执行	用工具网关与 Runner 约束智能行为
05	资产与上下文	先建可复用资产，再谈智能化
06	长任务与证据	为异步、失败和恢复设计产品体验
07	治理即体验	把安全、权限和审计做成可理解的操作流
08	原型带来的启发	从页面原型反推真实工作流
09	关键取舍	记录放弃什么，以及为什么放弃
10	衡量与演进	用结果指标和下一阶段问题校准方向

核心观点 AI 自动化测试平台的第一性原理不是“生成更多脚本”，而是让测试人员更快获得可信上下文，让执行过程始终可控，让每个结论都能回到版本、环境、步骤、工具和证据。

SECTION 01

01 设计起点：先定义产品边界

本次设计最先解决的不是页面数量，而是谁在什么场景下承担什么责任，以及哪些能力必须被隔离。

双端分工是风险设计

PC 应用终端承载测试人员的高密度业务工作：项目筛选、用例维护、接口调试、JMeter 压测、长任务执行和结果判定。Web 管理平台承载平台治理：组织、人员、角色、岗位、知识库、记忆、向量、模型、智能体、Gateway、MCP、Skill 和执行节点。两者共享服务底座，但不共享工作边界。

把高频测试操作放在 PC 端，减少治理菜单对测试人员的干扰。
把高风险配置和平台级变更放在 Web 端，集中权限、审批和审计。
用 applicationCode、Audience、路由和构建清单把双端边界落实到服务端，而不是依靠前端隐藏。

设计心得 产品边界不是导航栏的排列方式，而是责任边界、风险边界和发布边界的共同表达。

边界判断的三个问题

这个能力的主要使用者是谁？是测试人员连续操作，还是管理员偶发治理？
这个动作失败时影响一条用例、一个项目，还是整个运行平台？
这个能力需要被谁审批、谁审计、谁在结果上签字？

SECTION 02

02 先设计判定，再设计执行

自动化测试最容易被忽略的不是如何发请求，而是如何把结果变成可信、可追溯、可被组织采纳的质量结论。

保存结果不等于提交结论

产品将“保存测试结果”和“提交测试判定”明确拆开：保存只记录当前执行结果、说明、问题分类、缺陷关联和附件，不改变任务状态；提交判定才驱动 PASS 完成或 NG 进入测试回归。这个区分让自动化结果、人工复核和正式质量结论各自拥有清晰的责任边界。

图 2 测试用例状态与判定关系

对象	设计含义	产品约束
执行结果	AI/人工执行后产生的步骤结果、断言、日志、截图和说明	可以保存为草稿，不能单独作为正式质量结论
人工判定	测试人员结合业务语义、证据和缺陷关联提交 PASS/NG	改变任务状态，形成质量责任记录
平台状态机	平台校验版本、权限、前置状态和幂等条件	保证发布、下发、保存和判定的状态一致性

设计心得 先定义谁可以改变状态，再定义谁可以执行动作；否则自动化越强，错误结论传播得越快。

SECTION 03

03 AI 的正确位置：缩短认知链路

AI 最适合处理信息理解、测试点归纳、草稿生成、步骤规划和失败分析；最终责任仍由测试人员和平台规则共同承担。

从资料到用例的设计链路

输入：产品文档、接口定义、数据库信息、页面原型、历史用例和缺陷资产。
理解：按项目、产品、模块、环境和版本切分上下文，建立可检索的知识来源。
生成：AI 产出测试点、用例草稿、步骤和数据建议，统一进入“新增”状态。
复核：测试人员检查业务语义、覆盖范围、环境约束和风险等级。
下发：只有通过检查并具备必要上下文的用例，才能进入执行任务。

设计心得 “AI 可生成”与“平台可采纳”是两个不同问题。设计必须为二者之间保留可见的检查、补充和下发步骤。

可信 AI 的四个产品条件

条件	设计含义
有上下文	会话绑定项目、产品、模块、环境、业务对象和任务，避免无边界对话。
有工具边界	Agent 只能通过平台工具网关访问 HTTP、Playwright、数据库、JMeter、日志和文件能力。
有证据回写	每次工具调用、步骤结果、截图、trace 和日志都进入可追溯记录。
有人工结论	正式 PASS/NG 由测试人员提交，AI 只能提供草稿、建议和归因。

SECTION 04

04 确定性执行：让智能行为落到可控工具

OpenClaw 负责会话、规划和工具选择，平台服务、工具网关与 Runner 负责权限校验、确定性执行、证据回写和审计。

智能层与执行层分离

如果 Agent 直接连接数据库、执行任意脚本或操作生产环境，平台就无法解释一次结果是如何产生的。本次设计将 OpenClaw 视为外部独立运行时，通过短时任务令牌调用平台工具；工具网关校验项目、环境、工具和审批策略；Runner 在能力范围内完成 HTTP、Playwright、数据库、日志和 JMeter 执行。

图 3 智能编排与确定性执行的分层关系

角色	承担的智能/执行职责	必须守住的边界
OpenClaw	理解任务、规划步骤、选择工具、汇总结果	不直连数据库，不执行任意系统命令
工具网关	校验短时令牌、项目范围、环境白名单和审批策略	拒绝越权调用并记录审计事件
Runner	调用确定性执行器并回传步骤结果与证据	按节点能力、网络区域和工具版本受控运行
平台服务	保存结果、推进状态、归档证据、生成报告	以服务端状态机和幂等规则为准

SECTION 05

05 先建资产与上下文，再谈智能化

AI 的效果上限由上下文质量决定；上下文质量又由测试资产的归属、版本、结构和权限决定。

测试资产是平台的长期复利

项目、产品、产品模块构成稳定归属；环境集中保存 Web/API 地址、账号变量、测试数据、数据库和安全策略；产品文档、独立测试模板、历史用例、接口和缺陷形成可引用的知识输入。这样设计的价值不只是管理整齐，而是让每一次 AI 生成、执行和分析都有可重复的上下文。

资产层	典型内容	对智能化的作用
归属	Project → Product → ProductModule	决定用例、接口、任务和报告的业务边界
环境	地址、凭据引用、测试数据、数据库和白名单	决定一次执行是否允许发生以及在哪里发生
知识	文档、目录、切片、Embedding、引用来源	决定 AI 理解和检索的可解释性
模板	字段约束、输出结构、版本和发布状态	决定 AI 草稿能否进入统一用例模型
历史	执行结果、缺陷、判定、日志、截图和 trace	决定回归分析和失败归因能否复用

设计心得 真正可复用的不是一次 AI 回复，而是带有归属、版本、权限和证据的测试资产。

上下文设计的实践原则

先按组织、项目、产品、模块和环境过滤，再做向量相似度排序。
每条 AI 建议保留来源文档、版本和引用片段，允许测试人员回到原文核对。
把凭据放在企业密钥服务或加密凭证表，业务对象只保存 credentialRef。
知识库负责文档与切片，向量库负责集合、Embedding、索引和容量，两者职责分离。

SECTION 06

06 长任务与证据：把失败和恢复设计进产品

异步执行、批量回归、压测和 AI 任务都不是一次点击完成的动作，产品必须让用户看到状态、证据、阻塞原因和恢复路径。

任务体验的最小闭环

创建：记录项目、环境、模块、用例版本、执行器和发起人。
排队：进入 Celery/RabbitMQ 队列，展示等待、配额、节点和前置条件。
执行：通过心跳和事件流展示步骤、工具调用、日志、截图和耗时。
归档：结果、证据、trace、报告和审计记录落到统一存储。
恢复：按幂等键、状态版本、有限重试和人工介入恢复任务。

机制	设计做法	解决的问题
幂等	执行启动、证据上传、结果回写和状态流转使用 request_id / 幂等键	避免重复消费造成重复结果
心跳	Runner 和长任务定期汇报运行状态	区分执行中、节点失联和环境阻塞
有限重试	按错误类型、次数和环境策略重试	避免把产品缺陷误判为偶发成功
证据优先	步骤结果与截图、日志、trace、请求响应一起归档	让失败分析能够回到事实

SECTION 07

07 治理即体验：让安全成为正常工作流

安全不是一页配置说明，而是用户在选择环境、调用工具、发布能力和提交结论时能够理解并遵循的产品路径。

治理能力的三层体验

治理层	产品表现	形成的信任
看得见	平台把组织、人员、角色、岗位、模型、智能体、Gateway、MCP、Skill、节点列为独立治理对象	用户知道能力在哪里、谁在负责
选得对	环境白名单、工具授权、项目成员、审批策略和数据范围共同决定可执行动作	用户在操作前就知道是否被允许
查得到	记录操作者、终端、请求 ID、会话/运行 ID、对象、动作、前后快照、结果和时间	事后可以还原事实和责任

设计心得 越高风险的动作，越需要在界面上提前表达权限、环境和审批，而不是等失败后才解释原因。

把拒绝做成可行动的反馈

拒绝调用时说明缺少哪一类授权、审批或环境条件。
把“生产环境只读”“压测需审批”“数据库写入需二次确认”变成显式状态和按钮行为。
对第三方 Skill、Plugin、MCP 采用来源校验、静态扫描、人工审核和版本固定，形成可回滚发布链。

SECTION 08

08 原型带来的启发：从页面反推真实工作流

原型不是后端能力的证明，但它能把复杂业务压缩成可观察的操作节奏，帮助我们发现信息密度、入口关系和状态反馈的问题。

工作台应该先回答三个问题

从 PC 工作台、接口测试、用例执行和 OpenClaw 原型可以看到，测试人员进入平台后最关心的是：现在有什么任务？我应该先处理什么？当前结果是否可信？因此工作台需要把筛选条件、任务状态、风险指标、执行入口和待办动作放在同一视线内，而不是把信息拆散到多个孤立页面。

图 4 原型中的测试任务工作台

图 5 原型中的 OpenClaw 工作台

原型验证了什么，尚未验证什么

原型阶段	得到的认识
已验证	菜单分工、页面密度、三栏/双栏工作区、筛选与批量操作、会话上下文的可见性
待验证	真实权限拒绝、长任务断线恢复、批量任务进度、证据回写失败、版本并发冲突
设计结论	原型负责发现工作流和交互问题；契约、状态机、任务服务和审计负责证明系统行为

SECTION 09

09 关键取舍：记录放弃什么，以及为什么

产品设计不可能同时做到无限功能、无限自由和零风险；好的心得应该明确记录选择背后的约束，而不是只展示最终方案。

设计选择	放弃的替代方案	保留的长期价值
双端独立产品	把所有能力合并到一个 Web 或一个桌面端	测试业务与平台治理的用户目标、风险等级和发布节奏不同
OpenClaw 外置	把 Agent 逻辑全部内置在平台服务中	保留独立运行时的会话与工具编排能力，同时让平台掌握业务权限和证据
保存与提交分离	执行成功自动完成用例	避免 AI 或偶发结果直接成为正式质量结论
模块化单体起步	一开始拆成大量微服务	先控制复杂度，用 Worker、Runner 和队列解决可扩展执行
模板先行	让 AI 输出任意格式的自由文本	统一字段、版本和输出结构，才能纳入用例、报告和审计
生产默认只读	默认允许所有环境执行完整动作	把环境风险前置，减少误操作和不可逆影响

一个可复用的决策模板

先写清目标用户和业务风险，不先写技术实现。
把“必须保证的事实”与“可以让 AI 建议的部分”分开。
为每个高风险动作指定授权者、审批者和最终判定者。
确认失败后是否可解释、可重试、可回滚、可审计。

SECTION 10

10 衡量与演进：用结果指标校准设计

产品设计是否有效，不能只看页面完成度或脚本数量，还要看设计效率、执行稳定性、结论可信度和组织采纳程度。

图 6 试点阶段建议关注的结果指标

指标	口径	它回答的设计问题
AI 用例可采用率	人工检查后可下发的 AI 用例 / AI 生成用例	衡量上下文、模板和复核流程是否有效
用例设计提效	从文档到下发的平均耗时降幅	衡量 AI 是否真正缩短认知链路
自动化执行稳定性	排除产品缺陷和环境故障后的成功执行 / 总执行	衡量执行器、环境和任务系统的可靠性
结果可追溯率	可追溯到版本、环境、步骤、工具、证据和判定人的结果比例	衡量质量结论是否可解释
状态流转准确率	符合状态机和权限规则的流转 / 全部流转	衡量产品治理是否真正落地