我现在在做一套中后台页面的测试代码生成 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 系列知识，不知道如何落地，如果大家有类似的开源项目，好的建议都可以推给我！