什麼係 JSON？附例子嘅淺白指南

JSON（JavaScript Object Notation）係一種簡單嘅文字格式，用嚟寫低結構化資料——例如一個客戶、一張訂單或者一份產品清單——將名稱同數值配對。人類容易睇得明，程式亦容易產生同解析。當應用程式同服務喺網上交換資料，JSON 係最常見嘅格式。

用 AI 寫嘢時點解 JSON 重要

就算你從來冇寫過程式碼，都會經常見到 JSON：

• API。 當你個 app 嘅畫面由後端攞資料，或者你嘅後端去叫付款、電郵或者 AI 服務，資料通常都係以 JSON 傳送。睇吓什麼係 API。
• 設定檔。 好多項目設定檔都係 JSON——例如 package.json，列出一個 JavaScript 項目嘅依賴項。
• 資料庫。 Postgres 可以喺一個欄位入面儲存 JSON（jsonb 類型），用嚟放唔啱整齊行同列嘅資料。睇吓什麼係 Postgres。
• AI 輸出。 當你想 AI 模型回傳一啲程式可以直接用嘅嘢——例如一份標籤清單，或者提取出嚟嘅發票欄位——你通常會要求佢用 JSON。
• 錯誤訊息同日誌。 好多錯誤都以 JSON 形式出現，睇懂佢通常係搵出問題最快嘅方法。

識讀 JSON 令你可以核對 app 實際收到咩、發現缺咗嘅欄位，並且準確咁向 AI builder 描述問題。

日常比喻

諗吓一張紙本表格：姓名：，電話：，電子報：☐ 要 ☐ 唔要。 每個填寫位都係一個標籤，旁邊有對應嘅數值。JSON 就係將呢張表格寫成文字，用一種嚴格嘅格式，電腦唔使估都讀得明。同表格一樣，JSON 可以有分節入面再分節（一個地址區塊包括街道、城市同郵區），亦可以有清單（幾個電話號碼）。

JSON 長咩樣

以下係一個預約嘅 JSON：

{
  "id": 5001,
  "customer": "Lena Park",
  "service": "Haircut",
  "startsAt": "2026-10-03T14:00:00Z",
  "price": 35.5,
  "paid": false,
  "notes": null,
  "extras": ["beard trim", "hot towel"],
  "contact": {
    "email": "lena@example.com",
    "phone": "+44 20 7946 0000"
  }
}

讀法：

• 大括號 { } 包住一個物件（object）——一組名稱同數值配對。
• 每一組都係 "名稱": 數值，用逗號分隔。
• 方括號 [ ] 包住一個陣列（array）——一個有次序嘅清單。
• 物件同陣列可以互相包含，就好似 contact 同 extras 咁。

六種數值

JSON 只有六種數值類型。呢個小清單係佢到處都能夠用嘅其中一個主要原因。

JSON 冇日期類型。日期會寫成字串，通常用上面示範嘅 ISO 8601 格式（2026-10-03T14:00:00Z，其中 Z 代表 UTC）。大家都用同一種格式，就可以避免一整類時區錯誤。

嚴格規則（錯誤嚟源）

JSON 比表面上睇落嚴格。以下全部都係無效嘅：

{ name: "Lena" }            ← 鍵冇雙引號
{ 'name': 'Lena' }          ← 用咗單引號
{ "a": 1, "b": 2, }         ← 尾隨逗號
{ "a": 1 "b": 2 }           ← 漏咗逗號
{ "a": 1 // comment }       ← 唔可以有註解

你會見到嘅大部分「Unexpected token」錯誤，都係其中一種。JSON 驗證器或者格式化工具會指出準確嘅行。

實例：JSON 經過一個 app

一位客人喺一個美容院 app 預約剪髮。以下係 JSON 出現嘅地方：

1. 預約表格將呢段資料送去 app 嘅後端：

{ "service": "Haircut", "startsAt": "2026-10-03T14:00:00Z", "name": "Lena Park" }

1. 後端將預約儲存喺資料庫，並回覆狀態 201 Created 同埋：

{ "id": 5001, "status": "confirmed" }

1. 如果嗰個時段已經俾人預約咗，佢可能會改為回覆狀態 409 Conflict 同埋：

{ "error": "slot_taken", "message": "嗰個時段啱啱俾人預約咗，請揀另一個時間。" }

頁面會讀取 status 或者 error，然後顯示正確嘅訊息。如果頁面變成空白，打開瀏覽器嘅開發人員工具（Network 分頁）就會見到呢段 JSON——通常係搵出問題最快嘅線索。

主要術語

常見誤解

• 「JSON 即係 JavaScript。」 佢嘅語法源自 JavaScript，但佢唔依賴任何語言；Python、Java、C#、Go 同其他語言都可以讀。
• 「數字加咗引號都冇問題。」 "35" 係字串，唔係數字。混用會引發錯誤，例如 "35" + "5" 會變成 "355"。金錢通常最好以整數仙（3550）儲存，避免捨入問題。
• 「JSON 好安全，因為佢只係資料。」 JSON 可以載入任何嘢，包括秘密資料。唔好將 API key 放入會傳送去瀏覽器嘅 JSON。
• 「全部嘢都放入 JSON 欄位。」 彈性額外資料用嚟好方便，但你要搜尋、篩選或者串連嘅資料，通常應該放喺正規欄位。
• 「AI 一定會回傳有效嘅 JSON。」 模型可能加咗額外文字，或者破壞格式。好多服務商提供結構化輸出模式，但你嘅程式仍然要檢查返嚟嘅內容。

你可以叫 AI builder 做咩

• 「展示呢個端點回傳嘅 JSON 例子。」
• 「錯誤用 JSON 回傳，包括一個 error 代碼同一條人類可讀嘅 message。」
• 「日期以 UTC 嘅 ISO 8601 字串儲存，只喺畫面上先轉換做本地時間。」
• 「價格以整數仙儲存。」
• 「喺伺服器驗證收到嘅 JSON，遇到欄位缺失或者類型錯誤就拒絕請求。」
• 「調用 AI 模型時，要求佢用呢個確切格式回傳 JSON，並喺使用前檢查。」

Mythex 入面嘅 JSON

喺 Mythex 你唔使親手寫 JSON——你講出想要咩，agent 就會寫出負責傳送同讀取佢嘅程式碼。不過認得佢都有用：出現問題時，將 JSON 錯誤貼落對話，會俾 agent 一個準確嘅線索。文件入面嘅 REST API 後端食譜由一開始就要求「清晰嘅 JSON 錯誤」，而 整合任何 API 食譜就講點樣呼叫外部服務。如果想睇全局，可以睇REST 對 GraphQL同點樣 debug AI 寫嘅 app。

常見問題