從例子出發
物件、陣列、字串、數字會對映到對應 type。巢狀物件會盡量展開 properties。
空陣列缺少元素樣本時，items 型別可能不準，請補一條真實元素再推斷。
JSON Schema 校驗
本地處理 也可透過 #data={"name":"Ada"} 或 #url=... 灌入資料，讀完即從位址列清除。
根據一份示例 JSON 推斷 JSON Schema。適合先有真實響應、再補介面文件或給校驗器當起點。推斷結果請人工核對必填項和列舉——工具只能看到「這份例子裡有什麼」，看不到「業務上必須有什麼」。
當草稿用
自動推斷無法知道「這個欄位是否必填」，需要你改 required。可選欄位、列舉、format（email、uri）也需要人工補。
生成後交給 ajv 等工具在 CI 裡跑，比只靠口頭約定穩。
本地生成
示例資料不會上傳。用生產樣例時仍建議先脫敏。
輸出含 $schema 宣告，方便其它工具識別版本。
示例
{
"id": 1001,
"name": "Ada",
"active": true
}{
"type": "object",
"properties": {
"id": { "type": "number" },
"name": { "type": "string" },
"active": { "type": "boolean" }
}
}能用來校驗另一份 JSON 嗎？
本頁側重由示例生成 Schema。把生成結果交給你們的後端或 CI 裡的 ajv 等工具再做校驗。
巢狀和陣列呢？
會盡量往下推斷。空陣列缺少元素樣本時，item 型別可能不準。
和 GraphQL 頁怎麼選？
REST / JSON 文件用 Schema；GraphQL 服務用型別推斷頁。
會標 format: email 嗎？
以型別推斷為主。郵箱等格式請對照業務補進 Schema。
推薦工作流
- 準備一份「欄位儘量齊全」的成功響應樣例。
- 生成 Schema，檢查 type 和 properties 是否合理。
- 手工補 required、enum、additionalProperties 等約束。
- 放到 Mock / CI 裡校驗後續響應，和 Diff 一起做版本審查。
一份例子推不出完整契約。最好用多條樣例交叉核對，再收緊 Schema。