供應商表格
商品編號：AX-2047
重量：0.5 公斤
材質：空白
01
問題 · 能力與流程是兩件事
先找出難點，再決定怎麼用模型
整理 500 筆資料，要記住規則、處理例外，還要逐筆檢查。工作範圍一大，就容易在後半段漏掉條件。
看錯誤出在哪一步
強模型當然有價值。當任務需要更深的推理、更好的整合或更高品質的判斷時，模型能力本身很重要。
前 20 筆都正常，做到後面卻開始漏規則，這常和工作安排有關：同一個 AI 一次要記太多 上下文Context，還得整理、處理例外和自己檢查。
能力型問題 · CAPABILITY
難的是「想出好答案」
例如兩份市場資料說法不同，卻得決定產品要賣給誰。這時需要整合證據、評估取捨，並由負責的人確認方向。
流程型問題 · WORKFLOW
難的是「做很多次還要一直做對」
例如每筆商品資料只要轉單位、補欄位、配圖片，本身並不難；但做到第 200 筆後開始漏欄位、錯配圖片，問題就在流程如何維持一致。
LEVEL 3 · 工程觀點
模型能力提升可以降低單步錯誤率，但不一定消除 context dilution、state drift、error propagation 與 self-review bias。若 failure surface 沒被切小，錯誤仍可能在長鏈條中累積。
看到判斷題，就加強模型、證據和人類決策；看到大量重複工作，就先調整分工與檢查方式。
02
核心轉折 · 改變工作安排
把 500 筆分成小批，每批做完就核對
四行工作卡提供共同規則；分批和複查，讓每一步都有清楚的責任。
讓每一步都有明確責任
同樣用 Luna 這類成本較低的模型，也可以換一種工作安排。
把 500 筆商品分成小批，一個 AI 代理負責整理，另一個角色重新對照原始資料。每批按工作卡驗收；有錯就修正那一筆或那一批。
原本的做法
同一個 AI 代理，從整理到檢查都自己做
一個代理處理全部 500 筆
- 同時閱讀所有表格、PDF 和照片
- 整理欄位、處理例外，還得記住前面怎麼做
- 最後由自己檢查自己的結果
調整後的做法
分批整理，再交給另一個角色核對
主控代理：分批、分工、收集結果
↓
整理 A處理一批
整理 B處理一批
整理 C處理一批
↓
複查 A核對原始檔
複查 B核對原始檔
複查 C核對原始檔
↓
合併各批結果，再檢查整體資料
每批整理完就核對，AX-2047 的照片錯配能在這一批被發現和修正。
03
案例追蹤 · 從整理到複查
AX-2047 這筆資料，會怎麼被整理和複查？
把四行工作卡交給處理這一批的代理，看看 AX-2047 的照片錯配在哪一步發生、又怎麼被查出來。
CASEAX-2047 桌燈
來源Excel + PDF + 商品圖
任務轉成網站可匯入資料
這次錯誤圖片配成 AX-2074
觀察重點FAIL → 局部重做 → PASS
01
主控代理先分批
把 500 筆分成 25 批。負責這一批的執行代理拿到 AX-2041～AX-2060、四行工作卡與相關來源檔。
02
執行代理整理資料
把 0.5 公斤寫成網站需要的 500 公克、補上材質和標題，再選出它認為屬於 AX-2047 的照片。
03
另一個代理複查：不通過
欄位都填滿了，但複查代理重新比對原始資料，發現照片其實屬於 AX-2074。
04
修正 AX-2047 的照片
這一筆的照片換成正確商品圖，再交給複查者核對。
05
複查通過，再繼續整合
複查者對照工作卡與來源：商品編號、重量、材質和照片都符合要求，這一筆才進入整合。
執行代理 · 第一次提交
sku: AX-2047 weight_g: 500 material: aluminium image: AX-2074-main.jpg ← 配錯照片
局部修正後 · 再次提交
sku: AX-2047 weight_g: 500 material: aluminium image: AX-2047-main.jpg ← 複查通過
LEVEL 3 · 為什麼這個例子重要
這個流程的價值不只在「多驗一次」，而在 failure localization：錯誤有清楚的 task boundary、可定位的 state、可重做的最小單位，以及不需要重跑整條 pipeline 的 retry path。
工作卡定好共同標準，分批讓錯誤有明確位置。AX-2047 修正照片後，就從這一筆重新核對。
04
從工作卡到多人分工
工作量變大，四行要求就要有人分批執行、有人核對
AX-2047 的工作卡定好目標和檢查方法。處理 500 筆時，主控角色負責分批，執行者整理資料，複查者按同一份要求核對；有錯就修正那一筆。
想看這些動作的工程名稱？展開對照
先寫清楚商品編號、欄位、單位、資料說法不同時以哪份為準，以及什麼算完成
規格文件Specification
把 500 筆切成 25 批，決定誰處理哪一批
任務拆解與主控協調Task Decomposition / Master orchestration
執行代理 C 一次只處理 AX-2041～AX-2060
執行代理Worker
先檢查空欄位、型別、單位與檔案是否存在
自我檢查Self-check
另一個角色重新核對來源、SKU 與圖片關係
獨立複查Independent Reviewer
檢查通過才進下一步；有錯先回到這一筆修正
品質關卡Quality Gate
只修 AX-2047，再從同一個驗收點重新檢查
局部重試Local Retry
工作卡寫清楚目標和驗收方式；任務變大時，再指定誰整理、誰核對、出錯後由誰修正。
05
執行與複查 · 同一個假設的盲點
自己檢查過，為什麼還是可能漏掉錯誤？
AX-2047 的照片錯配就是例子：執行代理能確認「照片欄位有值」，卻可能沒回頭核對「這張照片是否真的屬於 AX-2047」。
執行者
「我找到一張看起來對的商品圖。」
它依檔名或相似外觀選了照片，再確認圖片欄位有值。自己檢查可以發現漏填，卻可能沒重新懷疑當初選的照片。
換個角色，從原始資料重新確認
複查者
「這張照片真的是 AX-2047 的嗎？」
複查代理重新對照規格表的外型描述、照片和商品編號；找不到足夠證據時，就標記待確認。
01
先由執行者自查
檢查必填欄位、格式和單位，確認沒有漏填或寫錯。
02
再由另一個角色複查
重新對照原始資料，確認照片和規格是否真的屬於這件商品。
03
最後檢查整批結果
把各批合併後，確認有沒有重複商品、欄位寫法不一致或資料互相矛盾。
資料說法不同時，該以哪份為準？
先約定哪份資料為準
- 由負責人核准的商品資料
- 最新的官方或供應商規格文件
- 供應商表格與業務備註
- 檔名、圖片位置或 AI 的推測
這份順序是示例。實際工作時，請熟悉商品資料的人先決定各份文件的採用順序。
資料對不上時，先留給誰確認？
如果這批只收到一張方底座的照片，規格表卻寫 AX-2047 是圓底座，就先把照片欄標成「待確認」。附上兩份資料，請商品負責人找出正確圖片，確認後再上架。
發現規格與照片對不上
照片欄標記待確認
附上來源，請負責人確認
三層檢查：先查明確的，再處理需要判斷的
01
程式規則檢查
先用程式查明確的條件，例如欄位、數字格式與檔案是否存在。
- 必填欄位是否為空
- weight_g 是否為數字
- SKU 是否重複
- 圖片檔案是否存在
02
模型複查
再核對需要理解的關係，例如照片的底座和燈罩是否符合這件商品的規格。
- 圖片是否為同一商品
- PDF 描述與 SKU 是否一致
- 分類是否符合來源證據
03
轉交人工判斷
兩份重要資料矛盾、沒有明確答案，或出錯代價很高時，把證據交給負責人決定。
- 可信來源彼此衝突
- 品牌 / 策略等主觀判斷
- 高風險不可逆決策
LEVEL 1 · 一句話
電腦先查「一定能判斷的」，模型再查「需要理解的」，真的沒有標準答案時才交給人。
LEVEL 3 · 驗證設計
Verifier 應盡量使用與 Generator 不同的 evidence path。Deterministic checks 是低成本、低歧義的 first-line defense；LLM Reviewer 處理 semantic validation；human escalation 負責 unresolved ambiguity，避免只堆疊同型 Reviewer 所造成的 correlated failure。
LEVEL 3 · 同模型 Reviewer 的限制
角色與 Context 可以獨立，但底層模型若相同，錯誤並不統計獨立。高風險任務若存在 correlated failure，應加入 deterministic checks、異質模型或人類審核，而不是只增加同型 Reviewer 數量。
複查者回到原始檔，核對照片與 AX-2047 的編號和外型。這一步讓錯配在上架前被發現。
06
可靠性 · 看預期效果，也看驗證證據
這套設計想縮小的，是一次錯誤的影響範圍
以 AX-2047 為例，分批整理與複查讓錯誤落在一筆可查的資料上。上架前找到錯配的照片，修正這一筆後就能繼續處理其他商品。
01
每次只處理一小批
負責 AX-2047 的代理一次處理 20 筆商品，並帶著這一批需要的規則。
02
知道是哪一筆出了錯
AX-2047 配錯照片，就在這一筆留下記號和原因，方便回頭查。
03
上架前先發現錯誤
照片核對失敗時，先把這筆留在待確認清單；確認正確圖片後再上架。
04
錯哪裡就只修哪裡
修正 AX-2047 的照片，重新核對這一筆；其他已通過的商品照原計畫繼續。
換成自己的任務，怎麼知道這套做法有沒有幫助？
把這套方法用到自己的工作時，先寫清楚怎樣算完成，再用三個問題看成果、錯誤與總投入。
結果符合要求嗎？
商品資料要填完整，照片也要配對。換成你的任務，先挑出最重要的完成條件。
錯誤在哪一步被發現？
AX-2047 的照片應在上架前查出。你的工作也可以記下錯誤出現和被發現的步驟。
合格結果花了多少？
把模型用量、費用、人工檢查與返工一起記下來，再比較不同做法。
先挑同樣五筆資料，用原本做法與新流程各試一次。記下合格數、token 用量（模型處理內容的計量單位）、費用、人工核對時間和重做次數，再比較完成一筆合格資料的總投入；工作卡與複查也算在內。
想進一步量化？展開七項參考指標
| 要觀察的指標 | 它回答什麼問題 | 如何判讀 |
|---|---|---|
| 欄位完整率Field Completeness | 處理到最後時，還有多少必填欄位完整填好？ | 越高越好；但欄位有值不代表內容正確。 |
| 完全符合率Exact Match | SKU、重量、型別等可以客觀核對的欄位，是否和人工確認的基準答案完全一致？ | 越高越好，適合檢查明確欄位。 |
| 跨來源一致率Cross-source Consistency | 圖片、PDF 與 Excel 是否真的指向同一件商品？AX-2047／AX-2074 的錯配就屬於這一類。 | 越高越好，專門揭露「格式正確、關係錯誤」。 |
| 錯誤攔截率Error Catch Rate | 已知錯誤在進入下一個工作階段以前，有多少被程式檢查、複查或品質關卡攔下？ | 越高越好；也要記下有多少警報後來證實是誤報。 |
| 錯誤放行率False Pass Rate | 被判定通過的結果裡，有多少經人工基準確認後其實仍然錯誤？ | 越低越好，通常比通過數量更值得警戒。 |
| 重試效果Retry Effectiveness | 哪些工作單元需要重做，而且重做之後是否真的修正了原本的錯誤？ | 不能只看次數；要和重試後成功率一起判讀。 |
| 每筆合格結果成本Cost per Accepted Item | 把模型用量、費用、人工核對與重做全部算入後，得到一筆合格資料需要多少？ | 用相同的完成標準比較不同做法，並一起看花費與品質。 |
LEVEL 1 · 一句話
把錯誤留在較小的工作範圍，及早發現、修正，再用實際結果看這套做法有沒有幫助。
LEVEL 3 · 更精確的工程說法
可靠性提升來自 failure surface reduction，而不只是 agent count。若拆解沒有降低 context dependency、verification cost 或 retry scope，多 Agent 可能只會增加 orchestration overhead。評估時應同時看 false-pass rate、accepted-unit cost 與 verifier incremental value。
成果品質、錯誤發現時間和每筆合格資料的總投入，會告訴你這套分工是否值得繼續使用。
07
任務類型 · 先看難點，再選做法
資料整理完了。現在主管問：「這盞燈要賣給誰、主打什麼價值？」
主管現在要決定 AX-2047 應走「設計家具」還是「平價居家」。資料能提供線索，最後仍得衡量顧客、價格和品牌方向；這一步更依賴判斷能力。
同樣是 AX-2047，前面處理的是「資料能否逐筆核對」，現在要回答的是「產品該怎麼定位」。兩種工作都可能很難，但難點不同：一種是量大，另一種是沒有現成答案。看清楚難點，才知道該先設計流程，還是提高判斷與複查能力。
工作量大的問題
500 筆商品資料要整理
工作量大、規則明確、每筆容易驗證、做錯一筆可以局部重做。
→ 很適合先想「怎麼拆、怎麼驗」。
需要判斷的問題
AX-2047 要走設計家具，還是平價居家？
這是在判斷產品要服務誰、主打什麼價值。資訊不完整、沒有單一正解，也很難只用「通過或不通過」驗收。
→ 模型的推理、證據整合與判斷能力本身更重要。
越能拆、越能驗、重做成本越低，就越適合優先設計工作流程；越模糊、越難驗、錯一次代價越高，就越需要提高模型與複查能力。
高吞吐／效率型
大量、可驗、成本敏感
適合規則清楚、處理量高、容易逐筆驗收的工作。這一類模型不一定「弱」，而是在大量重複工作中更重視速度與成本。
GPT-6 Luna
GPT-5.6 Luna
DeepSeek V4.1-Flash
Qwen3.8-Flash
Kimi K2.8 Preview
平衡型
兼顧推理、速度與成本
適合需要整合與判斷，同時也重視成本和速度的日常工作。
GPT-5.6 Terra
Gemini 3.8 Flash
Kimi K2.8 Preview
Qwen3.8-Flash
高能力／高判斷
難拆、難驗、判斷密度高
當任務需要複雜推理、長程工程、多工具協作或高品質判斷時，模型能力本身更重要。這些模型也可以負責大型流程中最需要判斷的步驟。
GPT-6 Astra
GPT-6 Sol
Claude Opus 5.5
Qwen3.8-Max-0902
Kimi K3
GLM-5.3
看工作量與判斷難度，選擇處理方式
越往上：越難驗證 / 越依賴判斷
高判斷／高能力
工作量未必大，但答案難驗，模型本身的推理與判斷品質更重要。
當前例：
GPT-6 Astra
Claude Opus 5.5
GPT-5.6 Sol
大工作量＋仍需高判斷
既需要跑很多工作，又需要長程整合、工具使用或複雜判斷。
當前例：
GPT-6 Sol
Gemini 3.8 Flash
Qwen3.8-Max-0902
Kimi K3
GLM-5.3
簡單直接做
工作量低、很好驗；可能單次使用快速模型就夠，甚至直接用規則程式。
當前例：
GPT-6 Luna
Qwen3.8-Flash
規則程式
大量處理＋工作流程
工作量高、重複度高、容易驗證、失敗可局部重做。
當前例：
GPT-6 Luna
GPT-5.6 Luna
DeepSeek V4.1-Flash
Qwen3.8-Flash
Kimi K2.8 Preview
越往右：工作量 / 重複度越高
先看任務，再試模型。 用同一小批工作比較成果品質、模型用量與總花費，會比只看單次價格更容易選出合適做法。
想看具體模型例子？展開補充資料
模型例子 · 2026 年 9 月
用途示例，請依自己的任務試用
Claude Opus 5.5Anthropic 9/22 新版；偏複雜工作與高能力端。
Gemini 3.8 FlashGoogle 9/2；workhorse，強調 reasoning、coding、agentic 與 Flash 的速度成本。
DeepSeek V4.1-FlashDeepSeek 9/10；高吞吐、較低成本、原生多模態，適合 agentic / long-context workload。
Qwen3.8-Max-09029/2 快照；複雜工程、長程自主開發、多工具 orchestration 與 1M context。
Kimi K3 / K2.8 PreviewK3 是 Kimi Code 旗艦；K2.8 Preview 9/11 上線，接近 K3 但更重視思考效率。
GLM-5.3目前旗艦之一，聚焦 coding、agentic 與長程複雜任務。
用合格成果的總花費選模型
同一批工作、同一套完成標準，才有辦法比較不同模型與流程。
先各做一小批，記下合格數量、模型用量、費用、人工檢查時間和重做次數。結果達到要求後，再選總投入較合理的做法。
如果困難在「要做很多次」，先想拆解；如果困難在「根本不知道哪個答案才好」，先想判斷能力與驗證方式。
08
任務分流 · 把方法用到自己的工作
拿自己的任務，回答六個問題
先看工作能拆多小、結果怎麼核對、出錯後要修多少；再沿著下方的路徑，決定先調整流程、加強複查，或提高判斷能力。
能不能拆成相對獨立的小工作？
不能拆，就先重新畫出工作邊界；若每一步都需要理解全局，可能不適合分給許多代理。
能不能清楚說出什麼叫「對」？
如果連驗收標準都說不清，設置檢查步驟也無法保證結果正確。
做錯一小塊，能不能只重做那一塊？
如果可以，局部重做很有價值；如果一次錯誤代價很高，就需要更謹慎的首輪處理和複查。
每個執行者真的只需要局部資訊嗎？
如果每個執行者還是得知道全部歷史與全局狀態，拆解就沒有真正降低難度。
執行者和複查者會不會犯同樣的錯？
如果兩者沿用同一份資料或同一個假設，就換一份證據來核對；多檢查幾次相同資料，幫助有限。
真正困難的是「做」，還是「判斷」？
大量重複工作可以靠流程分擔；沒有明確答案的判斷，更依賴證據、模型能力和人來負責決定。
從六項診斷，收斂成三條執行路徑
從上往下回答；「否」會在右側離開主路徑，「是」則繼續往下一題。
01任務能拆開，而且每個執行代理只需要局部資訊嗎？
否 →先調整任務邊界工作需要完整全局時，交給能整合全局的模型或熟悉任務的人。
是 ↓ 繼續判斷
02能不能用明確證據說清楚什麼叫「對」？
否 →路徑 C · 核心難點是判斷提高模型能力、證據品質，必要時由人類負責最後決策。
是 ↓ 繼續判斷
03失敗能被定位，而且可以便宜地局部重做嗎？
是 →路徑 A · 先設計流程分批執行、逐批驗收，做錯時只重做需要修正的部分。
否 →路徑 B · 強化首輪與驗證提高首輪能力，並加入規則檢查、異質模型、更多證據或人類複核。
共同檢查：複查者是否使用和製作者不同的證據？如果只是同一模型、同一資料、同一假設再看一次，應補上規則檢查、異質驗證或人類複核。
09
出錯後 · 先查原因，再決定怎麼改
出錯時，先找原因，再選修正方式
規格模糊，就補清楚要求；工作切得太大，就縮小範圍；反覆卡在推理或判斷，再提高模型與複查能力。
01
修正規格
把模糊的需求、可信來源與驗收條件寫清楚。
02
縮小任務
減少單一執行者需要掌握的資訊與責任範圍。
03
局部重做
只重做失敗的部分，確認問題是否只是偶發錯誤。
04
提高模型或複查能力
如果同類錯誤一再出現，或任務需要更深的判斷，就提高相關角色的能力。
05
更換驗證方式
加入規則檢查、不同模型、外部證據或人類專家。
LEVEL 3 · 多代理流程還需要可觀測性（Observability）
Agent 數量一多，如果沒有 trace，你只會得到「最後錯了」而不知道在哪裡開始錯。每個 work item 至少要能追溯輸入、規格版本、Worker 輸出、Reviewer 決策與理由、Retry 次數，以及最後完成的版本。
AX-2047 出錯時，沿著紀錄往回查
如果最後又出現 AX-2074 的圖片，可以查看當時用了哪些資料、第一次選了哪張照片、複查者怎麼判斷，以及修正後換成哪張。
商品：AX-2047
使用的原始資料使用的工作卡版本第一次選的照片
複查結果：需修正原因：照片屬於 AX-2074
重新處理：1 次最後使用的照片
能力不足就提高能力，流程不清就修正流程。不論有幾個代理，都要留下記錄，才能在出錯時查出是哪一步出了問題。
10
適用邊界 · 看到這些訊號就別硬拆
有些任務需要保留完整的判斷脈絡
下列情況適合先改善資料、提高判斷品質，或交給熟悉全局的人決定。
「好答案」的標準還沒清楚
先請熟悉任務的人定義目標和取捨，再安排模型協助蒐集證據。
整體一致性就是任務核心
品牌策略、完整敘事、產品定位等工作，拆得太碎可能讓各段看似完成，合起來卻前後矛盾。
每個執行者都得理解完整全局
這表示工作沒有真正被分解；執行者增加，需要交換的資訊也沒有減少。
錯一次的代價很高
提高首次處理與驗證的品質，並安排人負責最後確認。
驗證答案和做答案一樣難
為複查者增加新的證據或專業判斷依據，才能讓複查真正有幫助。
分工比工作本身還費力
小任務交給一個合適的模型，直接完成並核對，通常更省事。
LEVEL 3 · 一個實用判準
當驗證成本（verification cost）接近執行成本（execution cost）、上下文依賴（context dependency）無法下降，或同模型錯誤相關性很高時，多代理流程的邊際收益會迅速縮小。此時提高複查品質，往往比增加代理數量更有價值。
拆開工作後，再看檢查是否更容易、修正是否只影響一小部分。這兩點決定分工能帶來多少幫助。
讀完就能試
下次打開 AI，先做這四步
- 拿一件手上的工作，填好四行工作卡：目標、資料、最後要拿到什麼、怎樣算完成。
- 請 AI 先做一筆或一小段，並列出使用的資料和需要你確認的地方。
- 對照原始資料檢查示範結果，補清楚工作卡，再處理剩下的工作。
- 工作量大時分批整理和複查；完成後記下品質、返工、時間、模型用量與費用。
填好工作卡後，可以這樣開始：「請依照這四項要求先做一份示範，標明資料來源，並列出需要我確認的地方。」
主文到這裡 · 以下為名詞與來源
名詞註解 · 只留正文真的會用到的詞
先理解方法，再補上專業名稱
閱讀時可以點開有底線的詞看簡短說明；這裡再按三種深度整理同一個概念。
找不到符合的術語。
flowchart TB SPEC["01 · 四行工作卡
目標 · 資料 · 成果 · 檢查"] ROUTE{"02 · 工作主要難在哪裡？"} BATCH["量大且能核對
分批交給執行者"] SELF["先查欄位、格式與單位"] REVIEW["另一個角色核對原始資料"] GATE{"符合工作卡？"} FIX["修正這一筆，再重新核對"] WAIT["資料對不上
標記待確認，交給負責人"] FINAL["合併各批結果，再檢查整體"] JUDGE["答案需要判斷
補證據、提高模型能力"] HUMAN["由負責人確認方向"] MEASURE["看成果品質、模型用量、費用與時間"] SPEC --> ROUTE ROUTE -- "可拆、可驗" --> BATCH --> SELF --> REVIEW --> GATE GATE -- "需要修正" --> FIX --> REVIEW GATE -- "資料待確認" --> WAIT --> REVIEW GATE -- "通過" --> FINAL --> MEASURE ROUTE -- "需要判斷" --> JUDGE --> HUMAN --> MEASURE classDef core fill:#ead9de,stroke:#7c4e58,color:#24231f,stroke-width:1.5px classDef model fill:#dfe9ed,stroke:#536f7c,color:#24231f,stroke-width:1.5px classDef verify fill:#e0e7dc,stroke:#64745f,color:#24231f,stroke-width:1.5px classDef risk fill:#efe0d4,stroke:#9b704f,color:#24231f,stroke-width:1.5px class SPEC core class BATCH,SELF,JUDGE model class REVIEW,GATE,FINAL,MEASURE verify class ROUTE,FIX,WAIT,HUMAN risk
來源與案例說明
- OpenAI — 清楚說明目標、資料與輸出要求的提示設計
- OpenAI — 以實際任務評估提示與模型的效果
- OpenAI — GPT-6 Astra / Sol / Luna 與 GPT-5.6 系列模型定位
- Anthropic — Claude Opus 5.5（2026-09-22）
- Google — Gemini 3.8 Flash（2026-09-02）
- DeepSeek — DeepSeek V4.1-Flash（2026-09-10）
- Alibaba Cloud — Qwen3.8-Max-0902（2026-09-02）
- Alibaba Cloud — Qwen3.8-Flash / GLM-5.3 等當前 Model Studio 模型資訊
- Kimi Code — K3 / K2.8 Preview model overview
- Kimi Code — K2.8 Preview（2026-09-11）
- Z.AI — GLM-5.3 model overview
模型定位：依各家官方或官方雲端文件（查閱：2026-09-23）。四象限中的模型是「典型用途」範例，不是能力排名；同一模型可能因 reasoning effort、工具、成本與 task shape 出現在不同區域。
方法靈感：來自使用者提供的一則社群實務分享。原作者描述在大型批次工作中嘗試不同模型，最後採用全 Luna 的 Master–Worker–Reviewer 流程；這屬個案經驗，不是受控 benchmark。
本文主案例：500 筆供應商商品資料為教學用重製情境，綜合常見資料清理、CMS 上架與批次內容遷移工作，不對應單一真實公司。