【2026 最新】OpenAI Decisions API 能用了嗎？10 筆假工單練習有限選項與人工複核

OpenAI Decisions API 能用了嗎？你每天收到一堆客服工單，想讓系統先把「退款」「帳號」「訂單」分流，但又不願把盜刷與看不懂的訊息直接丟給自動流程。最容易犯的錯，是把一張看似合理的 JSON 範例當成 OpenAI 已公布的 API 規格。

這篇寫給完全沒有技術背景、但想理解如何設計決策流程的讀者。我們先核對官方公布到哪一步，再用 10 筆純假資料做一個可在本機跑的練習：定義有限選項、留人工複核出口、記錄錯分，最後知道日後接上正式服務前要驗什麼。

先說結論：OpenAI Decisions API 的位置

截至 2026 年 10 月 4 日，OpenAI 的 DevDay 2026 公告把 Decisions API 描述為 limited preview：由開發者先定義問題與有限答案，輸入文字或圖片脈絡，再把答案用於分類、請求路由或 Agent 下一步。公告當時寫的是「未來數日計畫擴大開放」，這是一項計畫，不能當成你目前帳號已取得存取權。

一句話記住：決策流程＝有限選項＋明確的人工出口＋可回看錯誤的紀錄。前半句與官方公布的有限答案方向相符；「人工出口」和「錯誤紀錄」是本文教你加上的應用設計，不是 OpenAI 已承諾的 Decisions API 回傳欄位。OpenAI 開發者文件入口可用來核對日後的正式接入文件。

為什麼「有限選項」比一句萬用提示更容易管理？

想像餐廳出餐口有三條輸送帶：帳務、帳號、訂單。你不能讓每張紙條都自由生成一個新部門；否則後面的系統不知道該把單子送去哪。有限選項像是先把出餐口做成固定的三個門。第四個門叫「人工複核」：需求同時碰到兩個門、資料不足或涉及高風險時，先停下來。

這個設計適合內容分類、客服分流、Agent 的下一步選擇，但「選了哪個答案」與「能否真的自動執行」是兩件事。例如把盜刷工單選成帳務類別，仍不等於系統應自動退款或修改付款資料；動作權限要由你的應用程式另行控制。想看 Agent 如何把選擇接到工具與停止條件，可讀 Agent Harness 的白話解釋。

OpenAI 的 Guardrails and human review 指南也把敏感動作的人類核准設計成獨立控制點。那份指南談的是 Agents SDK 工作流；這裡借用它的「決策與副作用分開」原則，沒有宣稱 Decisions API 自帶同一機制。

若你在討論區看見 Jev，也可以接著讀 Jev 決策模型解析，理解另一個有限選項題材。這裡不把不同產品的速度、價格或端點畫上等號；先把自己的題目和驗收標準寫清楚，後續比較才有意義。

用 10 筆假工單設計 OpenAI Decisions API 的決策練習

先定義「正確答案」，再寫分流規則。這 10 筆全是假工單，不包含真實姓名、交易資料或客服紀錄。練習的四個本機選項是「帳務」「帳號」「訂單」「人工複核」。前三個表示交給相應隊列，第四個表示先讓人判斷；它們不是官方 Decisions API 的固定答案。

第 1 步：先寫選項與複核規則

• 帳務：扣款、發票、退款等常見問題；若同時涉及其他類別，先複核。
• 帳號：登入、密碼、驗證碼等問題。
• 訂單：訂單、寄送、配送等問題。
• 人工複核：盜刷、看見別人的資料、個資外洩，或訊息無法唯一歸類。

規則的順序很關鍵：先查高風險字詞，再看一般類別。這讓「登入後看到別人的訂單」先停在人工複核，而不是因為碰到登入與訂單兩組字詞，隨意選一條輸送帶。資料不足的「請幫忙」也會停下來；它不是空白標籤，而是需要補問的工單。

第 2 步：複製程式，在本機跑一次

把下面整段存成 triage.py，在有 Python 3 的電腦執行 python3 triage.py。它只讀程式內的假資料，不需 API 金鑰；這段程式是本機規則模擬，沒有呼叫 OpenAI。

"""Local rules exercise. This is not an OpenAI Decisions API client."""
import json

CASES = [
    ("T01", "請幫我處理重複扣款", "帳務"),
    ("T02", "發票抬頭寫錯了", "帳務"),
    ("T03", "我忘記登入密碼", "帳號"),
    ("T04", "收不到登入驗證碼", "帳號"),
    ("T05", "訂單遲遲沒到", "訂單"),
    ("T06", "可以改寄送地址嗎", "訂單"),
    ("T07", "配送員態度惡劣", "人工複核"),
    ("T08", "登入後看到別人的訂單", "人工複核"),
    ("T09", "有人盜刷我的卡，請立刻處理", "人工複核"),
    ("T10", "請幫忙", "人工複核"),
]
KEYWORDS = {
    "帳務": ("扣款", "發票", "退款"),
    "帳號": ("登入", "密碼", "驗證碼"),
    "訂單": ("訂單", "寄送", "配送"),
}


def decide(text):
    if any(word in text for word in ("盜刷", "別人的", "個資外洩")):
        return "人工複核", "高風險字詞"
    hits = [label for label, words in KEYWORDS.items()
            if any(word in text for word in words)]
    if len(hits) != 1:
        return "人工複核", "無法唯一歸類"
    return hits[0], "單一類別命中"


errors = []
for ticket_id, text, expected in CASES:
    chosen, reason = decide(text)
    row = {"id": ticket_id, "text": text, "expected": expected,
           "chosen": chosen, "reason": reason, "correct": chosen == expected}
    print(json.dumps(row, ensure_ascii=False))
    if not row["correct"]:
        errors.append(ticket_id)
print(json.dumps({"count": len(CASES), "errors": errors}, ensure_ascii=False))

程式每處理一筆，就印出 id、expected、chosen、reason 與 correct。這些是教學自訂的日誌欄位，方便你查錯；不要拿它們推定 OpenAI 的正式請求或回應格式。程式省略了實際客服系統的資料保存、存取權限與併發處理；接入真工單時，這三件事要在應用層另外設計。

第 3 步：逐筆看錯誤，不只看總分

這段本機程式對 10 筆假工單輸出 {"count": 10, "errors": ["T07"]}。T07 的原文是「配送員態度惡劣」，人工預期應複核；規則只看到「配送」便選了訂單，於是錯分。這不是 Decisions API 的準確率、效能或測試結果，而是我們這份固定規則與固定假資料的輸出。

改法可以是替服務申訴加人工複核條件，然後拿未參與寫規則的新案例驗證，而不是把「配送員態度惡劣」整句塞進特例清單。若只把已知錯題補成特例，舊題分數可能變好，新題仍可能出錯。

在 OpenAI 的準確度優化指南裡，客服案例也用「錯誤代價」來決定哪些情況交由人處理。套回本題，總分 9/10 不是放行標準；你要先問：那一筆錯誤會造成什麼後果？

日後真的接入前，要核對哪四件事？

本機練習把問題定義、選項設計和驗收方法準備好了。要把它換成正式服務，先在你實際使用的 OpenAI 帳號與官方文件核對以下四件事，別從第三方範例猜。

• 存取權：你的組織與專案是否可見 Decisions API，以及官方標示的開放階段。DevDay 公告的 limited preview 不等於所有帳號都能直接呼叫。
• 請求與回應：正式 API reference 的端點、認證、問題與選項欄位、文字／圖片輸入表示方式、錯誤碼。本文的 KEYWORDS 與 chosen 不是該規格。
• 操作邊界：官方文件列出的限制、計費與資料處理條款，以及你自己的人工複核和執行權限。
• 驗收題集：用有人工標準答案的資料分別記錄錯分、需複核、處理時間與每筆成本；看高風險案例的錯誤型態，別只看總命中率。

如果只是想先理解「讓模型輸出固定枚舉值」的另一種現有做法，OpenAI Structured Outputs 指南展示 JSON Schema 的 enum 與結構約束。那是另一套已文件化的功能，不是 Decisions API 的欄位範例，也不能代替本文要核對的專用介面。

常見問題：OpenAI Decisions API、有限選項與複核

現在每個人都能呼叫 OpenAI Decisions API 嗎？

不能從發表公告推定。2026 年 9 月 29 日官方用語是 limited preview；請在自己的專案控制台與正式文件核對實際存取權。

本文程式有真的呼叫 Decisions API 嗎？

沒有。它用 Python 的字詞比對練習流程設計，日誌格式也由本文自訂。

為什麼一定要有人工複核？

因為資料不足、類別碰撞或高風險事件需要保留一條可暫停的路徑；本例把這些情況放進第四個選項。

是不是每張工單都只能選一個答案？

本練習每筆只輸出一個去向；官方公告說預定義有限答案，但完整請求與回應細節應以正式 API reference 核對。

模型回傳答案後，可以直接執行退款嗎？

先不要。分類答案與金流動作要分開；把權限、核准與留痕設在自己的應用層。

為什麼 T07 錯了？

因為「配送」關鍵字蓋過了服務申訴的語意。這是規則式模擬的漏項，應靠新的驗收題測試修正。

Structured Outputs 等於 Decisions API 嗎？

不等於。Structured Outputs 有自己的 JSON Schema 文件；本文只拿它說明固定枚舉值，沒有把兩者混成同一規格。

何時可以把假資料換成真工單？

先確認正式接入文件、資料處理條件與團隊權限，再用去識別、可複核的樣本做驗收；高風險動作仍由人核准。

給新手的 3 個重點

• 辨狀態：官方公布 limited preview，接入權限要看你的實際帳號與正式文件。
• 先設出口：把「人工複核」做成明確選項，讓無法唯一判斷的工單有去處。
• 看錯題：把人工標準答案與系統選擇並排保存，先修高風險錯分，再談擴大自動化。