核心原則

空間 / 尺寸類指令缺少明確數值時、先列計算過程或假設、確認後再實作。 直接用估算寫死會在使用者實際看到結果時才被發現不對、引起多輪試錯。澄清的成本是「多打一句話」、收益是「一次到位」。

為什麼空間指令需要澄清

商業邏輯

「對齊」「擺在旁邊」這類描述是關係性指令 — 描述了兩個元素的相對位置，但沒給絕對數值。實作時需要把關係轉成具體數字（padding 多少、top 多少）。

執行者依憑感覺取數字 = 用自己的估算代替使用者的意圖。估算與意圖不一致時、使用者看到結果才知道、糾正成本高。

把計算過程列出來確認 = 把「估算」變成「協商」 — 使用者有機會在實作前指正。

這次任務的實際情境

觀察

情境指令我的處理結果
Filter 的 padding 對齊「padding 對齊到搜尋欄下緣」估算 padding-top: 152px 寫死視覺差 ~10px、要重做
Breakpoint 取值「桌面顯示左欄、手機隱藏」取 768px 寫死視窗 1200 時看不到 filter、要重做
Filter 寬度「左欄 400px」直接用 400一次到位

第三個是少數有明確數值的情境、那次一次到位。前兩個沒給數字、靠估算、結果都要重做。

判讀

差別在「使用者有沒有給確定值」。沒給時、執行者該做的不是「自己決定」、是「把計算列出來確認」。

執行：澄清 protocol

收到空間 / 尺寸類指令時、先檢查：

檢查項動作
使用者給了具體數值嗎？是 → 直接用；否 → 進下一步
我能依據已知元件尺寸推算嗎？是 → 列出計算過程確認；否 → 直接問
推算依賴的假設明確嗎？是 → 列出假設與數字；否 → 列出選項供選擇

例：

「padding 對齊到搜尋欄下緣 — 我會用 H1 64px + form 68px = 132px 當基準、加 8px buffer 共 140px、OK 嗎？或是你想要其他數字？」

把計算過程攤開、使用者可以指正「H1 沒這麼高、應該 70px」、避免實作後重做。

內在屬性比較：四種空間指令處理方式

處理方式一次到位機率重做成本適用情境
直接照使用者給的數值寫100%無使用者明確給數值
列計算過程確認後寫高低數值可推算
用估算值寫、之後再調中中 — 一兩輪視覺差容易調的場景
不確認直接寫死低高 — 多輪試錯不適用

優先順序：有數值用、可算就算、估算寫死最後選。

列計算的好習慣

1. 攤開假設

1計算 filter padding-top：
2  H1 height = 64px（假設、實際看 theme 渲染可能不同）
3  Form height = 68px（pagefind input 64 + border 4，鎖定 scale=1.0）
4  Gap = 20px（pagefind drawer 預設 margin-top）
5  Total = 152px

每個值來源寫清楚 — 使用者可以指出某個假設錯了。

2. 用變數表達

1padding-top: calc(var(--search-title-h) + var(--search-form-h) + var(--search-gap));

使用變數取代 magic number — 改一處全部跟著動、未來調整成本低。

3. 區分「設計值」與「量測值」

值類型來源例子
設計值設計師決定的固定值filter 寬度 400px
量測值runtime 才知道scope UI 高度（受字型換行）
推算值由其他值計算filter padding = title + form + gap

確認時把每個值的類型寫清楚、使用者知道哪些是「我可以決定」、哪些是「實作時才知道」。

設計取捨：空間/尺寸指令的處理策略

四種做法、各自機會成本不同。這個專案在缺數值時選 A（列計算過程確認）當預設、其他做法在特定情境合理。

A：列計算過程確認後實作（這個專案的預設）

  • 機制：把計算過程與假設攤開、給使用者確認、再用 calc(var(...) + var(...)) 實作
  • 選 A 的理由：使用者能指正特定假設（不只「對」「不對」）、實作後改 token 自動跟上
  • 適合：缺數值的空間 / 尺寸指令（大多數情境）
  • 代價：多一輪對話確認

B：直接照使用者給的數值寫

  • 機制：使用者給「filter 寬 400px」就直接 width: 400px
  • 跟 A 的取捨：B 一次到位、無需確認；前提是使用者已給確切數值
  • B 比 A 好的情境：使用者明確指定數值、執行者只需照寫

C：用估算值寫、之後再調

  • 機制：執行者依感覺給數字（「padding-top: 152px」）、寫了之後等使用者試
  • 跟 A 的取捨：C 看似省溝通成本、實際把確認延後到實作後；C 在估算錯時要重做
  • C 才合理的情境：視覺差容易調（< 5px 微差）、且確認成本比實作高（罕見）

D：不確認直接寫死

  • 機制：執行者自己決定數值、不問也不告知
  • 成本特別高的原因：跟使用者意圖不一致時要重做、多輪試錯
  • D 是反模式：「使用者會看到的數字」屬於該確認的決定（#21 可決定 vs 該先確認）— 自決會跟意圖不一致、被退回時白做

判讀徵兆

訊號應該觸發澄清的指令第一個該確認的
「對齊到 X」對齊基準是 X 的哪個邊（top / bottom / center）？基準位置
「靠在 Y 旁邊」多近？同 row 還是 above / below？相對方向與距離
「desktop 顯示、mobile 隱藏」Breakpoint 多少 px？viewport 切換點
「跟 Z 一樣高」Z 的高度是固定還是動態？量測 vs 寫死
「適中的 padding」「適中」對應多少 px？給選項供選擇

核心原則：空間關係描述只是意圖、不是實作數字。把意圖翻譯成數字的過程要對外可見、讓使用者參與。

第三輪指令類型現有五類：空間（本卡）/ 相對位置（#17）/ 隔離（#18）/ 決定權（#21）/ 篩選（#58）。前四類缺幾何 / 邊界 / 拍板資訊、第 5 類缺操作層級資訊。