【claude code实践】让 Claude Code 编写脚本：自动化重复开发任务

让 Claude Code 生成 Mock 数据：提高本地开发效率

引言：为什么现在需要理解它

前端开发中最常听到的一句抱怨是：“接口还没好，页面写完了也跑不起来。”于是你打开 Mock.js，手写一堆模板规则；或者用 json-server 搭一个本地假接口，手工拼装几十条 JSON 数据。再往后，你可能维护了一份庞大的 mock 数据文件，每次接口字段一变，就要人肉同步。

这种“等接口 — 手写假数据 — 数据过时 — 再手写”的循环，几乎每个前端或全栈开发者都经历过。它消耗时间，且几乎不产生长期价值。

过去两年，AI 辅助编程工具逐步渗透到开发流程中：代码补全、函数生成、自然语言转 SQL 都已经不新鲜。但一个容易被忽视的场景是：本地 mock 数据的生成与维护。它不像“生成业务代码”那样性感，却直接影响着日常开发效率和调试体验。

Claude Code 是 Anthropic 推出的命令行 AI 编程代理（agent），运行在终端中，能够理解项目上下文、操作文件、执行命令。用它生成 mock 数据，本质上不是“让 AI 帮你写几行假数据”，而是把 mock 数据的生成变成一个可描述、可迭代、可跟随项目演进的工作流。

本文将以 Claude Code 生成 mock 数据为具体入口，讲清楚这个工具的工作方式、它能解决的问题，以及它在开发者工作流中的真实定位。

一、Claude Code 是什么

一句话定义：Claude Code 是一个运行在终端中的 AI 编程代理，能够理解整个项目的代码结构、文件系统和 Git 历史，并据此执行代码生成、修改、命令运行等任务。

它不是 VS Code 插件，也不是聊天窗口里的代码补全工具。Claude Code 的主体是一个命令行程序，你用自然语言描述任务，它在项目目录中读取文件、分析结构，然后直接操作文件或执行 shell 命令，最后把结果呈现给你。

需要明确几个“不是”：

• 不是普通的 AI 聊天助手。你不需要把代码片段复制粘贴到对话框里，Claude Code 会自己读取项目文件并理解上下文。
• 不是代码补全工具。它不负责在你敲键盘时一行一行地补全，而是面向“完成一个任务”的粒度工作，比如“为这个接口生成 20 条 mock 数据并写入文件”。
• 不是自动化脚本。它没有固定的执行模板，任务描述可以模糊，工具会根据项目实际情况调整生成策略。

如果你用过 GitHub Copilot 或 ChatGPT，可以把 Claude Code 理解为“能看懂整个项目、并能动手改代码、跑命令的 AI”。它从单纯的“建议者”变成了可以执行操作的“代理”。

二、从 Mock 数据生成开始理解它

为什么 mock 数据生成是一个很好的理解入口？因为这个场景足够具体，同时又能触及 Claude Code 的核心能力：理解数据结构、生成符合约束的数据、操作文件、验证结果。

假设你在开发一个用户管理后台，后端给了你一个接口文档，字段如下：

{"id":"string","name":"string","email":"string","role":"admin | editor | viewer","createdAt":"ISO 8601 string","avatar":"url string"}

传统做法是：你自己想几个名字、拼几个邮箱，还要注意 role 枚举值的分布，createdAt 的时间合理性，avatar 的 URL 格式。20 条数据写完，可能已经过了 15 分钟。

用 Claude Code 的话，你只需要在终端里说：

为 GET /api/users 接口生成 30 条 mock 数据，字段包括 id、name、email、role（admin/editor/viewer）、createdAt、avatar。数据写入 src/mocks/users.json，中文名，邮箱域名统一使用 example.com。

Claude Code 会怎么做？它会先去读你的项目结构，可能找到已有的 mock 文件或相关类型定义，确认数据文件的存放位置和格式习惯。然后生成一个 JSON 文件，里面包含 30 条符合约束的假数据。你打开一看，name 是正经的中文名，role 均匀分布在三种值中，createdAt 是近一年内的合理时间，avatar 拼接了可访问的占位图 URL。

这个过程中，你不需要写任何模板语法，不需要手动随机取值。重要的是，当后端接口字段变了，比如加了phone字段，你可以直接说：

users 接口加了 phone 字段，更新 src/mocks/users.json 里的所有数据。

Claude Code 会重新读取文件，理解结构变化，给已有的 30 条数据逐条补上 phone 字段并填充合理值。这就是从“一次性生成”到“可迭代维护”的转变。

三、它解决了什么问题

从 mock 数据这个场景出发，Claude Code 实际上解决了前端开发流中的三个具体问题。

1. 从手写假数据到描述约束

原来的痛点：手写 mock 数据本质上是枯燥的体力活。你要不停地编名字、邮箱、日期，还要注意数据类型和枚举值不出错。数据量一大，手写几乎不可行，于是很多开发者干脆只写三四条，覆盖不了边界情况。

它如何介入：开发者只需要描述数据结构、约束条件和数量，Claude Code 负责生成符合约束的完整数据集。约束可以是显式的（“role 只能取 admin/editor/viewer”），也可以是隐含的（看到 createdAt 字段，它会用合理的时间戳）。

改变了什么：mock 数据的创建从“手工拼装”变成“描述需求”。开发者的注意力从数据本身转移到数据应该长什么样。

仍然存在的限制：如果接口的业务逻辑非常复杂，比如字段之间有隐藏的依赖关系（某个状态下某些字段必填、另一些不可出现），AI 可能无法仅从字段名推断出这些规则。你仍然需要用自然语言把这些约束讲清楚。

2. 从数据与接口文档脱节到跟随变更

原来的痛点：接口迭代后，mock 数据往往是“僵尸数据”——结构已经过时，但没人记得去改。等你联调时发现字段对不上，再临时去修，浪费时间且容易引入错误。

它如何介入：当接口文档或类型定义更新后，开发者可以要求 Claude Code 同步更新对应的 mock 数据。它会把已有数据当作上下文，只做增量修改，不会推翻重来。

改变了什么：mock 数据的维护成本降低，使其更有可能在团队中保持“活着的状态”。你更有可能在联调前就发现字段不匹配的问题。

仍然存在的限制：目前这个过程依赖开发者主动触发。Claude Code 不会自动监听文档变更并更新数据。你需要在开发流程中养成“改接口，同步更新 mock 数据”的习惯。

3. 从单兵作战到可复用的上下文

原来的痛点：每个人写的 mock 数据风格不同，有的用英文名，有的用拼音，有的字段值明显是键盘乱敲出来的。这些数据在团队共享时缺乏一致性，测试和演示时看起来不专业。

它如何介入：Claude Code 生成的数据遵循一致的风格和合理的分布。你可以用一句话指定语言、域名、日期范围等全局规则，工具会把这些规则应用到整个数据集中。如果团队统一了 mock 数据的规范，你甚至可以把规范写成文档，让它每次都参照执行。

改变了什么：mock 数据从一个“临时凑合用”的东西，变成可以被团队共享、可被自动化流水线使用的资产。

仍然存在的限制：团队规范需要显式描述，Claude Code 不会自动继承“我们团队习惯用繁体中文名”这种隐性知识。规范越清晰，结果越好。

四、它的基本工作方式

Claude Code 的工作方式可以从四个环节来理解。

输入：开发者用自然语言在终端中给出的任务描述。这个描述可以是一句话，也可以是一段包含约束、格式、路径要求的详细说明。Claude Code 也支持从文件中读取任务（如claude -p "根据 spec.md 生成 mock 数据"），方便嵌入脚本化流程。

上下文理解：当它接收到任务后，会扫描当前目录下的文件结构，读取相关文件内容。它不会把所有文件一股脑塞进上下文，而是根据任务有选择地读取——比如你让它生成 mock 数据，它倾向于先看类型定义文件、接口文档、已有的 mock 文件或 API 路由定义。Git 历史也在它的视野之内，可以用来理解项目近期的变更方向。

任务拆解：对于一个“生成 mock 数据”的任务，它内部会拆成几个步骤：确定数据结构 → 确定数据量 → 确定约束条件 → 生成数据 → 写入文件 → 验证格式。这个拆解过程开发者看不到，但最终执行时你能观察到它一步步地创建、修改文件。

输出与操作：Claude Code 可以直接创建新文件，也可以修改已有文件。它还会执行命令，比如在生成数据后自动跑一下jsonlint验证 JSON 合法性，或者运行npx json-server快速启动一个 mock 服务让你验证。最终呈现给你的是一个可直接使用的 mock 数据文件。

关键点在于：它不只是给出文本建议，而是直接操作文件系统、执行命令。这意味着你要允许它在你的项目中做出实际的变更。这也是它和聊天式 AI 最本质的区别。

五、一个典型使用流程

下面构造一个完整的示例：开发者要为待办事项应用生成 mock 数据。

第一步：提出任务

请为 Todo 应用的接口生成 50 条 mock 数据。 字段包括： - id: uuid - title: 中文待办事项，5-15个字 - completed: boolean - priority: high | medium | low - dueDate: 未来30天内的日期，部分可为 null - tags: 0-3个标签，从 "工作" "个人" "学习" "健康" 中选取 数据写入 src/mocks/todos.json，同时生成一个 src/mocks/db.json 供 json-server 使用。

第二步：工具读取上下文

Claude Code 扫描项目，发现src/types/todo.ts中已经定义了 Todo 类型，还发现package.json中有 json-server 的脚本配置。这些信息会帮助它对齐字段名和文件格式。

第三步：生成数据并写入文件

它首先生成todos.json，包含 50 条数据，title 是自然的中文句子，priority 有合理分布（不会全是最高的），tags 数组长度在 0 到 3 之间随机。然后它构造一个db.json，把数据挂到todos路由下。

第四步：验证

Claude Code 自动执行npx json-server --port 3001 src/mocks/db.json，确认服务启动成功，然后在终端输出一条 curl 命令供你快速验证：

curl http://localhost:3001/todos | jq length # 应返回 50

第五步：开发者 review

你打开文件，检查几条数据，发现 priority 为 high 的项 dueDate 都偏近，这不合理——你希望高优事项均匀分布在未来 30 天。于是追加一句：

高优先级任务的 dueDate 不要集中在最近几天，均匀分布在未来 30 天内。

Claude Code 据此调整数据并重新写入。整个过程迭代两三轮，耗时不超过 5 分钟。

六、它和传统方式的区别

下表对比了几种 mock 数据生成方式的核心差异：

ChatGPT 也能生成 mock 数据，但你需要手动把类型定义复制过去，把结果复制回来，格式化后再保存。项目规模变大后，这种“复制粘贴式 AI 辅助”很难持续。Claude Code 把 AI 嵌入到了你工作的同一环境（终端+项目目录）中，省去了中间搬运环节。

七、适合什么场景，不适合什么场景

适合的场景：

• 快速生成符合接口定义的 mock 数据。当你拿到一份新接口文档，想立刻让页面跑起来。
• 维护已有 mock 数据集。接口字段变更后，批量更新现有数据。
• 生成边界数据。比如“给这批数据加几条 completed 为 true 但 dueDate 已过期的条目”，测试异常情况。
• 统一团队 mock 规范。将规范写成文档，让 Claude Code 每次参照生成，保证一致性。
• 阅读陌生代码库时快速构造数据。看到不熟悉的 API，让它生成一些示例数据，帮助理解返回结构。

不适合的场景：

• 生产环境数据生成。AI 生成的数据不能直接用于生产，必须经过校验。
• 高度敏感的接口（支付、权限等）。mock 数据涉及敏感字段时，需格外注意，不要让 AI 生成看起来像真实凭证的内容。
• 过于复杂的业务约束。如果字段之间有严格的状态机逻辑，AI 很难仅从描述中正确表达，建议手写核心数据，AI 补量。
• 未经 review 直接用于测试断言。如果自动化测试依赖 mock 数据的精确值，AI 生成的数据可能不够稳定，需要人工确认后固化。

八、开发者应该如何使用它

Claude Code 不是替代开发者的“自动 mock 机”，而是一个需要你指挥的协作代理。用好的关键在于以下几点：

写清楚任务，而非模糊指令。
差：帮我生成一些用户数据。
好：生成 30 条用户数据，字段见 types/user.ts，写入 mocks/users.json，中文名，邮箱域名为 company.com，role 按 6:3:1 的比例分配 admin/editor/viewer。

提供上下文，而非让它猜。
如果你的项目有 OpenAPI 文档或 TypeScript 类型定义，确保它们在项目目录内，Claude Code 会自动读取。如果没有，你可以在任务描述中直接粘贴接口文档。

限制修改范围，保护已有代码。
可以用.claudeignore文件排除不需要访问的目录（如node_modules、dist），也可以在任务中明确说“只修改 src/mocks/ 目录下的文件”。

把它的输出当作草稿，而不是最终答案。
生成的数据要过一遍：格式对不对，字段全不全，边界值合理吗。这是开发者的责任，不是工具的。

用命令验证，不要只靠看。
Claude Code 可以执行验证命令，比如jsonlint、ts-node跑一个快速检查脚本、启动 mock 服务后 curl 几个端点。养成自动验证的习惯。

建立安全边界。
不要让 Claude Code 直接操作.env、密钥文件或生产配置。在需要操作 Git 时，建议手动 commit，不要让它自动提交，确保每次变更都在你的掌控中。

九、它的局限和风险

客观地说，Claude Code 在当前阶段仍然有明显局限。

幻觉问题：它可能生成看起来合理但实际错误的字段值。比如一个status字段，它猜出active/inactive/suspended，但实际接口只允许active/disabled。缓解方式：始终对照接口文档或类型定义校验。

上下文遗漏：当项目很大、文件很多时，它可能漏读某些关键文件，导致生成的数据与项目其他地方的定义不一致。缓解方式：在任务描述中显式引用关键文件路径。

代码质量不稳定：同一条指令执行两次，生成的数据可能略有不同。对需要精确一致性的场景（如视觉回归测试的基准数据），需要人工固化结果。

安全风险：Claude Code 在终端中拥有执行命令的能力。理论上，恶意的任务描述或意外行为可能导致不期望的命令被执行。缓解方式：仔细阅读它计划执行的命令，对于敏感操作（rm、git push等）保持警惕，必要时使用沙箱环境。

依赖开发者的判断力：工具不会告诉你“这个任务我不太确定”，它会尽力生成。因此使用者的技术判断仍然是最后一道防线。初级开发者如果过度信任输出，可能会引入隐蔽的错误。

对大型项目的理解有限：Claude Code 的上下文窗口虽然大，但理解整个大型项目的全局架构仍有困难。它更适合在局部范围内（几个文件、一个模块）高效工作。

十、总结：它真正改变的是什么

回到标题——让 Claude Code 生成 mock 数据，表面上是省掉了一些打字时间，实质上改变的是 mock 数据在整个开发流程中的角色。

以前 mock 数据是一次性的、个人的、易腐的。用 Claude Code 之后，mock 数据可以变成一种可描述、可生成、可跟随迭代的制品。你不再“写” mock 数据，而是“定义” mock 数据应该是什么样，然后让工具去填充。这和从手写 HTML 到模板引擎的转变有某种相似性——抽象层级提高了一层。

Claude Code 在开发者工作流中的定位，更像一个能直接操作项目文件的初级搭档。它不会替你做出架构决策，也不应该被信任到跳过 review。它能做的是把那些你清楚知道怎么做、但做起来繁琐耗时的事情，以更快的方式完成。mock 数据生成是这样，写单元测试框架、批量重命名、格式化配置文件，也都是类似的场景。

对待它，合理的态度是：把它当作一个熟悉你项目结构、能动手干活的协作者，但最终的代码质量和正确性，始终由你负责。如果你能用好这个边界，它会成为日常开发中一个真正有用的工具，而不只是一个新鲜一时的玩具。