UI 站交付紀律(UI Station Delivery)
什麼時候用
任何時候你要交付一個使用者要親手操作的東西:一個畫面、一段對話流程、一個表單、一個從
「按下去」到「拿到結果」的互動站。這技能講:在說「做好了 / 請人驗收」之前,你自己必須先做什麼。
核心洞見:一個站是不是「能用」,不是看它的功能清單有沒有全部打勾,是看使用者能不能從入口
一路走到終點。 清單全綠但走到一半沒有下一步,這個站就是壞的。
核心法則
法則 1:清單驗「做了沒」,劇本驗「能用嗎」——兩者缺一不交
- 清單(checklist):每個要求的零件做了沒?(有開場白、有按鈕、有三個分類…)——驗存在性。
- 劇本(journey):一個真使用者從入口動作(上傳/點擊/輸入)一路走到終點動作(產出/儲存/
送出),中間每一步都走得通嗎?——驗可用性。
- 兩者是不同的驗證,缺一不可。 清單全綠 ≠ 能用。最常見的失敗:每個零件都做了、都在畫面上,
但「看得到、說不上話」或「說得上話、動不了手」——站不成站。
法則 2:自驗必須跑「完整使用者劇本」,一條路走到終點
交付前,自己扮演使用者,從入口走到終點,一步都不跳:
入口動作 → 每一個中間狀態 → … → 終點動作(真的拿到結果)
每走一步,問一個問題:「使用者現在,知道下一步是什麼嗎?」
- 按了「全部」→ 系統確認了,但沒告訴他接下來按哪? → 斷頭,不成站。
- 看到清單了→ 但沒有地方能表達「我要這個不要那個」? → 說不上話,不成站。
- 走到最後→ 按了送出→ 沒有任何回饋說成功了沒? → 「然後呢」,不成站。
走不到終點,就是還沒做完。 不論清單多綠。
法則 3:「請人親驗」的前置 = 劇本自己先走通 + 逐步存證
「交給人做最終驗收」是有前置條件的,不是做完清單就能喊:
- 前置:完整劇本你自己先走通了,而且逐步留下存證(截圖 / 錄影 / 逐步輸出),
證明無斷頭、無殘影、無「然後呢」。
- 走不通,不准掛「請人驗收」。 把一個走不到終點的東西推到人面前,是把「自己走一遍就會發現
的洞」丟給人找。
法則 4:人的親驗是「最終拍板」,不是「幫你找自走就會發現的洞」
分清楚人親驗該做什麼、不該做什麼:
- 該做(最終拍板):領域正確性(數字/邏輯對不對)、作業實情(實際流程符不符)、手感(順不順、
舒不舒服)——這些只有人能判,你自己走再多遍也判不了。
- 不該做(替你抓自走就會發現的洞):斷頭、殘影、按了沒反應、走不到終點——這些你自己走一遍
就會撞到。讓這類洞跑到人面前,是交付流程的缺陷,要跟「漏到生產的 bug(escaped defect)」
同等看待、同等記錄、同等檢討。
法則 5:交付格式 = 「劇本已走通(存證 N 份)+ 自驗結果一行」
交付一個 UI 站時,附上:
- 劇本走通聲明:入口→終點一條路走通,附逐步存證(截圖幾張,對應哪幾步)。
- 自驗結果一行:清單 X 項全綠 + 劇本 Y 步全通 + 關鍵不變式(如無殭屍進程 / 無殘影)。
- 先讓「把關者」審劇本完整性(這條路真的通嗎、有沒有藏斷頭),通過才轉「決策者」做最終拍板。
法則 6:截圖守「行為」、規則測守「規則」——缺一不可
互動站常有一層純規則邏輯(輸入哪些詞 → 哪個意圖:確認詞、取消詞、指令關鍵字、fuzzy 命中…)。
這層要用確定性單元測試守(node:test / pytest),逐條列規則表(每個詞、每種命中數、兜底);
- 截圖劇本證的是「打了『確認』真的按到確認鈕」——行為接得上。
- 規則單元測試證的是「『好/對/確認』都算確認、『毛利率』不會被誤當確認」——規則本身對。
- 兩者是不同保證:截圖不可能窮舉每個詞,單元測試看不到 DOM 有沒有接線。只有截圖 = 規則沒人守
(改壞了截圖那條剛好沒踩到);只有單元測試 = 接線斷了沒人知道。 交付要同時附這兩種證據。
- 對應現場:一個「零單元測試、只靠截圖」的對話站是欠帳——規則沒有回歸網,下次改字就靜默壞。
法則 7:E2E 對真實副作用區要「結構性隔離」,不靠小心
只要 E2E 會寫入持久狀態(配方 / 檔案 / DB),就必須讓它寫到隔離的臨時區,而不是真實資料區——
且隔離要做在結構上(環境變數 / 注入路徑指向 tmp),不是靠「測試時小心一點、記得事後還原」。
- 真實環境層 E2E(真瀏覽器打 live server)無法 monkeypatch 那支獨立進程;所以 live server 啟動時
就要帶「測試資料目錄」環境覆寫(如
APP_DATA_DIR=<tmp>),讓它從 import-time 起就碰不到真資料。
- 「事後 git 還原」不算隔離:那是踩到地雷後拆彈,不是不踩雷。一次忘了還原就污染/覆蓋真實使用者
資料。隔離的價值是「結構上不可能碰到」,把安全從人的紀律移到機制。
本專案案發現場(佐證,非通用必需)
- 「看得到、說不上話」不成站:某財務報表自動化專案「反推多份」站第一版——多份清單渲染出來了、三分類
忠實浮出、清單項目全綠,但沒有對話,使用者只能看不能改 → 決策者親驗紅:「切站錯誤,最小可用
必須含最小對話」。清單全綠 ≠ 能用。
- 「說得上話、動不了手」不成站:第二版加了對話(可改選擇)但沒有產出出口——使用者打「全部」→
系統回「共 15 份」→然後沒有然後。決策者親驗紅:「行動出口斷頭,第三件缺(動得了手)站不成站」。
- 殘影 = 沒走完:單份問句在多份路徑「後方透出」——舊元素沒從 DOM 移除(只被蓋住)。決策者:
「z-index 蓋住不算修,要看移除的 code diff」。自走時看到殘影就該當場修,不該讓它到人面前。
- 交付流程缺陷 = escaped defect:決策者定案把「自走一遍就會發現的洞跑到親驗」定性為交付流程
缺陷、與漏到生產的 bug 同等記錄——逼出「交人前先自走完整劇本 + 逐步截圖」的硬前置。
- 零單元測試的對話站是欠帳(法則 6):「反推多份」對話連動站(某任務)只有截圖劇本、零 pytest/
node 測——規則(全部/加X單命中/加X多命中/不要X/純名/兜底/確認詞/取消詞)沒有回歸網。晨審被
把關者抓出補課:純規則抽到 對話規則模組(純規則層) 上 node:test 逐條守,截圖守瀏覽器行為,兩者並存。
- E2E 覆蓋真配方 = 隔離缺陷(法則 7):存檔 E2E 真瀏覽器打 live server → 經真 資料寫入函式
寫到真實資料目錄,靜默覆蓋了某份既有配方;當時靠「事後 git checkout 還原」收拾。
根因是 live server 用 production config(conftest 的 tmp 隔離只對 pytest 有效)。修法:
config 的配方目錄
支援 APP_DATA_DIR 環境覆寫,E2E 起 server 帶 tmp——結構上碰不到真配方,不靠小心。
- 與姊妹技能:自走劇本時撞到的功能性壞掉,用 systematic-debugging 找根因;劇本的「一行自驗結果 +
存證」格式,呼應 handoff-protocol 的「一行結論 + 可把關證據」;「清單驗做了沒、劇本驗能用嗎」
呼應 verification-discipline 的「該有而沒有」(清單漏項)與「不信自報」(要真走通不是宣稱走通);
法則 7 的結構性隔離呼應 engineering-economy 法則 8「測試隔離防假卡」——把安全從紀律移到機制。
1---2name: ui-station-delivery-23description: 交付「使用者要親手用的東西」(UI 畫面、對話流程、任何有入口與終點的互動站)前的驗收紀律。用於任何 UI/互動交付:自驗必須跑「完整使用者劇本」——從入口動作一路走到終點動作,每步問「使用者現在知道下一步嗎」;清單項目驗「做了沒」、劇本驗「能用嗎」,兩者缺一不交。走不到終點=站不成站,不論清單全綠。4---56# UI 站交付紀律(UI Station Delivery)78## 什麼時候用910任何時候你要交付一個**使用者要親手操作**的東西:一個畫面、一段對話流程、一個表單、一個從11「按下去」到「拿到結果」的互動站。這技能講:**在說「做好了 / 請人驗收」之前,你自己必須先做什麼。**1213核心洞見:**一個站是不是「能用」,不是看它的功能清單有沒有全部打勾,是看使用者能不能從入口14一路走到終點。** 清單全綠但走到一半沒有下一步,這個站就是壞的。1516---1718## 核心法則1920### 法則 1:清單驗「做了沒」,劇本驗「能用嗎」——兩者缺一不交2122- **清單(checklist)**:每個要求的零件做了沒?(有開場白、有按鈕、有三個分類…)——驗**存在性**。23- **劇本(journey)**:一個真使用者從**入口動作**(上傳/點擊/輸入)一路走到**終點動作**(產出/儲存/24 送出),中間每一步都走得通嗎?——驗**可用性**。25- **兩者是不同的驗證,缺一不可。** 清單全綠 ≠ 能用。最常見的失敗:每個零件都做了、都在畫面上,26 但「看得到、說不上話」或「說得上話、動不了手」——**站不成站**。2728### 法則 2:自驗必須跑「完整使用者劇本」,一條路走到終點2930交付前,**自己扮演使用者**,從入口走到終點,一步都不跳:3132```33入口動作 → 每一個中間狀態 → … → 終點動作(真的拿到結果)34```3536每走一步,問一個問題:**「使用者現在,知道下一步是什麼嗎?」**37- 按了「全部」→ 系統確認了,但**沒告訴他接下來按哪**? → 斷頭,不成站。38- 看到清單了→ 但**沒有地方能表達「我要這個不要那個」**? → 說不上話,不成站。39- 走到最後→ 按了送出→ **沒有任何回饋說成功了沒**? → 「然後呢」,不成站。4041**走不到終點,就是還沒做完。** 不論清單多綠。4243### 法則 3:「請人親驗」的前置 = 劇本自己先走通 + 逐步存證4445「交給人做最終驗收」是有前置條件的,不是做完清單就能喊:46- **前置**:完整劇本**你自己先走通了**,而且**逐步留下存證**(截圖 / 錄影 / 逐步輸出),47 證明無斷頭、無殘影、無「然後呢」。48- **走不通,不准掛「請人驗收」。** 把一個走不到終點的東西推到人面前,是把「自己走一遍就會發現49 的洞」丟給人找。5051### 法則 4:人的親驗是「最終拍板」,不是「幫你找自走就會發現的洞」5253分清楚人親驗該做什麼、不該做什麼:54- **該做(最終拍板)**:領域正確性(數字/邏輯對不對)、作業實情(實際流程符不符)、手感(順不順、55 舒不舒服)——這些**只有人能判**,你自己走再多遍也判不了。56- **不該做(替你抓自走就會發現的洞)**:斷頭、殘影、按了沒反應、走不到終點——這些**你自己走一遍57 就會撞到**。讓這類洞跑到人面前,是**交付流程的缺陷**,要跟「漏到生產的 bug(escaped defect)」58 同等看待、同等記錄、同等檢討。5960### 法則 5:交付格式 = 「劇本已走通(存證 N 份)+ 自驗結果一行」6162交付一個 UI 站時,附上:631. **劇本走通聲明**:入口→終點一條路走通,附**逐步存證**(截圖幾張,對應哪幾步)。642. **自驗結果一行**:清單 X 項全綠 + 劇本 Y 步全通 + 關鍵不變式(如無殭屍進程 / 無殘影)。653. **先讓「把關者」審劇本完整性**(這條路真的通嗎、有沒有藏斷頭),**通過才轉「決策者」做最終拍板**。6667### 法則 6:截圖守「行為」、規則測守「規則」——缺一不可6869互動站常有一層**純規則邏輯**(輸入哪些詞 → 哪個意圖:確認詞、取消詞、指令關鍵字、fuzzy 命中…)。70這層要用**確定性單元測試守**(node:test / pytest),逐條列規則表(每個詞、每種命中數、兜底);71- **截圖劇本**證的是「打了『確認』真的按到確認鈕」——**行為接得上**。72- **規則單元測試**證的是「『好/對/確認』都算確認、『毛利率』不會被誤當確認」——**規則本身對**。73- 兩者是不同保證:截圖不可能窮舉每個詞,單元測試看不到 DOM 有沒有接線。**只有截圖 = 規則沒人守74 (改壞了截圖那條剛好沒踩到);只有單元測試 = 接線斷了沒人知道。** 交付要同時附這兩種證據。75- 對應現場:一個「零單元測試、只靠截圖」的對話站是欠帳——規則沒有回歸網,下次改字就靜默壞。7677### 法則 7:E2E 對真實副作用區要「結構性隔離」,不靠小心7879只要 E2E 會**寫入持久狀態**(配方 / 檔案 / DB),就必須讓它寫到**隔離的臨時區**,而不是真實資料區——80且隔離要做在**結構上**(環境變數 / 注入路徑指向 tmp),不是靠「測試時小心一點、記得事後還原」。81- 真實環境層 E2E(真瀏覽器打 live server)**無法** monkeypatch 那支獨立進程;所以 live server 啟動時82 就要帶「測試資料目錄」環境覆寫(如 `APP_DATA_DIR=<tmp>`),讓它從 import-time 起就碰不到真資料。83- **「事後 git 還原」不算隔離**:那是踩到地雷後拆彈,不是不踩雷。一次忘了還原就污染/覆蓋真實使用者84 資料。隔離的價值是「結構上不可能碰到」,把安全從人的紀律移到機制。8586---8788## 本專案案發現場(佐證,非通用必需)8990- **「看得到、說不上話」不成站**:某財務報表自動化專案「反推多份」站第一版——多份清單渲染出來了、三分類91 忠實浮出、清單項目全綠,但**沒有對話**,使用者只能看不能改 → 決策者親驗紅:「切站錯誤,最小可用92 必須含最小對話」。清單全綠 ≠ 能用。93- **「說得上話、動不了手」不成站**:第二版加了對話(可改選擇)但**沒有產出出口**——使用者打「全部」→94 系統回「共 15 份」→**然後沒有然後**。決策者親驗紅:「行動出口斷頭,第三件缺(動得了手)站不成站」。95- **殘影 = 沒走完**:單份問句在多份路徑「後方透出」——舊元素沒從 DOM 移除(只被蓋住)。決策者:96 「z-index 蓋住不算修,要看移除的 code diff」。自走時看到殘影就該當場修,不該讓它到人面前。97- **交付流程缺陷 = escaped defect**:決策者定案把「自走一遍就會發現的洞跑到親驗」定性為交付流程98 缺陷、與漏到生產的 bug 同等記錄——逼出「交人前先自走完整劇本 + 逐步截圖」的硬前置。99- **零單元測試的對話站是欠帳(法則 6)**:「反推多份」對話連動站(某任務)只有截圖劇本、**零 pytest/100 node 測**——規則(全部/加X單命中/加X多命中/不要X/純名/兜底/確認詞/取消詞)沒有回歸網。晨審被101 把關者抓出補課:純規則抽到 對話規則模組(純規則層) 上 node:test 逐條守,截圖守瀏覽器行為,兩者並存。102- **E2E 覆蓋真配方 = 隔離缺陷(法則 7)**:存檔 E2E 真瀏覽器打 live server → 經真 資料寫入函式103 寫到**真實資料目錄**,靜默覆蓋了某份既有配方;當時靠「事後 git checkout 還原」收拾。104 根因是 live server 用 production config(conftest 的 tmp 隔離只對 pytest 有效)。修法:`config` 的配方目錄105 支援 `APP_DATA_DIR` 環境覆寫,E2E 起 server 帶 tmp——結構上碰不到真配方,不靠小心。106- **與姊妹技能**:自走劇本時撞到的功能性壞掉,用 systematic-debugging 找根因;劇本的「一行自驗結果 +107 存證」格式,呼應 handoff-protocol 的「一行結論 + 可把關證據」;「清單驗做了沒、劇本驗能用嗎」108 呼應 verification-discipline 的「該有而沒有」(清單漏項)與「不信自報」(要真走通不是宣稱走通);109 法則 7 的結構性隔離呼應 engineering-economy 法則 8「測試隔離防假卡」——把安全從紀律移到機制。
poloplay0114