ELI5 · PPA 每晚分析

小哥的截圖
變成今晚的觀察名單

PPA 截圖 × 籌碼湖 × 規則卡 → 推播、記帳、追蹤

寫給 PM 與未來的維護者：先講比喻，再講精確機制。本頁所有股票範例都是虛構的（例如「9001 測試甲」），不含任何 PPA 真實清單、選股或付費內文。

1一句話

小哥每晚在付費專欄貼一疊軟體截圖；這套程式每晚自動把截圖讀成表格、拿籌碼湖核對、用小哥自己的規則卡打分，把「符合規則卡的股票」推到 Telegram，再全部記帳，之後持續追蹤。

小哥每晚丟一疊「今日菜單」照片到信箱。
抄寫員（Gemini）把照片抄成表格，查帳員（籌碼湖）逐行核對有沒有抄錯，裁判（打分程式）拿小哥寫過的規則卡一條條比，分數夠高的才寫進今晚推薦單（Telegram）。所有菜不管有沒有入選都抄進帳本（資料庫），之後每天回頭看它們後來好不好吃。

2為什麼要做

以前	現在
每晚手動四步（抓文章→辨識→校驗→挑股），約 5 分鐘、要開電腦	每晚排程自動跑，手機收推播
地板股 22:15 跑，但籌碼湖 22:40 後才有當日資料，一直推前一天的清單	總控等湖就緒才跑，地板股改成當天
挑股只印在終端機，沒有紀錄	所有候選（含沒入選的）全部入庫，可以事後驗證分數有沒有用
「沒收到推播」分不出是 0 檔還是壞掉	每條終止路徑都推一句話

候選股從哪來

只來自當晚圖上列出、且通過校驗的股票。籌碼湖只用來打分排序，不會從全市場另外加股票。

分數能信嗎

權重還沒經過記帳驗證（要累積約 3 個月）。在那之前請把推播當「觀察順序」，不是買賣建議。

3大地圖：系統架構

總控 scripts/xiaoge/run_nightly.py 把所有步驟串起來。紅框是來源與輸出，金框用到 AI，綠框是籌碼湖。

圖一　系統架構：PPA 主線（中間）與地板股線（下方）共用籌碼湖與 Telegram

4每晚時間表

總控像一個守門人，22:40 起每 5 分鐘探頭看一次：「湖的貨到了嗎？小哥的文章貼完了嗎？」到了就做事，等不到就在截止時間推一句「今晚沒等到」，絕不默默消失。

我們的程式籌碼湖截止時間

圖二　資料處理流程：湖的時間是 10-21 實測

「湖就緒」怎麼判斷

chip_lake.ready_for：價量、法人、融資三張表，當日普通股檔數 ≥ 前一交易日的 95%。不看「最大日期」——湖是分批寫的，日期出現不代表寫完；也不數全表列數——權證、ETF 每天浮動 5～12%，會誤判。股票分點另有 chip_lake.branch_ready，分點到齊才做漲停價買進掃描。

防呆

同時只會有一個總控在跑（鎖檔 ppa_watch/nightly/.lock，2 小時過期）。
每一步的結果寫在 nightly/state_<日期>.json；中斷重跑會接續，送到一半只補送沒送的。
排好的訊息先存成 nightly/<日期>/msg_*.txt，補推只送存檔原文，不重算。
子行程都有逾時（抓文章 300 秒、辨識 900 秒、掃描 300 秒），逾時砍整棵行程樹。
交易日：靜態休市表 data/twse_holidays_2026.json（10-23 起的休市日待補）→ 湖的交易日曆 → 都不能確認就退回「週一～五」並在推播加註。

python scripts/xiaoge/run_nightly.py --as-of 2026-10-22 --force   # 手動補跑
                                     --no-notify                   # 影子模式：只算不推、不上傳
                                     --once                        # 只跑一輪

5第一步：從 PPA 抓文章

fetch_ppa_articles.py　比喻：拿會員卡（cookie）去報攤，只拿今晚新到的那份報紙。

會員身分	Netscape 格式的 cookie 檔，路徑寫在 `.env` 的 `PPA_COOKIES_FILE`。程式與 Claude 都不讀它的內容，只拿來發請求。
清單 API	向 PressPlay 網頁 API 逐頁要文章清單，再抓單篇的標題、發布時間、內文、圖片清單（每張圖標了屬於哪個段落）。
只抓新文	每晚用 `--since <當天>`；已抓過且內容完整（圖片非 0 byte）的直接跳過。
--no-media	晚上只抓文字和圖片，影片音訊留給隔天 08:00 的排程。
沒發完不算	文章一旦出現清單段落，就必須有「關鍵分點買超股、關鍵分點賣超股、主力權證認購表」三段才算完整，否則繼續等到 23:30。
cookie 失效	PressPlay 照樣回 200 但 `is_login=false`；程式丟 `NotLoggedIn` 整批停下，總控推「換 cookie」。
連續失敗	連續 3 篇失敗整批停（多半是環境壞了，不要空轉）。

產出在 data/xiaoge/ppa訂閱線/articles/<日期>_<key8>/：article.json 進版控；content.html、images/、media/ 不進版控。

6第二步：看圖（Gemini 辨識）

ppa_list_ocr.py　比喻：抄寫員把每張截圖逐格抄成表格，規定是「看不清楚就留白，不准猜」。

只辨識清單類段落（開頭大盤、近期申購股不送）：

段落	抄出來的欄位（JSON）
主力權證認購表（1 日）波段權證（30 日）	`buy`／`sell`：排名、代號、名稱、買賣超金額（萬）、漲跌天數、1／5 日漲幅、自營比。`detail`：外資／投信／自營、權證買超與賣超最多的券商、`trace`（所選券商、進出場柱狀圖最後 20 根、型態、信心）、庫存張數、推估損益。
四張篩選表：投信買超＋籌碼偏多、投信賣超＋籌碼偏空、籌碼好沿上軌、籌碼差沿下軌	`columns` 表頭照抄；`rows`：代號、名稱、成交、漲幅，`cells` 放每一格（主1／主5／主10、位階、帶寬、維持率…）。
關鍵分點買超股、關鍵分點賣超股	`rows`：代號、名稱、關鍵分點、買／賣方向、股價、漲跌；`cells` 放其他每一格。
小於地板股	`rows`：代號、名稱、收盤、地板價、天花板價（只有畫面正在顯示的那檔有價位）。

另記 image_dates（圖上日期，只記錄不擋）與 ocr_meta（呼叫次數與用量）。
一篇切成幾批平行送（每批最多 8 張圖），約 5 次呼叫、1～2 分鐘；存 ppa訂閱線/lists/<篇>.json（不進版控）。
回空清單不落地、某批缺段落整篇不存（下次自動重做）；額度用完 [ABORT] 整批停；辨識失敗總控最多再試 2 輪。
備援引擎 Claude（--engine claude），平常不用。

7第三步：校驗

ppa_lists.py　比喻：查帳員拿官方帳本（籌碼湖）逐行對——代號和名稱配得起來嗎？收盤和漲幅跟官方一樣嗎？

不採信辨識結果：代號↔名稱一致、收盤／漲幅與湖裡當日數字吻合，才標 verified 進打分；對不上的標 unverified 並寫原因。
容差：漲幅 0.06 個百分點、收盤相對 0.1% 或絕對 0.051 元（表上只顯示一位小數）。
整篇擋下：0 列、沒有一張圖的日期是交易日、失敗超過 10%。
推播降級：通過率 < 90% 時不打分，只列候選代號——辨識不可靠，分數就是噪音。
實測通過率約 99.8%，剩下多是冷僻字名稱讀錯，代號本身是對的。
交易日取自標題開頭的 YYYYMMDD（有些文章隔天早上才發）。

8AI 用在哪、不用在哪

地方	AI？	說明
看圖辨識	Gemini	模型正本 `llm_config.py` 的 `GEMINI_MODEL_ID`，現行 `gemini-3.8-flash`；溫度 0.1；每篇約 5 次呼叫，與其他管線共用每日 100 次上限；被 429 擋會退額度重試。
校驗	不用	純比對籌碼湖。
打分	不用	純規則：可回測、可記帳、同樣輸入永遠同樣結果。
推播、記帳、追蹤	不用	純程式。

另一條相關但獨立的線：文章規則萃取

extract_ppa_rules.py 把 PPA 影片逐字稿萃成規則卡（每篇約 14 次呼叫），新卡先放 ppa訂閱線/rule_cards_pending/（待審），PM 並排審閱 --apply 後才併入主手冊。打分用到待審區的卡時，推播標〔未審〕。

9第四步：打分

裁判手上有一疊小哥的規則卡。每檔股票對每張卡：符合就加分、犯規就扣分或直接出局。分數夠高的前幾名才進推薦單，寧缺勿濫。

九個家族（＝推播上的交易條件標題）

#	家族	方向
1	關鍵分點買超 → 波段做多	做多
2	關鍵分點賣超 → 波段做空	做空
3	籌碼好沿上軌 → 波段做多	做多
4	籌碼差沿下軌 → 波段做空	做空
5	投信買超＋籌碼偏多 → 波段做多	做多
6	投信賣超＋籌碼偏空 → 波段做空	做空
7	主力權證認購 → 隔日權證賣壓放空	隔日放空（附隔日劇本）
8	波段權證 → 波段做多	做多
9	波段權證 → 波段做空	做空

怎麼算分

每條命中叫一個 hit，帶著 rule_id（規則卡代號）、分數、理由、所屬群組。
分群計分：籌碼群（主力、投信、關鍵分點、融資）不設上限；價格趨勢群、位置群各最多 2 分。至少一項籌碼證據才能入選。
「條件同時成立」的卡只在全部成立才給分（例如月線下彎＋主力持續大賣）。
排除直接出局並寫原因：高檔（120 日區間 ≥80%）、20 日均量 <50 張、主力只是小賣、假突破、湖裡沒資料…
入選：總分 ≥ MIN_SCORE（3），同代號只留最高那列，取前 MAX_PICKS（5）名；不足就少推。
衝突移除：同一檔同晚同時入選做多與做空家族，兩邊都拿掉（隔日放空與波段做多時間尺度不同，不算衝突）。
資料分工：主1／主5／主10、主力連買用圖上數字；投信、外資、位置、月線、布林、融資、集保用籌碼湖；圖上投信% 只交叉核對，差太多印 ⚠。

三種標籤

〔A041〕	依據的規則卡在主手冊；卡號＝隨身讀題目編號，可用 `#r=A041` 直接打開對照。卡號來自 `reader手機隨身讀/card_codes.json`（只增不減；A 籌碼判讀、B 進出場、C 風控、D 權證工具、E 選股流程）。
〔未審〕	依據的卡還在 PPA 待審區；審過併入主手冊後自動消失。
〔SOP〕	依 SOP 欄位定義或輔助判斷給分，不是規則卡。

推播長什麼樣（虛構範例）

PPA 觀察 2026-10-xx（1/3）
▸ 關鍵分點買超→波段做多：2 檔
9001 測試甲 6 分｜主5 22%（大買）〔A0xx〕；低檔＋關鍵分點大買〔B0xx〕 +3 條
9002 測試乙 4 分｜投信佔量連兩天 >10%＋低檔〔A0xx〕；站上上彎月線〔B0xx〕〔未審〕 +1 條
▸ 籌碼好沿上軌→波段做多：0 檔
詳情：（隨身讀 ppa.html 的連結）

每檔一行：代號名稱分數｜最強 2 條理由〔卡號〕 +N 條；最強＝加分最多的規則卡命中（〔SOP〕與扣分不列）。
依做多／做空／隔日放空分則並編號「(i/n)」；每則末尾附 ppa.html 詳情連結。
0 入選的家族也有一行「0 檔」，「0 檔」和「沒跑」分得開。
PPA 訊息與地板股同一個目的地（2026-10-26 改）：TELEGRAM_ALERT_CHAT_ID 優先，沒設就退回 TELEGRAM_ALLOWED_CHAT_IDS 的第一個，第二個之後絕不送；兩個都沒設才不送。

10籌碼湖怎麼用

chip_lake.py　比喻：籌碼湖是隔壁鄰居（另一個專案）每天整理好的官方帳本倉庫，我們只有唯讀鑰匙。

用途	表（全部唯讀）
價量（原始價、漲跌停判斷）	`fact_price_raw`
還原價（月線、布林、位置、報酬）	`fact_price_adj`＋除權息補套（`load_price_adjusted`）
三大法人（投信、外資、自營避險）	`fact_institutional_daily`
融資融券	`fact_margin`
集保戶數變化	`fact_shareholding`
處置股	`fact_disposition`
股票分點逐檔（連買天數、漲停價買進掃描、就緒判斷）	`fact_branch_daily_fallback`
主力買賣超比（已算好的欄位）	`ml.duckdb` 的 `feat_chip_branch`（目前缺資料）
代號名稱、交易日曆	`dim_universe`、湖的交易日曆檔

幾個公式

月線斜率

＝月線(今) ÷ 月線(昨) − 1
全套教材 p7 與 PPA 教學圖的定義（欄位 ma20_slope1_pct）。布林上／下軌斜率同樣用 1 日比率。

主1／主5／主10／主20

＝（近 N 日前 15 名分點買超 − 前 15 名分點賣超）× 100 ÷ 近 N 日成交量
PPA 教學圖定義。

投信佔量

＝投信淨買超張數 ÷ 當日成交張數。

不偷看當天

120 日區間位置、20 日均量都不含當日；布林用母體標準差（與小哥軟體帶寬相差 ±0.5 內）。

已知資料缺口

股票分點 09-16～10-13 整段沒有資料；逐檔分點表 10-14 才開始每天有。連買涵蓋不到 5 個交易日就當「不知道」，不加分。
feat_chip_branch 的主力比自 08-26 起全空，要等湖專案決定回補路線。所以目前主力數字用圖上的；自算版本開發中（第 13 節）。
湖裡沒資料的股票不當 0 分，是排除並寫原因；法人或融資當日沒更新，打分整批 [ABORT]。

11記帳與週報

ppa_store.py、ppa_ledger_eval.py　比喻：帳本只准往後寫、不准塗改；每一筆都蓋上「當時用哪一版規則」的章。

表	內容
runs	一晚一次執行一列（重跑是新的 run_id，不覆蓋歷史）
rows	圖上每一列辨識結果（含校驗沒過的）
scored	每一列 × 每個家族的打分，全量——含排除、沒達門檻、被衝突拿掉的（只記入選會有存活者偏誤）
ledger	方向、進出劇本、發布／抓取時間、打分版本；評估欄位由週報回填

資料庫 ppa訂閱線/ppa_watch/ppa_watch.duckdb；Excel 每晚一檔 ppa_watch/excel/<日期>.xlsx。
版本＝打分程式內容雜湊＋門檻＋主手冊 rule_id 集合雜湊；程式沒動版本就不變。
評估規格 v1（預先登記、凍結）：波段家族 T+1 開盤進、第 5 個交易日收盤出（另記第 10 日）；隔日放空 T+1 開盤進、T+1 收盤出（湖沒有分 K，只能近似）。
漲停買不到、跌停空不到、處置股放空、持有期未滿都不算成交；用還原價、扣手續費與稅；只計抓取時間早於 T+1 09:00 的列。
週報只列累積的日等權超額報酬（相對同方向 0050）＋統計檢定；不推播，存 ppa_watch/reports/weekly_<日期>.txt。要改規則開 v2，v1 保留。

12隨身讀「PPA 選股追蹤」頁

比喻：推播是「今晚的便條紙」，ppa.html 是「整本相簿」——可以翻回前幾天、看某一檔後來怎樣。

每晚推播＋入庫之後，ppa_cloud_sync.py 把算數那次執行的入選標的（附卡號）上傳雲端 D1；同一晚重傳是整晚覆寫；0 檔不送（送空會清掉那晚）。
D1 三張表：ppa_picks（入選與全部理由）、ppa_track（入選後走勢：入選日收盤 → 最新收盤，做空取負）、ppa_marks（觀察中／已進場／放棄＋備註）。
要登入才看得到：輸入編輯權限驗證碼（與隨身讀編輯模式同一組），沒登入 API 回 401；頁面外殼本身不含任何資料。
功能：依日期／分數／走勢／連續入選排序，依多空／家族／標記篩選；點一檔看全部理由與規則卡；「個股」看各晚出現與走勢；標記跨裝置同步。
補傳：python scripts/xiaoge/ppa_cloud_sync.py --backfill-all；影子模式不上傳；上傳失敗只記警告。

13後續追蹤：三份追蹤清單開發中

PM 2026-10-25 核准的計畫，分支 feat/ppa-watchlists 正在實作，尚未上線。以下是計畫內容，細節以合併後的程式為準。

今晚上榜的股票不一定今晚就適合做。我們幫它們各開一個觀察本，留 60 個交易日，每晚翻一次，等「時機到了」的條件出現才響鈴一次。

圖三　後續追蹤流程（開發中）

五個階段

階段	內容
0	修正「連續」欄誤讀（第 14 節）；連買天數改用湖自算、遇資料缺口算中斷；記帳帶入辨識 prompt 版本。
1	自算主力比：從分點逐檔表算主1／5／10／20，窗口內缺任何一天就回「不知道」；校準閘門拿圖上數字比對命中率，不夠準就停發依賴它的提醒並推一句警告。
2	追蹤清單入庫：新表 `watch` 與只增不改的 `watch_events`；兩張關鍵分點表的全部列都入清單，申報轉讓取自文章；已在清單上只更新最後出現日。
3	每晚判斷，另起一則「PPA 追蹤提醒」推播，每筆只提醒一次。
4	Excel 加「追蹤清單」工作表；雲端多一張 `ppa_watch` 表，`ppa.html` 加「追蹤清單」視圖。

提醒條件與對照卡

清單	觸發條件	對照卡
關鍵買	從列入日收盤算起報酬 ≥5%，且布林打開（量化：上軌斜率 ≥1% 且 5 日前帶寬 <6%；或當晚文章把它列在「籌碼好沿上軌」，任一即可）→ 提醒加碼做多	A041、B001、B129、A211
關鍵賣	列入時主5 ≥0（主力還在買），之後主5 轉負，且從列入日算起跌幅仍 <5% →「關鍵賣＋主力跟著賣」波段空單	B093、B115、A008
申報轉讓	主5 達到「大賣」門檻，且月線斜率 <0 → 波段做空	B142、A022、A140

主5 優先用當晚清單圖上的值，沒有才用湖自算值。提醒與主推播用同一個收件規則，失敗只記警告、不影響主推播；影子模式只存檔不送。

14錯誤修正：「連續」欄不是連買天數

我們把菜單上的「老店 12 年」看成「連續 12 天都有人點」，然後告訴你「這道菜連續熱賣 12 天」。其實它只是老店。

錯在哪：關鍵分點表有一欄「連續」，程式原本當成「關鍵分點連續買超天數」，推播寫出「某分點連買 12 天」之類的理由。
真相：PPA 教學圖寫「連續年＝連續配發現金股利年數」，表上這欄也和殖利率、除息日排在一起。
證據：10-22 影子推播的「連買 12 天」，用籌碼湖分點資料實查：前一天淨賣、當天淨買，實際只連買 1 天；同晚另外兩檔也一樣。
連帶 bug：湖自算的連買天數原本只看「有資料的日子」，會跨過 09-16～10-13 的缺口把兩段接起來多算。
修正（進行中）：「連續」欄不再計分（只顯示為配息年數）；連買一律用湖自算、照交易日曆數、缺資料的日子算中斷；用影子模式重跑 10-22，舊的訊息存檔會被取代。記帳庫只增不改，新版本號自動和舊結果分開。

15隱私邊界

東西	放哪	能公開嗎
截圖（帶會員 uid 浮水印）、付費內文、逐字稿	本機 `ppa訂閱線/articles/…`	否：不進版控、不上雲、不進備份
辨識清單、關鍵分點清單、隔日沖分點	本機 `lists*/`、`key_branches/`、`day_trader_branches/`	否
記帳庫、Excel、訊息存檔、週報	本機 `ppa訂閱線/ppa_watch/`	否
每晚入選與理由	雲端 D1	只有登入才讀得到；不進靜態頁、不進版控
推播	Telegram 指定聊天室	只有文字（代號、名稱、分數、理由、卡號），不附圖、不引內文

推播裡所有外部字串先過 ppa_notify.scrub：抹金鑰、網址（只放行自家詳情頁）、磁碟路徑、圖檔路徑。
辨識時圖片會送到 Gemini 付費層；備援 Claude 引擎加了「不留 session 紀錄」。
本頁不含任何真實選股、真實清單代號或付費內文。

16常見問題

為什麼不 22:15 就推？

籌碼湖 22:40～23:00 才有當日資料。太早跑只會拿到前一天的資料（以前的地板股就是這樣一直晚一天）。

推播上的分數可以直接照著買嗎？

不行。權重還沒經過記帳驗證，現在只是「觀察順序」。記帳累積約 3 個月後看週報才知道哪些家族、哪些卡有效。

〔未審〕是什麼？

依據的規則卡還在 PPA 待審區，PM 審過併入主手冊後標籤會自動消失。

為什麼有的家族寫「0 檔」？

當晚那段沒有股票達到門檻。這是「有算、結果是 0」，跟「沒算」不同（沒算會推原因）。

同一檔同時出現在做多和做空？

會被兩邊都拿掉，推播第一則會寫「同日多空衝突」。

AI 會不會亂挑股？

挑股完全不用 AI。AI 只負責把截圖抄成表格，而且每一列都要對上籌碼湖才算數。

辨識讀錯怎麼辦？

對不上湖的列不會進打分；整篇錯太多（>10%）整篇擋下；通過率 <90% 推播只列清單、不打分。

17沒收到推播時怎麼查

每條終止路徑都會推一句話，所以「完全沒收到」只剩幾種可能。照順序查：

今天是交易日嗎？非交易日不跑、不推。
電腦有開、排程有跑嗎？看 ppa訂閱線/ppa_watch/nightly/_run.log 和 runs.jsonl 有沒有今天的紀錄。整晚沒開機，隔天也不會有「昨晚未送達」橫幅。
狀態檔說了什麼？看 nightly/state_<日期>.json：每一步的結果、已送集合、錯誤訊息。
排好了但沒送出？nightly/<日期>/msg_*.txt 在＝是 Telegram 送失敗；下一晚第一則會補「昨晚未送達」。手動補推：run_nightly.py --as-of <日期>（接續、只補送沒送的）。
收件聊天室對嗎？.env 有 TELEGRAM_ALERT_CHAT_ID 就送那裡；沒設則送白名單 TELEGRAM_ALLOWED_CHAT_IDS 的第一個；兩個都沒設才不送。
只收到地板股、沒有 PPA？正常會另外收到「未發文」「換 cookie」「額度用完」「辨識失敗」「校驗失敗」之類的一句話，照那句話處理；cookie 失效就換 PPA_COOKIES_FILE 指的檔案。
收到「湖未更新到 <日期>」？籌碼湖當晚漏跑或很晚才完成，是湖專案的事；之後用 --as-of <日期> --force 補跑。
還是不知道？影子模式重跑看完整輸出：python scripts/xiaoge/run_nightly.py --as-of <日期> --force --no-notify --once。

18檔案地圖（給維護者）

檔案	做什麼
`scripts/xiaoge/run_nightly.py`	每晚總控（純函式狀態機 `next_action`＋薄迴圈）
`start-nightly.bat`	排程進入點（工作排程器 `xiaoge-nightly`，週一～五 22:40；2026-10-26 建立，目前是影子模式 `--no-notify`，只存檔不推播，確認兩晚後才拿掉）
`fetch_ppa_articles.py`、`ppa_client.py`	抓文章、PressPlay API、`NotLoggedIn`
`ppa_list_ocr.py`	截圖 → 清單 JSON（Gemini；備援 Claude）
`ppa_lists.py`	對湖逐列校驗
`ppa_pick.py`	九家族純規則打分、衝突移除
`day_trader_branches.py`	漲停價買進分點掃描（隔日沖分點）
`ppa_key_branches.py`	小哥關鍵分點清單辨識與校驗
`chip_lake.py`	籌碼湖唯讀轉接層（就緒判斷、還原價）
`ppa_notify.py`、`notify_telegram.py`	推播排版、存檔補推、scrub
`ppa_store.py`	DuckDB 入庫、記帳、Excel
`ppa_ledger_eval.py`	記帳評估＋週報
`ppa_cloud_sync.py`	上傳 D1
`scripts/ops/reader_auth/lib/ppa_api.js`、`schema.sql`	雲端 API 與 D1 表
`reader_assets/ppa.*`、`build_ppa_page.py`	`ppa.html` 頁面外殼
`extract_ppa_rules.py`	文章影片逐字稿 → 待審規則卡（獨立的萃取線）
`ppa_watch.py` 開發中	三份追蹤清單與提醒

延伸閱讀（本機文件）：使用 SOP docs/PPA每日分析-使用SOP.md、計畫 docs/plans/2026-10-22-PPA每晚流程與推播-plan.md、記帳規格 docs/plans/2026-10-22-PPA記帳規格v1.md、追蹤頁設計 docs/plans/2026-10-24-PPA選股追蹤頁-design.md。Markdown 版：docs/PPA每晚分析-ELI5.md。