有的做就把当前的事情做熟做好再说。然后再看看公司有没有机器学习，数采质量评估等测试的活，毕竟是具身智能行业最少也能吃几年。

AI 出来最大的问题是消费的的死亡螺旋坠落，裁的越多越没人敢消费，需求进一步收缩，这边也确实不需要更多人去测需求了。块也就 2,3 年吧大萧条就要来了，现在最大的问题是吉祥三宝，铁人三项都开始不要人了

1. 行业下行人少了非常多。
2. 大家想咨询的问题 AI 基本都能解决，即便是非常专项的问题 ai 解决不了一般人也遇不到呀。

我的意思是你搞来搞去，不如弄一下 agent 的远程协作，将任务跑到本地 codex，你说的开发一个接口，还停留在上个时代

你自己折腾出来的马鞍，不如 codex，Claude 一根毛。除非你们下定决心要持续维护了，反正舍本逐末你们老大怎么说就怎么搞吧。听老板就行

先开通 codex ChatGPT plus 试试先

AI 目前对逻辑覆盖，场景碰撞已经有较好的探索和覆盖了。但是前段时间发现整个研发链路（产品 - 开发 - 测试）都用 AI 后最大的问题是，AI 无法判断业务的使用方式，功能好不好用。交互在人类世界是否友好，这样的功能到底有没有用。这些就算有描述去堆积，执行时的判断体感 AI 都很难做出有效结果。

后端 50%，前端 50%-80%，测试 80%-100%。对了这个是噶人的比例

为什么要用需求文档去生成，我是建议用前端代码去生成，增量部分 ai 完全都能识别出来转化率基本是 100%，不可转化的原因也能很清晰的评估出来。需求文档拿来评估实现差异，实现缺失，增量实现部分用于人审评估。

codex ChatGPT5.6 启动，帮我生成一个覆盖功能测试用例较为全面的 skills，要包含生成，审核，标记标准 sop，然后帮我优化一下这个 skills 还有没有改进空间。
xxx 为什么没有生成，帮我看一下为什么然后优化到 skills 中。
一直重复就行

测试发展要么往技术深度走要么往业务广度走，取决于你在什么行业，其实大部分人就是这样是被事推着走的。

少看广告，真要看可以去 boss 上搜一下，聊一下现在吹牛逼的太多了

这篇文章的主线是成立的，而且表达很顺：从 “review 跟不上生成速度” 推到 “审证据”，再用 BDD 把契约落地，逻辑完整。主要改进空间在于：把几个概念边界再压实，否则容易被读者质疑 “这是一个新名词包装老实践”。

建议重点改 5 处

1. 弱化 “Trust Engineering 是一个已有标准答案” 的语气

目前写法像是在说行业已经有一个明确方法论叫 Trust Engineering。公开资料里确实有很多相近讨论，比如 trustworthy AI software engineers、programming with trust、AI harness engineering、spec-driven development，但 “Trust Engineering” 还不像 DevOps、SRE、BDD 那样有统一公认定义。

可以改成：

我把这种方法称为 Trust Engineering：不是单点工具，而是一套围绕 AI 产出物建立可验证信任的工程实践。

这样更稳，也更有原创表达空间。

1. 区分 trust 和 trustworthiness

你现在讲的是 “如何信任 AI 产物”，但更准确地说，应是 “如何证明 AI 产物具备可被信任的性质”。研究里也常区分：trust 是人的依赖决策，trustworthiness 是系统可证明的属性。可以补一句：

信任不是主观感觉，而是对 trustworthiness 的判断：系统是否具备足够的可验证证据，使人愿意在特定风险边界内依赖它。

这会让文章更严谨。可参考 Trustworthy AI Software Engineers。

1. 重新处理 Harness 和 Trust Engineering 的关系

你现在写 “Harness 管 AI 能做什么，但不回答怎么知道它做对了”。这个说法有道理，但略窄。最新关于 AI Harness Engineering 的讨论里，Harness 不只包含权限和沙箱，也包括验证、失败归因、可观测性、任务状态、episode package 等能力。也就是说，Harness 不只是 “防越权”，它可以成为 Trust Engineering 的运行时底座。

建议改成：

Harness 是 Trust Engineering 的执行基础设施，负责约束、记录和反馈 Agent 行为；Trust Engineering 则进一步定义如何把这些运行轨迹、测试结果和风险判定组织成可审查的证据链。

可参考 AI Harness Engineering。

1. 补一段 “证据也会造假或自洽” 的风险

你已经提到 “自证闭环”，这是全篇最重要的点之一，可以再往前推一步：不是有测试就可信，而是证据必须满足几个条件。

建议加一个小段：

证据本身也需要质量门槛。有效证据至少要满足四点：来源尽量独立、过程可复现、结果可追溯、失败时能给出定位线索。否则 Evidence Package 只是更漂亮的自我声明。

这能把 “证据包” 从文档包装提升为工程标准。

1. 补上生产后的信任闭环

现在文章偏重 merge 前验证，但真实系统的信任还来自上线后的持续观测。建议在六层之后补一个 “运行反馈层” 或在证据层里加入：

• 灰度发布 / feature flag
• 关键指标监控
• 错误预算或报警阈值
• 回滚策略
• 线上事件回灌到回归测试

一句话可以写成：

Trust Engineering 不应止步于 CI 绿灯。真正的闭环是：线上异常、用户反馈、事故复盘都会反向进入 Change Contract 和回归测试库，让证据系统随系统演化。

可以补充的几个概念

• Traceability Matrix：把 intent、invariants、tests、mutation、风险项一一对应。证据包不是散装截图，而是映射表。
• Risk-based Gate：风险不仅按 “低中高” 分，还可以按数据敏感性、可逆性、影响半径、是否涉及权限/资金/状态流转来打分。
• BDD 的边界：BDD 适合业务行为，不适合所有单元测试。不要把 Gherkin 写成 UI 操作流水账。
• 人工审查的新职责：人不再逐行看完所有代码，而是审契约是否正确、风险是否遗漏、证据是否独立、残余风险是否可接受。
• 负例库 / 历史故障库：信任工程最值钱的资产不是测试数量，而是团队过去踩过坑沉淀下来的反例。

一句话评价

文章方向很好，最需要加强的是 “概念严谨性” 和 “证据质量标准”。把 Trust Engineering 定义成你提出的一套实践框架，而不是已成型的行业标准；再把 Harness、BDD、Evidence Package、上线观测之间的边界说清楚，文章会更有说服力，也更不容易被技术读者挑概念漏洞。

来自 ChatGPT5.5 的重新评估，我个人觉得还是有进化空间的。当下 AI 已经基本覆盖 WEB UI,APP UI,API 等常规自动化覆盖和业务覆盖了，剩下专项测试我相信在这个领域深耕的人应该也会用的不错。确实现在的重点是面对庞大的生成该如何审核评估。

很有用的干货

自己写的所谓提示词工程再怎么搞，都不如 Claude 和 codex 的马鞍

AI 生成用例，审核用例，需求功能合理性推导，生成接口自动化，WEB UI,APP UI。人只去核对场景是否缺失，以及探索性测试，专项测试。感觉现在真的做到几年前大家的设想测试工程师应该去做更有价值的地方。一开始有点迷茫现在感觉就是这样的趋势走了

但现实基本上是先裁测试，发现还是得要几个测试再重新招

挺好的起码有事情可以做，等都 AI 化了测试组就该裁的没人了。

让我想起了应该是 2014 年左右，微软内部的 QA 全部转全栈的新闻。最后还是保留了 QA 的角色，我相信 AI 带来的软件行业的变化，最终不是将测试全部转为开发这么简单。如果是的话就不会有这个角色的设定了。这次不过是再走一回 2014 年

不是 monkey 不是猜测，前端整合出来的知识库会明确告知 AI 哪些元素是有意义的，对应元素点击后的响应是怎么样的

就是上面口语化的表达，你只需要告诉他调整效果就行了

人生很长 29 就不知道了往后怎么办。看看先吧不行就要跳出去干其他的积累经验了，别让自己的下一个十年还和现在一样

好用

RAG，pageindex，文本文档。不用纠结方式，你只要结构化掉，AI 自己就会去检索。

不冲突都可以，核心是用 AI 快速把页面关键元素扒下来，走的还是传统的 UI 自动化脚本 POM 框架的维护，只是节约了人工核对一个个点位的成本，毕竟 80% 的 UI 自动化成本都在元素定位上。这套方案就是把这个过程异步给 AI 去做了。不是自然语言的 AI+UI 那一套我自己也没咋用