前言

假設今天是星期二早上。PM 在群組問：「 某某案子的 xxx 跟 OOO 過 SignOff 了沒？最新那次 DRC 有多嗎？」結果有幾個工程師同時去查：A 翻 share folder 裡日期最接近的報告，B 在信件裡搜昨天的 checklist，C 憑記憶馬上回說「應該是過了」。十分鐘後三個答案對不上，最後發現看到的根本不是同一個版本。

SignOff 的結果從來就不缺。缺的是 大家怎麼看到同一個現況。接下來要分享的，就是這個困擾的解決方案 - 一個完整專案的 Dashboard：網站怎麼分層、各層各管什麼、畫面怎麼從首頁一路走到看到某顆 Block 的情況

專案目前還在整理中，之後再放上來分享

到底在統一什麼

神聖而不可分割的一塊 ( 笑

設計團隊的痛點不是「沒有資料」，而是資料的住處、形狀、時效都不一樣。在 EDA 工具各自產報告後，有人把重點貼到試算表，有人只在會議口頭講。時間一久，專案變成一座沒有門牌的倉庫：東西都在，但你找不到「現在」到底是哪一個。

所謂的統一入口是要對齊三件事

1. 同一條路: 所有人走同一條路：製程 → 專案 → Block → 階段。路徑一旦變成網址，就可以傳連結：「你看這個位置，我們看的是同一個 block」

2. 同一份資料: 畫面不是手貼的數字，而是讀 disk 上明確會有的檔案：描述每一次上傳跑了什麼。刷新頁面看到的，就是 disk 上現在有的東西。這讓「我昨天看過」與「你今天看到」有機會重合

3. 同一個網址:不論過去現在未來，所有專案的資料與審查，都會統一從一個網址出發

這套不是可寫入的流程系統，也不做登入。它是一份 唯讀的網站：瀏覽器負責呈現，disk上的檔案負責提供事實，把入口想成大廳，而不是展覽館。大廳要夠清楚：進來之後立刻知道有哪些製程、每個製程底下有哪些專案、每個專案有哪些 block、點下去會落到哪個階段。展覽內容 —— 細節、版本比對、品質、Waive 了沒等等 ...

用到哪些東西

若從「完整網站後端」起步，很容易變成某個應用框架加資料庫再加上傳介面。那套對長期平台是合理的，但我不想搞那套。假設現場只有 Python 跟 node；我們要的是 把 EDA 跑出來的任何結果檔案都變成可點的網站，不是再建一個資料庫，然後再把同一份資料搬進去

整站可以想成四樣東西，職責分得很開：

建置與執行必須切開。會改畫面的人裝前端工具鏈；只負責把網站開起來給同事看的人，只要 Python。現場解開一份已經建好的目錄就能開站，不必在伺服器上再編一次。

畫面為什麼還要 React，而不是整頁都用拼字串的方式畫？因為大廳會有好幾種頁，頂欄、錯誤與載入狀態會反覆出現。用元件來接「這一頁的資料包」，之後要改某一層的長相，不必去動讀檔與組樹的邏輯。反過來說，讀檔、正規化、把父子版本串成樹，也不該散落在各個按鈕裡——那些是資料引擎的工作。

中間那條縫很重要。資料引擎 不把 HTML 塞進頁面，而是交出一張「快照」：現在是哪一種頁、標題該寫什麼、這一頁需要哪些列、哪些燈號、哪一棵版本樹。畫面層只認快照。這讓兩邊可以分開演進：改顏色與表格排版走畫面的流程，改「 Leaf 怎麼數、father 怎麼對」是資料引擎在負責的

執行期刻意沒有資料庫、沒有寫入介面、沒有登入。新增一個專案等於多一份階層檔；新一筆 run 等於多一份上傳檔。刷新頁面，清單會再列一次。沒有遷移腳本，也沒有「先重啟再看」。開發時則讓打包工具把資料相關的請求轉去那台 Python 小伺服器，每天看的就是之後會上線的一堆檔案。

Q: 為什麼不只放靜態檔、連小伺服器都不要？
A: 我感覺很多人都這樣做，但最後都付出了無法好好做資料比對跟資料無法很順利的刷新的代價，況且在資料量大的時候，網頁會載入非常久

整座網站其實只有三個角色在傳球

請把整站想成三個角色：disk 上的檔案、一個會列檔名的小伺服器、一個會走網址的瀏覽器。瀏覽器內部再拆成「引擎」與「畫面」，但對外仍是同一個網站。沒有背景排程，沒有每晚重算一次的彙總檔。所有版本譜系都在瀏覽器裡現場組起來。

  磁碟上的 dist/                      瀏覽器
  ├─ 網頁資產          <--- 打開網站 ------  步驟 1 載入殼
  ├─ 階層檔            <--- 逐份讀取 ------  步驟 3 專案裡有哪些 block
  └─ 上傳檔            <--- 逐份讀取 ------  步驟 4 每一次 run

              小伺服器
              ├─ 送出上面那些檔
              └─ 回答「現在有哪些檔名」
                    ↑
                    步驟 2 先問清單，再問內容

瀏覽器從不自己掃資料夾。第一次進站的順序固定，除錯也建議照這個順序：先看殼有沒有出來，再看清單回了什麼，再看單一檔能不能讀到，最後才看畫面為什麼空。

殼起來之後，資料引擎會做四件事：看網址現在指到哪一層、把清單與檔案讀進來並整理成內部資料、必要時再補該專案的階層、然後交出對應的快照。畫面層接到快照，才決定是畫首頁卡片、專案階層，還是 Block 頁的標題與階段頁籤。載入中與失敗也是兩種正式的快照，而不是讓畫面自己猜。

網址全部走頁面井字號後面的路徑，所以伺服器不必把所有路徑都指回同一個首頁檔。對應關係如下：

首頁                         依製程分組的專案卡片
專案                         階層表
專案 / block / 階段          Block 頁（本篇終點）
專案 / block / 階段 / 版本   版本細節（今天只留門）
專案 / 總覽                  專案級摘要（Day 19）

專案識別來自檔名：第一個底線前面是製程，後面是專案名。檔名一旦不遵守，首頁上就不會出現那張卡——這是刻意的嚴格，避免一張說不清自己是誰的卡片混進大廳。目前階段做到 APR、ECO、SignOff，以及靠右的 Summary

快照是整座橋的橋面。首頁快照帶的是「按製程分好組的專案卡」；專案快照帶的是「展平後的階層列」加上每顆 block 的燈號與葉節點數；Block 快照帶的是標題列需要的版本與負責人，以及本體是檢查表、版本樹，還是摘要。畫面不回頭去翻原始檔。誰負責「這一頁該有什麼」很清楚：引擎組包，元件拆包。

引擎內部的記憶也很瘦：整理過的專案與上傳、階層快取、版本樹快取、目前位置、錯誤字串。重新整理等於重新問清單。對唯讀儀表這是優點：你永遠看到磁碟上的最新檔。代價是第一次進站會讀比較多檔。入口階段這個代價可接受；若哪天變成瓶頸，那是「清單改成一次打包」的題目，不是今天把資料庫請回來的理由。

整理上傳檔時，只要先建立幾個直覺，欄位細節留給之後。每一筆會被收成：它屬於哪個製程與專案、哪個 block、走的是 APR 還是 ECO、父親是誰、有哪些指標、有沒有 SignOff。block 名稱必須對得上階層裡的名字；對不齊的時候，階層列還在，但燈號與葉數量會是空的——這通常代表拼字不一致，而不是網站壞了。沒有階層檔，首頁是空的；沒有上傳檔，Block 頁進得去但表是空的。

目錄怎麼擺：改畫面的地方，跟跑起來的地方

把「開發樹」和「執行樹」分開想，後面比較不會把資料建丟。同事若只想開站，他們只需要小伺服器加上整個執行目錄。同事若要改大廳長什麼樣子，他們改原始碼再打包。

原始碼
  入口殼            品牌、標題列、把快照交給主畫面
  畫面各頁          首頁 / 專案 / Block / 版本 / 摘要
  資料引擎          讀檔、組樹、看網址、交出快照
  共用格式          數字怎麼顯示、燈號用哪種顏色

執行目錄
  網頁資產          打包後的殼與樣式
  階層檔            一個製程加一個專案一份
  上傳檔            每一次 run 一份

執行目錄裡不要另開第三個「彙總檔」當入口資料源。一有彙總檔，就會有人忘記重算，大廳就開始說謊。階層檔描述樹狀結構：哪些名字是上層、哪些是葉子、誰底下還有小孩。專案頁把這棵樹展平成列，縮排表示層級，並在列上掛 SignOff 燈號、APR 與 ECO 的葉節點數量、最近一次上傳日期。同一個 block 名稱既是樹上的節點，也是上傳紀錄對得上的鍵。

視覺語言也屬於入口。淺底、白卡片、深色強調；通過、失敗、警告、未知各用固定顏色；識別碼用等寬字。這不是為了像消費級產品，而是為了在投影機前、在遠端會議分享畫面時，燈號與名稱仍然分得出來。入口如果花花綠綠，統一感會先死在配色上。

怎麼建到 Block 那一頁：六個結構台階

這一段是結構順序，不是逐行實作。假設你從空白大廳開始，目標是：打開網站 → 看到專案卡 → 點進階層 → 再點一個 block 名稱 → 看到 Block 頁的標題與階段頁籤。

台階 1：先有殼，而且殼只認快照

殼負責三件事：品牌連回首頁、副標告訴你現在在哪一層、麵包屑告訴你怎麼走回去。中間那一大塊交給「主畫面」，主畫面再依快照種類分派到首頁、專案或 Block。載入中與失敗也走同一條路，不要讓某一頁自己偷偷畫轉圈圈。

殼一開始可以很素，但契約要穩：畫面不自己去抓檔，引擎不自己去畫按鈕。之後無論加哪一頁，都是「多一種快照、多一個畫面」，而不是在大廳中央再開一扇後門。副標也有工作：首頁顯示有幾張卡，專案頁顯示你在看階層，Block 頁顯示名稱與目前階段。使用者還沒讀表格，先從頂欄知道自己在哪。

台階 2：用網址當地圖

位置只存在網址裡。沒有後綴就是大廳；指出專案就是階層；再指出 block 與階段就是房間。更深的版本頁今天可以先能解析、先能回頭，不必裝潢。規則要從深到淺認，避免較短的路徑把較長的吃掉。

好處是重新整理、複製網址、從信件點回來，行為都一樣。麵包屑跟著位置走：大廳、專案、block，能點的都是真連結。使用者迷路時，入口的責任是讓他按兩下回到大廳，而不是按瀏覽器上一頁碰運氣。名稱裡若有特殊字元，進出網址必須成對處理，否則麵包屑會把一個名稱拆成兩段路。

台階 3：最小後端——只回答「有哪些檔」

伺服器做兩件事：把執行目錄當靜態網站送出，以及列出兩種資料檔的檔名。前端不必寫死專案清單。新同事丟進一份新的階層檔，重載頁面就出現新卡片。清單是入口能長出來的關鍵。若有人提議「把專案列表寫進設定檔比較快」，請記得設定檔會過期，檔名掃描不會——只要命名規則守住，大廳就跟磁碟一致。

清單回的是檔名不是內容，也是刻意的。把「有哪些」與「裡面是什麼」分開，之後若要做分批載入，還有縫可以插。今天不必做分批，可是不要一開始就把所有東西嵌進單一巨型檔，把縫封死。

台階 4：首頁——依製程分組的專案卡片

首頁不展示階層細節。它只做三件事：依製程分成大區塊、每張卡顯示專案名稱與 block 數量、整張卡點進去就是該專案。沒有階層檔時，要明白寫出「請放入階層檔」，而不是一片空白——第一個使用者會以為網站壞了。

卡片讓人三秒內找到自己的專案即可。首頁若開始堆燈號與趨勢，它會變成第二個儀表，真正的專案頁反而沒人點。排序也要穩定：製程名稱、同一製程底下的專案，都用固定順序。不要依最後修改時間排大廳，否則每天開門都在變陣。時間屬於專案表的更新欄，以及 Block 頁的上傳日期。

台階 5：專案頁——階層表，每一列都能點進 Block

專案頁把樹展平成表。沒有小孩的標成 block，有小孩的標成上層並寫出直接子節點數，必要時另有一列標成頂層。每一列大約是這些資訊：

名稱預設走進 APR。多數工程師從「我剛跑完的那次 APR」進來；SignOff 放在頁籤裡一點就到。葉節點數量讓你還沒進房間就知道這顆 block 有沒有料。階層表因此不是純靜態樹，它已經把「結構」和「有沒有 run」疊在一起。這是入口的最後一哩：使用者在專案頁就能決定要點哪一顆。

頁首可以先放一顆通往專案總覽的按鈕，內容哪怕很素。入口的地圖要先把鄰近房間畫出來。回程則靠回到階層與麵包屑，Block 頁不應該成為斷頭路。

台階 6：Block 頁——先站穩骨架，再填血肉

進到 Block 之後，頁面分成三塊就夠：標題列、階段頁籤、本體。標題是 block 名稱，底下是專案、版本、負責人、日期。旁邊一顆按鈕回到階層。頁籤列出 APR、ECO、SignOff；未開放的階段灰色；Summary 靠右，提醒它跟左側工程頁籤不是同一類觀眾。

  block 名稱                                      [ 回到階層 ]
  專案 · 版本 · 負責人 · 日期

  APR | ECO | SignOff | PV | STA | IR        Summary
  -------------------------------------------------------
  依目前頁籤決定的本體
  APR / ECO  → 末端版本列表
  SignOff    → 檢查表
  Summary    → 這一顆的最新摘要

本體先做三種就好。APR 與 ECO 在瀏覽器裡把父子關係串成樹，但這一頁 只列出末端——工程師通常問的是「現在最新的那次結果」，不是每一個中間站。欄位保持極簡：版本、沿途譜系、少數幾個一眼能看的數、上傳時間、父親是誰。列可以點，點進去的版本頁今天可以很素；完成定義是列表看得到、點得動。SignOff 取最新一份檢查，畫名稱、狀態、數值、準則；沒資料就直說還沒有，不要畫一張全是橫線的空表假裝有內容。Summary 能切過去即可。

整列可點，但點到列裡的連結就不要再搶一次。這種小細節屬於入口的手感：使用者不該猜「到底該點字還是點列」。

到這裡，統一入口已經閉環。任何人從首頁走兩次點擊，就能站在某顆 block 前面，並在 APR、ECO、SignOff 之間切換。工程師核對 Layout 與 Timing 的好幫手，是下一層的事；沒有這層骨架，那些表會變成沒有門牌的房間。

今天停在門口，明天再進房間

回顧這篇實際排了什麼結構。我們承認結果散落是流程問題，不是再做一份報表就能自動消失；於是選了一條「檔案當事實、小伺服器當門房、引擎出快照、畫面只負責畫」的路。建置與執行切開；專案清單來自掃檔，不來自設定；網址就是地圖。六個台階之後，團隊有一個統一入口：任何人打開同一個網址，兩次點擊就能站在某顆 block 前面。