看到 Simon Willison 9/26 分享的 Kākāpō Party，我第一個想到的不是 Claude Opus 5.5 多會生動畫，而是設計師交付 demo 時那個很熟悉的瞬間：畫面明明能跑，卻還不能放心拿去見人。

他的做法很務實。三張鳥類照片加一句 prompt，先生成至少 20 隻鳥和彩帶的 HTML5 Canvas pixel-art 動畫。要放進 Keynote 時，再請本機 Claude Code 用 Playwright 開啟 local HTML，等到第 3 秒後分散點擊，最後錄成 15 秒影片。對工程師來說，這可能只是把互動流程錄下來，對 UX 來說，這其實是在處理展示的可信度。

我在新創做設計時，最怕的不是 prototype 有 bug，而是 demo 的 bug 沒有被設計過。點擊太早，動畫還沒進狀態；點擊太集中，觀眾只看到一隻角色動；錄影時游標飄過去，大家開始看游標，不看產品。使用者體驗不只發生在產品完成之後，展示本身也是一個 user journey。

所以我現在交付互動 demo，會先跑一份自己的 preview checklist。第一，開場 3 秒內有沒有清楚的 visual cue，讓人知道這不是卡住。第二，至少測 20 個角色一起動時，畫面會不會掉幀，或某一隻鳥突然飛出畫布。第三，所有點擊的座標和時間能不能重現，不要靠現場手感。第四，最後輸出的 15 秒影片，即使靜音播放，觀眾也看得懂發生了什麼。

這幾項聽起來很像 QA，但 UX designer 在這裡做的事情不只是找錯。我要先定義觀眾應該在第 3 秒理解什麼，在第 8 秒注意什麼，15 秒結束時記住哪一個畫面。沒有這個 narrative，AI 生成的 demo 很容易變成效果堆疊，鳥很多、彩帶很多、粒子很多，但沒有人知道自己到底看了什麼。

還有一個很現實的問題是 fallback。我不會把「現場重新跑一次 AI 生成流程」當成展示方案。真正交付給 PM 或 sales 的版本，至少要有錄好的影片、固定狀態的 local HTML，必要時再準備一張 still image。因為 end user 在乎的其實不是我們用了哪個 model，而是畫面會不會在他面前突然壞掉。

以前我也會覺得，把一個會互動的 demo 錄成影片有點可惜，好像少了產品的靈魂。現在反而覺得，能不能把互動的重點剪成 15 秒，是另一種 interaction design。你必須取捨狀態、節奏和注意力，這比單純讓它跑起來更接近真正的產品工作。

AI 讓做出第一版變得很快，卻沒有自動替我們補上展示品質。從 UX 的角度來看，最後那一哩不是 polish，而是把不確定性藏在使用者不需要承擔的地方。能跑是 prototype 的門檻，能放心展示，才算交付。