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

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

没有业务权限就白瞎，只能从开发沉淀的知识库进行二次挖掘。一步步完善是说你现在只有一颗积木，你需要将所有有关联的积木都做出来，然后在分层构建流程节点，场景节点，风险节点等

接口文档是黑盒的状态，AI 只能通过字段语义去判断依赖。你直接把接口文档对应的后端项目给 AI，让 AI 去做出来的测试用例起码依赖会大体正确的。但是就算这样你还会遇到新的问题，业务上下文看不到，说白了微服务参与进来又是新的黑盒状态，你需要一步步的完善知识库链路流程，这样生成出来的结果就很详细了。

公司有预算就先做吧，成本飙升也是好事情，否则就真没人啥事了，现在只是 AI 驱动端到端测试有很高成本，AI+ 用例生成 + 人工提示修改这条路成本还是相对低廉的。

角色设定

你是一位有 10 年经验的测试架构师，精通等价类划分、边界值分析、判定表、正交实验法等测试设计方法。

这个提示词已经是去年的过去式了。感慨一下去年学提示词工程，今年已经完全可以不 care 了，AI coding 的马鞍发展太快了，现在是一个月一个变化的感觉。

兄弟说实话，这个节点和以前几年你裸辞真不一样。真不如硬扛着，然后在公司里落地 AI 相关的流程实践。我不知道你是否已经做了充足的准备，但是今年真的是 AI 应用元年，变化太大了。以前你裸辞也就裸辞了现在是天堑横着。

你应该庆幸，AI 还没在开发团队产生质量优化的效果。其实这一点的问题很容易解决，特别是你自己以测开的角色去做工具的开发和自测的时候你就能发现并解决问题，并将这个 skills 优化到团队里面。但是我目前是更倾向于还是迭代的慢点，给人留一条活路吧。反正我自己开发工具现在的开发质量是直线上升了，就看你们业务团队是否也去这样做。

感觉你没有使用 codex，Claude code 这类工具直接进行工作而是绕了一层做 prompt，实话说有点落伍了。

已经废了，现在完全 skills 化了，下一个新的能力成熟起来就转移过去或迁移进去。目前完全看不到行业的希望，效率提升有很多有个 2 倍吧，开发效率提升 5 倍都多。反正就这样再吃几年饭就准备退休了。

感觉还是老问题呀，你说的一堆失败异常，不应该回归到自动化代码质量为何这么差吗？还是业务需求的高速迭代为何变动如此大，基础框架为何不支持维护变动大的需求场景。寄托于 AI 或者人工取分析一堆失败有什么意义，分析完看起来没有改进和收敛的效果，有的话那自动化的结果应该是越来越稳定，而不是又还是每天一堆异常需要分析呀。例如我们稳定的脚本大批量失败，一定是一个大的更前序的链路出问题了，基本都很好统计和分析原因。所以你的回答并没有脱离老问题诶。

你说的这些问题还是老问题，以前怎么解决现在还是怎么解决只是加一个 AI 罢了。

1. 想法。AI 时代，你的想法可以不再需要前端支持，后端支持。你就能独立完成前后端开发调试，并且只要你的想法可能有效，产品力的表现已经远超前几年了。
2. 行业经验，当技术能力没达到不可代替的阶段，行业经验无疑是最强的壁垒了。毕竟你吹自己用 AI 补齐了行业经验也没人信，其中的失败经验，情绪控制，沟通交流不是机器人能代替的。
3. 暂时想不出第三点了，什么这个技术那个技术，真的基本都破灭了。

哎用一下 AI coding 吧，你说的这些很快会消失到仅剩下有丰富的业务和排查经验的选手。

是的，不过这个已经是很久以前的帖子了。现在我们通过 AI，将文档涉及到的有意义的字段，自动去分析和生成测试点记录到知识库，让其他工具节点知道这个字段是干嘛的。只能说时代变太快了

你说的这个东西，就是建立一套动态的知识库体系，让 AI 自己去做这个分类，以及结合流程，在不同阶段接入不同的 prompt 去迭代这个知识库。相当于是执行 agent+ 维护 agent 的组合才能完成这个事情。也是现在有这么多开源的流程节点 AI 但是落地到实际项目的时候，很多人一脸懵逼的原因。这一块必须要有这个思路和结构

说了一大堆，没看到具体价值贡献。其次没 AI 真的没亮点了

第一个问题，明显是行业术语，背景知识库的维护。这 2 块没有进行设计和维护的原因，单纯靠调整 prompt 是没用的。这也是 AI 目前最大的问题，也是需要人的地方。如果 AI 连这一层都突破了，人就真的就要那几个就行了

和我们团队现在的方向很类似，我们也差部分预估 26 年 Q2 就能完成这个方向的建设了。越是深度的参与使用 AI 越发对行业前景感到悲观。好在我一向奉行先吃螃蟹的人能多吃几口螃蟹，而且已经 33 奔 4 了本来就没多少之前发展时间了，后面就留给新一代人操心吧

其实就是把你们的通用能力封装成 skills，给对应的 AI 去调用。如果没有 AI 业务赋能的基座，你的 skills 也没地方可以用。

很精彩呀。同时也宣告了测试得从执行者往行业规范定义这个角色转变。类似工程师向专家的转变，同时 AI 时代以前的工程师阶梯晋升路线也将被缩短，这种缩短是不快速的递进，而是在变相的更快的筛选。有风险意识的也应该更快速的转变和思考后面要去做什么内容了。

明确测试范围，范围内测试主责，范围外测试次要。然后后续各个角色的 action 才能加强团队能力

普通人的工作上限由城市、行业决定，再就是角色职位了。

就拿近期比较火的 skills 做例子吧，就算 llm 已经被大家承认能力很强，也需要各种 skills 进行 token 压缩或者更具体更明确更效率的结果产出。我们用 AI 也只是在现有的流程工具下，增加 agent 角色的引入，它解决了一些显而易见的效率提升质量提升，但是这之后呢？挖掘额外的质量和效率依然是一个大的课题，然后重新回到 agent 角色和流程引入替换。

方案 1 适合已产品状态为基地的测试流。方案二适合以围绕产品配置的测试流。一个是静态数据，一个是动态数据。