逐條比對規格書時，偶爾會碰到這種條文：招標文件要求某項功能，型錄上確實找得到那項功能的逐字說明，但同一段文字旁邊，或者另一頁的但書，寫著這項功能要另外加購授權才能使用。這種條文送進本站的判定席，會拿到什麼結果？
判✅，因為型錄上真的寫了那個功能
本站比對時的判定規則 1，只認文件逐字或數字當證據，常識不補。一項功能要判✅或❌，前提是型錄上得有對應的字樣或數字，型錄沒寫，兩個方向都下不了判，只能判❓。
加購授權這類條文，型錄上通常寫得很清楚：功能名稱、規格數字都在，只是附帶一句「需另購授權」或類似的字樣。這種情況下，判定所需要的逐字證據其實已經齊了——招標文件要的功能，型錄確實對得上。依規則 1，這種條文照樣可以判✅，不會因為旁邊那句加購授權的但書，就把整條拉去❓或❌。
本站的判定規則：判✅之外，多寫一行提醒
型錄裡出現「這項功能要另外加購授權」這種字樣，是十條判定規則裡專門處理的一種情形。本站比對時的判定規則 6 原文如下：
- 功能存在但需加購授權 → ✅，並在 red_flag 寫「報價須含 ○○ 授權」。
這條規則做兩件事：先判✅，因為功能真的存在；再多寫一行提醒，因為存在不等於不用另外花錢。十條規則裡，其他判定通過的情形（✅ 或 ⬆️）都不會額外輸出提醒，規則 6 是唯一一條「判定通過、同時主動發出提醒」的規則。這個特殊之處不是巧合，是規則 6 存在的理由本身：型錄上寫了某項功能，跟這項功能不用再花錢，是兩件不同的事，規則 6 把這個落差記下來，不讓判✅被讀成「這項不用再管」。
red_flag 是獨立欄位，不是判定結果的附注
判定席每一次呼叫，輸出的 JSON 有固定格式。本站的輸出 schema 原文如下：
{"verdict": "✅"|"⬆️"|"❌"|"❓", "note": "判定理由（≤80字，引用數字要與證據一致）", "red_flag": "需寫進報價或投標文件的提醒；沒有就空字串"}
verdict、note、red_flag 是三個各自獨立的欄位。verdict 是四態判定本身，note 是判定理由，red_flag 是另一件事——需要寫進報價或投標文件的提醒，沒有就是空字串。三者不是同一欄拆出來的文字，是判定席每次輸出時就分開產生的三塊內容。
再往下一層看，每份文件的完整輸出物件裡，逐條判定結果放在一個陣列，需要提醒的項目放在另一個獨立的陣列，兩者分開存放。程式的做法很單純：判定結果如果帶有 red_flag 這段文字，就把「條文編號＋這段文字」加進提醒的陣列裡；判定結果沒有 red_flag，這個陣列就不會多一筆。系統設計上把「判定結果」與「要另外注意的事」分成兩軌，是為了讓找證據的人跟算報價的人，各自看各自要看的那部分，不必從一長串逐條結果裡自己挑出哪些帶了提醒。
判✅不代表這項不用再花錢
這是規則 6 最容易被誤讀的地方，需要說清楚：判✅代表產品文件裡確實找得到逐字或數字證據，這項功能真的存在；但判✅不代表這項功能免費，也不代表報價不用再算這筆錢。規則 6 存在的理由，正是把「功能存在」跟「不用另外付費」這兩件事分開處理——如果判✅被讀成「這項不用再花錢」，那正好讀反了規則 6 想提醒的事。
也要說清楚 red_flag 這個欄位實際上做了什麼、沒做什麼。它是一段文字提醒，寫進判定結果附帶的陣列裡，讓看報告的人知道有這麼一件事要另外處理。它沒有任何金額運算或加總邏輯，不會去查這項授權大概要多少錢，也不會把這筆金額算進任何報價的總數。本站目前沒有試算授權費用的功能，red_flag 能做到的，就是在對的位置留一句提醒，剩下的——確認授權的實際條件、去跟原廠或代理商確認費用、把這筆算進報價——仍然要靠報價的人自己去處理。
規則 6 也不是採購規定要求本站這麼做。它是本站自己訂的一條判定紀律：既然判定的邏輯只認逐字證據、不看常識，那麼「這項功能存在，但存在的方式帶著一個額外條件」這種情形，就值得在判定結果之外多留一筆記錄，不讓✅這個符號單獨承擔它裝不下的訊息。
這條規則只講事實存在與否，不做投標建議
規則 6 判✅、寫 red_flag，講的都是型錄上寫了什麼、有沒有加購授權的字樣，是事實層面的判斷。本站另有一條措辭上的紀律，畫出這條規則的邊界：判定不去談機關會不會因此挑這家廠商、廠商投這件案子划不划算這類問題，那些不是逐條判定回答得了的事，也不是本站要回答的事。規則 6 能做到的，僅止於把「這項功能存在，但需要另外加購授權」這件事記下來，交給看報告的人自己判斷要不要投、怎麼報價。
型錄沒寫到「需加購授權」這幾個字，會被標記嗎
規則 6 觸發的前提，跟規則 1 是同一套邏輯：只認逐字證據。型錄上如果沒有出現「需另購授權」或類似字樣，判定不會去揣測有沒有加購授權這件事，也不會因為某類功能常見要加購授權，就主動幫它補一筆提醒。沒有那句話，這項功能的判定就照一般規則走，不會因此多一個 red_flag。反過來說，一旦型錄上真的寫了那句話，判✅之餘多寫這一行提醒，就是規則 6 要做的事。
要先知道整份招標文件裡哪些條文提到授權，可以用本站的規格預檢，它會先把出現「原廠授權」「授權書」這類字樣的條文挑出來，讓對型錄之前先心裡有數。需要逐條判定、看到哪些條文真的被標了 red_flag，則要用本站的規格比對，逐條判定的輸出裡，需要加購授權的項目會列在 red_flag 欄位裡。
常見問題
判定結果是✅，是不是代表這項功能不用再花錢？
不是。規則 6 存在的理由，正是把「功能存在」跟「不用另外付費」分開處理：判✅代表型錄上確實有逐字或數字證據證明這項功能存在，不代表不用再花錢。如果型錄上寫了需要另外加購授權，判定結果會是✅加上一筆 red_flag 提醒，兩者一起看，才是完整的訊息。
red_flag 會出現在報告的哪裡，跟判定結果是同一欄嗎？
不是同一欄。verdict、note、red_flag 是判定輸出裡三個各自獨立的欄位，紅旗提醒不會混進判定理由裡，也不會取代判定結果。每份文件的完整輸出物件裡，逐條判定與需要提醒的項目，各自放在分開的陣列，方便分開查看。
如果型錄沒有明講「需加購授權」，本站怎麼知道要標 red_flag？
依規則 1，判定只認逐字或數字證據，型錄沒有出現「需另購授權」這類字樣，判定不會臆測有沒有加購授權這件事。沒有那句話，這項功能的判定照一般規則進行，不會多出一筆 red_flag 提醒；判定不會因為某類功能常見要加購授權，就主動幫它補上這個推測。
本文為法規與投標作業的一般性說明，不構成法律意見；個案以招標文件、機關釋疑與主管機關解釋為準。