用临时服务器验证AI生成的HTTP接口

验证 LLM 生成的 HTTP 接口最快的方式不是去读代码，甚至不是在本地跑单元测试；而是让代码站起来，作为一个真实的 HTTP 服务处理真实请求，在它接近合并请求之前就证明自己。大多数 LLM 生成的后端代码的问题隐藏在静态正确性与运行时真相之间：某个依赖只在进程启动时才生效、某个默认 host 的假设、某个在伪代码里可行但框架路由解析器不认的路径参数，或者响应格式与客户端期望不符。本地单元测试可以通过，而以上所有问题都依然不可见，因为测试从未启动过进程、从未绑定过端口、也从未通过 socket 发送过请求。

值得展开的闭环刻意收得很窄：用免费模型根据简短规格起稿一个小 HTTP 接口，然后把这个草稿部署到一个临时服务器，在那里向它发送真实请求、观察响应，再决定生成的代码是否值得成为项目的一部分。MonkeyCode 的免费模型访问和免费服务器选项让这个闭环很容易尝试，无需为托管付费或手动撸本地容器，不过这个工作流搭配任何模型和任何已有的临时运行时都一样有用。说明：本文作为 MonkeyCode 产品推广的一部分而撰写。

首先让模型生成一个微小但外部可观察的东西。健康检查路由加一个回显路由就够了，因为目的不是展示技巧，而是证明生成的服务能够绑定、路由、验证查询参数，并在真实 HTTP 条件下返回 JSON。以让它生成一个 FastAPI 应用为例：

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Echo(BaseModel):
    message: str

@app.get('/health')
def health():
    return {'status': 'ok'}

@app.post('/echo')
def echo(body: Echo):
    return {'received': body.message}

这段代码简单到几秒就能读完，但它的行为依赖好几件只有在运行时才明显的事：FastAPI 和 uvicorn 都必须已安装、模块启动时不能有导入时副作用、自动生成的 OpenAPI schema 需从 Pydantic 模型推导、服务器必须真正监听临时环境暴露出的 host:port 组合。以上任一细节出错，代码在屏幕上看起来依然完全合理。

临时服务器才是真正检验的地方。把生成的文件连同最简依赖清单一起部署、启动服务，然后让它响应客户端最终会发送的同一批请求。最小的可复现测试计划只需三条命令：一条检查健康路由、一条用合法 body 触发 echo 路由、一条发送错误内容类型或无效载荷，从而观察失败模式是否可接受。例如：

curl -s http://your-temporary-server/health
curl -s -X POST http://your-temporary-server/echo -H 'Content-Type: application/json' -d '{"message":"hello"}'
curl -s -o /dev/null -w '%{http_code}' -X POST http://your-temporary-server/echo -H 'Content-Type: text/plain' -d 'hello'

第三条请求比看起来更重要，因为生成的 Web 代码往往语法正确、愉快路径也没问题，但对失败完全无力。缺少 422 验证响应、堆栈跟踪泄露到客户端、遇到畸形 JSON 时服务器崩溃而非返回状态码、或者进程在处理完单个请求后就退出了——这些比起一个通过的单元测试，能告诉你更多是否应该接受这段代码。临时服务器给了你"对接口不客气"的权限，而这些不客气在共享开发环境里你可能不会去试。

这个工作流也改变了你审查生成代码的方式。不再问"代码看起来合理吗"，而是问三个运行时问题：进程在第一次请求后是否保持存活、响应体是否与客户端期望的 schema 匹配、失败路径是否返回结构化错误而非崩溃？这些问题靠读代码回答不了，本地 mock 也回答得很差，因为它早就把真实服务器启动时容易出问题的东西抽象掉了。临时运行时让验证贴近生产，同时让糟糕生成结果的成本极低。

在把它变成习惯之前，你应该接受一些真实的局限。免费服务器选项不是生产部署；它可能有冷启动、持久化有限、出站网络限制，或者生命周期迫使你之后重建服务。免费模型生成的代码可能使用了过时或虚构的库版本，所以你应该在清单中锁定依赖，并在花时间部署之前读一下生成的 import。此外这个方法的质量也取决于你发送的请求——意味着它能捕捉契约和运行时失败，但替代不了安全审查、负载测试或仔细阅读生成的代码。如果你处理敏感数据、受监管系统或必须保持可用的服务，这只是一个粗糙的初筛而非最终关卡。

不应该使用这个工作流的人有两类：一类是对每个生成的代码片段无法多容忍五分钟额外设置的人；另一类是已经有本地容器和测试工具链能启动真实进程的人。如果你当前的反馈闭环已经启动服务并发起网络调用，你不需要再加一台机器；原理是一样的。但如果你目前是在做了一次语法检查和单元测试之后就合并生成的 HTTP 代码，那么临时服务器就是让那段代码证明自己能做后端必须做的唯一一件事——接收请求并返回响应，而不是返回一个想法——的最便宜方式。

下次你生成一个 API 接口时，抵制住去读它然后批准它的冲动。把它放到某个临时的地方，发送那三条请求，让运行时告诉你给你的代码是一个服务，还是只是一段看起来像代码的说服性注释。