原型債是什麼，跟一般所說的「原型還不夠完美」有什麼不同？
原型債指的不是「這個原型看起來不夠精緻」這種表面問題，而是一種累積性的隱性成本：為了快速交出可視化成果，在缺乏足夠脈絡的情況下做出的設計決策，短期內滿足了「先做出東西來」的需求，但這些決策彼此之間沒有經過協調，會在之後需要修改、擴充、或整合這些畫面時，變成需要額外時間去理解與收拾的負擔。
這跟「原型不夠精緻」是兩個維度的問題。一個原型可以視覺上很精緻、但同時背負著很重的原型債（例如每個畫面各自處理登入邏輯，彼此互不相同）；也可以視覺上粗糙、但幾乎沒有原型債（例如整批畫面共用同一套元件與命名邏輯，即使外觀簡陋，之後要擴充也很容易）。原型債關注的是「這些設計決策彼此協調嗎」，不是「這個畫面好不好看」。
為什麼原型債會在 AI 生成工具普及後變得特別明顯？
核心原因是生成一個「看起來完整」的畫面所需的時間被大幅壓縮，但「確保這個畫面跟其他畫面協調一致」所需的時間並沒有跟著壓縮。傳統手動設計流程裡，設計師在畫第二十個畫面之前，通常已經自然而然建立起對整個系統的心智模型（這個元件我在哪裡用過、這個互動模式在別的地方是怎麼處理的），因為畫每個畫面本身就花了足夠的時間，讓這種累積自然發生。
AI 生成工具把「畫一個畫面」的時間壓縮到接近零，但工具本身通常沒有被要求，也沒有能力在生成第二十個畫面時，回頭確認前面十九個畫面是怎麼處理類似情境的——除非使用者主動把設計系統或既有規則餵給它作為參照。這代表生成速度提升的同時，「協調一致」這件事所需要的心力並沒有跟著自動被工具吸收，反而變成一個容易被忽略的隱性任務，落到後續維護的人身上。
原型債累積起來，實際上會呈現出什麼具體樣貌？
參照工程端技術債的典型演變模式，原型債的累積通常有一個可辨識的時間軸。初期（原型生成完成後不久），一切看起來正常：畫面能點擊、能拿去簡報、利害關係人反應正面。中期（開始要修改或擴充某個看似很小的功能時），第一個訊號會出現——原本以為只是小調整，結果發現同一個功能背後其實有好幾種略微不同的實作方式分散在不同畫面裡，因為每次生成新畫面時，都是重新猜一次邏輯，而不是延用前面已經確立的規則。到了後期，如果沒有處理，這種不一致會擴大成一種模式：新功能要花的時間遠超預期，因為每次改動都要先花時間搞清楚「這次要改的邏輯，跟另外三個地方類似但不完全相同的邏輯，到底哪個才是對的」。
具體徵兆包括：同一個互動模式（例如下拉選單、表單驗證提示）在不同畫面上長得不太一樣；同一份資料在不同畫面被賦予不同的命名；新加入團隊的人問「這個畫面的邏輯是根據什麼決定的」，得到的答案是「不確定，這是當時生成出來的」。
身為使用者，我要怎麼判斷自己現在做的原型，值不值得花額外時間去處理原型債？
最關鍵的判斷標準是這批原型接下來的用途。如果目的是驗證一個概念、跑一次性的使用者訪談、或是拿去做一次性的提案簡報，用完就會丟棄或整批重做，那麼原型債幾乎不需要在意——這正是 AI 生成工具最擅長、也最划算的使用情境，花額外時間去統一設計系統反而是浪費，因為這批原型本來就不打算被長期維護。
但如果這批原型有機會演變成後續要持續疊加功能的產品雛型（例如通過內部驗證後就要直接開始接工程、或是準備拿給開發團隊當作實作依據），值得在數量還不大的早期階段，先花時間確認生成流程裡有沒有匯入設計系統或至少一套共用元件規則，讓後續每一次生成都能參照前面已經定案的規則，而不是每次都重新猜一次。判斷的分水嶺不是「這個原型看起來多正式」，而是「這批東西之後還會不會有人在它的基礎上繼續蓋東西」。
「原型債」（prototype debt）指的是為了快速交出一個可視化成果，在壓力下做出脈絡不足、樣板化設計，短期內滿足了眼前需求，卻在之後為設計與工程團隊留下一連串問題與返工的隱性成本。這個詞本身還不算主流，但它描述的現象在 AI 生成工具普及之後變得格外明顯——當生成一個看起來完整的畫面只需要十分鐘，「先做出來再說」的誘惑會壓過「先想清楚再做」的紀律，而代價通常不會馬上出現，會累積到後面才一次爆發。
這個概念其實是「技術債」（technical debt）在設計端的對應版本。技術債這個詞由 Ward Cunningham 在 1992 年提出，維基百科的條目本身就把它跟「設計債」列為同義詞，指出這是選擇權宜方案换取短期開發速度、卻可能在未來墊高維護成本的現象。原型債的邏輯完全一樣，只是發生在設計決策層，而不是程式碼層。
雖然目前還沒有專門針對「AI 生成原型後續代價」的大規模量化研究，但同一種現象在工程端已經有紮實的數據可以參照，邏輯上高度可類比。一份分析 810 萬筆 pull request 的大型研究發現，採用 AI 編碼工具後，技術債成長了 30% 到 41%；GitClear 對超過 2 億行程式碼的分析則發現，重複邏輯的比例從 2021 年的 8.3% 成長到 2024 年的 12.3%，這段期間正好是 AI 編碼工具開始普及的時間點。這些數字量化的雖然是程式碼層面的現象，但背後的機制——為了立即可用而生成的內容，彼此之間缺乏協調——跟原型債描述的設計現象是同一件事的兩種呈現形式。
參考工程端技術債的時程模式，這類代價通常不是立刻出現的。剛生成完的原型，畫面看起來完整、可以點擊、能拿去做簡報，短期內一切正常。真正開始出現摩擦的時間點，通常是在後續需要「改一個看似很小的東西」的時候：例如要調整一個表單流程，才發現這個流程背後其實有三種畫面各自處理著同一件事、彼此邏輯不一致，因為每次生成新畫面時，AI 都是憑當下的提示詞重新猜一次邏輯，沒有意識到之前已經生成過類似的東西。工程端的對應現象是「同一個驗證函式在三個檔案裡各自存在、彼此略有差異」，設計端的對應現象則是「同一個互動模式在不同畫面上有三種略微不同的實作方式」。
原型債難以被及早發現的核心原因，是它跟效率提升在早期階段的表徵完全一樣：交付速度變快、看起來產出更多。真正的差別要到後續維護與擴充階段才會顯現——當團隊要在原本快速生成的一批畫面基礎上疊加新功能時，才會發現每個畫面背後的假設、命名邏輯、互動規則都不一致，整合這些不一致所花的時間，很可能超過當初直接用傳統方式從頭設計所省下的時間。這也是為什麼「原型债」是一個需要主動去問、而不會自己跳出來提醒你的東西——沒有人會在生成第十個畫面的時候意識到，自己正在往後面的自己身上疊加一筆帳單。
如果你正在用 AI 設計工具快速產出大量原型畫面，一個實務上可行的自我檢查方式，是在專案進行到一定量之後，回頭審視這些畫面之間是否有共用的命名邏輯與互動規則，而不是每個畫面各自獨立生成、看起來能用就算了。如果你是要拿原型去驗證概念、跑一次性的使用者測試、之後就會丟棄，原型債幾乎不需要在意，這正是 AI 生成工具最適合的場景；但如果這批原型有機會演變成之後要疊加功能的正式產品雛型，值得在早期就花一點額外時間，把設計系統或至少一套共用的元件規則匯入生成流程，這筆早期投入的時間成本，通常遠低於後期為了解決不一致而付出的返工成本。