https://yennj12.js.org/yennj12_blog_V4/tags/mkdocs/Recent content in MkDocs on YennJ12 Engineering BlogHugo -- gohugo.ioen-usTue, 30 Jun 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/finance-data-ai-pipeline-how-it-works-zh/Tue, 30 Jun 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/finance-data-ai-pipeline-how-it-works-zh/多數人做股票分析:打開券商 App,看 K 線、查財報、Google 新聞,然後自己下判斷。 finance_data 的做法:讓 42 個機器人每天定時自己抓數據、自己讀財報、自己寫成繁中研究報告、自己發佈上線——全程沒有人手介入。 這篇就拆解這條「零人工」pipeline 的每一個齒輪是怎麼咬合的。 一、它到底是什麼 finance_data 是一個全自動的 AI 投資研究平台。它覆蓋 30+ 家公司(AAPL、MSFT、NVDA、TSLA、PLTR、台股 0050、2330.tw……),每天自動產生: 個股基本面分析(fundamental analysis) 個股技術面分析(technical analysis) 每日市場新聞摘要(market news) 配合 SEC 申報文件(10-K / 10-Q / 13-F / 6-K)、investor day 簡報、研究 notebook 關鍵字是「全自動」:從定時觸發、抓數據、餵 LLM、生成報告、到建置部署上線,整條鏈沒有任何一步需要人手操作。 整體 pipeline 長這樣: ┌──────────────┐ 每天定時觸發 │ GitHub Actions│ ◀────── cron schedule │ Cron │ └──────┬───────┘ │ 1. 排程把「某支股票 + 某種分析」丟給腳本 ▼ ┌──────────────────────┐ │ 資料蒐集層 │ yfinance + Finviz + StockAnalysis + Roic.https://yennj12.js.org/yennj12_blog_V4/posts/mkdocs-site-size-deploy-perf-tuning-zh/Tue, 30 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/mkdocs-site-size-deploy-perf-tuning-zh/多數人優化靜態站台的做法：壓縮一下圖片、開個快取就收工。 但當站台是由 42 個機器人每天自動寫進去的 5,000 頁報告時，問題不在「檔案大」， 而在「整個 pipeline 的每個環節都在重複放大成本」——搜尋索引、導覽樹、git 歷史、部署觸發頻率。 真正的調校，是找出那些被無限複製的單位成本。 一、問題：一個會自己長大的站台 finance_data 是一個自動化金融分析站台。它的內容不是人手寫的，而是由大約 42 個每日排程任務自動產生：10-K / 10-Q / 13-F 財報摘要、investor day 筆記、AI 生成的個股報告、notebook PDF……每天都有新的 dated report 被寫進 repo，再透過 MkDocs（Material 主題）建置成靜態站台，部署到 GitHub Pages。 這種「機器人持續寫入」的特性，讓站台的成本不是線性增加，而是在好幾個環節同時被放大。等到我們去看的時候，數字已經很難看： 症狀 數字 ────────────────────────────────────────────── 搜尋索引 (search_index.json) 195 MB 首頁 HTML 1.07 MB 單一深層報告頁 HTML 590 KB 單次部署 payload 752 MB 建置完成的站台總大小 ~3.1 GB CI 建置 + 部署時間 ~15 分鐘 每天觸發部署次數 ~42 次（每個分析任務 push 一次） 最致命的不是任何單一數字，而是它們互相加乘：5,000 頁 × 每頁 1MB 的導覽樹 = 站台爆炸；42 次/天 × 752MB 的部署 = CI 排隊塞車。我們要做的，是逐一拆掉這些放大器。