用四步提取长技术文档的关键约束

把 40 页 RFC 或第三方 API 文档交给 AI，几秒钟就能得到摘要。问题是，读起来顺畅的摘要，可能恰好漏掉必填字段、rate limit 和 timeout 行为，而这些才是接入时容易出错的地方。

作者给出了一套四步流程：按结构拆分、定向提取、合并速查表、回原文抽查。它的价值不是让你彻底跳过文档，而是帮助你确定哪些内容必须仔细读。方法容易照做，但原文没有提供准确率或对照实验。

先按章节拆，再让 AI 回答具体问题

作者反对每隔 N 个字符就切一段。技术文档里的信息有结构：认证、endpoint、错误码、使用限制，各自需要保留上下文。机械截断可能把规则和例外分开，后面的摘要即使单句正确，也可能失去适用条件。

按章节处理还有一个实际好处：发现问题时，你知道该回查哪一部分。

接下来，别只要求「总结这段」。摘要倾向于保留大意，而接入 API 需要的是字段、类型、限制和异常行为。作者使用下面的提示词，把任务改成有明确目标的信息提取。保留原文如下：

Từ phần tài liệu dưới đây, liệt kê:
- Các tham số bắt buộc và kiểu dữ liệu
- Giới hạn (rate limit, kích thước, timeout)
- Các mã lỗi và ý nghĩa
- Những điều tài liệu KHÔNG nói rõ
Chỉ dùng thông tin có trong văn bản; ghi "không đề cập" nếu thiếu.

这段提示词要求列出必填参数及类型、各类限制、错误码含义，以及文档没交代清楚的地方。最关键的是最后一行：只使用输入文本的信息，缺失时写「未提及」。

文档没有写清楚，也应该成为提取结果的一部分。

作者认为，这条限制能减少 AI 用通用知识补空白的情况。不过，原文没有给出减少了多少错误的数据，不能把提示词约束当成准确性保证。

速查表要留下矛盾，抽查要能回到原文

各章节提取完成后，再让 AI 合并成一页速查表（cheat sheet），按主题组织，并标记不同章节之间的矛盾。

这里不能只追求整洁。假如两处说明互相冲突，合并时直接选一个答案，会把需要人工确认的问题藏起来。作者把这类冲突视为潜在 bug 的线索，要求它们留在结果里。

然后，从速查表里随机选 3–5 行，与原文逐条核对。如果全部吻合，作者认为可以在合理程度上信任结果；只要发现一行错误，就重新检查它所在的整个部分。

原文还补充了三个使用条件：内部或含客户信息的文档，先确认公司对公共 AI 工具的使用政策；重要表格和示意图，先把关键信息转成文字；最终速查表放在代码旁，例如 docs/vendor-api.md，供团队共享，并随原文变化更新。

我的判断

我赞同它把「压缩篇幅」改成「提取接入所需的事实」。对 API 文档而言，一段漂亮概述通常不如一张保留限制、异常和未知项的表有用。相比一次性总结，这套流程也更方便定位错误，但需要投入更多整理和核对时间。

它仍然是一套经验方法。作者说这是自己使用的流程，却没有展示完整样例、处理耗时、模型信息，也没有和一次性摘要做对照。

尤其是抽查 3–5 行，只能提供有限信心。抽查检查的是已有条目是否正确，无法证明关键内容没有被整段漏掉。请求量、必填字段、timeout 等会直接影响实现的项目，我会建议逐项回查，而不是只等随机抽中。

按章节拆分也有前提：章节未必完全独立。认证规则可能统一适用于多个 endpoint，通用限制也可能写在另一处。原文没有说明如何处理这些跨章节依赖，实际使用时仍需要人工补足上下文。

能拿来做什么

• 接入第三方 API 前，先按认证、endpoint、错误码和限制拆分文档，再提取必填参数、类型和未说明事项，用它组织接入检查。
• 让 AI 辅助编写前端请求或 Node 接口代码前，先核对速查表里的关键约束；遇到「未提及」，回原文确认，不让模型自行补成服务规则。
• 把确认过的速查表放进 docs/vendor-api.md，在上游文档变化时同步更新，让团队有一个共同维护的查阅入口。
• 对决定实现行为的条目逐项核验，再用随机抽查检查其余内容；涉及内部资料或客户信息时，先确认公司允许使用的工具范围。