模型 · System One
你聲明的選項就是整個模型
用語言模型，糟糕的提示會生成糟糕的句子，你看得出來。用型別化的決策模型，糟糕的問題會生成一個型別完全正確、格式完美的答案，而你根本看不出任何毛病。
這正是值得在把模型接入任何系統之前先理解的陷阱。來自2026年9月17日那一周的兩項證據——一項是預先註冊的評測，一項是實踐者的執行——從不同方向指向同一個結論：你得到的準確率，很大程度上取決於你如何寫這些問題。Ciyo 不執行 Jev；它不產生影像，也不產生影片，且不在我們的任何一個模型註冊表中。
一個問題，還是五個
本週發布最直接的證據來自一位執行釣魚郵件分流的實踐者。作為一個單一問題提問時，這項任務得了 62.6%。拆成五個獨立問題，針對同一 state 評估並在程式碼中合併後，得了 95%。
這只是某人用自己的標籤、在沒有公開資料集情況下的執行，所以它是一個嘗試拆分的理由，而不是一個可以引用的數字。但它與廠商自己的文件建議一致——分解成原子化的單一目的問題，而不是在一個問題裡做多因素判斷——也與 API 的形態一致：在一次呼叫中，每個問題都針對同一 state 平行評估。
經濟帳讓這條建議很容易遵循。一次呼叫中佔主導的成本是發送 state，而不是回答問題。只要 state 上了線路，問五個幾乎免費。
發布於 2026-09-21。發布者從自己的釣魚分流執行中報告了這兩個數字，並補充說在答案確實無法確知的地方，機率表現得自信卻錯誤，最後給出正確建議：先在你自己的標籤上做影子測試。由於未發布資料集，這些數字屬於發布者本人。
如何拆分一個抗拒拆分的問題
「這封郵件是釣魚企圖嗎」是結論，不是問題。拆分的方法是去問能使之成立的證據，一次一條，然後把下結論的事交給你自己的程式碼。
發件人網域是否與它聲稱所屬的組織匹配？訊息是否在索取憑證或付款？措辭裡是否有時間壓力？可見的連結文字是否與它們實際指向的地方一致？在這個發件人通常使用名字的地方，問候語是否泛泛？
五個窄問題，五個各自帶信度的值的答案，以及你程式碼中一條可以讀取、測試和修改而無需觸碰提示的規則。最後這部分才是真正的獎賞：合併邏輯變成了普通的軟體。
questions: {
"sender_mismatch": { "type": "noul", "instructions": "發件人網域與訊息聲稱所屬的組織不匹配。" },
"asks_for_secret": { "type": "noul", "instructions": "訊息向讀者索取密碼、驗證碼或付款。" },
"time_pressure": { "type": "noul", "instructions": "訊息迫使讀者迅速行動。" },
"link_mismatch": { "type": "noul", "instructions": "可見的連結文字與其實際指向的位置不同。" },
"risk": { "type": "score", "instructions": "把這封訊息投遞到收件匣有多危險？",
"criteria": ["無害", "可疑", "疑似釣魚", "明顯惡意"] }
}選項名是一個標籤；標準才是定義
Choice 接受一個從選項名到描述的 `criteria` 映射，Score 接受一個有序的級別描述陣列。這些字串不是寫給你同事的文件。它們是模型唯一擁有的定義。
「billing（帳單）」幾乎什麼也沒告訴它。「發件人在詢問一張發票、一筆他不認得的收費、一筆退款，或者更改付款方式」才告訴它要找什麼。這第二個版本也是你在任何東西自動化之前可以和同事爭論的版本，而那正是分歧代價最低的時刻。
寫標準就像給入職第一天的新人寫操作指引：什麼歸這裡，什麼看起來相似卻歸別處，以及當兩者都不是時該怎麼辦。
它給不了你的那個答案
現在說一個更尖銳、也會改變設計的發現。在2026年9月20日發布的預先註冊評測中，作者們測試了模型是否會示意某個 state 落到了聲明選項之外。在30個不存在逃生選項的越界案例裡，它沒有標記其中任何一個。
那不是缺陷。那是型別系統正按宣傳的那樣運作：你聲明了可能的答案，於是就回傳了一個宣告型別的值。但這意味著一個越界的輸入不會響亮地失敗。它安靜地成功，附帶最接近的選項和一個信度的值。
修復只需一行問題設計。你自己聲明逃生選項——`none_of_these`、`needs_a_human`、`not_applicable`——並像對待真正選項一樣仔細地為它寫標準。然後在程式碼裡路由它。
同一項評測發現它擅長什麼
值得把另一半也報告出來，因為圍繞這些模型的民間說法，往往在令人安心的方向上錯，在悲觀的方向上也錯。
同一項執行發現，數字比較和日期排序在13種不同的問題設計間保持在 99.6%，否定在 100% 的被測案例中都被正確處理。三天前發布的一份實踐者指南曾警告說否定可能失靈，且模型不擅長算術和日期。那次更大規模、預先註冊的執行沒有重現這一點。
這對於2026年9月整個這個話題是個有用的提醒：圍繞一個公開還不到一週的模型，大量言之鑿鑿的建議正在流傳。優先選擇附帶方法和程式碼倉庫的證據。
| 主張 | 來源 | 預先註冊的執行發現了什麼 |
|---|---|---|
| 不擅長算術和日期計算 | 一份實踐者指南，2026-09-17 | 數字比較和日期排序在13種設計中保持在 99.6% |
| 否定可能失靈 | 同一份指南 | 否定在被測案例的 100% 中被正確處理 |
| 上下文腐化：準確率隨無關 state 而下降 | 同一份指南 | 此處未被反駁；值得在你自己的 state 上測試 |
| 逐字讀取指令 | 同一份指南 | 與越界發現一致：它回答的是你寫下的那個問題 |
問題上線生產前的檢查清單
它是否原子化？如果句子裡含有「和」或「除非」，它很可能是兩個問題。
選項是否詳盡，包括一個逃生出口？如果一個看似合理的輸入無處落腳，它會落到錯誤的地方。
每個選項都有標準嗎？選項名是個標籤；標準才是定義，而模型只擁有你寫下的東西。
評分表有序嗎？Score 期望兩到十個在序列中有意義的級別，而回傳的評分可以落在它們之間。
你是否針對自己的標籤測量過它？本文中的每個數字都來自別人的任務。
關於問題設計的問題
為什麼拆分問題更好
每個問題都針對同一 state 孤立評估，所以窄問題就是窄任務。合併邏輯於是住進你的程式碼裡，可被測試。一位實踐者的執行在拆分後，於自己的標籤上從 62.6% 提升到 95%。
多問問題會更貴嗎
貴得極少。佔主導的成本是你發送的 state；問題針對它平行評估。
如果一個輸入不符合我的任何選項，會怎樣
它無論如何都會得到最接近的選項。一項預先註冊的評測發現，在未聲明逃生選項時，30 個越界案例中有 0 個被標記。聲明一個。
它在日期和否定上很弱嗎
一份實踐者指南在 2026年9月17日 這麼說。三天後更大規模的預先註冊執行測得，數字與日期排序為 99.6%，否定為 100%。與其相信任一方，不如在你自己的資料上測試。
繼續閱讀
Ciyo 撰寫關於創意與智慧代理工具背後的模型，並測試那些它能執行的模型。