核心判断
公开资料没有证明 OpenAI 已把所有应用所有功能完全无人值守自动测试。能确认的是：他们把仓库知识、运行环境、浏览器验证、日志/trace/eval、结构化反馈和人类 review 门禁组合成 harness，让 Codex 可以持续执行、验证、修正。
对 ZHCT 来说，正确目标不是一口气“全自动”，而是先让每个系统可观察、可复现、可验证、可回滚。
PDCA 系统思维 黑匣子思维 帕累托法则OpenAI 做法到本项目的映射
Harness engineering
把应用、仓库知识、架构规则和验证方式变成 Agent 能理解和执行的控制层。
落地：`zhctprompt` 记录每个系统的启动、测试、证据、修复和人审规则。
Browser use / Chrome
通过页面、DOM、截图、控制台、网络和 CDP 观察真实用户行为。
落地：Web/H5/后台先做 Playwright 和 Codex Browser smoke。
CI autofix
CI 失败触发 Codex 读取错误并生成修复建议，仍由测试和权限边界约束。
落地：业务仓库保留 repo-local test，控制项目统一错误 handoff。
Trace / eval 飞轮
用 trace、反馈、eval 和 Codex handoff 保存每轮经验。
落地：失败记录转成 regression 用例和 QA Gate。
总控闭环
需求 / 告警 / 变更
系统登记
启动环境与账号
用户行为测试
证据包
错误分类
Codex 修复
repo 验证
回归测试
人审门禁
任务索引
经验沉淀
本次新增资产
control/automated-testing/README.mdcontrol/automated-testing/system-test-registry.csvcontrol/automated-testing/test-case-template.mdcontrol/automated-testing/error-repair-record-template.mdstandards-stack/ai-engineering/automated-user-behavior-testing-control-standard.md
测试分层
| 层级 | 目标 | 工具 | 证据 |
|---|---|---|---|
| L0 | 服务能启动、路由可访问 | shell, curl, docker health | 命令输出 |
| L1 | 接口成功/异常/边界 | Apifox, CLI, repo tests | request/response 摘要 |
| L2 | 核心页面能走通 | Playwright, Codex Browser | screenshot, trace, console, network |
| L3 | 订单、采集、导出、回调等业务闭环 | Playwright + API + dev data | 业务数据断言 |
| L4 | 已知 bug 不复发 | regression suite | error-repair-record |
| L5 | 合并/上线前证据完整 | pre-submit, task index, human review | 任务索引、人审记录 |
优先试点
- store：登录 -> 菜品/档口 -> 绑盘打餐 -> 订单查询。
- qc：登录 -> 创建项目 -> 轻采集 -> 图片/录音上传 -> 导出。
- ai_web + ai_api：H5 首页、AI 营养交互、移动端布局、接口错误态。
生产写入、支付退款、补贴、合同投标承诺、客户数据、Chrome 登录态和发布上线都必须保留人工门禁。
验收指标
- 每个系统至少有 1 个可重复执行的 L0-L2 测试包。
- 每个核心系统至少 3 条主链路 smoke 用例。
- 每次失败都有证据包和错误分类。
- 每次 Codex 修复都能关联失败记录、修改文件、验证命令和人审结论。
- 自动化不绕过人工门禁。
下一步建议：先让 store 与 qc 各跑通一条 P0 smoke，再把失败记录转成 regression 用例。