先講一個我遇過很多次的場景。

某家公司今年營業利益掉了一半。你手上的資料庫告訴你：掉了 50%。然後呢？

為什麼掉？ 是產能問題、價格問題、原物料成本，還是一次性的資產減損？

這個答案不在任何數字欄位裡。它寫在財報 PDF 的第 30 頁到第 150 頁——「管理階層討論與分析」裡講產能和價格、「風險事項」裡講匯率和原物料、附註裡講那筆減損是怎麼來的。

你拿這個問題去問 LLM，它手上只有一個「-50%」，就只能編一個聽起來合理的解釋給你。

這就是我這 30 天想講的問題：財報的「數字」早就有一堆人在做，但「本文」沒有。

數字這條路已經很成熟了

先說清楚，我不是要說數字不重要。

如果你只要三大表的數字，選擇多到不用自己動手：中國有 Tushare、AKShare、東方財富；台灣有 FinMind、CMoney；韓國有 OpenDART 官方 API；美國更不用說。這塊已經被做滿了，不需要再造輪子。

而且各國主管機關這幾年還在加碼——韓國金融監督院擴充了 DART 的英文揭露系統並提供免費即時 API；日本有 J-Quants；美國 SEC 有 XBRL 全文檢索。

所以問題從來不是「拿不到數字」。

但本文這條路，四個市場都還在原地

真實情況是這樣：

看出來了嗎——四個來源，本文全部只給 PDF。

日本看起來最好，有 API、有 XBRL。但 XBRL 裡只有數字。「経営方針」「リスク情報」這些章節，一樣得回 PDF 裡撈。

韓國 DART 的 Open API 能拿到文件清單和原文檔案，但原文格式不統一，有的年份是 PDF、有的是 HTML，欄位口徑還會變。

台灣 MOPS 和中國巨潮更直接：沒有公開 API，就是 PDF。

一句話總結：四個市場，數字各有各的路，本文都是 PDF 苦力活。

為什麼「把 PDF 轉成文字」這麼難？

你可能會想：PDF 轉文字不是有現成工具嗎？

我一開始也這麼以為。做完之後才知道，財報 PDF 是所有 PDF 裡最難啃的一類，主要有四個坑：

坑一：三大表是「畫」出來的，不是文字表格。

資產負債表、損益表、現金流量表看起來是表格，但在 PDF 裡很多是用向量線條畫的——文字是散落的獨立片段按座標排列，沒有任何表格結構資訊。你用一般文字抽取，拿到的是一坨按座標亂序拼接的文字。

坑二：Identity-H 字型沒有 ToUnicode，整篇變亂碼。

有些東亞 PDF 嵌入了字型卻沒帶對照表，PDF 裡存的是字形編號而不是字元。PyMuPDF 這類函式庫只能原樣吐回編號，抽出來的內文整篇亂碼。我們實測某一類文件亂碼率高達 42%。

坑三：掃描件。

老一點的文件是真·掃描件，完全沒有文字層，只能走 OCR。

坑四：單位會騙人。

元、千元、百萬元在同一份文件裡都可能出現。不統一換算的話，你的資料會錯得很隱蔽——數字看起來正常，量級錯得離譜。

接下來 30 天要講什麼

我會用 30 天，把這套系統從架構到上線拆開來講。大致分四塊：

• 第一週（Day 1–7）：一個人做這件事的架構與成本取捨。為什麼採集要留在牆內、分發放上 Cloudflare；為什麼選 SQLite 而不是 PostgreSQL；定價是怎麼算出來的。
• 第二週（Day 8–15）：PDF 解析工程。上面四個坑逐一拆解，包含表格重建怎麼從 47% 命中率做到 96%、GID 對照表怎麼建、OCR 怎麼補最後那 4%。
• 第三週（Day 16–22）：四個市場的採集實戰。每個官方源都有自己的脾氣——巨潮的參數陷阱、DART 的每日兩萬次額度、MOPS 擋流量時回 200 卻塞給你 HTML 的那種陰招。
• 第四週（Day 23–30）：合規、分發與成長。包含我怎麼用讀程式規格的方法去讀交易所的條款、一次引錯法條的教訓，以及讓 LLM 找得到你的實際做法。

先交代立場

最後講清楚我的身分，免得你讀到一半覺得被騙。

我一個人做這套系統，它就是我的產品。 所以這 30 天裡會提到它——但我盡量把它當「案例」而不是「廣告」：講架構的時候它是我做的架構，講踩雷的時候它是我踩的雷。

這組是「佛心分享」，不評審、不競賽，我也不打算靠這 30 篇賣東西。如果你只是想自己把財報 PDF 轉成 Markdown，這個系列裡的每個技術細節你都可以直接拿去用——官方來源都是公開的，自己動手完全可行，門檻是體力活和踩雷，不是資訊落差。

反過來說，如果你正在做 RAG、做量化、或者做 LLM 應用，曾經被財報 PDF 卡住過，那這 30 天應該對你有用。

明天（Day 2）來講架構：為什麼我把採集留在牆內、分發放上 Cloudflare，以及這個決定當初是怎麼逼出來的。