散落的文件，成為可核對的規格。

將 PDF、Markdown、Word、HTML 或 OpenAPI 等來源整理成 OpenAPI 3.1、繁中串接指南與來源追溯。缺漏與衝突留下來，讓人回到原文核對。

看具體示例開啟使用文件

One concrete example

從來源，到產物，再回到人工核對。

同一個 API 的規格可能散落在 PDF、網頁與附件。整理後，開發者需要機器可讀的規格，也需要能追查依據與確認缺漏的閱讀入口。

使用示例 · 不是本次執行紀錄

loop-apidoc / 文件示例

來源：PDF / Markdown / Word / HTML / OpenAPI

openapi.yaml              → OpenAPI 3.1
api-guide.zh-TW.md         → 繁中串接指南
provenance.json           → 逐項來源追溯
validation/report.json    → 驗證與缺漏報告
review.html               → 離線人工核對

這是文件所列的產物名稱與閱讀順序。先看規格與指南，再用 provenance 回查來源，最後在 review.html 核對缺漏與衝突；不是本輪產生的串接成果。

01 / When to use

什麼時候用？

適合需要可追溯規格、交由多人或多個 agents 共用，且來源文件會持續改版的 API 串接。只想快速理解一份文件時，可以先用較短的閱讀流程。

02 / My work

我在這個作品上的工作

我維護來源依據式 API 文件流程，將來源擷取、規格生成、確定性驗證、來源追溯與人工核對串起來；讓整理結果能被檢查、比較及接續修正。

03 / Boundaries

先理解限制，再開始。

來源未提供的內容保留為缺口，不以常見 API 慣例補寫。模型擷取提案不等於來源事實或人工核准。
文件產物與驗證報告不能代替真實 API 串接測試；本頁沒有執行 pipeline 或呼叫供應商 API。
fixture 驗證、來源支撐的重驗與實作觀察是不同證據層級，不能互相當成通過證明。人工仍需核對來源、缺漏與衝突。

04 / Start here

從自己的專案開始。

先閱讀安裝、設定與完整操作文件，核對你使用的版本與環境。

安裝與完整使用文件

本文依 README b37229f 整理。示例描述文件內容，不代表本次已執行或驗證產品。

返回作品總覽

繼續看看其他工具與方法。