AI生成接口Mock，应先读取接口契约，再为正常、空数据和失败等场景返回明确的状态码、响应头与响应体。只有一份JSON样本，还无法验证前端在请求失败、方法错误或数据为空时会怎样表现。
把接口文档、类型定义和页面请求代码放在本地项目中，可以用墨刀AI客户端协助整理Mock规则与文件。先确定模拟范围，再生成可运行服务；不需要为了演示界面去连接真实客户数据或线上接口。
先写一份小而一致的接口约定
本例是工单列表接口GET /tickets。成功响应包含items和total，每条工单包含字符串编号、标题和状态。空列表仍返回200，只是数组为空；服务失败返回503和明确的错误码。
| 场景 | HTTP状态 | 响应约定 | 页面要验证 |
|---|---|---|---|
| success | 200 | 一条open工单，total为1 | 正常列表与字段展示 |
| empty | 200 | items为空，total为0 | 空数据说明和下一步 |
| error | 503 | code与message | 错误提示、重试和原条件保留 |
这里的scenario查询参数只用于本地切换情境，不是正式接口必须提供的业务字段。把这一点写清，可以避免前端将模拟控制参数带到生产请求中。接口若本来已有错误格式，应沿用现有约定，不让AI凭空发明另一套。
保存并启动一个无需第三方包的服务
将下面内容保存为mock-server.mjs，安装Node.js后在该文件目录执行node mock-server.mjs。本例在Node.js v24.14.0验证，使用Node.js内置HTTP模块接收请求并返回JSON；只监听本机地址。
import http from 'node:http';
const fixtures = {
success: { status: 200, body: { items: [{ id: 'T-1', title: '检查导出结果', status: 'open' }], total: 1 } },
empty: { status: 200, body: { items: [], total: 0 } },
error: { status: 503, body: { code: 'TEMPORARILY_UNAVAILABLE', message: '服务暂时不可用' } }
};
const server = http.createServer((req, res) => {
const url = new URL(req.url, 'http://127.0.0.1');
const send = (status, body) => {
res.writeHead(status, { 'Content-Type': 'application/json; charset=utf-8', 'Cache-Control': 'no-store' });
res.end(JSON.stringify(body));
};
if (url.pathname !== '/tickets') return send(404, { code: 'NOT_FOUND' });
if (req.method !== 'GET') {
res.setHeader('Allow', 'GET');
return send(405, { code: 'METHOD_NOT_ALLOWED' });
}
const scenario = url.searchParams.get('scenario') ?? 'success';
if (!Object.hasOwn(fixtures, scenario)) return send(400, { code: 'UNKNOWN_SCENARIO' });
const fixture = fixtures[scenario];
send(fixture.status, fixture.body);
});
server.listen(Number(process.env.PORT ?? 8787), '127.0.0.1', () => {
console.log(`Mock: http://127.0.0.1:${server.address().port}/tickets`);
});
启动后终端显示http://127.0.0.1:8787/tickets。若8787已被占用，可以先关闭自己的旧实例，或通过PORT环境变量选择其他可用端口。结束当前练习时，在运行服务的终端按Ctrl+C。
分别调用三个场景，看状态与内容是否一致
curl -i "http://127.0.0.1:8787/tickets"
curl -i "http://127.0.0.1:8787/tickets?scenario=empty"
curl -i "http://127.0.0.1:8787/tickets?scenario=error"Windows PowerShell如果将curl解释成其他命令，可使用curl.exe运行同样参数。第一条应返回200及一条工单，第二条返回200及空数组，第三条返回503和TEMPORARILY_UNAVAILABLE。状态码也属于契约，不能所有情况都返回200，再让前端猜某段文字代表失败。
本例另外处理未知路径404、错误方法405和未知场景400。实际验证已覆盖这六条路径，响应与上述约定一致。它没有实现登录、分页、写入或真实数据库；后续需要哪一项，就应先把相应契约补齐再实现，而不是让Mock默默替正式服务扩功能。
让页面连上Mock时，别把环境区别藏起来
前端可通过开发环境的接口基址或本地代理连接这个服务。若页面与Mock地址不同源，浏览器会涉及跨域规则；本例没有开放任意来源，建议使用项目现有开发代理转发请求，或者只为明确的本地开发来源增加相应配置。
一次只让一个场景生效，便于重现。页面测试503时，确认界面没有把上一次成功列表当成新结果；恢复success后，检查重试是否回到正常内容。测试empty时，空数据提示不应使用“网络错误”的文案。
如果要增加延迟或超时，应明确延迟发生的位置和触发方式，避免把随机等待做成无法稳定复现的默认行为。固定场景能帮助团队讨论一个确定的问题，随机样本则适合另有目的的覆盖测试。
给AI的交付要求要包含运行方法和反例
读取contracts/tickets.md及前端工单请求代码，建立仅用于本地联调的Mock服务。保留字段类型和错误格式，提供success、empty、error三个可选择场景。未知路径、方法和场景要明确返回错误。交付服务文件、启动与停止方法、三条调用命令及对应预期结果；不要调用真实接口，也不要更改正式接口基址。
拿到代码后，先按命令运行，再逐项对照响应。若契约还没整理清楚，可以先完成接口文档与字段定义；若需要更多数据组合，再用可复现测试数据的方法扩充样本。Mock负责行为与返回，数据文件负责具体记录，两者保持分工更容易维护。
正式接口就绪后，对照差异再切换
用相同请求比较正式接口的字段、状态码、错误结构与空值处理。发现差异时判断是文档遗漏、Mock写错还是服务实现变化，不要为了让演示继续通过就随手兼容一切。
保留一张“场景—请求—预期响应—界面表现”的小表，后续改动都能重走这条链。Mock的价值不是让后端看起来已经完成，而是让界面依赖的契约更早变得可讨论、可调用和可验证。
