一開始我一直在修 prompt。後來才發現是狀態設計沒做好
這兩週我一直在整理一條 AI 協作的設計 workflow，本來以為卡住的點會是 prompt 不夠準，或 UI 上的操作太碎。結果跑久了才發現，最容易把整條流程搞亂的，根本不是輸出品質，是 state 沒有被好好設計。
我最近有一條 12 個節點的流程，會在 Figma 產 variant、把 copy 丟去另一個 agent 修語氣、再把 handoff note 寫回 Notion。前面幾次看起來都正常，直到有一次同一個 component spec 被兩個 agent 同時改。畫面沒有壞，檔案也沒有 crash，但第三天開始整份設計稿的 decision 慢慢歪掉，連 CTA 文案都回到舊版本，超難抓 🙄
後來我把 shared state 拆開，只留一份 job_state.json 當主版本，裡面硬塞三個欄位：decision_owner、updated_at、resume_from。每次 agent 要改 durable decision，先寫自己名字和 timestamp，handoff 前再補 resume point。很土，但真的有差。原本一條 flow 平均要手動補 6 次交接，現在剩 2 次。中途掛掉之後，最多重跑一個節點，不會整段重來。
我看 Reddit 上有人提到 14 個 agents 協作，plugin 做完之後 handoff 從 minutes 變 seconds，我超有感。因為當流程開始變長，速度根本不是最先痛的。最先痛的是每個介面都覺得自己知道現在做到哪裡，最後沒有人真的知道。Figma 裡一份、文件裡一份、agent note 又一份，這種狀態在 UI 上看起來很完整，其實只是假的完整 ✨
所以我現在反而會先畫 state flow，再畫 wireframe。先定義什麼資訊可以被覆蓋，什麼一定要 lock，哪一段失敗後要從哪裡 resume。prompt 之後再修都還來得及，state 一亂，後面每一次 iteration 都是在替之前的混亂付利息。
如果你也在做多 agent workflow，我會很推薦先不要急著加更多功能。先把主版本放哪裡、誰能改、掛掉後從哪裡接回來，這三件事寫清楚。design system 要有 source of truth，agent workflow 其實也一樣。
作者：Wendy 林