API 文档需要覆盖完整生命周期

接口 Schema 告诉你如何发送请求，却很少解释响应到达前连接断开该怎么办。AntAPI 将生成的 API Reference 与接入指南分开维护，让字段定义和实际工作流程都有明确的位置。

从能力出发，解释它的生命周期

API Reference 描述已发布的 Method、路径、参数和响应字段，产品页说明能力的用途。接入指南将这些内容连接成应用流程：鉴权、提交工作、保存执行身份、取得结果，再理解结算。

WHOIS 很适合说明这种区别。单条查询返回注册信息，批量提交先返回 Job ID，之后才是查询进度和分页读取结果。如果将提交的 HTTP 202 当作完成，应用流程和计费解释都会缺少后半段。

受理、执行与结算是不同事件

异步付费操作执行前，Gateway 预留授权范围内的最高费用。平台之后验证最终成功数量，扣除对应部分，再释放剩余预留。WHOIS 的进度查询、已有结果读取、取消和 TLD 支持范围查询免费，但仍需鉴权。

成功定义也应和流程一起说明。WHOIS 将已注册和明确未注册都视为成功结果，unknown 则不能作为明确结论。同批规范化后的重复域名共用处理，取消不会抹去已经完成的成功项。

这些区别既影响 Receipt 的理解，也影响产品界面的实现。界面应该能够展示任务已受理，而不会让用户误以为所有条目已成功，或预留已成为最终扣费。

把恢复步骤放进示例

批量示例需要在提交前保存幂等键，收到响应后保存 Job ID，并解释响应丢失时如何处理。使用原 Key 恢复同一次逻辑操作，生成新 Key 则可能创建第二个任务。

同样的要求也让示例更适合直接使用：调用统一经过配置的 Gateway，Secret 只保存在可信服务端环境，文档不编造价格或通用限制。

快速开始介绍第一次请求，批量查询指南和计费说明覆盖后续生命周期。这些指南配合生成的接口参考使用，不重复维护字段 Schema。