处理AI 生成前端 Mock 数据：先定义业务状态，再生成随机字段这类问题时，先确认目标场景，再按步骤核对配置或玩法细节。

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

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

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

一、先画状态矩阵

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

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

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

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

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

// __mocks__/states/order-list-states.tsexport 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: orderstates:- normal_paid- refunding- payment_timeout- long_receiver_name- missing_optional_noteconstraints:amount_cent: "0-999999"created_at: "within 90 days"

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

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

mock_request:entity: orderscenarios:- paid_order:amount_cent: 9900status: paidnote: null- zero_amount:amount_cent: 0status: paidnote: "赠品订单"- timeout:amount_cent: 19900status: payment_timeoutcreated_at: "1 hour ago"- large_refund:amount_cent: 999900status: refundingrefund_amount: 500000field_rules:id: uuidamount_cent: 0..999999created_at: 2026-01-01..2026-07-01status: 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(),}));}// 不同场景使用不同 seedexport 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.tsimport { 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 才会稳定地服务研发流程。