请教一个“基于内部组件库页面代码 + 运行表格数据 + AI 生成 E2E 测试”怎么落地的问题

我现在在做一套中后台页面的测试代码生成 agent 。这个场景是前端的代码与测试代码都是二次封装的内部库（已经建了内部库的 skills ）

• 前端页面基于内部二次封装组件库开发
• 页面规律比较固定，很多开发本质上是在配置字段、组件、规则、联动
• 测试代码也不是直接写 Playwright ，而是基于 Playwright 又封装了一层内部测试库
• 所以最终想生成的，也不是原始 Playwright ，而是基于内部测试库的测试代码

也就是说，这不是一个“面对任意前端页面自由发挥”的问题，而是一个：

前端代码有固定规律、测试代码也有固定框架的场景里，怎么借助 AI 做测试生成。

典型前端字段表单配置代码（已脱敏）

{ component: 'CustomInput', fieldName: 'fieldCode', label: '字段 A', rules: z .string({ message: t('请输入字段 A') }) .min(1, t('请输入字段 A')) .max(20, t('最多输入 20 个字符')) .regex(/^[A-Za-z0-9\\-. *+\\/%$]+$/, t('格式不符合要求')), rulesBlur: z.string().superRefine(async (value, ctx) => { const checkResult = await verifyFieldUniqueness('fieldCode', value) if (!checkResult?.passed && checkResult?.msg) { return ctx.addIssue({ code: 'custom', message: t(checkResult?.msg), }) } }), } 

这类页面里，很多逻辑不是散落在各处，而是通过字段配置表达：

• 用什么组件
• 字段名和标签是什么
• 主校验规则是什么
• 失焦时是否做异步校验
• 是否存在后端重复校验/业务校验

典型测试代码（已脱敏）

test('列表查询', async ({ page, tableLocator, searchLocator, formActions, selectActions, datePickerActions, }) => { const search = searchLocator.createSearchArea(TABLE_ID) const table = tableLocator.createTable(TABLE_ID) await formActions.fillInput(search.getInput('keyword'), '示例关键字') await datePickerActions.setDate(search.getField('period', 'custom-period'), '202601') await selectActions.selectFromTableByIndex(search.getSelect('category'), 1) await search.getQueryButton().click() const row = await table.getRowData(0, ['displayName']) expect(row.displayName).not.toBeUndefined() }) 

也就是说，测试代码本身用的是内部封装的测试库，不是直接裸写 Playwright 。

我现在最关心的点

我最想解决的，不是“怎么生成一份测试代码”，而是：

测试数据不希望写死，而是尽量基于页面当前运行时的表格数据，再借助 AI 去推断。

也就是：

• 查询值不要硬编码
• 新增值不要硬编码
• 编辑值不要硬编码

而是尽量来自：

1. 页面当前表格里的真实数据
2. 页面代码里的字段 / 规则 / 联动 / 数据流
3. 最后才是 AI 推断

因为在很多中后台页面里：

• 表格里已经有现成的业务数据
• 新增和编辑的数据其实应该参考这些真实数据来生成
• 如果测试数据写死，后面会比较脆，也不够通用

我现在卡的几个问题

1. 查询 / 新增 / 编辑的数据推断边界怎么设计更合理？

我更希望是：

• 先拿页面当前表格里的真实数据
• 再结合页面代码
• 最后才让 AI 推断

而不是让生成器或 LLM 一开始就直接猜测试值。

2. 复杂校验该怎么交给 AI ？

比如：

• A 字段必须大于 B 字段
• 如果 A 有值，B 必填
• 字段重复校验
• 多字段组合校验

这种场景下，是给 AI 更多源码片段更好，还是给：

• 结构化规则
• 局部源码证据
• 运行时表格数据

这种“证据包”更合理？

3. 这种场景里，AI 的边界怎么放更稳？

我现在倾向于：

• 规则代码负责提取事实
• 运行时负责提供真实数据
• AI 只负责高语义推断
• 最终生成的代码仍严格落在内部测试库能力范围内

但不确定这种拆法是不是更稳。

想请教大家的点

如果有做过类似：

• 内部组件库驱动页面
• AI 辅助测试生成
• 代码理解 agent
• 基于运行时数据生成测试数据
• 基于既有测试框架生成测试代码

很想听听大家的经验，尤其是这种：

前端代码和测试代码都有固定规律，而且测试数据尽量不写死，而是依赖页面当前运行时表格数据 + AI 推断

的场景下，怎么划分：

• 哪些必须规则化
• 哪些交给 AI
• 哪些一定要依赖运行时数据

由于才刚接触 agent 开发，熟悉一点 langchain 系列知识，不知道如何落地，如果大家有类似的开源项目，好的建议都可以推给我！