一個新功能，
從設計到手機上的旅程

平常的日子：養成一個習慣就好

沒有新功能的日子，設計師只需要記住一件事——要用任何元件之前，先查目錄。打開 Storybook，找到你要的直接用。找不到？先和 AI 說「我需要一個長這樣的東西」，AI 會幫你比對目錄裡有沒有很相似的既有元件。真的沒有，才走正式程序新增一顆。

• 設計師用任何元件前先查目錄；找不到先問 AI「有沒有相似的」，不要直接畫一顆新的。
• AI比對目錄，回報「其實已經有了」還是「真的是新零件」。
• 工程師照常維護 App。改到哪一頁，順手把那頁換上目錄的正式零件（觸碰即換，不搞大工程）。

提醒：這一站沒有交付物，但它是整條管線最重要的習慣——重複的零件只要停止增加，後面每一站都會變輕鬆。

新功能誕生：長出可以點的 Demo

流程像這樣：和 AI 討論需求（像跟同事聊天，把「這功能給誰用、解決什麼問題、有哪些畫面」講清楚）→ AI 用目錄零件組出畫面，你負責看和改 → 產出一個可以點的 Demo，老闆、同事、工程師都能用瀏覽器打開試玩。全程不寫一行程式。

• 設計師和 AI 聊清楚給誰用、解決什麼問題；看畫面、下修改指令、把關視覺品質。
• AI把討論整理成需求文件、用目錄零件組出每一頁、自動生成七份交接文件。
• 工程師（可選）先試玩 Demo、提前給意見——愈早講，改起來愈便宜。

提醒：Demo 用的是示範資料，這是刻意的——先把「長什麼樣、怎麼流動」定下來，真資料是之後工程的事。

實際例子：「股利日曆」聊了兩個下午，AI 用目錄裡的「股票日曆」「事件列表」「篩選彈窗」組出四個畫面，改了三輪細節，產出可點的 Demo 和七份文件——全程沒有人打開設計軟體重畫任何一顆按鈕。

交接日：只給工程師三樣東西

交接不是開會傳話，是寄一個包裹。包裹裡固定只有三樣東西——寫不進包裹的需求，視同不存在。

• 設計師確認七份文件齊全、說明書上寫明目標是 App（Target Surfaces），然後按下「打包定版」。
• AI為用到的每顆零件產出工程規格書（平台中立，iOS / Android 都讀得懂）。
• 工程師收到三樣東西後開工。用和目錄一一對應的原生零件組 App，不是憑印象重刻。

提醒：工程規格書是規格，不是連線。Storybook 裡的按鈕不會遠端控制 App 裡的按鈕——它描述的是「這顆零件該有哪些尺寸、狀態、行為」，工程端照著用平台最好的方式實作。細節看 native-design-contracts.html。

背後的指令：npm run contracts:native-spike（產出平台中立的元件與 token 規格）　·　定版檢查：validate_prototype.py --handoff-ready（章蓋了才會過；通過時寫下版本戳記 HANDOFF_MANIFEST.json）

交接之後：用勘誤單溝通，不用來回開會

工程端照說明書組 App——自己動手，或讓自己的 AI 用 /native-product-implementation 接棒：AI 會先確認章蓋了、讀懂目標是 iOS 還是 Android、用目錄對應的原生零件組畫面，先以示範資料把整個流程在模擬器走通；真資料是下一棒（/production-data-integration）的事。實作時一定會發現對不上的地方——「這個顏色目錄查不到」「這顆元件缺一個狀態」。不是打電話吵，而是開一張勘誤單：一張單寫一個問題，附截圖、寫清楚「預期 vs 實際」。設計師收單、修正目錄、出小版本，工程師更新後關單。半年後有人問「當初為什麼這樣改」，翻單子就知道。

• AI接棒時先看章、看平台；用原生零件組畫面、跑示範資料走完流程；缺零件或缺 token 停下來問，不自己刻。真資料不接，留好接縫給下一棒。
• 工程師對不上就開勘誤單，一張單一個問題、附截圖。把關手勢、無障礙這類手機平台行為——那是你的專業，分工表白紙黑字寫好了。
• 設計師收單 → 修正目錄 → 出小版本更新。有未關的單子，那顆元件就不算「工程可用」。

提醒：最後驗收很直觀——把工程師做出來的真機截圖，和 Storybook 的畫面並排比對，像對印刷打樣，對得上就過。

背後的指令：/native-product-implementation（組 App，示範資料）→ /production-data-integration（接真資料）。兩支的輸入、把關與地雷寫在 docs/workflows/product-feature.md 的〈階段 3〉〈階段 4〉，web 與 App 共用同一份說明。