把 AI 寫進系統前，先摸清它的四道限制：context window、prompt、法規、模型聰明度

D4 的結論是：這行的規模牆，逼你把事情交給 AI。但「交給 AI」最容易被誤會成「接個 API、把問題丟進去就有答案」。真正動手把 AI 寫進一套要上線的系統，你會先撞到四道它自己的限制——每一道都不是 bug，是你逃不掉的設計決策。

這篇先清點一下要考慮的點，我們接下來一個一個指出我會怎麼取捨。

上下文視窗（一次讀多少）、提示設計（怎麼指揮它）、法規合規（哪些資料與模型不准用）、原廠的模型與思考深度設定（聰明度、成本、速度的旋鈕）。把這四道設計進去，AI 才從「丟進去碰運氣」變成「可控、可預期、可負責」的一個元件。

這篇先不寫程式（ D6 以後會開始），先把這四個決策點講清楚。你未必用我一樣的技術路線，但只要把 LLM 寫進系統，這四道限制人人都會遇到。

限制一：為什麼不能把資料一股腦全丟給 AI？（context window）

AI 一次能「讀進去」的量有硬上限，這個上限叫 context window（上下文視窗）。 你每次餵給模型的所有東西——問題、背景資料、對話歷史——都得擠進這個視窗，超過就得取捨。

問題是，你手上的資料常常遠比一個視窗大。每日 CVE 通報要比對的，是「全球當天新增的漏洞清單」乘上「你在管的設備版本表」；這兩張表合起來，遠超過任何模型一次吞得下的量。你不能把它們全塞進去叫 AI「自己找」——塞越多不只越貴、越慢，它還越容易在雜訊裡抓錯重點。

所以正確的設計不是「塞更多」，是先用程式篩出「今天可能相關的那一小撮」，再交給 AI 判斷。這個「先檢索、再生成」的做法叫 RAG（Retrieval-Augmented Generation）——後面 CVE 通報（D22–24）用比對、向原廠下單（D25–27）用向量檢索，都是同一套「先篩掉雜訊、再交給 AI」的思路。

context window 逼你回答一個設計問題：這一次，到底哪些資訊「非帶不可」、哪些是雜訊？

限制二：為什麼 prompt 不是「許願」，是設計？（prompt）

AI 的行為幾乎全被 prompt（提示）決定，但 prompt 寫得鬆或緊，輸出穩定度天差地遠。 prompt 就是你給 AI 的指令與脈絡；同一個模型，模糊的 prompt 會讓它自由發揮，緊的 prompt 會把它框在你要的軌道上。

自由發揮最危險的產物，是幻覺（hallucination：把不存在的型號、查不到的規格，講得條理分明、煞有其事）。你沒辦法命令它「不要亂編」——它講錯的時候，語氣跟講對時一模一樣篤定。你能做的，是用 prompt 把它的發揮空間關小。

以向原廠下單為例：要 AI 幫你查 SKU、組報價，prompt 就得明講「只能用我給你的這份資料、只回結構化的 JSON、查不到就回查不到」，而不是讓它憑印象生一個型號出來。結構化輸出、給範例（few-shot）、限定範圍、要求標來源——這些都是把 prompt 從「許願」變「設計」的手段（D6 直接演一次、D15 再標準化）。

你不能叫 AI「別幻覺」，只能用 prompt 把它關進一個比較不會出錯的籠子。

限制三：這件事「准不准做」，比「做不做得到」更早要問（法規／合規）

有些限制不是技術問題，是合規問題——而它是所有技術決策的前置門檻。 這道牆有兩個層面：

• 哪些「資料」不能餵：個資、客戶名單、內部報價與折扣、設備拓樸……把這些直接送進公有雲上的模型，可能踩到個資法規、合約保密、或資料落地（在地端保存）的要求。
• 哪些「模型／部署」不能用：資料能不能出境、要不要地端或私有部署、有沒有可追的稽核軌跡。

這道牆會直接改寫你的選型：你挑的不是「最聰明的模型」，是「合規前提下可用的模型」。舉個去識別化的情況——當某類客戶環境資料不允許上公有雲，你就得改用可私有部署的方案，或先把資料去識別化再送；這一關沒過，後面功能再強也不能上線。

合規不是綁手綁腳，是決定「這套系統到底能不能真的上線」的第一道門。

限制四：原廠給的不是一個 AI，是一整排旋鈕（模型與思考深度設定）

模型原廠（供應商）給你的從來不是單一個「AI」，是一整排要你自己轉的旋鈕，每一格都是成本 × 正確率 × 速度的取捨：

• 模型檔位：聰明但貴的大模型，還是便宜快的小模型。
• 思考深度（reasoning effort）：讓它「多想幾步再答」還是「直接答」——想越深通常越準，但越慢、越貴。
• 其他：溫度（temperature，越高輸出越發散）、回答長度上限等。

預設值不會剛好適合你的任務。全部都開最貴最聰明的檔位，帳單會爆；全用最便宜的，關鍵判斷會出包。務實的做法是按任務難度分配檔位：每天幾百封 CVE 摘要，用便宜快的模型批量跑；真正要判斷「這個漏洞打不打得中我」的那幾步，才切到聰明檔位。同一套系統、不同任務、不同檔位——這正是 D17／D18「分裂操作」要做的事，也是 D28 那筆成本帳的來源。

用 AI 的成本，不取決於「你用不用聰明模型」，而取決於「你有沒有只在對的地方才用它」。

這四道限制，其實是同一張設計清單

把四道擺在一起你會發現，它們不是四個「AI 好難用」的抱怨，是同一張設計清單——它們合起來，正好圈出了 AI 在你系統裡真實的能耐邊界。context window 決定它一次看得到多少、prompt 決定它聽不聽得懂你、法規決定它能不能碰這些資料、模型設定決定它想多深。四個旋鈕轉對了，AI 就從「丟進去碰運氣」變成一個可控、可預期、可被追責的元件。

至於這四個旋鈕各自要轉到哪一格、把因此省下的力氣放到哪去——沒有一組通用的標準答案，那是你對自己場景的判斷。這系列能給你的是旋鈕的位置，不是替你轉好。

明天先看它怎麼「自信地錯」

這四道限制裡，最會咬人的是第二道：AI 會自信地錯。光用講的你可能沒感覺——明天 D6，我直接拿一個真實的 WEBEX 設定問題餵給 AI，讓你親眼看它怎麼一本正經地編，再看我怎麼用 prompt 逼它自己把幻覺抓出來。

先認清限制、再把它設計進去——這是後面每一套系統都遵守的第一條規矩。