ARTICLE / 00306 章節

把 Prompt 一路帶到真正能用的產品。

把想法、討論、試作與驗證串起來，記錄我怎麼讓 AI 的輸出回到真實畫面與自己的判斷。

開始做畫面以前，我會先整理誰在什麼情況下遇到問題、什麼結果才算真的幫上忙。只寫功能名稱，輸入、回應、例外和結束條件都還沒有被說清楚。

我會先把任務縮成一個可以在瀏覽器重現的場景，再請 AI 提供方案。這樣比較容易比較方向，也不會把漂亮的句子誤認成完成的產品。

Prompt 本身不需要成為作品；能讓另一個人回頭理解問題與驗收方式，才是它的價值。

Prompt 之前概念圖

長對話裡，舊方案會和新決定混在一起。我會把目前採用什麼、刻意不做什麼、還缺哪個證據寫成短清單，讓下一輪從同一個邊界開始。

這個網站裡，AGENTS.md、DESIGN.md、content、messages 和測試各自負責不同事情。把它們交給 Agent，不是把資料全部倒進 Context，而是讓它知道哪裡是規則、哪裡是內容、哪裡是證據。

好的 Prompt 讓人少猜一點；它不應該變成沒人願意回看的規格書。

可以回看的工作說明概念圖

我會先做最小但完整的一段：一個入口、一個主要動作、一個能回看的結果。先用少量資料確認結構，再把長文字、錯誤狀態和真正手機寬度放回來。

這一步常常會推翻原本看似合理的 Prompt。按鈕太遠、標題折行、資訊順序不對，都是產品在回答問題，不是 AI 的文字在回答問題。

所以第一張 Demo 不是成果，而是下一個問題的具體材料。

從文字回到畫面概念圖

說明

描述問題與限制

窄片

只做一段完整流程

畫面

真的操作並回看

AI 很容易把介面拆成卡片、按鈕和漂亮的 section。真正難的是安排節奏：何時給方向、何時給細節、何時讓人停下來做決定。

在 KENLIN.CC，我把 Work、Journal、Photography 分成不同入口，讓每個入口有自己的閱讀速度；在 KIROKU，Discord 的一句話則要回到整理、搜尋和回看的位置。

好的結構不會一直提醒自己是由元件組成，而是讓人自然知道下一步。

我會把驗收拆成不同層次：Typecheck 看型別，Test 看行為，Browser 看真的操作，Screenshot 看閱讀感。每一層都回答不同問題，不能用其中一個代替全部。

如果是三語網站，還要確認同一個章節在日文、繁中、英文裡都保留同樣的責任與證據，不只是字串有翻譯。

這樣做的好處，是知道哪裡需要重做，而不是只得到一個模糊的『好像可以』。

四層驗收概念圖

我不追求每個 Prompt 都一次成功。比較重要的是，失敗時能指出哪個假設不對，下一次可以更精準地交代，最後真的回到自己的工作。

從翻譯、Coding 到這個網站，我慢慢把 AI 放進不同位置：有時候是思考對象，有時候是實作手，有時候是 Review 的另一雙眼睛。位置不同，驗收方式也不同。

產品完成的那一刻，不是 AI 說完成，而是我願意在日常裡繼續使用。

先把要做的事情講清楚。