新鮮勢 MNnews：近期變更與未來改進計劃
這份頁面把過去四天（6/1–6/4）對 MNnews 的所有變更，依照你的九層內容架構歸位，再接上看板上的未來路線圖。重點不是「改了哪些檔案」，而是每個變更動到哪一層、讀者或 API 端會有什麼差別。下方的近期變更可以用架構層篩選，看看每一層這陣子被改了多少。
一句話總結：這四天的工作集中在第 5 層（事件鏈脈絡）、第 6/9 層（編輯品質閘門）與跨層的 AutoFarm 同步韌性。未來路線圖則只有一個明確下一步——把判斷收斂成 Web3 Attention API。
總覽數字
6
變更主題（6/1–6/4）
40+
commits（含自動同步）
5/9
被觸及的架構層
3
未來看板卡片
變更主題與被觸及架構層的對照（點下方圖例或近期變更的篩選鈕互動）：
九層內容架構地圖
MNnews 的核心是一條「從雜訊到可信內容」的供應鏈。下圖標出近期變更落在哪些層——深色節點是這四天有改動的層。
flowchart TD
S1["① 來源匯入
媒體報導 影片 區塊勢背景 社群討論"]:::hot S2["② 過濾來源
去除內容農場與不可信來源"]:::cool S3["③ 事件歸群
同一件事歸成一團"]:::cool S4["④ 挑出主角
封面與排序"]:::hot S5["⑤ 掛上前因後果
事件鏈脈絡 context_links"]:::hot S6["⑥ 寫標題摘要排序
Editorial Desk 品質閘門"]:::hot S7["⑦ 統一內容檔
docs/feed.json 單一真相"]:::cool S8a["⑧a 新鮮勢網站
Astro 給人讀"]:::hot S8b["⑧b 資料入口 API
給程式與 AI"]:::hot S9["⑨ 同一套品質流程
兩個入口共用"]:::hot S1 --> S2 --> S3 --> S4 --> S5 --> S6 --> S7 S7 --> S8a S7 --> S8b S8a --> S9 S8b --> S9 classDef hot fill:#1f2937,stroke:#1f2937,color:#fff; classDef cool fill:#fff,stroke:#cbd5e1,color:#475569;
媒體報導 影片 區塊勢背景 社群討論"]:::hot S2["② 過濾來源
去除內容農場與不可信來源"]:::cool S3["③ 事件歸群
同一件事歸成一團"]:::cool S4["④ 挑出主角
封面與排序"]:::hot S5["⑤ 掛上前因後果
事件鏈脈絡 context_links"]:::hot S6["⑥ 寫標題摘要排序
Editorial Desk 品質閘門"]:::hot S7["⑦ 統一內容檔
docs/feed.json 單一真相"]:::cool S8a["⑧a 新鮮勢網站
Astro 給人讀"]:::hot S8b["⑧b 資料入口 API
給程式與 AI"]:::hot S9["⑨ 同一套品質流程
兩個入口共用"]:::hot S1 --> S2 --> S3 --> S4 --> S5 --> S6 --> S7 S7 --> S8a S7 --> S8b S8a --> S9 S8b --> S9 classDef hot fill:#1f2937,stroke:#1f2937,color:#fff; classDef cool fill:#fff,stroke:#cbd5e1,color:#475569;
深色＝近期有改動的層（①④⑤⑥⑧⑨）。第②③⑦層這四天維持穩定，沒有結構性變更。
近期變更（6/1–6/4）
依架構層篩選。每張卡寫的是變更前 → 變更後與下游影響，不是 commit 流水帳。
影響：
未來改進計劃（看板）
看板把工作拆成兩條軌道，不混在一起看。A 消費端產品 面向使用者與 API 客戶；B 內容智慧與供應鏈 面向背後的判斷品質。原則：別用消費端需求把供應鏈做成萬用資料庫，也別只研究來源卻沒變成可用產品。
下一步
已有明確第一個可交付成果
K-001 · A 消費端
Web3 Attention API
把「什麼值得注意」變成穩定可接的 API。第一交付：
GET /v1/attention/daily.json，回傳今天 10–30 件 Web3 事件，每筆附 attention_score 與 why_ranked。不做帳號、API key、dashboard，也不先搬資料庫。待釐清
有想法，但還沒決定做不做
K-002 · B 內容智慧
非新聞來源與自產內容資料層
鏈上資料、YouTube、Podcast、研究報告、社群原始討論。讓新鮮勢不只是新聞摘要，而是事件情報系統。下一步：列 3 個候選來源，各自回答能補哪種缺口、能否穩定抓取、能否驗證。
K-003 · B 內容智慧
權重與篩選模型
把來源品質、重要性、可信度轉成可被檢查的分數與理由。定義
source_type v0、attention_score v0、why_ranked fallback。不做 ML、不做精密公式、不讓分數取代人工判斷。已完成
已交付，留作基礎
D-001 · A 消費端
Astro reference client
正式前端由 Astro SSG 接管，從手刻 HTML 變成可維護的 reference client，也是 API 的展示櫥窗。
路線圖的張力：近四天的工程都在強化第 5/6/9 層的內容品質（事件鏈、編輯閘門、同步韌性）——這正好是 K-001 Web3 Attention API 能賣出去的前提。先把「判斷」做紮實，
attention_score 與 why_ranked 才有可信基礎，API 才不只是另一個新聞 feed。
從近期變更到下一步的時程
左邊是已完成（6/2–6/4 的品質強化），右邊是看板上待排程的下一步。
gantt
title MNnews 內容品質 → Attention API 路徑
dateFormat YYYY-MM-DD
axisFormat %m/%d
section 已完成 品質強化
事件鏈脈絡 pipeline :done, a1, 2026-06-03, 1d
編輯品質閘門 :done, a2, 2026-06-04, 1d
社群討論直譯與補回 :done, a3, 2026-06-04, 1d
AutoFarm 同步韌性 心跳 :done, a4, 2026-06-04, 1d
section 下一步 K-001 API
v1 public schema :active, b1, 2026-06-05, 3d
serializer feed→API :b2, after b1, 3d
/v1/attention/daily.json :b3, after b2, 2d
build 驗證前端不受影響 :b4, after b3, 1d
section 待釐清 內容智慧
K-003 權重模型 v0 :c1, after b4, 5d
K-002 非新聞來源 選型 :c2, after b4, 5d
時程為示意；K-001 各步驟順序依看板「下一個動作」排定，K-002/K-003 仍在待釐清，待 K-001 v1 落地後再評估升級。
資料來源：/Users/staarrr/MNnews git log（6/1–6/4）、docs/strategy/project-kanban.md、九層架構來自 mnnews-site-operations 報告慣例。反白頁面任一段文字即可留言，右下角可一鍵匯出回饋 markdown 給我做下一輪修改。