YAML — 其遞歸意義為「YAML Ain't Markup Language」— 透過縮排而非括號或大括號來表示資料。所有內容皆由三個基本元素建構而成：純量值（字串、數字、布爾值）、序列（有序清單，以 - 標記）以及映射（鍵值對，以 : 標記）。透過進一步縮排來巢狀結構。在某個鍵下使用兩格縮排表示「此內容屬於該鍵」。這正是 YAML 可以一目了然的優點，也是當結構出錯時令人頭痛的原因。除了基本功能外，YAML 還支援錨點（&name）與別名（*name）來重複使用設定片段、以 --- 分隔的多文件，甚至自訂標籤用於類型提示。大多數人從不碰觸高階功能，但僅僅錨點就能讓你避免在五個地方重複維護相同的設定區塊。
如果你從事任何與 AI 基礎設施相關的工作，YAML 是無法避免的。Hugging Face 模型卡片使用 YAML 前置資料來描述模型的授權、資料集、指標與預期用途 — 這就是 Hub 能夠辨識你的模型並顯示它的方法。啟動推論伺服器、向量資料庫與監控系統的 Docker Compose 檔案皆為 YAML。部署與擴展模型服務容器的 Kubernetes 設定檔也是 YAML。Hydra、MMEngine 和 Axolotl 等框架的訓練設定檔同樣為 YAML。GitHub Actions、GitLab CI 和 CircleCI 的 CI/CD 管線也是 YAML。甚至 Prometheus 警告規則與 Ansible playbook 都是 YAML。這種格式之所以在設定檔戰爭中勝出，不是因為它完美，而是因為當你在凌晨兩點盯著 200 行的部署規格時，它是最不痛苦的選擇。
YAML 最著名的陷阱是其隱式類型轉換。值 no 會被解析為布爾值 false。值 3.10 會變成浮點數 3.1，這在它代表 Python 版本時會造成問題。挪威的國家代碼 NO 會被轉換為布爾值 false — 這被稱為「挪威問題」，並在實際生產資料集中導致過真實的錯誤。還有 tab 與 space 的問題：YAML 明確禁止使用 tab 來縮排，這一點毫無妥協空間。在一個 500 行的檔案中只要有一個 tab 字元，整個檔案都會無法解析，而且錯誤訊息通常會指向錯誤的行數。多行字串則透過 |（文字區塊，保留換行）、>（折行區塊，合併行數）及其帶有 - 和 + 的變體來控制尾部換行，這增加了另一層混淆。大多數人會選擇一種風格並記住它，而不是學習所有組合。
JSON 結構嚴謹、無歧義且廣泛支援 — 但因為需要大量引號與括號，手動撰寫時非常痛苦，而且不支援註解。YAML 是 JSON 的超集合（有效的 JSON 也是有效的 YAML），以可讀性取代嚴謹性：你獲得註解、更乾淨的語法與錨點，但也必須面對隱式類型轉換與空白敏感度。TOML 則處於中間位置 — 明確類型、支援註解、無縮排敏感度 — 非常適合用於 pyproject.toml 和 Rust 的 Cargo.toml 等扁平或淺層設定。實際應用的準則：使用 JSON 進行機器間通訊與 API 載荷，使用 TOML 進行淺層應用程式設定，使用 YAML 進行需要人類頻繁閱讀與編輯的深層設定。如果你的設定超過三層深，YAML 可能是最佳選擇。若為兩層或更淺，TOML 可以幫助你避免頭痛。
你能做出的最佳投資就是使用 YAML 格式檢查器。yamllint 不僅能偵測語法錯誤，還能發現風格問題，例如不一致的縮排與尾部空格。在 CI 管線中執行它，讓不良的 YAML 永遠無法進入生產環境。IDE 擴充套件 — Red Hat 提供的 VS Code YAML 外掛是標準選擇 — 可提供即時驗證、根據 JSON Schema 的自動補全，以及當縮排偏移時的即時反饋。對於包含重複區塊的大型設定，學習錨點與別名：以 &defaults 定義一次預設設定，並透過 <<: *defaults 合併至特定項目，僅覆寫需要變更的部分。如果你正在使用 Kubernetes 或 Docker Compose，kubeval 和 docker compose config 等工具會根據實際結構驗證你的 YAML，偵測一般檢查器無法發現的錯誤。當所有方法都失效時，請記住你始終可以將 YAML 轉換為 JSON，進行驗證後再轉換回來 — 因為最終它們代表的都是相同的資料。