前兩天製作企業產值評估的模型2與模型3
主要的處理方向是透過**「假設」來進行評估
那今天的模型4
主要則是用「事實」(MOPS的月營收時間序列)做趨勢預測~
這是正常數據分析的邏輯，
資料越細緻，那自然能做出更有效的評估
因此這種方式相較於年資料
實際效果是比較好的，但就會有適用對象問題?
因為以台灣企業營收來說，月報與年報差異，在實際營收上會反應出來~
主要的問題點就在於農曆年節**
因此如若兩種型態的資料，若不處理這種變化
單純透過計算來衡量
勢必會出現大問題**「資料有效性」的部分
因此今天我將針對「月營收時間序列」一事建模
同時釐清模型的適用性**

一、今日目標

• 實作企業模型4，讀 data/financials.json 的月營收序列，做季節性調整後外推 6 個月、附殘差區間
• 釐清模型適用性

二、模型設計

計算方法：

1. 12 個月移動趨勢抓長期方向，濾掉單月噪音
2. 同月季節係數（近兩年同月均值）處理春節與年終效應 【2月的營收谷底不是衰退，是放假】
3. 外推僅 6 個月：月資料噪音大，拉長必失準
4. 區間用殘差 ±1σ：歷史上模型自己錯多少，未來就給多寬的容錯

強制揭露欄再加一條：接單型企業不適用
營收由大單驅動的公司，時間序列外推無意義，模型偵測到營收變異係數過高時主動降級並說明

三、我下的 Prompt

依企業模型4規格實作 models/revenue.ts

1. 讀指定公司近 24 個月營收，計算 12 個月移動趨勢與同月季節係數
2. 外推 6 個月（趨勢 × 季節係數），區間為歷史殘差 ±1σ
3. 變異係數 > 門檻時回傳 insufficient 並附「接單型企業不適用」文案
4. ECharts 畫歷史實線＋外推虛線，2 月點加標記說明季節性

四、撞牆實錄：'2025-9' 排在 '2025-10' 後面

第一版圖表畫出來，折線在年底附近莫名鋸齒
放大一看，月份順序錯了
10 月排在 9 月前面
原因是 financials.json 某批資料的月份欄位沒補零（2025-9 而非 2025-09），而排序用的是字串比較：字典序裡 '2025-10' < '2025-9'。

修法：
我修正的prompt

針對時間上出問題，進行修正，並告知原因

Claude 的說明

解析端在 Day 4 的資料腳本統一補零並加進 meta 檢核（schema 驗證欄位格式 YYYY-MM），計算端一律轉成年月數值再排序、不信任字串順序。

Claude 的總結

「日期當字串排序，是資料工程的經典陷阱——它九成的時間都對，剩下一成專挑跨十月的資料咬你。」

五、debug

規格寫「上市櫃自動帶入月營收序列外推」
問題點: 證交所端點只給最新一期、沒有序列，但翻回原始欄位發現它附了「去年當月營收」。於是設計成雙模式:**手動模式(主)**輸入 3–5 年年營收,走與產業 CAGR 完全同一套外推數學(今天抽成 shared.cagrForecast,ind2 重構後共用);**上市櫃快速模式(輔)**用單一 YoY 外推,只有一個成長率資料點,所以區間退化為固定寬度並在假設與侷限明寫「資料少,誠實說少」,「淡旺月與一次性訂單會扭曲單月同比」直接進侷限第一條。

抽共用函式時漏改一個變數範圍(growths 移進函式後 ind2 還在引用),回歸測試立刻紅燈抓到,修一行回綠——「重構必配回歸」再次自我證明,終端機紅轉綠的兩張截圖就是現成素材。

Claude修正結論

• 季節係數的體檢：把 12 個月的係數印出來人工看——2 月 0.72、12 月 1.18，符合台灣製造業的體感；若某月係數詭異（例如 1.9），先懷疑資料再懷疑產業
• 回測驗收：留最後 6 個月不給模型，讓它「預測」這段已知的歷史——誤差落在殘差區間內才放行。預測模型的驗收，就該拿它沒見過的過去考它
• 變異係數門檻實測：餵一家營收大起大落的示範公司——如期降級並顯示不適用文案，不硬算

六、驗收

Claude給的打包檔

資料同步
node scripts/fetch-twse.mjs

進入localhost點選「營收趨勢預測」
手動版部分如下

快速自動版部分如下

七、今日小結

今天整個製作過程來說
我認為就過去的經驗來說
時間序列模型的建模來講，最重要的不是預測，而是「認得日曆」
因為如若沒進行季節性資料處理，
其整體評估結果將全是幻覺式內容
而在製作過程中遇到**「補零的bug」**
提醒我，資料格式的紀律要守在源頭，下游補救式後續的debug而已