用 AI 跑通 MVP 核心功能：从输入到真实结果

页面已经能输入文章、显示摘要，下一步接入真实模型。这时要检查的是处理结果：一篇带有数字和条件的长文，能否被整理成可用的标题、摘要和标签？

如果界面、提示词、接口和数据库同时开发，出错后很难判断是哪一层的问题。先单独测试 API，再把它接到页面，可以少一些混在一起的故障。

本文继续使用前两篇的长文内容整理工具作为教学示例。

先拿真实材料测试能力#

准备几篇有代表性的文章，可以覆盖信息密集的教程、带数字和条件的说明，以及重复表达较多的口述整理稿。这里的材料应当是自己有权使用的文本；用户原文需要取得相应授权，测试日志也不必保存全文。

先在供应商的测试界面，或独立的 API 调试工具中试一次。保持材料和输出要求一致，再比较不同候选方案：

检查项	看什么
事实准确	数字、主体、时间和条件是否保持原意
信息覆盖	原文的主要结论是否保留
输出格式	是否稳定返回约定字段和类型
处理速度	等待时间是否适合当前使用场景
成本	每次实际调用的输入输出用量和费用

先确认最难的一类材料。如果原文写“仅限已有付费用户申请”，摘要却变成“所有用户均可申请”，这个模型或提示词还不能交付。接入页面前，应先修正这类内容错误。

我会先测试效果，再写接入代码。具体服务的模型能力、价格和限制，以当前文档和实际测试为准。

把处理过程分成几处明确的交接#

对于带私密密钥的模型服务，示例工具可以采用这条数据流：

1
浏览器收集输入并做初步校验
2
  -> 服务端再次校验输入
3
  -> 服务端调用模型 API
4
  -> 服务端解析并检查结果
5
  -> 浏览器展示可用结果或错误提示

前端校验方便用户马上改输入，服务端校验负责拒绝绕过页面直接发来的无效请求。长度限制、格式限制都应在服务端执行。

接口内部可以分别处理输入校验、供应商调用和结果检查，但不必为每一步建立复杂框架。第一版的目标是能单独检查这些交接处，出错时知道收到什么、返回什么。

先固定返回约定，再接页面#

下面是一种成功响应示例，其中的内容仅用于演示格式：

1
{
2
  "requestId": "example-request-001",
3
  "data": {
4
    "title": "如何安排一轮产品测试",
5
    "summary": "这里展示依据输入原文生成的摘要。",
6
    "tags": ["产品测试", "独立开发", "用户反馈"]
7
  }
8
}

失败响应则使用稳定的错误码，页面根据错误码显示信息：

1
{
2
  "requestId": "example-request-002",
3
  "error": {
4
    "code": "UPSTREAM_TIMEOUT",
5
    "message": "处理时间较长，请稍后重试。"
6
  }
7
}

requestId 用于把这次页面反馈与服务端日志对应起来。上面的编号是示例，实际系统应为每次请求生成独立标识。

错误详情不应原样发给浏览器。供应商响应可能含内部地址或其他实现信息，用户只需要知道现在能怎么继续；开发者通过受控日志排查具体原因。

检查返回格式与内容#

要求模型返回 JSON，并不能省掉结果校验。可以优先使用供应商支持的结构化输出能力，再检查解析结果是否满足约定：

title 和 summary 是否是非空字符串。
tags 是否是字符串数组，数量是否符合规格，有没有重复项。
模型是否拒绝回答、提前截断，或者返回了无法解析的内容。

校验失败时，页面应当提示处理失败，不能悄悄把空摘要显示成成功。需要重试的话，应设定次数和总耗时上限，记录额外调用成本。第一版也可以先不自动重试，让用户自行选择。

格式通过后，还要做内容检查。结构校验能发现标签字段是数字，发现不了摘要把“不能”写成“可以”。用测试文章对照原文，这一步不能被 JSON 校验替代。

文章原文本身也可能带有“忽略之前要求”之类的句子。将待整理的文本作为数据，与处理指令分开传递；本任务无需让模型获得工具执行权限。仍应测试这类输入，因为单纯分隔文本不能保证模型始终遵守指令。

把等待和失败也接到页面#

点击提交后，页面进入等待状态，并阻止同一页面的重复提交。无论成功还是失败，等待状态都要结束。

请求失败时保留输入，用户才不需要重新粘贴整篇文章。如果页面还留着上一次的结果，标明它属于上一次任务，避免误用。

前端超时、服务端超时和供应商超时可能发生在不同时间。浏览器停止等待，并不保证供应商已经停止处理或不再计费。为服务端调用设置明确的超时，并核对所选 API 的取消机制；不要仅靠页面上的“取消”按钮控制费用。

公开接口还需要服务端限制调用次数、请求大小和并发。按钮禁用只能防止当前页面误点，不能限制别人绕过页面发请求。早期小范围测试，可以结合访问控制、供应商用量上限和必要的服务端限流，按实际情况选择。

记录一次可用结果花了多少#

估算成本时，应计入失败和重试。假设一组教学测试调用 12 次，共花费 1.2 元，其中得到 10 份可用结果：

1
每次调用平均成本 = 1.2 / 12 = 0.1 元
2
每份可用结果成本 = 1.2 / 10 = 0.12 元

这些是演示数字，不是模型报价。实际记录还应考虑服务器、存储等费用，不过第一轮可以先把占主要部分的调用费用算清楚。

用同一组样例做优化前后的比较。只看单次最快的请求，会忽略慢请求；只看最便宜的一次调用，也会漏掉格式错误和重试。样本较小时保留每次记录即可，不必急着搭数据平台。

给 AI 的下一次任务#

接口约定与样例准备好后，可以按这样的范围安排开发：

1
本次将现有模拟处理替换成真实的服务端模型调用。
2
沿用 SPEC 的输入规则、输出字段和页面状态。
3
密钥只由服务端读取，不写入前端代码或日志。
4
增加输入校验、结果校验和服务端调用超时。
5
暂不增加数据库、登录或自动重试。
6

7
检查正常输入、无效输入、供应商超时和返回格式错误。
8
说明每项如何验证，并确认生产处理路径没有返回模拟结果。

真实请求返回后，先用一篇自己熟悉的文章走完整流程，再用更难的材料检查内容。遇到错误，留下触发操作和请求标识，排查时就能找到对应记录。下一篇继续讨论调试和验收。