去年寫完《Android 不會只更新 UI！用 Vibe Coding 加速打造 AI-native App》的最後一篇，我就在想一件事
那系列在講「怎麼讓 AI 幫你把東西做出來」
今年我想講的是下一個問題：做出來之後，你怎麼知道它是對的？

閱讀資格

先講門檻，免得你看到第三天才發現不對勁 🙂

你最好已經有的：

• 知道什麼是 LLM、什麼是 API 呼叫，會看 JSON
• Python 基礎（會裝套件、看得懂 requests 在幹嘛）
• 對 Docker 不會過敏

你不需要有的：

• 不需要有 DGX Spark（沒有這台我照樣會把數字跟推算過程寫給你，你換算到自己的顯卡上就好）
• 不需要懂量化數學（我也不懂到能推公式的程度，我只懂到「哪個會壞、哪個不會壞」）
• 不需要會寫 Agent framework（這系列不用 LangChain、不用 CrewAI，我們手刻）

完全零基礎的話，建議先補一下這兩塊再回來：LLM 的基本推論流程、還有 OpenAI 相容 API 長什麼樣子。不然一開始會有點痛苦。

介紹

我手上有一台 NVIDIA DGX Spark（GB10 Grace Blackwell），128GB 統一記憶體
聽起來很爽對吧
我原本也這樣以為 😅
實際上這 30 天有一大半的篇幅，都在講這台機器不能做什麼、以及那些「不能」怎麼反過來把我的架構長成現在這個樣子

這系列要做的東西講白了就一件事：
把一份台灣上市櫃公司的年報 PDF 丟進去，吐出一份你敢直接拿去用的結構化資料。全程不出機房。
聽起來很簡單

為什麼要從 LLM baseline 開始講？

我知道你想看 Harness
標題都寫了「從 LLM 到 Harness」，你八成想直接跳到那個有 Commander、有 Subagent、有 Verifier 的漂亮架構圖
但我如果 Day 2 就給你架構圖，那張圖對你來說就只是一張圖
你會覺得「喔，蠻合理的」，然後關掉分頁，但我就想騙點閱。

所以我要先讓你看它壞掉。

我會把整頁文件直接丟給一顆 26B 的模型，什麼架構都不做，然後我們一起看它怎麼錯
我會告訴你，就算你想用更大的模型救它，你的記憶體頻寬也不會答應
我會把「模型的失敗模式」跟「硬體的物理限制」放在同一張表上交叉比對
等這三件事你都看過了，之後的架構圖才會變成你自己也會這樣設計的結論，而不是我單方面的宣稱

主題解析？

來拆標題。這標題有四個詞是我刻意挑的，一個一個講

「從 LLM 到 Harness」

這是整個系列的主軸，也是我今年最想講的觀念
先講 Harness 是什麼。我看過最精準的一句定義是這樣的：

讓 agent 根據目標，持續、正確地動作的工程。

重點在後半句。核心材料是「回饋訊號」——你得有東西能判斷對不對、完了沒，否則一切都是 open loop（無回饋迴路）
還有一句話我很喜歡，直接引用：

Agents need feedback loops, not perfect prompts.

大概的意思就是：再怎麼改 prompt，沒有迴路就收斂不了
這句話在我身上應驗過很多次。我花過整個晚上在調一句 prompt，想讓模型不要把「應收帳款」跟「應付帳款」看錯，結果呢
改完這頁對了，下一頁換個地方錯
因為那不是 prompt 的問題，那是沒有人在檢查它的問題
三層的差別我畫成這樣你比較好記：

三層是疊加不是取代。你 prompt 寫得爛，有 Harness 也救不了
但你 prompt 寫得再好，沒有 Harness，它就只是每次都用不同的方式失敗

「隱私」

這兩個字在這系列不是口號，是限制條件
我處理的文件情境是財務資料。這類東西的前提就是不能上雲，所以整條鏈路必須在本地跑完——這也是為什麼我會有那台 DGX Spark
但隱私不只是「不連外網」這麼單純
Day 12 我會講一個更麻煩的問題：你用的模型是誰做的？
你把資料留在本地，但你跑的是別人訓練的權重、別人寫的推論框架、別人打包的 Docker image。這條供應鏈上每一個環節你都審過了嗎
我審了。而且因為審了，我砍掉了一個在 CJK OCR 上表現最好的開源模型
那一刀砍下去，效能是有代價的。這個代價我 Day 12、Day 13 會攤開給你看數字

「可信任」

這是我覺得最難、也最少人講的部分

OCR 辨識正確，不等於結果可以信任。
舉個例子。模型把一頁財報讀出來了，每個字都對，格式也漂亮
然後它把附註裡的「同前項」對應到錯誤的主表科目
所有字都是對的。整份資料是錯的
整個 Phase 我都在處理這件事——語意層的正確性。
為什麼要四層？
因為可信任是疊出來的，不是宣稱出來的。任何單一機制我都能舉出它漏掉的案例

「繁中進階」

「進階」這兩個字我知道看起來很像行銷詞

Day 6 到 Day 8 整整三天我都在證明它不是

繁體中文在 OCR 這件事上有一整組英文世界不會遇到的問題：字型變體、罕用字、直橫式混排、跨欄表格、繁簡混排、異體字對齊

而財報文件很壞心的地方在於，它把上面這些同時用上

反正我是打上一個大大的問號：那些在英文文件上跑到 99% 準確率的方案，換成一頁中文財報表格，還剩下多少

Day 6 我會給你答案

還有一條軸線：讀懂年報，不只讀出年報

這是我今年加的東西，也是我覺得這系列跟一般「OCR 教學」最不一樣的地方

我的目標文件是台灣公開資訊觀測站（MOPS）的年報與重大契約摘要

選它的原因很實際：公開、免爬蟲、法定格式、而且它同時有 PDF 跟 XBRL 結構化資料

最後那點是關鍵

一般做 OCR 評測最痛的就是沒有 ground truth，你得自己標。但 MOPS 的 XBRL 是同一份財報的官方結構化版本

我可以直接拿它來校驗我的輸出。

省掉一整層自建詞彙表跟人工標註的工。這個設計 Day 17 會完整講

30 天地圖

一些我得先承認的事

去年我在開場文寫「原本想加 MCP、RAG，但顯然 30 天不夠我寫 :(」

今年一樣有這種東西 😅

• 這不是一個完整的商用產品。它是一套可運行、有實測數據、有失敗紀錄的系統，但它沒有前端、沒有使用者管理、沒有 SLA
• 我的數字是我這台機器上的數字。GB10 128GB 統一記憶體、273 GB/s 頻寬，你的環境不一樣，數字一定不一樣。所以我會盡量把推算過程寫出來，讓你能換算到自己的機器上
• 有些坑我到現在還沒填完。例如 XBRL 對比，我只做到部分科目。做不到的地方我會直說「這裡我還沒解」，不會用漂亮的句子蓋過去

最後這點我想多講一句
這系列會有很多「失敗」的段落。模型吐亂碼、輸出停不下來、記憶體分配失敗、量化把某個模態整組打壞
我沒有要把它們藏起來
30 天，我們把它們一個一個撿起來
明天開始，先讓一顆 26B 的模型在我面前出糗

以上文章經過大量 claude code 協助撰寫與整理我的專案記憶與經驗，不適者盡快遠離!!!