📍 真實場景
小型電商的客服兼工程師小美
每天要看幾百張買家寄來的商品照片和客訴訊息，決定哪些是破損、要轉給哪個部門
😖 卡住的地方：以前得叫大型語言模型寫一段回答，再自己用程式去解析文字。慢、貴，格式還常常不一致。
💡 讀完你會知道 Decisions API 適合做哪種判斷，也能在今天用一個 curl 指令試出第一個「是否破損」的機率。
⚡ 一句話講清楚
OpenAI 公開測試了一個新的 API讓程式之間互相呼叫的服務窗口，你的程式送出請求、對方回傳結果，叫 Decisions API。它不是用來寫文章的，而是用來「做判斷」。你送進去文字、圖片，或兩者都送，再附上你想問的問題，它回傳的是整齊的答案，不是一大段話。官方說它比 Responses API 快約 10 倍。
問題分三種。第一種是 predicate（判斷式），例如「這張照片有沒有明顯破損？」，回傳 0 到 1 之間的 機率數字越接近 1，代表模型越相信這件事是真的。第二種是 choice（選一個），例如「這則訊息該轉給哪個部門？」，從你事先給的選項裡挑一個。第三種是 score（評分），例如「問題嚴重度」，依你定義的有序等級打分。分數是各等級機率的加權平均，所以可能落在兩個等級之間，例如 1.6。
什麼時候不該用它？如果你要的是自己設計欄位的 JSON一種用大括號和鍵值組成的資料格式，程式很容易讀取（例如抽取姓名、地址），或要模型寫解釋，官方建議改用 Responses API 搭配 Structured Outputs。要模型呼叫工具則用 function calling。Decisions 只負責上面那三種答案。目前它是公開測試版（beta），官方預計幾週內正式推出（GA），而且只有 gpt-6-luna 這一個模型可用。
🏃 快速上手三步（今天就能做）
1
先在 Playground 玩一下到 OpenAI 官方文件的 Decisions 指南頁（developers.openai.com 的 API docs 裡找 decisions），打開頁面中提供的 Playground。先不寫程式，拿 3 到 5 張你自己的圖片或訊息，試著問一個 predicate 問題，例如「圖片中是否有裂痕、破洞或凹陷？」。觀察回傳的機率是否合理。
▼
2
用一個 curl 打 /v1/decisions確認環境變數 OPENAI_API_KEY 已設定。對 POST https://api.openai.com/v1/decisions 送 JSON，內容有三個欄位：model 填 "gpt-6-luna"、input 放文字或含圖片的 user 訊息、questions 放問題。每個問題要有不重複的 name，回應的 answers 陣列會用同一個 name 回報答案，你才對得起來。questions 內其他欄位的確切寫法，請照官方指南範例複製，不要自己猜。要用 SDK 的話，版本要不低於 Python 3.26.0 或 JavaScript 7.30.0。
▼
3
拿真實資料驗證門檻，再上線取 20 到 30 筆你已經知道答案的資料跑一遍。看「確定破損」和「確定沒破損」的機率大概落在哪裡，再決定門檻，例如機率大於 0.8 自動分流，0.4 到 0.8 之間交給人看。注意：它還在 beta，GA 前參數或行為可能改變，所以先用在不影響結果的分流和排序上，不要直接拿去做不可逆的決定，例如自動退款。
🧠 工程思維透鏡（資深工程師看到的是什麼）
🔭 「快 10 倍」與「回傳機率」對系統設計有什麼實際影響？
分類、分流、排序這類工作量大、單筆價值低，延遲和成本通常是瓶頸。回傳機率而不是文字，等於免掉解析輸出的步驟，也讓你能自己設門檻，在召回率和誤判率之間取捨。代價是你得自己校準這些機率：模型給 0.9 不等於實際有 90% 的準確率，必須用自己的資料驗證。另外「10 倍」是官方對比 Responses API 的說法，你的圖片大小、問題數量都會影響實際數字，上線前要自己量測。
🔭 只有單一模型、又在 beta，該不該把它放進正式流程？
風險有三個：模型只有 gpt-6-luna 一個，沒有替代選項，也沒有在品質和成本之間切換的空間；beta 階段介面和計價可能調整；你的程式會綁定這個專用端點。比較穩妥的做法是在你的程式裡加一層薄薄的包裝（輸入問題，輸出機率、選項或分數），讓底層日後可以換成別的實作。先拿它處理可回復、可人工覆核的任務，等 GA 公告和穩定性確認後再擴大使用範圍。