鐵人檔案
財報的「數字」各家 API 都拿得到，但「本文」——管理階層討論、附註、風險事項——只存在官方 PDF 裡，而那正是 LLM 分析真正需要的材料。本系列橫跨中國巨潮、日本 EDINET、韓國 DART、台灣 MOPS 四個官方揭露來源，用 30 天拆解把財報 PDF 轉成乾淨 Markdown 的工程：向量線條繪製的表格如何重建行列、Identity-H 字型缺少ToUnicode 造成的整篇亂碼如何救回、掃描件如何補 OCR、單位混用如何統一，以及章節切分、RAG 檢索與 MCP 工具化。過程中也分享四個市場各自的採集限制與踩雷紀錄，以及獨自把系統做成產品的真實取捨
先講一個我遇過很多次的場景。 某家公司今年營業利益掉了一半。你手上的資料庫告訴你：掉了 50%。然後呢？ 為什麼掉？ 是產能問題、價格問題、原物料成本，還是一次...
第一個版本的架構只有一台機器：一支 FastAPI、一個 SQLite 檔、一個放 markdown 的目錄。能跑，功能也對，壓力測試打下去幾百 QPS 就開始...
一個人做產品，最怕的不是技術難，是「還沒收到一毛錢，帳單先來」。所以架構拍板那天，我先做了一張表：免費額度到底能撐到哪裡，以及撞到牆的時候會發生什麼事。 不把這...
「用什麼資料庫」這個問題，預設答案通常是 PostgreSQL。但預設答案沒有回答我真正的問題：我的瓶頸在哪裡？ 選工具之前先量瓶頸，順序反過來的話，你只是在抄...
documents 表只有 13 個欄位，但其中幾個是踩過雷才長出來的，還有一個是為了補洞而存在。 第一條原則：正文不進資料庫 CREATE TABLE IF...
定價最容易犯的錯是「憑感覺」。我把它變回一道算術題：先把成本結構攤開，再看每個數字該落在哪裡。 今天把推導過程完整寫出來，包含算完之後我必須接受的風險。 先看數...
第一週講完了架構、成本、資料庫、資料模型、定價——全部都是「決定」。決定這種東西，當下看不出對錯，要跑一段時間才知道。 今天不講新東西，來盤點。而且盤點要有誠意...
前七天講的是架構、成本、資料庫、資料模型、定價。從今天起要講的是它最花時間的部分：把一份財報 PDF 變成 LLM 讀得懂、而且數字不會騙人的 Markdown...
先做一個實驗：拿一份 A 股年報，翻到資產負債表那一頁，用任何一個 PDF 轉文字的工具跑一遍。 你看到的不是表格。你看到的是一長串按座標排好、但沒有分行也沒有...
