Standard · v1.0

視覺導向靜態網站標準

讓圖片說話，讓數字用圖表達，建立親切、專業與信任，然後以最少阻力導向聯絡。
而這一切能不能撐過三年，取決於這個網站好不好維護。

適用 · 作品集、產品展示、工作室官網、品牌介紹站不限產業9 章 · 83 條硬規則 · 2 層評分

適用對象：以視覺說服、以詢問轉換的網站——作品集、產品展示、工作室官網、品牌介紹站。不限產業。

四件事必須同時成立：訪客看得到他要的（內容）、畫面讀得下去（版面）、打開得夠快（效能）、改得動（維護）。前三件靠規則與驗證守住，第四件靠單一來源與決策記錄守住。做不到第四件，前三件會在半年內退回原點。

不適用：以連續捲動敘事為主體的實驗性網站（scrollytelling）、以互動為核心產品的應用程式介面。那是另一種設計語言，本文不涉及。

九章依「建一個網站的順序」排列，每章固定四段：

段落性質用途
原則不變的判斷準則遇到本文沒寫的情況時，用它推導
硬規則可執行、可檢核編號 R章.項，直接寫進驗收清單
怎麼驗工具或流程規則若無法驗證，它半年內就會失效
踩過的坑真實修正紀錄包含被自己推翻的決策

「踩過的坑」全部來自一個實際運作的作品集型靜態網站，累積約二十條架構決策記錄與一年的修改史。案例已抽象化，數字為實測值。

規則措辭：必須／不得／上限 為硬約束；建議 為有條件採用；標註 （未驗證） 者為推論而非實作經驗，採用前請自行測試。

1

定位與內容優先序

原則

訪客不是來看你的，是來找「跟我的問題像的東西」。第一屏該回答的是「你做過我這種案子嗎」，不是「我們是誰」。

內容優先序決定版面順序，不是反過來。先排出訪客做決定所需的資訊順序，再切版。順序錯了，版面再精緻也只是把錯的東西做得漂亮。

信任不是靠形容詞建立，是靠可查證的具體物：真實案例、可辨識的規模與時間、第三方認證、法務頁、真的打得通的聯絡方式。形容詞是自己說的，具體物是可以被反駁的——正因為可以被反駁，它才建立信任。

硬規則

  • R1.1

    首屏（不捲動）必須同時出現三件事：這個站在做什麼、一個代表性視覺、一個聯絡入口。

  • R1.2

    「關於我們／公司介紹」不得是首頁的第一個 section。

  • R1.3

    每個 section 必須能對應一個訪客真的會問的問題。寫不出那個問題，就刪掉該 section。

  • R1.4

    單頁 section 上限 5。超過表示這一頁承擔了兩個目的，應拆頁。

  • R1.5

    每個作品／產品必須帶至少三項可比對的客觀屬性（類型、規模、地點、時間之類），讓訪客判斷「像不像我的案子」。

  • R1.6

    不得以無法查證的形容詞作為信任證據（「業界領先」「頂級工藝」「全方位服務」）。

  • R1.7

    法務頁（隱私權政策、服務條款）必須存在，且從全站頁尾可達。

  • R1.8

    頁面上的每一項數字承諾（年資、案量、工期）必須有出處或計算方式，不得四捨五入成整數後當作事實。

怎麼驗

  1. 優先序對照表：列出「訪客決策所需資訊」前五項，對照首頁前三個 section。序位不符即為缺陷。這張表要在動工前做，不是驗收時才補。
  2. 五秒測試：找一個沒看過的人看首屏五秒，關掉，問他兩個問題——這個站在做什麼、下一步該點哪裡。答不出來就是 R1.1 未達標。
  3. section 清點：掃描頁面結構標籤計數。
  4. 形容詞掃描：搜尋最高級與空泛用語，逐一要求提出證據，否則刪除。

踩過的坑

那個站最後每一頁都收斂到 1–3 個 section，遠低於上限 5。上限不是目標值，它只是防呆；真正的收斂力來自 R1.3「答不出問題就刪」。若一開始就宣布「一頁最多 5 個」，很容易被當成配額填滿——這是量化規則的典型副作用：訂上限的人想防守，執行的人聽成了指標。

因此本章的兩條規則有主從關係：R1.3 是判斷準則，R1.4 是防呆。順序不能顛倒。

2

資訊架構與分類

原則

分類是給訪客找東西用的，不是給你歸檔用的。命名要用訪客搜尋時會打的字。

分類軸只能有一條。 兩條軸混在同一組篩選鈕裡，訪客不會知道自己漏看了什麼——他以為篩完了，其實另一軸的東西整批沒出現。這是資訊架構最常見也最隱形的缺陷，因為它不會報錯。

分類一旦被寫進網址、資料夾名、檔名、設定檔，它就成了跨系統契約。改一次要同步多處，而成本不在搬檔案，在「有沒有漏改哪一處」的不確定性。所以分類必須在放內容之前定案。

硬規則

  • R2.1

    一組篩選只能有一條分類軸。同一組篩選鈕內不得混用不同分類維度（如「空間類型」與「服務類型」）。

  • R2.2

    一個項目只能歸屬一個分類。需要多重歸屬時，表示分類軸選錯了。

  • R2.3

    分類名稱必須是目標訪客會使用的詞彙。不得使用內部術語、專案代號、英文縮寫。

  • R2.4

    分類必須與儲存結構 1:1 對齊：篩選值 = 資料夾名 = 檔名 slug = 設定檔 key。

  • R2.5

    分類數量上限 8。超過時訪客無法一眼掃完，應合併或改為兩層。

  • R2.6

    新項目不合任何既有分類時，必須先決定「新增類別」或「調整既有類別定義」，不得暫時塞進最接近的一類。暫時等於永久。

  • R2.7

    站內連結不得帶副檔名，不得帶無意義參數。

  • R2.8

    每個分類至少要有 2 個項目。只有 1 個項目的分類應併入他類。

怎麼驗

  1. 分類軸檢查：把所有分類名稱列成一行，問「這些是不是在回答同一個問題」。若其中一個回答的是「做了什麼服務」、其餘回答的是「什麼空間」，就是混軸。
  2. 對齊檢查（可自動化）：腳本比對三個集合——篩選值、資料夾名、設定檔 key——兩兩差集必須為空。這支腳本要在放第一批內容之前就寫好。
  3. 連結檢查：全站掃描連結是否帶副檔名，是否有斷鏈。
  4. 空類檢查：計數每類項目數。

踩過的坑

那個站的圖片資料夾一開始按「空間類型」分，篩選鈕卻多了一個按「服務類型」定義的值。結果一個資料夾底下混了兩種篩選分類。事後拆分要同步修改五個地方：頁面圖片路徑、社群分享圖的 meta 標籤、列表頁縮圖、浮水印目標清單、浮水印座標設定檔。

當時的決策是「只拆有落差的部分」，不把全部資料夾改成統一的英文 slug——風險與效益不成比例。這個判斷是對的，但它同時證明了：分類沒對齊的代價，是往後每一次改動都要多想一層「這次會不會又漏改」。

另一個坑：站內連結原本帶著 .html。伺服器會把它 308 轉址到無副檔名版本，人類完全無感，但搜尋引擎每一頁都吃一次轉址，導致頁面不被編入索引。對人無感的錯誤最貴，因為沒有人會回報。

3

版面與留白

原則

留白不是剩下的空間，是分組的工具。兩個元素的距離傳達它們是不是一組，這比任何框線、卡片、色塊都有效，而且不佔視覺重量。

間距一旦允許寫字面值，節奏就會在三個月內崩解。因為每一次「這裡再多 3px 就好」都是局部合理、全域災難。

以圖為主的網站，留白的工作是讓圖被看見。圖與圖太密，訪客看到的是「一片格線」；夠鬆，才看得到「一張作品」。

捲動也是版面的一部分。讀者不是連續地看，是一段一段地跳。每一次跳完停在哪裡，決定他看到的是完整的一頁，還是兩段的殘骸——而這件事不由版面決定，由捲動器決定。

硬規則

  • R3.1

    所有 margin / padding / gap 必須引用間距 token，不得寫字面值。例外必須在該行註明理由。

  • R3.2

    間距階梯採倍增制，5–6 階為宜（例如 0.5 / 1 / 2 / 4 / 8 rem）。倍增制的好處是任兩階差異明顯，不會出現「16 還是 20」這種無意義的爭論。

  • R3.3

    垂直節奏必須遵守層級：section 間距 > 群組間距 > 標題與內文間距 > 段落內間距，相鄰兩級至少差一階。

  • R3.4

    字級階梯必須是唯一真相源，所有字級指向階梯變數，不寫字面值。階數上限 7。

  • R3.5

    內容容器必須有最大寬度。全寬只用於視覺元素（大圖、色塊），不用於文字。

  • R3.6

    圖片格線的卡片比例必須固定，由比例反推尺寸，不得讓比例隨欄寬浮動。

  • R3.7

    吸頂元素必須完整遮蔽其下方內容，不得半透明或留縫。

  • R3.8

    翻頁式捲動的落點必須吸附到 section 起點——按 PageDown 或空白鍵之後，畫面應該是一個完整的 section，不是卡在兩段之間、下緣露出下一段的背景色。吸附強度必須用「就近」而非「強制」：只要有任何一段比視窗高，強制吸附就會把那段的內文卡住捲不完。吸附點必須配上等同吸頂高度的捲動邊距，否則落點被吸頂導覽蓋住。

  • R3.9

    同一個捲動容器內的所有直屬 section 都必須是吸附目標，不能只挑「剛好一頁高」的那幾段。漏掉任何一段，從它的前一段翻頁過去就會停在半途。

  • R3.10

    一頁化的高度必須用 min-height 搭配動態視窗單位（dvh），不得用固定高度或 vh。內容用彈性置中，讓短內容置中、長內容自然撐開而不被截斷。

  • R3.11

    行動裝置必須關閉吸附與一頁化。手機沒有翻頁鍵，吸附在那裡沒有用途卻有副作用；而動態視窗單位會隨瀏覽器工具列收合而改變，一頁化在捲到底時會多出空白。

怎麼驗

  1. token 檢查（可自動化）：正規式掃描樣式檔中 margin / padding / gap 後直接接數字字面值的宣告。
  2. 節奏檢查：量測實際渲染後的間距值，確認層級單調遞減。人眼容易被內容長度騙，量測不會。
  3. 幾何回歸（強烈建議）：自動量測關鍵元素的位置與尺寸，在 DOM 沒變、位置卻變了時判定失敗。這一項比截圖比對更能抓到「改 A 壞 B」，而且不會因為換了一張圖就整批誤報。
  4. 翻頁逐段測試：桌機每頁按 PageDown 走到底，每一次落點都必須是某個 section 的起點，畫面下緣不得露出下一段的背景色。這一項只能人工做，而且每種螢幕高度都要測一次——殘留量會隨螢幕變高而變大。
  5. 行動裝置捲到底：在真的 iOS Safari 上捲到最底，頁尾下方不得有空白。工具列收合與展開兩種狀態都要看。模擬器量不出這個問題。

踩過的坑

作品格線改了三輪：

  1. 第一版固定欄數、寬度自適應 → 圖被壓扁變形。
  2. 第二版改成「比例優先、列數讓步」→ 圖不變形了，但視窗縮放時寬度會震盪。
  3. 第三版改成「由高度反推寬度」，卡片維持精準比例，篩選列跟著格線同寬 → 穩定。

教訓：格線的自由度只能留一個。 固定比例，就得讓欄數浮動；固定欄數，就得讓比例浮動。想把兩個都釘死，第三個變數（寬度）就會失控。這條規律適用於所有響應式格線。

另一個坑：吸頂的篩選列原本寬度與內容欄相同，捲動時兩側露出底下的作品圖，看起來像破圖。改成整條滿版才解決。吸頂元素的職責是遮蔽，不是對齊。

翻頁吸附這件事，錯了三次才對：

  1. 以為把 section 做成「剛好一頁高」就會自然翻整頁。 不會。Chrome 的 PageDown 只捲 87.5% 個視窗高，與一頁高的 section 對不上，於是每翻一次就累積一點偏移，畫面下緣露出下一段的背景色。版面對齊解決不了捲動器的行為，得用吸附把落點釘住。
  2. 以為只要把「剛好一頁高」的那幾段設成吸附目標就夠。 不夠。有一段內容比視窗高、沒被設成目標，結果從它的前一段翻過去就停在半途，吸頂下方殘留一條上一段的顏色——實測 24～298px，螢幕越高殘留越多。內容比一頁高是另一回事，但它的開頭仍然必須是吸附目標。
  3. 以為吸附是純桌機功能，沒有限定裝置。 業主回報 iOS Safari 上「滑到底、頁尾下方還有一片空白」。量測後發現不是版面多長了東西，而是捲動容器的高度在手機上會變動：動態視窗單位隨工具列收合而改變，實測同一頁在 390×750 與 390×844 之間差 146px；工具列收合時捲到底，工具列一回來文件變矮，捲動位置卻不會跟著回收。加上根捲動器有吸附點時 iOS 容易停在內容尾端之外且不彈回。最後在 768px 以下把吸附與一頁化整組關掉。

教訓：吸附是「捲動行為」的修正，不是「版面」的裝飾。 它要修的是捲動器每次跳多遠這件事，所以判斷它對不對，只能靠真的去按翻頁鍵、在多種螢幕高度上各按一遍——沒有任何自動化檢查會告訴你「這次停的位置很醜」。

4

RWD 與跨語言排版

原則

斷點是為了「版型必須改變」而存在，不是為了「尺寸要變」。尺寸的連續變化交給公式。

每多一個斷點，就多一組必須被測試與維護的狀態。斷點數量是複利型的技術債：它不會讓你今天寫不出來，它讓你半年後不敢改。

拼音文字與方塊文字的排版規則不同，不能共用一套數值。方塊字沒有空白斷字、字面填滿字框、沒有升降部撐開行距——三項差異各自都足以推翻拉丁文的預設值。

實測 · 一個站累積的斷點數

實際17 個
本文上限4 個
高度斷點2 個

硬規則

  • R4.1

    全站主斷點上限 4 個，且必須集中在一處定義。

  • R4.2

    連續變化（字級、間距、容器寬度、格線欄數）必須用流體公式（clamp() / min() / max() / auto-fit），不得用斷點逐級指定。

  • R4.3

    斷點只用於「版型換排」：欄數改變、元素換位、導覽形態改變。

  • R4.4

    超出主斷點的元件級斷點必須在該處註明理由。

  • R4.5

    互動能力的分歧必須以能力查詢判斷（hover / pointer），不得以螢幕寬度推測。

  • R4.6

    中文與拉丁文的字距必須分開設定，不得共用同一個值。

  • R4.7

    內文行長：拉丁文 45–75 字元，中文 25–40 全形字。超過必須限制容器寬度。

  • R4.8

    中文內文行高不得低於 1.7（拉丁文 1.5）。方塊字沒有升降部留白，行距要靠行高補。

  • R4.9

    中文標題字距可加寬（0.05–0.2em），但內文中文字距不得超過 0.05em——內文加字距會破壞詞組辨識，讀起來會一個字一個字跳。

  • R4.10

    中英混排的接縫空白必須由樣式處理，不得靠手動插入空白字元。手動空白會在斷行時留在行首行尾。

  • R4.11

    必須設定正確的語言屬性，混排段落內的外語片段要個別標記。斷行規則、字型選擇、螢幕閱讀器發音三者都依賴它。

  • R4.12

    標點不得出現在行首（避頭尾）。中文標點的預設寬度是全形，密集標點處要檢查是否需要壓縮。

怎麼驗

  1. 斷點清點（可自動化）：掃描所有 media query 的寬度值，去重後計數。超過 4 個主斷點就列為技術債，逐一要求理由。
  2. 行長量測：在每個斷點量測內文容器的實際每行字數。
  3. 語言標記檢查：HTML 驗證器可抓缺漏的語言屬性。
  4. 極端視窗：360px 與 2560px 兩端各檢查一次。多數版型在中間尺寸都正常，壞在兩端。

踩過的坑

那個站累積了 17 個不同的寬度斷點，外加 2 個高度斷點。每一個當初都有具體理由，沒有一個是隨便加的——但合起來，沒有人能回答「這個站到底有幾種版型」。改任何一處都得在 17 個寬度上驗一次；實務上不會有人做，於是只驗自己改的那幾個，然後在別的斷點壞掉。

高度斷點是合理的例外：首屏視覺要在筆電的矮視窗裡完整呈現，只能用視窗高度判斷，寬度幫不上忙。這證明斷點本身不是壞事，數量失控才是。

字距的教訓：該站確實給拉丁文一組獨立字距，方向是對的；但其餘二十多處字距散在各元件裡寫字面值。等於承認了「中文排版有自己的規則」，卻沒有把規則變成 token。規則沒有變成 token，就等於沒有規則，只有二十多個個案。

5

圖像策略

原則

以視覺說服的網站，圖就是內容本身，不是內容的配菜。圖的品質標準應該比文案更嚴格。

「最少資源、最大表達」的關鍵不是壓縮率，是選對載體：能用向量說的不要用點陣，能用一張說的不要用三張，能用圖說的不要用一段文字，能用數字說的不要用形容詞。

動態的目的是解釋，不是吸引注意。看不到動畫的人必須得到完整正確的畫面——關掉動態偏好的人、動畫還沒開始播的人、截圖的人、列印的人。

實測 · 一張主視覺的實送尺寸 vs 版面需求

實際傳輸1477–2048 px
版面最大需求846 px

實測 · 主視覺誤加延遲載入的代價

載入延後+1.7 ~ 2.2 秒

硬規則

  • R5.1

    圖片標記（srcset / sizes / 尺寸屬性 / 格式分支）必須由腳本產生並寫回原始碼，不得手改。手改的標記無法保證與實際檔案一致。

  • R5.2

    每張圖必須有明確的寬高（或比例），避免載入時的版面位移。

  • R5.3

    圖片實際傳輸尺寸不得大於它在版面上最大顯示尺寸的 2 倍。

  • R5.4

    每頁第一張主視覺必須立即載入並提高載入優先權；其餘延遲載入。判定必須由腳本按位置決定，不能靠人記得。

  • R5.5

    圖片格式全站統一。導入新格式必須有實測數據支持，不得因為「比較新」而採用。

  • R5.6

    每個作品／產品的圖片數量必須有上下限（建議 5–15）。少於下限說服力不足，多於上限訪客不會看完，而且拖慢頁面。

  • R5.7

    圖片裁切必須以主體為準（空間照切齊上緣或水平線、人像切齊視線），不得一律置中裁切。

  • R5.8

    圖示與說明性插圖必須用內嵌向量，不得用點陣圖或圖示字型。內嵌向量沒有額外請求、可隨主題變色、可動。

  • R5.9

    動畫的靜止狀態必須等於它的最終狀態——線畫完、長條長好、對照定位。不是回到起點。

  • R5.10

    同一組動畫的週期與節奏必須一致。

  • R5.11

    動畫必須尊重減少動態的偏好設定，且在無滑鼠環境有明確策略（見 R4.5）。

  • R5.12

    裝飾性圖片必須有空的替代文字；內容性圖片必須有描述性替代文字。兩者都不寫檔名。

怎麼驗

  1. 重產檢查（可自動化）：記錄來源圖的雜湊值，比對產物記錄，抓出「同檔名換了內容卻沒重新產生縮圖」。這是最容易漏、也最難用眼睛發現的一類錯誤。
  2. 尺寸稽核：量測每張圖的傳輸尺寸與實際顯示尺寸比值，超過 2 倍的列表。
  3. 優先權檢查：確認最大內容繪製元素沒有被設為延遲載入。
  4. 動畫停用測試：開啟系統的減少動態設定後逐頁截圖，畫面必須完整且正確。

踩過的坑

分類錯誤導致效能最差的策略用在最關鍵的圖上。 該站曾把一組跨欄主視覺歸類為「縮不動的圖」而直接給原圖。直到量測才發現：它在版面上最大只需要約 846 CSS px，原圖卻是 1477–2048px——而它正是每一頁的最大內容繪製元素。先分類、後套策略的做法，會讓一個分類判斷失誤放大成全站的效能問題。

為求整齊而統一加上延遲載入，實測慢了 1.7–2.2 秒。 延遲載入的直覺是「除了首屏都加」，但「哪張是首屏」必須由腳本按實際位置判定。人只要記錯一次，代價就是兩秒。

評估過更新的圖片格式，實測後決定不導入，並把理由與數字寫進決策記錄。 這一步看似多餘，實則必要——否則每隔幾個月就會有人「順手加上去」，而且他不會知道半年前已經測過。否決的決策比通過的決策更需要留檔。

6

效能與預算

原則

效能要訂成預算，不是目標。目標會被「這次先這樣」逐次侵蝕，預算超支則是一個事件，必須有人決定砍掉什麼。

先問「這個位元組能不能不要送」，再問「能不能壓小」。刪除永遠贏過壓縮。

分數不是目的，是代理指標。真正要盯的是三個實際感受：最大內容繪製、版面位移、互動延遲。

硬規則

  • R6.1

    每頁必須設定並記錄效能預算：首屏請求數、傳輸位元組、DOM 節點數上限。

  • R6.2

    阻塞渲染的樣式檔數量上限 1。多支來源檔必須合併輸出。

  • R6.3

    原始碼與產物必須分離。原始檔保持可讀（含註解），產物精簡並帶內容雜湊檔名。

  • R6.4

    字型必須自架並子集化，不得依賴第三方字型服務。

  • R6.5

    字型載入前後的行框必須一致，需提供度量對齊（metric-matched）的備援字型。

  • R6.6

    不得為了單一效果引入第三方函式庫。

  • R6.7

    若首屏內容是隨機或動態決定的，預載清單必須與實際內容由同一份資料驅動，並有自動校驗。

  • R6.8

    效能改動必須指名它針對哪一個指標。說不出來的改動不算優化，算重構。

怎麼驗

  1. 自動化效能檢測，設定各項下限並在 CI 擋。門檻要在達標當天就收緊（見第 7 章的教訓）。
  2. 預算檢查腳本：計算每頁圖片總位元組與 DOM 節點數。
  3. 一致性檢查：預載清單與實際內容清單逐筆比對。
  4. 真機測試：低階手機、慢速網路各一次。開發機的數字沒有意義。

踩過的坑

把四支樣式檔併成一支並精簡，改善的是首次內容繪製，不是最大內容繪製——因為最大內容繪製的瓶頸在圖片，不在樣式。合併本身是對的，但如果把它記成「LCP 優化」，下一次遇到 LCP 問題時就會再做一次無效的事。這就是 R6.8 存在的理由。

原始檔一度被就地精簡，結果註解全失、行號位移，其他工具寫死的行號引用一起壞掉。原始碼與產物必須是兩份檔案，這條沒有例外。

首屏視覺是隨機挑選的，預載清單與實際清單一度靠人工同步。漏改一次，預載的就是沒被用到的那張圖——白白多下載一張大圖，還延後了真正需要的那張。後來改由檢查腳本強制兩者一致。凡是「兩個地方必須一樣」的關係，都必須有腳本擋，不能只寫在文件裡。

7

無障礙與動態

原則

無障礙不是加分項，它是「這個人能不能用」的二元問題。

滿分不代表沒問題，但不滿分一定有問題。自動化只能測到一部分，把能自動測的部分做到滿分，人力才有餘裕看剩下的。

動態效果的預設值應該是「可以沒有」。

硬規則

  • R7.1

    自動化無障礙檢測必須零違規，CI 門檻設為滿分。

  • R7.2

    文字與背景對比度必須達標並實測記錄。色彩 token 的註解要寫明它對哪些背景達標。

  • R7.3

    所有互動元素必須可鍵盤操作，且有可見的焦點樣式。

  • R7.4

    焦點樣式不得只靠顏色變化。

  • R7.5

    標題階層必須連續，不得跳級。

  • R7.6

    所有動畫必須提供減少動態時的靜態版本（見 R5.9）。

  • R7.7

    自動輪播必須可暫停，且不得是唯一的資訊來源。

  • R7.8

    表單欄位必須有關聯的標籤；錯誤訊息必須與欄位關聯，不得只用顏色標示。

  • R7.9

    顏色不得作為唯一的資訊載體。

怎麼驗

  1. 自動化無障礙掃描每一頁，不是只掃首頁。
  2. 鍵盤全站走一遍：只用 Tab / Enter / Esc 完成主要任務，全程看得到焦點在哪。
  3. 對比度量測記錄在色彩 token 旁邊，改色時一併重測。
  4. 開啟系統的減少動態設定後複查每一頁。

踩過的坑

無障礙補到滿分之後，同步把 CI 門檻收緊為滿分。 這一步是關鍵：沒有收緊門檻的「補到滿分」，三個 PR 之後就會退回去。修好與擋住是兩件事，只做前者等於沒做。

動靜分界一度想用螢幕寬度判斷（小螢幕不播動畫），後來改用「有沒有滑鼠」判斷。平板與觸控筆電的螢幕寬度像桌機，但沒有 hover——用寬度判斷，它們會永遠停在靜止畫面。改成能力查詢後，有滑鼠的裝置只播游標所在那一格，沒有滑鼠的裝置常態播放。同一個效果，兩種輸入方式需要兩種策略，而螢幕寬度無法區分它們。

8

轉換與聯絡

原則

訪客願意聯絡的那一刻是隨機的——可能在第一張圖，也可能在最後一頁。聯絡入口必須隨處可得，不能只放在頁尾等他捲到。

阻力來自兩件事：「我要填多少東西」和「我填完會發生什麼」。前者靠減欄位，後者靠明說。

靜態站不需要為了收件而長出後端。但「不長後端」與「訊息真的有送到」是兩回事，必須擇一負責。

硬規則

  • R8.1

    每頁必須有至少一個聯絡入口，且不需捲到頁尾才找得到。

  • R8.2

    主要聯絡動作必須一鍵完成。不得要求先註冊、先選類別、先看說明。

  • R8.3

    初次詢問的必填欄位上限 5。

  • R8.4

    每個必填欄位必須說得出「少了它就無法回覆」的理由。說不出來的欄位改為選填或刪除。

  • R8.5

    送出後必須有明確回饋：成功訊息、預期回覆時間、以及萬一沒收到的備援聯絡方式。

  • R8.6

    若以第三方通訊軟體作為聯絡管道，必須預填訊息內容（訪客正在看的項目、來源頁面），降低對方「不知道要打什麼」的阻力。

  • R8.7

    聯絡管道必須有明確的收件責任人與回覆時限，並寫在頁面上。

  • R8.8

    不得使用彈出視窗、倒數計時、離開挽留等打斷式手法取得聯絡資訊。

怎麼驗

  1. 逐頁清點聯絡入口的位置與可見性。
  2. 端到端測試：從隨機一頁出發，計算到「送出詢問」的點擊次數，上限 3。
  3. 實際送一筆測試訊息，確認收得到、確認回饋訊息正確。這一項要定期做，不是上線時做一次。
  4. 表單欄位逐欄質問必要性。

踩過的坑

該站一開始決定表單純前端、不接後端，把訊息導到通訊軟體，理由是維護成本低。後來發現這個做法在部分情境下會靜默失敗——訪客以為送出了，其實沒有。於是改為經伺服器收件，推翻了自己先前的決策。

教訓有兩層：

  1. 「不接後端」省下的是維護成本，付出的是可靠性。當轉換是這個站唯一的商業目的時，這筆交換不划算。
  2. 決策記錄要把被推翻的版本留著原文並加註推翻它的記錄。否則半年後會有人再提一次同樣的省事方案，而且提得振振有詞——因為他看不到上次為什麼失敗。
9

維護

原則

網站不是被做壞的，是被改壞的。每一次改動都是一次退化機會。

同一件事只能有一個地方可以改。有兩個地方，就有一天會不一致——不是可能，是一定，只是時間問題。

決策要留下記錄，尤其是被推翻的決策。沒有記錄，團隊會在同一個問題上重複試錯，而且每次都覺得自己是第一個想到的。

實測 · CI 產物無條件上傳的累積代價

實際用量2.3 GB
每月額度0.5 GB

硬規則

  • R9.1

    共用區塊（頁首、頁尾、卡片模板）必須有單一來源，各頁的副本由建置產生。改共用區塊只改來源，不改各頁。

  • R9.2

    所有衍生資產必須有唯一的產生者腳本，且該腳本是唯一被允許寫入這些檔案的東西。

  • R9.3

    任何「改了 A 就必須改 B」的關係，必須有檢查腳本擋，不得只寫在文件裡。文件擋不住任何東西。

  • R9.4

    每個架構決策必須留下記錄：背景、決策、理由、日期。被推翻的決策保留原文，加註推翻它的記錄編號。

  • R9.5

    同一件事只寫在一份文件裡。多份文件重複描述同一規則時，更新必然分歧。

  • R9.6

    CI 產物必須設定保存期限與觸發條件。

  • R9.7

    本機預覽環境的路由行為必須與正式環境一致。

怎麼驗

  1. 單一來源檢查（可自動化）：確認產物與來源同步，漏跑建置就擋。
  2. 規則覆蓋率自檢：定期清點——本文的每一條硬規則，有哪些已經有自動檢查、哪些還只靠人記得。後者就是下一批要補的腳本。
  3. 文件重複掃描：同一個規則出現在兩份文件時，其中一份改為引用。

踩過的坑

CI 每次執行都無條件上傳測試產物，額度 0.5 GB／月被撐到 2.3 GB。 改成只在失敗時上傳、保存天數縮到個位數才解決。這類「成功時也留下垃圾」的設定在專案初期完全無感，累積幾個月才爆——而爆掉的那天，通常正好是你急著要 CI 跑的那天。

本機曾用最簡單的靜態伺服器預覽，它對無副檔名的路徑直接回 404，整站連結在本機全部點不動，而正式環境是好的。預覽環境與正式環境的路由差異，會讓開發者要嘛誤判有 bug、要嘛誤判沒 bug——兩種都會浪費一整個下午。

A

快篩（10 題，5 分鐘）

用於判斷「這個站值不值得進入深評」。每題只答是／否，任一題答否即為一支紅旗。

紅旗快篩

用於判斷「這個站值不值得進入深評」。每題只答是／否，未勾選即為一支紅旗。

10
紅旗

尚未評估。

判讀

第 10 題通常要問人或看原始碼，是唯一無法從外部觀察的一題。但它最能預測這個站三年後的狀態——前九題測的是今天做得如何，第 10 題測的是明年還能不能改。

B

深評（九維度加權評分）

九個維度對應九章，各評 0–5 分，加權後總分 100。

計分表

九個維度對應九章，各評 0–5 分，加權後總分 100。點選分數即時計算。

0/ 100
—尚未評分
維度權重0 分3 分5 分
1 · 定位與內容優先序14首屏講自己，訪客找不到作品作品優先，但缺可比對屬性內容順序即訪客決策順序，每項有可查證的具體資訊
2 · 資訊架構與分類8分類混軸或無分類單軸清楚，但命名偏內部術語單軸、用訪客語言、與儲存結構對齊
3 · 版面與留白12間距隨手寫，分組讀不出來有 token 但節奏層級不明節奏層級清楚，圖有呼吸感，格線比例穩定
4 · RWD 與跨語言排版8斷點失控或手機版壞掉斷點收斂，但中西文共用一套數值少斷點＋流體公式，中西文分別設定字距行高
5 · 圖像策略14直接放原圖，無響應式標記有壓縮與響應式，但標記手改、裁切一律置中標記由腳本產生，裁切依主體，向量用於圖示，動畫靜止即最終態
6 · 效能與預算14首屏數 MB，無任何預算概念分數合格，但沒有預算也沒有 CI 守門有明文預算、CI 擋線、每次改動指名指標
7 · 無障礙與動態10鍵盤不可用或對比不足自動檢測大致通過，門檻未收緊自動檢測滿分且 CI 鎖住，動態尊重偏好與輸入裝置
8 · 轉換與聯絡12聯絡方式只在頁尾，或表單十幾欄入口明顯，但無回饋、無責任人隨處可達、一鍵完成、預填內容、有回覆承諾
9 · 維護8共用區塊各頁各改一份有單一來源，但靠人記得同步單一來源＋腳本產生＋檢查擋線＋決策留檔

等第

總分等第判讀
90–100A可作為他人的參考標準
75–89B專業水準，改善點明確且局部
60–74C堪用，但有結構性問題會在改版時浮現
40–59D表面可用，內在需重做
< 40E建議重做，修補成本高於重建

評分注意事項

  • 維度 9（維護）通常無法從外部觀察。若沒有原始碼存取權，以間接證據推估（各頁頁尾是否一致、圖片標記是否規律、樣式檔是否為產物），並在報告中標示為推估。
  • 權重可依網站目的調整，但調整必須在評分之前宣告，不得評完再改權重。
  • 同一份評分表用於比較兩個站時，必須由同一人在同一天完成，否則標準會漂移。
C

最小工具清單

一天內可以在任何靜態站裝起來的一套。工具會換，分層不會：

01資產完整性（自製腳本）

擋什麼：斷鏈、清單不一致、產物沒重跑、來源圖換了內容

擋不到什麼：內容對不對、好不好看

02標準合規（HTML 驗證器）

擋什麼：標籤錯誤、屬性缺漏、語言標記

擋不到什麼：語意用得對不對

03無障礙（自動掃描）

擋什麼：對比不足、標籤缺漏、階層跳級

擋不到什麼：鍵盤操作的實際順暢度、替代文字寫得好不好

04效能分數（自動化檢測 + CI）

擋什麼：分數退步、預算超支

擋不到什麼：真機的實際感受

05視覺與幾何回歸（端到端測試）

擋什麼：版面位移、元素跑位

擋不到什麼：變好還是變壞

第 1 層是自製的，也是最值得投資的一層。 通用工具擋不到你的專案特有的一致性關係——哪個清單必須跟哪個資料夾一致、哪份設定必須跟哪些檔名對齊。這些關係每個專案都不同，但每個專案都有。

D

機器擋不住的那一半

自動化能守住的是「有沒有壞」，守不住「對不對」。以下項目必須人工判斷，且必須有人被指定負責：

項目為什麼機器做不到
內容優先序是否符合訪客的決策順序需要知道訪客在想什麼
分類名稱是不是訪客的語言需要知道他們會打什麼字
圖片裁切的主體判斷需要知道這張圖在講什麼
留白是否讓分組可讀自動化只能測數值一致，測不出「看起來是不是一組」
文案是否具體可查證空泛與精準在語法上沒有差別
動畫是不是在解釋，還是只在吸引注意需要判斷意圖
翻頁捲動每一次停下來的位置好不好看沒有工具會回報「這次停在半途」，只能真的去按翻頁鍵
視覺回歸的差異是變好還是變壞它只能告訴你「變了」

最後一項最容易被誤解。視覺回歸測試的價值不在於它會判斷美醜——它不會。它的價值在於強迫你看見每一個非預期的改動，把「我不知道這裡變了」變成「我知道這裡變了，而且我決定接受」。

怎麼用這份文件

新站

照第 1–9 章順序做一遍。每章做完就把該章的「怎麼驗」接上 CI，不要等全站做完才補檢查——那時候要補的量會大到沒人想動。

既有站

先跑附錄 A 快篩。紅旗優先修，修完再進附錄 B 深評，按維度分數由低到高排改善順序。

評估別人的站

附錄 A → 附錄 B。產出報告時，把維度 9 的推估性質標示清楚。

團隊協作

把硬規則編號（R1.1、R5.4）直接寫進 PR 檢查清單與 code review 意見，避免每次都重講一次理由。

來源與性質　本文的規則來自一個實際運作的作品集型靜態網站，累積約二十條架構決策與一年的修改史。所有「踩過的坑」為真實事件，數字為實測值，案例已抽象化處理。標註「未驗證」者為推論，採用前請自行測試。

本頁的自我遵守　內文行寬鎖在約 38 全形字（R4.7）、中文行高 1.75（R4.8）、內文中文字距 0.01em（R4.9）、中文與拉丁字型分別承擔各自的排版角色（R4.6）、圖示與資料視覺化使用純 CSS 與內嵌向量而非圖檔（R5.8）、尊重減少動態的偏好（R7.6）、焦點樣式不只靠顏色（R7.4）。

本頁如何產生　網頁版由 build.py 從這份 Markdown 單一來源產生，樣式與行為的原始碼分別是 template/site.css 與 template/site.js，產物是併檔後的 dist/index.html（R6.3、R9.1、R9.2）。計分表的維度、權重、等第判讀都從本文的表格讀出來注入，不在程式碼裡另寫一份（R9.3）。

v1.0