AI 生成前端 Mock 数据：先定义业务状态，再生成随机字段- 惊觉

AI 生成前端 Mock 数据：先定义业务状态，再生成随机字段

前端开发经常需要 Mock 数据。AI 生成一批 JSON 很容易，但真正好用的 Mock 不是字段看起来完整，而是能覆盖业务状态。空列表、加载中、权限不足、部分失败、超长文本、边界金额、异常日期，这些状态才是页面开发最容易漏掉的地方。

如果只让 AI 随机生成用户、订单、商品，界面会看起来很热闹，但测试不到真正危险的场景。Mock 数据要先服务状态覆盖，再服务数量。

一、先画状态矩阵

flowchart TD
  A[Feature Scenario] --> B[Normal]
  A --> C[Empty]
  A --> D[Loading]
  A --> E[Error]
  A --> F[Permission Denied]
  A --> G[Boundary Data]

做列表页时，不要只生成 20 条正常数据。至少要准备空数据、单条数据、超长数据、分页最后一页、接口错误和权限不足。

在做订单列表页时，我们梳理过一份完整的状态矩阵。除了正常态，至少还需要：

空状态：新用户刚注册，没有任何订单
单条数据：分页逻辑在只有一条记录时是否正确
超长文本：收件人地址超过 100 字，UI 是否截断处理
边界金额：0 元订单（礼品）、999999 元订单（大额商品）
异常日期：1970 年的订单（时区问题）、未来的订单（数据错误）
权限不足：普通成员看不到管理员的订单
接口错误：网络断开、500 错误、超时

仅靠随机数据，这些场景大部分不会出现。AI 的随机生成倾向于生成"平均"样本，恰好在边界上掉链子。

为了验证这些状态，我们给每个列表页维护一个状态文件：

// __mocks__/states/order-list-states.ts
export const orderStates = {
  normal: {
    data: generateOrders(20),
    total: 20,
    meta: { status: "ok" },
  },
  empty: {
    data: [],
    total: 0,
    meta: { status: "ok" },
  },
  single: {
    data: generateOrders(1),
    total: 1,
    meta: { status: "ok" },
  },
  error: {
    data: [],
    total: 0,
    meta: { status: "error", message: "网络异常，请稍后重试" },
  },
  permission: {
    data: [],
    total: 0,
    meta: { status: "permission_denied" },
  },
  longText: {
    data: generateOrders(3, { receiverName: "A".repeat(200) }),
    total: 3,
    meta: { status: "ok" },
  },
} as const;

开发时只要切一个常量名，就能覆盖六种状态。比每次手动改接口返回效率高得多。

二、Prompt 要描述业务状态

比起"生成 10 条订单数据"，更好的输入是：

mock_request:
  entity: order
  states:
    - normal_paid
    - refunding
    - payment_timeout
    - long_receiver_name
    - missing_optional_note
  constraints:
    amount_cent: "0-999999"
    created_at: "within 90 days"

这样 AI 输出的数据会更贴近页面验证，而不是只生成看起来平均的样本。

在实际使用中，我们发现更好的做法是把状态定义和字段约束分开。状态定义告诉 AI"要覆盖什么场景"，字段约束告诉 AI"数据长什么样"。

mock_request:
  entity: order
  scenarios:
    - paid_order:
        amount_cent: 9900
        status: paid
        note: null
    - zero_amount:
        amount_cent: 0
        status: paid
        note: "赠品订单"
    - timeout:
        amount_cent: 19900
        status: payment_timeout
        created_at: "1 hour ago"
    - large_refund:
        amount_cent: 999900
        status: refunding
        refund_amount: 500000
  field_rules:
    id: uuid
    amount_cent: 0..999999
    created_at: 2026-01-01..2026-07-01
    status: enum[paid, refunding, timeout, shipped]
    receiver_name: 2..50 chars, mixed Chinese/English

分离场景和规则后，AI 生成的每条数据都有明确的验证目的，而不是随机填坑。评审时对照场景清单逐项确认，更容易发现遗漏。

三、Mock 数据要可复现

随机数据如果每次都变，截图回归和调试会很痛苦。建议固定 seed 或把生成结果落到文件。

export const orderMocks = {
  normal: [...],
  empty: [],
  paymentTimeout: [...]
};

页面开发时可以直接切换状态，而不是临时改接口返回。可复现的 Mock，是前端工程效率的一部分。

对于使用 faker.js 或类似库的项目，可以用固定 seed 保证每次生成结果一致：

import { faker } from "@faker-js/faker";

// 固定 seed，保证每次生成相同数据
export function generateMockData(seed: number, count: number) {
  faker.seed(seed);
  return Array.from({ length: count }, (_, i) => ({
    id: faker.string.uuid(),
    name: faker.person.fullName(),
    amount: faker.number.int({ min: 0, max: 999999 }),
    createdAt: faker.date.past({ years: 1 }).toISOString(),
  }));
}

// 不同场景使用不同 seed
export const mocks = {
  normal: generateMockData(42, 20),
  timeout: generateMockData(99, 5),
};

这样做的好处是：截图对比永远是同一批数据，调试时可以反复重现同一个问题，团队成员拉取代码后看到的 Mock 数据完全一致。随机是为了覆盖多样性，固定 seed 是为了可复现。两者不矛盾。

四、不要让 Mock 掩盖契约问题

Mock 数据要和接口 schema 对齐。AI 生成字段时，容易把 createdAt 写成 createTime，或者把金额从分改成元。最好用 TypeScript 类型或 zod schema 校验。

const OrderSchema = z.object({
  id: z.string(),
  amountCent: z.number(),
  status: z.enum(['paid', 'refunding', 'timeout'])
});

如果 Mock 都过不了 schema，说明它不是开发资产，而是噪声。

还可以把 Mock 场景接到 Storybook 或组件预览里，让设计、测试和产品都能直接切换状态。

export const Timeout = {
  args: {
    orders: orderMocks.paymentTimeout
  }
};

这样评审时不需要手动改接口，也不用靠口头描述"如果这里很长会怎样"。状态能被看见，问题才更容易被发现。

我们在 CI 中加了一个简单的检查：所有 Mock 数据文件必须能被 zod schema 校验通过，否则构建失败。

// __tests__/mock-validation.test.ts
import { OrderSchema } from "@/schemas";
import { orderMocks } from "@/mocks/orders";

test("all mock data validates against schema", () => {
  for (const [scenario, orders] of Object.entries(orderMocks)) {
    for (const order of orders) {
      const result = OrderSchema.safeParse(order);
      if (!result.success) {
        throw new Error(
          `Mock scenario "${scenario}" has invalid data: ${result.error.message}`
        );
      }
    }
  }
});

这个测试跑在 PR 阶段，任何 Mock 数据变更如果和 schema 不匹配都会暴露。后端接口改了字段名，前端的 Mock 也会同步卡住，迫使团队更新。这是 Mock 数据工程化中最简单也最有效的一道防线。

五、总结

AI 生成前端 Mock 数据时，先定义业务状态矩阵，再生成字段内容。覆盖正常、空、错、权限、边界和长文本等场景，并用类型或 schema 校验。

Mock 数据不是越多越好，而是越能暴露界面问题越好。随机字段只能填满页面，状态覆盖才能提升质量。

AI 的价值是快速生成候选数据，但前端要负责定义状态标准。标准在前，生成在后，Mock 才会稳定地服务研发流程。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/weixin_49475940/article/details/162549253

AI 生成前端 Mock 数据：先定义业务状态，再生成随机字段