Stanza：用自然语言生成有状态Mock API

前端开发中，后端接口尚未就绪时，Mock API 是常见解法。但传统 Mock 工具往往只能返回静态 JSON，无法模拟真实业务中的状态流转和依赖关系。Aaditya Dubey 在 dev.to 上分享的开源项目 Stanza，尝试用自然语言提示直接生成带状态的 Mock API，把「写 Mock」这件事的门槛进一步拉低。

核心思路：从静态响应到有状态服务

Stanza 的定位可以概括为「instant stateful mock APIs from natural language prompts」。它的关键差异在于 stateful 一词：生成的不只是一组固定响应，而是一个能在多次请求之间维持状态的服务。

这对前端联调意义明显。以购物车为例，加购、修改数量、结算这几个接口之间存在数据依赖，静态 Mock 很难覆盖完整链路，而有状态 Mock 可以让前端在真实接口到位前就跑通主流程。作者在 Hacktoberfest 开源 AI 挑战第二周提交了这个项目，属于 Side Hustle 类目，项目贴上 #devchallenge、#hf26challenge、#hacktoberfest 标签。

什么是「有状态」Mock

在 Web 开发语境里，stateful 指的是服务端在多次请求之间保留数据。典型的无状态 Mock 每次请求都返回同一份预设 JSON，而真实后端会把「用户 A 把商品加进购物车」这条记录存起来，后续查询或结算请求都会读到这同一份数据。有状态 Mock 模拟的正是后一种行为：它在内存或简单存储中维护一份可变数据集，让 POST/PUT/DELETE 请求真正改变后续 GET 的结果。与之相关的常见概念还有幂等性（同一请求重复执行结果是否一致）和事务——真实数据库能保证一组操作要么全部成功要么全部回滚，而简易 Mock 通常不具备这一能力，这也是它只适合联调、不适合作为生产依赖的原因。

自然语言作为接口定义入口

传统 Mock 工作流通常要求开发者手写 JSON schema 或维护一套 mock 配置文件，接口变更后还要同步修改。Stanza 把输入换成自然语言描述，由模型理解意图后生成对应的 API 行为。

这种做法降低了 Mock 的创作成本，尤其适合原型阶段快速验证。代价是生成结果的可控性依赖提示质量，复杂业务规则仍可能需要人工补充。原文篇幅较短（标注 2 分钟阅读），没有展开具体的模型选型、状态存储方式与路由机制，这些工程细节需要到项目仓库中确认。

JSON Schema 与 OpenAPI 的背景

传统 Mock 工具（如 json-server、Mock.js、MSW）通常围绕接口契约工作：开发者先定义每个端点的路径、方法、请求体结构和响应字段，再据此生成假数据。描述这套契约的主流标准是 OpenAPI Specification（原 Swagger），它用 YAML/JSON 描述接口清单，可以进一步生成文档、客户端 SDK 或测试桩。JSON Schema 则是描述 JSON 数据结构的通用规范，常被 OpenAPI 引用。Stanza 用自然语言替代这一层手写契约，本质是让大模型从描述中推断出隐式的 schema 与行为；问题在于自然语言省略了大量边界条件（字段类型、必填与否、错误码），而这些恰恰是契约体系严格定义的部分，因此生成结果若要被团队复用，通常仍需回填为标准格式。

适用场景与边界

从使用场景看，Stanza 更贴近以下需求：

• 前端在接口契约未定稿时需要先行动手
• 演示或黑客松场景下快速搭建可交互的后端假数据
• 教学和原型验证中模拟有依赖关系的接口序列

它不太适合替代生产级后端服务。Mock 的状态通常是进程内或简单持久化，与真实数据库事务、并发控制存在差距；自然语言生成也存在不可复现的问题，同一提示多次生成可能得到不同行为。对需要严格契约的团队，生成结果仍应沉淀为可版本管理的接口定义。

提示的不可复现性从何而来

大语言模型在生成时通常带有采样过程（temperature 等参数控制随机性），同一提示在不同时刻可能得到措辞甚至结构不同的输出。即使在 temperature 设为 0 时，模型版本更新、上下文长度变化也可能改变结果。这与配置文件的性质形成对比：一份 JSON 配置文件是确定且可 diff 的，而一次自然语言生成更像一次性的构建产物。因此工程实践中常见的做法是把生成结果固化下来——导出为静态文件、纳入版本控制和代码评审，而不是每次启动都重新生成。这一点对判断 Stanza 这类工具的成熟度尤为关键。

对 AI 辅助开发工具的一点观察

Stanza 代表了一类正在出现的工具形态：用大模型把「配置」变成「描述」。这类项目真正的竞争力往往不在生成那一刻，而在生成之后——能否导出成标准格式、能否接入现有测试流程、能否在团队内共享和审查。原文没有涉及这些方面，但它们决定了工具是停留在演示阶段还是进入日常开发链路。

对个人开发者而言，Stanza 的价值在于缩短从想法到可交互原型的距离；对团队而言，值得关注的是它能否与 OpenAPI 等现有契约体系衔接。