"溝通"
- 空間 / 尺寸類指令的澄清時機
聽到「對齊 X」「擺在 Y 旁邊」但沒給數字時，先列計算過程讓使用者確認、不直接寫死。本文展開這類指令的處理 protocol。
- 元件相對位置類指令的澄清時機
聽到「X 在 Y 旁邊」時、先用文字畫個 layout 草圖讓使用者確認、不憑直覺擺。本文展開這類指令的處理 protocol。
- 隔離程度類指令的澄清時機
聽到「隔離」「不要動 X」時、先確認邊界是 DOM 結構、layout flow、state、還是 framework 管轄區。本文展開隔離邊界的四種類型與澄清方式。
- 覆寫深度的成本告知
客製可能對抗 UA + 跨瀏覽器 + framework 三層時、先報需要寫多少規則 / 哪幾條 / 殘留風險、讓使用者判斷值不值再開工。本文展開覆寫深度的事前告知 protocol。
- 「可決定」與「該先確認」的邊界
寫死任何使用者會看到的數字 / 順序 / 文字之前、先給選項讓使用者點頭。技術實作細節可以自決。本文展開兩者的區分原則。
- 「先還原」「先重來」類退出指令的處理
聽到「還原 / 重來」時、先問「還原到哪個 commit？要不要先 commit 一個 checkpoint 再動、方便日後比對？」本文展開退出指令的安全處理 protocol。
- 篩選類指令的澄清時機
「依 X 篩選」這類指令必須先澄清三件事才能寫：定義域（已載入 / 全部 / 子集）、資料分批方式、空狀態的語意。三問跑完才寫、否則必然寫成視覺層 post-filter、撞上 #55 層錯位。
- 跨專業溝通用情境遞進、不用比喻堆疊
向非本領域的專業人士解釋技術議題時，減少術語並從簡單情境遞進到複雜情境，比堆疊比喻有效。比喻傳遞形狀但不傳遞嚴重性；情境遞進讓對方用自己熟悉的決策框架（成本、風險、時間）消化資訊。
- 技術教材要內嵌管理層可彙報的資訊
技術文章的讀者不只要知道怎麼做，還要能向上彙報為什麼做、花多久、花多少。成本量級、時程估算、進度指標與需簽核的決策點應該嵌在技術段落旁邊，而非集中在另一篇溝通指南裡。