Day 04 把申請、審核和分派帶回 DAP 後，畫面開始承接更多角色與狀態。
下一個問題變成：這些畫面到底要怎麼講清楚，才不會又靠 AI 盲猜？

• 第三代我先用 Pencil 把導覽、元件和畫面狀態畫出來，UI 不再只靠一句 prompt 描述。
• 改的不是只有配色；我把功能入口從產品分類改成使用者任務分類。
• 設計稿讓 Coding Agent 看得懂畫面，但 API、權限與驗收條件，仍要用 Spec 寫清楚。

頁面設計樣子跑出來，不代表符合我的需求

第二代開始用 Vibe Coding 做 DAP Web 版時，我最有感的是：原本在 Notebook 裡操作的流程，真的可以很快變成表單、按鈕和可點選的頁面。

但功能愈多，畫面的問題也愈明顯。表格裡的勾選應該放哪裡？按鈕靠左還是靠右？這段文字是不是太大？有時我只覺得畫面「不太對」，卻說不出應該改多少。

如果我繼續丟一句「按鈕再往右一點」給 AI，它可以改出下一版；但那通常只是比較接近，不代表我們已經對同一個畫面有共識。因為連我自己也要先看到畫面，才知道那個「一點」到底是多少。

UI 做不準，常常不是 AI 不會寫，而是我要的畫面還沒有被說清楚。

我重做的不是顏色，而是使用者找功能的方式

第三代一開始，我還是想把畫面拉皮。使用者對一個新系統的第一印象很重要。

第二代的白底頁面能用，但第三代的使用者不再只有我們部門。產品準備推到全公司使用，會有更多非工程背景的同仁進來操作；企業系統的風格、內容排版與用詞，也得更貼近他們。

真正開始重做後，我發現問題不只在顏色。原本 DAP 依 EDB、GCP 等產品分類功能，這對熟悉系統架構的人或許合理；但使用者進來時，通常不是先想「我要用哪一個產品」，而是「我要申請資料」「我要建立專案」，或「我要調整專案設定」。

所以第三代調整導覽時，我改用使用者任務來整理入口。

我沒有做使用性研究來證明這個分類一定比較好。這是我當時的設計判斷：先讓使用者看見自己要完成的事，再讓系統在後面處理產品和技術邊界。

導覽列不是系統功能的目錄，而是使用者開始工作的地方。
代三代一開始，我選擇先投入規劃頁面流程與操作動向，為了讓使用者操作更直覺。

一個申請頁，其實有兩種工作狀態

我想用一個「資料權限批次申請」頁面來說明。這張圖已經重新生成並匿名化，只保留當時要討論的版面與互動，不是 DAP 的真實截圖。

本圖依當時的設計討論重新生成並匿名化，只用來說明版面與互動，不是 DAP 真實畫面。

這個頁面不是讓使用者填完一張表就送出。左側是工作區，讓使用者搜尋或選擇想申請的項目；右側固定保留已選項目、申請資訊與送出動作。

使用者在左側調整內容時，右側仍看得到自己目前選了什麼。它不是額外的裝飾區塊，而是讓使用者不會在操作途中失去申請整體狀態的地方。

左側至少有兩種狀態：

搜尋／選取項目
  ↓ 點選右側已選項目
詳細設定／編輯
  ↓ 完成更新
搜尋／選取項目

第一次進來時，使用者在左側搜尋或加入項目。從右側點選一個已選項目後，左側切換成詳細設定，讓他編輯這個項目的內容；完成後，再回到搜尋狀態，繼續處理下一個項目。

如果只看一張靜態截圖，這些行為很容易被忽略；但在設計稿裡，狀態、切換條件和返回路徑可以先被畫出來。開發前，我們至少能先討論：點哪裡後哪一區會變？哪些資訊一定要留在畫面上？做完後要回到哪裡？

設計稿不是一張截圖，而是一組畫面狀態、互動與返回路徑。

我怎麼把設計稿交給 Coding Agent

第三代當時，我是在 VS Code 裡接 Pencil MCP，用 Claude 模型和 Pencil 來回產生頁面初稿。模型版本我已經不記得了，所以不硬補名稱。

當時留下的設計對話裡，agent 不只是收到一句「幫我畫一頁」。它會先讀取既有元件與變數，建立左右欄版面，調整右側申請清單與左側頁籤，再建立另一種編輯狀態；中途也會截圖檢查結果。

我在這個過程中做的，不是把設計交出去後等它自己決定。我會根據畫面繼續調整元件位置、文字大小、導覽分類和互動規則。設計確認後，再告訴 Coding Agent 要參考哪個 Pencil 頁面，並提供既有頁面位置與這次要修改的範圍。

Anthropic 對 MCP 的說明將 MCP 定義為應用程式向 LLM 提供外部 context 與工具能力的協定；Pencil 的 AI Integration 文件也說明，agent 可讀寫設計元素、版面和預覽。這能解釋當時設計工具為什麼可以接進 Coding Agent 的工作裡。

但 MCP 沒有替我決定產品設計。它只是讓 agent 能讀取我已經做出的設計決策。要用任務還是產品分類、哪一區固定、哪些互動值得保留，還是要由我自己判斷。

MCP 在這裡不是替我決定美感，而是讓設計決策能被 agent 讀取。

畫面講清楚後，還有很多事情要交代清楚

做到這裡，我還是不能直接說：「照這張設計稿開發就好。」

設計稿可以說清楚版面、元件、狀態和互動，卻不會告訴 agent：這個按鈕該呼叫哪一個既有 API、哪些資料規則不能改、誰有操作權限，或什麼情況才算完成。

第三代後來沒有把全部既有功能一次重寫。我會依設計稿分段處理：一次處理登入／框架、幾個既有功能，或一段新的流程。接著用 Existing Spec 補上既有頁面、API 和這次改動的邊界。

設計稿和 Spec 不是二選一。設計稿讓畫面變得可以討論；Spec 則讓工程上的假設、範圍和驗收可以被 review。

設計稿讓 AI 少猜畫面；Spec 能限制它不要猜業務邏輯與規則。

今天可以做的：先畫一張能討論的畫面

今天不需要安裝 Pencil，也不必重做整個專案。選一個正在改、最常被說「畫面怪怪的」的既有頁面，用你習慣的工具畫一張低保真 wireframe。

重點不是畫得漂亮，而是另一位工程師或 Coding Agent 看著它時，能回答下面幾個問題：

# UI Design Context｜功能名稱

## 使用者任務
- 使用者想完成什麼：
- 他從哪個入口找到這個功能：
- 現在的分類是產品分類，還是任務分類：

## 狀態與互動
- 狀態 A：
- 觸發切換的操作：
- 狀態 B：
- 完成／取消後去哪裡：

## 元件與邊界
- 哪些資訊必須一直可見：
- 哪些元件會依狀態改變：
- 哪些 API、角色或資料規則不能自行假設：

現在使用 Claude Code 的讀者，也可以請它先讀既有頁面，幫忙列出畫面可能有的狀態和元件。但要採用什麼任務分類、留下哪些資訊、哪些規則不能動，仍要由真正理解使用者與流程的人確認。

小結：先把畫面變成可閱讀的輸入

Pencil 對我最有用的地方，不是幫我做出一張比較漂亮的圖，而是讓我不再只用文字描述一個自己還沒想清楚的畫面。

我可以先把導覽、元件和狀態攤開來看，再把設計稿交給 Coding Agent。這讓後續討論有共同參照，而不是每次從一句模糊的 prompt 重新開始。

不過，畫面有了還不夠。只要既有 API、資料規則、權限和驗收條件沒有被寫下來，Coding Agent 還是可能在工程邊界外做出看似合理的修改。

Part 1 小結：AI 已經進到我的開發流程裡

回看 Day 01 到 Day 05，我其實不是在介紹 AI 工具，而是在回頭整理 DAP 從 Vibe Coding 走到第三代時，開發流程怎麼一步一步長出來。

這些做法沒有讓 AI 自己把系統做完。它們先讓我知道：哪些地方可以交給 AI 加速，哪些地方要把業務邏輯說清楚，才不會把不確定性帶進專案開發中。

接下來會進入新的章節：我怎麼開始把一次開發工作寫成 Spec → Plan → Task → 實作 的流程。Day 06 先從第一步開始：怎麼把一個改動寫成 Spec，讓它不再只是長一點的 Prompt，而是一份可以被 review 的變更範圍。

參考資料

• Anthropic. Model Context Protocol.
• Pencil. AI Integration.