後台系統的資訊架構
這一頁管站台層：側邊欄怎麼分區、全域狀態列、深連結、單一出口。 進到某一頁之後的內部組成（區塊順序、元件、行為規範）是單頁層的事， 見頁面章。
v0.12.0 起這份規範有了對應載體：AppShell／Sidebar
與 NavGroup[] 導覽契約（ADR-0011，已採用）；v0.14.0 起多了多應用版型的
功能選單列。規則仍以本頁為準——
元件解決「怎麼組出來」，本頁回答「為什麼這樣分、什麼不能做」。
問題
後台系統的側邊欄，預設會長成資料表的目錄：
單據
對象
類別
區域
任務
報表
設定
每一項都對應一張資料表。開發的人覺得完整又整齊，使用者卻找不到東西—— 因為使用者要做的不是「看一張表」，是完成一件事， 而一件事幾乎不會只碰一張表。
「這個月的結算」要碰單據、類別、報表；「新對象開通」要碰對象、設定、任務。 於是使用者的日常變成在側邊欄之間反覆跳，而每一次跳都要重新想「這一步在哪裡」。
更糟的是同一件事有好幾個入口：結算流程裡有一個「匯出報表」， 側邊欄也有一個「報表」，兩邊做的事差不多但不完全一樣。 使用者會問「哪一個才對」，而正確答案是「都對，但你要記得哪個場合用哪個」—— 這不是一個系統該要求使用者記住的事。
做法：依工作節奏分區
側邊欄的分區不對應資料表，對應使用者的工作節奏：
每日作業 ← 天天做、有時間壓力
工作台
批次結算 〔例行〕
存量清查
規劃與分析 ← 想事情的時候才進來、不影響正式資料
用量分析 〔試算〕
報表 ← 對外交付
報表中心 〔例行〕
主檔與設定 ← 偶爾改、影響全公司
基本資料
系統設定
說明 ← 卡住的時候
使用說明
操作手冊（外連）
同樣是七、八個項目，但這個排法回答的是**「我現在要做的事在哪一區」**， 而不是「我要找的資料存在哪張表」。
分區的判準是頻率與後果，不是資料模型：
| 分區 | 頻率 | 改壞了會怎樣 |
|---|---|---|
| 每日作業 | 每天 | 當天的作業卡住 |
| 規劃與分析 | 每週／每月 | 不會怎樣（沙盒） |
| 報表 | 每期 | 對外文件錯誤 |
| 主檔與設定 | 每季 | 全公司的計算結果改變 |
把影響半徑最大的東西（主檔、設定）放在最下面、最不順手的位置。 順手程度應該與「按錯的代價」成反比。
不要把設定放在最上面只因為它字母排序在前， 也不要因為「這一區只有一項」就把它併進別區。分區的數量不是成本， 分錯區才是。
這個分法換一種系統一樣成立，因為它問的是同一組問題—— 所以判準要用系統的形狀去描述，不要用某個行業的名詞去描述：
| 系統形狀 | 每日作業 | 規劃與分析 | 主檔與設定 |
|---|---|---|---|
| 有待處理隊列 | 今日待處理、逾期項目 | 負載預測（沙盒） | 對象主檔、階段定義 |
| 有資源分配 | 今日指派、未完成項目 | 產能模擬 | 類型定義、費率設定 |
| 有數量增減 | 收發登錄、存量清查 | 補充模擬 | 項目主檔、區域設定 |
多應用系統：側欄切應用、頂部選單切功能
使用者一天要在好幾個應用之間切換時（作業、文件、排程、管理……）， 導覽分成兩層，各放一個地方：
| 層 | 放哪裡 | 回答的問題 |
|---|---|---|
| 應用 | 側欄（應用清單） | 我現在要在哪個應用裡工作 |
| 功能 | 頂部功能選單（目前應用的） | 這個應用裡，我要做的事在哪一區 |
上面那套工作節奏分區原封不動搬到頂部：一個分區＝一個頂層選單， 分區的判準、順序、「影響半徑最大的放最後」全部照舊。換應用時頂部選單整組換掉。
側欄收合時工作區要最大：可以收成圖示欄（還認得出應用），也可以收到 0、 滑鼠碰左緣再叫出來（浮在內容上，不推版面）。兩種都要有鍵盤與觸控的路—— 頂列左端的側欄開關、以及 ⌘K。
頂列三段：左右留給系統
[≡ 目前應用] │ 每日作業 規劃與分析 報表 主檔與設定 說明 │ [搜尋 ⌘K] [通知] [使用者]
└ 左：系統 ┘ └──────────── 中：目前應用的功能 ────────────┘ └──────── 右：系統 ────────┘
左右兩端是系統的，每個應用都一樣、位置不動：左端是側欄開關與目前應用， 右端是搜尋（指令面板）、通知、使用者選單。只有中段隨應用改變。 位置不動的東西才會變成肌肉記憶——右上角找使用者選單、左上角找應用， 在哪個應用裡都一樣。
頂層選單最多六個，用使用者說得出口的詞。選單裡保持一層，
兩層群組用分區標題分開；標題結尾的 … 表示選了還要再填東西（開對話框）。
不要做往右彈的子選單，也不要把「檔案／編輯／檢視」這種桌面軟體的通用選單搬進來—— 後台的頂層是工作節奏，不是文件操作。
側欄、頂部選單、⌘K 吃同一份資料：選單裡有的，⌘K 一定找得到； ⌘K 也找得到其他應用。
不要讓應用自己在中段以外放東西（例如把應用的設定鈕塞到右端）。 右端一旦被各應用各放各的，「右上角是系統的」就不再成立。
什麼時候不用多應用版型：只有一個應用、或使用者幾乎不在應用之間切換時， 側欄直接放分區導覽（單應用版型）更直接，少一層。不要為了「看起來像平台」而硬分應用。
「例行」與「試算」標籤
在項目旁掛一個小標籤，說明這個畫面動不動到正式資料：
| 標籤 | 意思 |
|---|---|
| 〔例行〕 | 正式作業。這裡做的事會進入正式紀錄 |
| 〔試算〕 | 沙盒。隨便改，不會影響任何正式資料 |
為什麼值得為此多做一個標籤：沙盒的價值來自使用者相信它是沙盒。 一個不確定會不會弄壞東西的模擬工具，使用者不會拿它來模擬—— 他會改到一半就退出去，然後用試算表算。
反過來也一樣：正式作業畫面要讓人知道自己在正式環境裡， 這是硬鎖定那條「刻意的決定」在導覽層的延伸。
試算畫面內部再標一次資料狀態徽章 （「試算暫定」／「已確認實際」／「歷史實際」）。導覽層說的是這個畫面的性質， 徽章說的是眼前這組數字的性質。
不要讓試算畫面有任何一顆按鈕會靜靜寫入正式資料。 真的需要「把試算結果套用出去」，那顆按鈕要獨立、要說清楚後果、 而且要是整個畫面上唯一一個。
全域健康度狀態列
頂列上隨時看得到兩件事：
- 待處理項目數（驗證器即時算出的錯誤數）
- 目前作業期間的狀態（已確認／未確認）
它的作用不是通知，是定位。後台使用者常常在五、六個畫面之間來回， 狀態列讓他在任何一頁都知道「這一期還能不能收」「還有沒有東西沒處理」， 不必回到工作台才看得到。
多應用版型裡，這兩件事落在頂列右段：待處理數是通知鈴鐺上的未讀徽章 （數字寫進鈕的可及名稱，不只靠徽章的顏色），點開就是待處理清單、 每一則都直接連到目的地；作業期間狀態若需要常駐，放在通知旁邊、同樣可點。
數字要可點，點下去直接到待處理清單。 一個說「還有 3 項」卻不告訴你是哪 3 項的指示器，只會製造焦慮。
不要在狀態列放「一切正常」以外的常駐訊息。 常駐的東西一旦超過兩項，全部都會變成背景，包括真正重要的那一項。
單一出口：同一件事只有一個入口
「產出對外文件」這件事只有一個地方做得到，其餘位置一律連過去。
舊入口不刪，改成轉址：
/flow/export → redirect → /reports
/export → redirect → /reports
為什麼是轉址而不是刪除：使用者收藏過網址、文件寫過網址、同事之間傳過網址。 直接刪掉會得到 404，而 404 對使用者的意思是「這個功能被拿掉了」—— 他不會猜到功能還在、只是搬家了。
合併多個入口時，把各入口原本能做的事全部確認過一遍。 「差不多的兩個入口」通常有一個做得到某件另一個做不到的事， 那件事就是使用者當初選擇走那條路的原因。
不要保留「兩個入口，功能 90% 重疊」。使用者遲早會發現兩邊算出來的數字不一樣， 然後就再也不相信任何一邊。多入口的真正代價不是混淆，是不一致。
深連結：讓待辦能直接跳到目標
畫面內的分頁與選中的對象要寫進網址：
/master?tab=records&id=C-1043
沒有這個的話，工作台上的待辦事項只能寫「請到基本資料 → 異動紀錄 → 找到 C-1043」， 使用者要自己走三步；有了之後，待辦本身就是一個連結。
連帶得到三件事：可收藏、可貼給同事、瀏覽器上一頁行為正確 （分頁切換算不算一次導覽？寫進網址之後這個問題就有答案了）。
網址參數用使用者看得懂的字（?tab=records），
不要用內部索引（?t=2）。網址是會被貼進聊天室的，第 2 個分頁是哪個沒有人記得。
不要把「哪一列被展開」「捲軸位置」這種暫時狀態也寫進網址。 判準是：別人打開這個連結時，需要看到一樣的東西嗎？ 不需要就別寫。
行動版：側邊欄改抽屜
窄螢幕下側邊欄收成左滑抽屜（點遮罩關閉），分區與順序完全不變。 （Sidebar 元件內建此行為——同一份 children 在桌面與抽屜間切換，順序不變是結構保證，不是紀律要求。）
多應用版型同理：抽屜裡是同一份應用清單；頂部功能選單收成一個「選單」鈕， 裡面依原順序列出每一區（功能選單列內建）。 頂列右段只剩圖示，位置不變。
不要為手機重新設計一套導覽。後台系統的手機使用者多半是同一個人在通勤時查東西， 他腦中的地圖是桌機版那一張；換一套結構等於要他學第二遍。
取捨
代價一：分區沒有標準答案，而且改起來很痛。
側邊欄是使用者肌肉記憶的所在地。上線半年後把「報表」從第二區搬到第四區， 會收到「東西不見了」的回報——即使它明明還在。
所以分區要在還沒有人熟悉之前定案，並且盡量用「頻率與後果」這種 不隨功能增減而變動的判準，而不是用當下的功能清單去湊。
代價二：依工作節奏分區，代表同一張資料表可能出現在兩區。
主檔在「主檔與設定」可以完整維護，同一筆資料在「每日作業」也可能被就地編輯。 這是刻意的——使用者在作業流程中發現要改一個欄位時， 不該被要求離開流程、去另一區、改完再回來。
要付的代價是：這兩個地方的行為必須一致（同樣的鎖定規則、同樣的稽核紀錄）。 做不到一致的話，寧可只留主檔那一個入口。
反例
側邊欄的每一項都要是使用者會說出口的詞。
不要用系統內部的模組名當導覽標籤。 「基礎資料維護模組」不是任何人會用來描述自己在做什麼的講法。
未知路徑 fallback 到最常用的作業畫面。
不要 fallback 到首頁然後什麼都不說，更不要顯示空白。 使用者手動改網址失敗時，最需要的資訊是「你在哪、可以去哪」。