【关键词】
AI 自动化测试、质量闭环、AI 协同、产品设计、可追溯、制造数字化
【摘要】
测试平台引入 AI 后，如何保证质量结论可信？本文复盘精工智能 AI 自动化软件测试平台的设计过程：先划清责任边界，再设计判定与执行；让 AI 缩短认知链路而不替代质量责任，用权限、证据和审计守住质量闭环，让每个结论可执行、可验证、可追溯。
阅读导览
本文不是功能说明书，而是对产品设计过程的结构化复盘：为什么这样划分产品边界，为什么让 AI 参与草稿和规划，为什么必须把执行、证据和最终判定留在平台控制之内，以及这些选择对后续建设意味着什么。
核心观点 AI 自动化测试平台的第一性原理不是“生成更多脚本”，而是让测试人员更快获得可信上下文，让执行过程始终可控，让每个结论都能回到版本、环境、步骤、工具和证据。
SECTION 01
01 设计起点：先定义产品边界
本次设计最先解决的不是页面数量，而是谁在什么场景下承担什么责任，以及哪些能力必须被隔离。
双端分工是风险设计
PC 应用终端承载测试人员的高密度业务工作：项目筛选、用例维护、接口调试、JMeter 压测、长任务执行和结果判定。Web 管理平台承载平台治理：组织、人员、角色、岗位、知识库、记忆、向量、模型、智能体、Gateway、MCP、Skill 和执行节点。两者共享服务底座，但不共享工作边界。
把高频测试操作放在 PC 端，减少治理菜单对测试人员的干扰。
把高风险配置和平台级变更放在 Web 端，集中权限、审批和审计。
用 applicationCode、Audience、路由和构建清单把双端边界落实到服务端，而不是依靠前端隐藏。
设计心得 产品边界不是导航栏的排列方式，而是责任边界、风险边界和发布边界的共同表达。
边界判断的三个问题
这个能力的主要使用者是谁？是测试人员连续操作，还是管理员偶发治理？
这个动作失败时影响一条用例、一个项目，还是整个运行平台？
这个能力需要被谁审批、谁审计、谁在结果上签字？
SECTION 02
02 先设计判定，再设计执行
自动化测试最容易被忽略的不是如何发请求，而是如何把结果变成可信、可追溯、可被组织采纳的质量结论。
保存结果不等于提交结论
产品将“保存测试结果”和“提交测试判定”明确拆开：保存只记录当前执行结果、说明、问题分类、缺陷关联和附件，不改变任务状态；提交判定才驱动 PASS 完成或 NG 进入测试回归。这个区分让自动化结果、人工复核和正式质量结论各自拥有清晰的责任边界。
图 2 测试用例状态与判定关系
设计心得 先定义谁可以改变状态，再定义谁可以执行动作；否则自动化越强，错误结论传播得越快。
SECTION 03
03 AI 的正确位置：缩短认知链路
AI 最适合处理信息理解、测试点归纳、草稿生成、步骤规划和失败分析；最终责任仍由测试人员和平台规则共同承担。
从资料到用例的设计链路
输入：产品文档、接口定义、数据库信息、页面原型、历史用例和缺陷资产。
理解：按项目、产品、模块、环境和版本切分上下文，建立可检索的知识来源。
生成：AI 产出测试点、用例草稿、步骤和数据建议，统一进入“新增”状态。
复核：测试人员检查业务语义、覆盖范围、环境约束和风险等级。
下发：只有通过检查并具备必要上下文的用例，才能进入执行任务。
设计心得 “AI 可生成”与“平台可采纳”是两个不同问题。设计必须为二者之间保留可见的检查、补充和下发步骤。
可信 AI 的四个产品条件
SECTION 04
04 确定性执行：让智能行为落到可控工具
OpenClaw 负责会话、规划和工具选择，平台服务、工具网关与 Runner 负责权限校验、确定性执行、证据回写和审计。
智能层与执行层分离
如果 Agent 直接连接数据库、执行任意脚本或操作生产环境，平台就无法解释一次结果是如何产生的。本次设计将 OpenClaw 视为外部独立运行时，通过短时任务令牌调用平台工具；工具网关校验项目、环境、工具和审批策略；Runner 在能力范围内完成 HTTP、Playwright、数据库、日志和 JMeter 执行。
图 3 智能编排与确定性执行的分层关系
SECTION 05
05 先建资产与上下文，再谈智能化
AI 的效果上限由上下文质量决定；上下文质量又由测试资产的归属、版本、结构和权限决定。
测试资产是平台的长期复利
项目、产品、产品模块构成稳定归属；环境集中保存 Web/API 地址、账号变量、测试数据、数据库和安全策略；产品文档、独立测试模板、历史用例、接口和缺陷形成可引用的知识输入。这样设计的价值不只是管理整齐，而是让每一次 AI 生成、执行和分析都有可重复的上下文。
设计心得 真正可复用的不是一次 AI 回复，而是带有归属、版本、权限和证据的测试资产。
上下文设计的实践原则
先按组织、项目、产品、模块和环境过滤，再做向量相似度排序。
每条 AI 建议保留来源文档、版本和引用片段，允许测试人员回到原文核对。
把凭据放在企业密钥服务或加密凭证表，业务对象只保存 credentialRef。
知识库负责文档与切片，向量库负责集合、Embedding、索引和容量，两者职责分离。
SECTION 06
06 长任务与证据：把失败和恢复设计进产品
异步执行、批量回归、压测和 AI 任务都不是一次点击完成的动作，产品必须让用户看到状态、证据、阻塞原因和恢复路径。
任务体验的最小闭环
创建：记录项目、环境、模块、用例版本、执行器和发起人。
排队：进入 Celery/RabbitMQ 队列，展示等待、配额、节点和前置条件。
执行：通过心跳和事件流展示步骤、工具调用、日志、截图和耗时。
归档：结果、证据、trace、报告和审计记录落到统一存储。
恢复：按幂等键、状态版本、有限重试和人工介入恢复任务。
SECTION 07
07 治理即体验：让安全成为正常工作流
安全不是一页配置说明，而是用户在选择环境、调用工具、发布能力和提交结论时能够理解并遵循的产品路径。
治理能力的三层体验
设计心得 越高风险的动作，越需要在界面上提前表达权限、环境和审批，而不是等失败后才解释原因。
把拒绝做成可行动的反馈
拒绝调用时说明缺少哪一类授权、审批或环境条件。
把“生产环境只读”“压测需审批”“数据库写入需二次确认”变成显式状态和按钮行为。
对第三方 Skill、Plugin、MCP 采用来源校验、静态扫描、人工审核和版本固定，形成可回滚发布链。
SECTION 08
08 原型带来的启发：从页面反推真实工作流
原型不是后端能力的证明，但它能把复杂业务压缩成可观察的操作节奏，帮助我们发现信息密度、入口关系和状态反馈的问题。
工作台应该先回答三个问题
从 PC 工作台、接口测试、用例执行和 OpenClaw 原型可以看到，测试人员进入平台后最关心的是：现在有什么任务？我应该先处理什么？当前结果是否可信？因此工作台需要把筛选条件、任务状态、风险指标、执行入口和待办动作放在同一视线内，而不是把信息拆散到多个孤立页面。
图 4 原型中的测试任务工作台
图 5 原型中的 OpenClaw 工作台
原型验证了什么，尚未验证什么
SECTION 09
09 关键取舍：记录放弃什么，以及为什么
产品设计不可能同时做到无限功能、无限自由和零风险；好的心得应该明确记录选择背后的约束，而不是只展示最终方案。
一个可复用的决策模板
先写清目标用户和业务风险，不先写技术实现。
把“必须保证的事实”与“可以让 AI 建议的部分”分开。
为每个高风险动作指定授权者、审批者和最终判定者。
确认失败后是否可解释、可重试、可回滚、可审计。
SECTION 10
10 衡量与演进：用结果指标校准设计
产品设计是否有效，不能只看页面完成度或脚本数量，还要看设计效率、执行稳定性、结论可信度和组织采纳程度。
图 6 试点阶段建议关注的结果指标
下一阶段最值得持续验证的问题
不同项目、不同文档质量下，AI 用例可采用率是否稳定？
测试人员对 Agent 解释、证据和失败归因的信任是否会随使用增长？
知识、记忆、向量和模型版本变化后，历史用例与回归结果是否仍然可比？
Runner 节点、队列和模型调用成本如何按组织、项目和环境进行配额治理？
SECTION 11
11 结论：把智能化建立在可控的质量系统上
这次设计最重要的成果，不是新增了多少菜单，而是建立了一套能让 AI、测试人员和平台各自承担正确责任的产品秩序。
AI 可以加速理解、设计、规划和分析；平台必须守住权限、环境、执行、证据、状态和最终质量结论。
六条设计心得
先设计责任边界，再设计页面和 API；双端分工应落实到服务端权限和发布物。
先设计判定和状态，再设计执行按钮；保存草稿与提交结论必须可区分。
让 AI 进入有上下文、有模板、有工具边界的工作流，避免把自由文本当作产品能力。
让确定性执行器承担事实，让 Agent 负责理解与编排，让平台承担状态与审计。
把失败、断线、重试、阻塞和恢复作为一等产品体验，而不是运维补丁。
用可采用率、设计提效、执行稳定性和可追溯率衡量价值，用真实试点持续校准设计。
最终判断 AI 自动化测试平台的竞争力，最终不在于模型能说出多复杂的答案，而在于它能否在正确的上下文和权限边界内，持续产出可执行、可验证、可追溯的质量证据。
参考基线
《AI 自动化软件系统测试平台产品介绍》；《自动化软件系统测试平台产品规划设计方案》V3.4；prototype/原型说明.md；prototype/index.html；prototype/admin.html。
质量结论要可执行、可验证、可追溯。这条原则不只适用于测试平台：制造业里每一个引入 AI 的数字化系统，都要先回答同一个问题——AI 的建议可以被谁采纳，关键动作由谁负责，出了问题能不能回到证据。把答案写进设计，系统才经得起长期运行。
精工智能数字化工厂，制造业Online，持续在场，赋能企业高质量发展。
