接入前先发现能力
通过 GET /v1/capabilities 查看平台当前能力，并通过 GET /v1/capabilities/content.detect/schema 读取检测输入契约。应以返回的版本化 schema 为准，不要根据营销页面硬编码请求字段。
通过 GET /v1/capabilities 查看平台当前能力，并通过 GET /v1/capabilities/content.detect/schema 读取检测输入契约。应以返回的版本化 schema 为准，不要根据营销页面硬编码请求字段。
平台请求在 X-API-Key 请求头中携带 WriteGo API 密钥。检测客户端需要 platform:runs:write 创建运行，并需要 platform:runs:read 读取状态；请只授予流程所需权限，且不要把密钥放进网页正文、源码仓库或客户端日志。
向 POST /v1/capabilities/content.detect/runs 提交文本。当客户端可能重试时，应发送 Idempotency-Key，避免同一次逻辑提交被意外创建多次。请把返回的运行 ID 与自有文档 ID 关联，不要用提交原文充当标识。
通过 GET /v1/runs/{run_id} 查询，直到运行进入终态。分别保存运行 ID、状态、时间戳、能力版本、必要输出和人工审阅结论，让审计记录明确区分模型证据与最终人工决定。
客户端应处理非成功 HTTP 响应、结构化错误、超时以及 failed 或 canceled 终态。需要停止任务时使用 POST /v1/runs/{run_id}/cancel，并使用有上限的退避策略，避免高频轮询或无限自动重试。
API 工作流不应止步于一个分数。高风险、低置信、短文本、翻译文本、编辑后文本或政策敏感文档，应连同来源语境、段落证据、备注、保留规则和申诉或更正路径一起进入人工审阅队列。
好的工作流应包含文档 ID、风险等级、置信度、审阅路由、审计记录、保留规则和每次提交的政策状态。
不建议。API 结果应主要用于排序和路由。高风险、低置信或敏感文档在最终处理前应由人工复核。
使用 POST /v1/capabilities/content.detect/runs 创建检测运行，使用 GET /v1/runs/{run_id} 读取结果。由于支持字段会随版本化平台契约演进，接入前应先读取公开 capability schema。
同一次逻辑提交重试时使用稳定的 Idempotency-Key，配合有上限的退避，并保存返回的运行 ID。不要为每次网络重试生成新键，否则可能产生重复运行。