讓 AI 有章可循：從 Apple 的 iPhone Duo 設計指南說起

2.1 先說要達到甚麼結果

Apple 開頭先說明希望應用程式帶來怎樣的體驗：打開或合上手機時，用戶可以接着完成手上的工作。這樣，後面的細則就有了共同目標。給 AI 寫指南時，先寫清結果，也能幫助它判斷那些細則沒有逐一說明的情況。

目標最好是用戶能感受到的。例如：「頁面版面變化時，已填寫的內容不能遺失，用戶可以繼續填完表格。」AI 調整頁面時就有了保留輸入內容的依據，你也有一個明確的結果可以檢查。

2.2 先把後面要用的名稱說清楚

Apple 先介紹螢幕、鉸鏈和相機，後面的版面要求就能直接使用這些名稱。這種順序建立了共同的用詞，也讓每條規則有明確的對象。AI 更容易把要求對應到正確的部分，不必每次都猜文中的名稱指甚麼。

自己的指南可以先解釋容易混淆的詞：「卡片是結果清單中的一個項目；點選卡片後開啟的是詳細資料頁。」這樣，再說「修改卡片標題」就更明確。背景說明只保留會影響工作的內容，關鍵定義也更容易找到。

2.3 先列出變化，再找共用規則

Apple 列出幾種使用姿態後，把它們歸到少量版面類型中。這種寫法把許多具體情況連到一套可以重複使用的判斷方法上。給 AI 一連串單獨答案，很容易漏掉下一個新情況；共用規則則能幫助它繼續判斷。

寫規範前，先列出需要應對的變化：標題變長、切換語言、視窗變窄。再寫它們共同要滿足的要求，例如標題仍能完整閱讀，操作仍然可用。用這些情況檢查規則，確實需要不同處理時再補充例外。

2.4 先寫要求，再解釋和舉例

Apple 的主要建議都先用粗體短句給出指令，再補充原因、例子和連結。讀者能很快找到要做甚麼，也能就近了解為甚麼這樣做。AI 從長指南中查找某一部分時，也更容易一起讀到規則和使用它所需的背景。

例如，先寫：「版面變化時，保留已填寫的資料。」再解釋原因，並給出檢查情境：表格填到一半時調整視窗大小。把細節放在要求後面，下次查閱時就不用讀完整段解釋，才能找到真正要執行的那句話。

2.5 讓規則能適應變化

Apple 用內容與可用空間的關係來說明版面要求。畫面變了，這種關係仍然適用。這種寫法值得參考：給 AI 寫規範時，說明不同情況下都要滿足甚麼要求，能減少它把某一個例子當成所有情況的固定答案。

例如，卡片規範可以寫：「卡片寬度隨容器調整；文字換行時，按鈕仍須完整顯示。」AI 可以據此處理不同寬度，你也能用同一條規則檢查窄版和寬版的結果。

2.6 把條件和動作寫在一起

「只有相機啟用時才存在」為後面的要求加上了明確條件。Apple 還區分了系統會自動處理的變化，以及自訂組件需要處理的部分。這些說明讓讀者先判斷是否需要改，再決定怎樣改，避免把某種情況下的要求用到所有地方。

自己的規範也可以這樣寫：「清單為空時，顯示原因說明和新增按鈕。」先寫條件，再寫動作。檢查時同時看空白和有內容的清單，就能知道 AI 是否在正確的情況下執行了這條規則。

2.7 告訴 AI 可以用甚麼工具

Apple 把預期效果和標準組件的連結放在一起，讓讀者能從設計要求直接找到實作方法。對 AI 來說，明確的組件名稱和準確的參考資料，可以減少需要自行選擇和猜測的細節。規範也因此更容易落實到實際修改上。

例如：「按鈕使用團隊組件庫中已有的尺寸和顏色。如果現有組件不合適，先說明缺少甚麼，再提出新方案。」這樣，AI 知道從哪裏開始，也知道現有方法不夠用時該怎樣處理。

2.8 寫清楚每條指令的範圍

Apple 先定義排列視圖負責甚麼，再說明導覽應該放在哪裏。這一步把職責劃清楚，讓讀者知道每件事應該由哪一部分處理。給 AI 寫規範時，類似的界線能幫助它控制修改範圍，減少順手改動相關功能的情況。

例如：「調整卡片的排版，保留原有連結目的地和按鈕行為。」前半句說明要做甚麼，後半句說明改到哪裏為止。大家對修改範圍有了共同理解，檢查結果時也更容易判斷。

2.9 把預設做法和例外放在一起

Apple 介紹按鈕通常放在哪裏時，緊接着就寫出例外，再說明兩個應用程式並排等情況。這種順序讓讀者先有一個預設做法，再判斷甚麼時候需要調整。AI 只查閱這一部分時，也更容易同時看到適用條件。

例如，表格規範可以寫：「欄位名稱預設放在輸入框上方；核取方塊的名稱放在核取方塊旁邊。」把兩句放在一起，再讓 AI 各檢查一個例子，就能減少它把通用規則套錯地方的情況。

2.10 要求有衝突時，給出取捨順序

空間不足時，所有按鈕都保持可見就做不到了。Apple 給出優先順序，並容許進一步區分整組和單個按鈕的重要程度。這種寫法的價值在於：提前告訴讀者怎樣取捨，避免到了必須刪減時才臨時決定。

簡短總結也需要這樣的規則：「保留決定、負責人和截止日期，先縮短背景討論。」AI 有了刪減依據，你也能按事先約定的順序檢查，而不用每次改寫後再重新決定甚麼更重要。

2.11 把籠統目標寫成能檢查的要求

Apple 在按鈕位置的要求後面，接着解釋原因，並給出 Mail 的例子。讀者能看到：按鈕放在哪裏，會影響用戶判斷它操作的是哪一部分。規則因此對應到一個看得見的結果，比單說「介面要清楚」更容易理解和執行。

自己的設計規範也可以這樣寫：「錯誤提示放在需要修改的輸入框旁邊，讓用戶知道該改哪裏。」這句話包含具體做法、目的和檢查方式。AI 設計頁面時有依據，完成後也知道該檢查甚麼。

2.12 寫出做不到時的處理辦法

Apple 遇到空間不足的問題時，用頁面主要用於瀏覽還是完成任務來決定優先保留甚麼，還為放不下的操作指定了統一去處。這樣的指令既說明如何選擇，也交代了剩餘內容怎樣處理，執行時少一個需要臨時猜測的步驟。

例如：「總結超過一頁時，把決定留在正文，補充資料移到附錄。」AI 知道怎樣縮短，細節也有地方可放。如果這樣仍會失去重要內容，再寫明需要把甚麼問題交給你決定。

2.13 讓例子和參考資料解答具體疑問

一張圖可以幫助讀者看懂位置關係，準確的參考連結則方便查清實作細節，正文裏的規則也能保持簡潔。Apple 同時使用了這兩種方式。我們可以參考的是：每份輔助資料都要有明確用途，要麼展示結果，要麼解答某個具體問題。

給 AI 一張示例頁面時，順便寫明要看哪一處；需要使用組件時，連結到對應組件。關鍵要求仍要寫在文字裏，並檢查工具是否能開啟圖片或連結。資料真正能被讀取和使用，才會起作用。

查看 Apple 的圖示

Apple 檔案中的參考資料

以下是 Markdown 檔案中的輔助連結。開發者參考名稱保留原文，方便 AI 編程工具找到準確的資料。

2.14 讓規則日後也容易核對和更新

Apple 的更新記錄和頁腳為指南留下了日期與來源。這些資料幫助讀者追溯建議從哪裏來，以及是否需要重新核對。反覆交給 AI 使用的規範也需要這樣的記錄，因為產品變了，過去合適的規則可能就要調整。

更新時，記下改了甚麼、甚麼時候改，以及依據是甚麼。例如：「9 月 14 日：錯誤提示改為放在輸入框旁，見已確認的表格示例。」這比只留一個日期更有用，下次設計變化時，你和 AI 都更容易找到需要更新的規則。

已於 2026 年 9 月 14 日核對本篇草稿所用的 Markdown 檔案。