AI 時代的原型開發速度：速度、願景與執行成本

多年來，軟體原型開發的主要瓶頸一直是「無聊的部分」——即將一個想法從心理概念轉化為具體概念驗證（proof-of-concept）所需的腳手架、佈線和重複性的樣板代碼。對於許多開發者來說，這種摩擦意味著許多有前景的想法僅僅停留在筆記或被遺棄的分支中。

然而，AI 編碼代理（coding agents）的出現從根本上改變了這種動態。從「我想知道是否...」到「它可行」的轉變已大幅加速，這不僅改變了開發速度，也改變了工程工作的本質。這種轉變帶來了生產力的強大提升，但也引入了速度與技術精通度之間的關鍵緊張關係。

速度的飛躍：從想法到 Repos

當腳手架的成本趨近於零時，開發者的產出可以呈指數級增長。在實踐中，這表現為已完成原型開發的激增。以前會被歸類為「好主意，但沒時間」的項目——例如自定義系統語言、符號語言或專用的 CLI 工具——現在可以在一個下午內實現。

這種速度的提升是可量化的。一些開發者報告稱，以 time-to-PR 為衡量標準，他們在日常工程任務中的速度大約快了 4 倍。這種餘裕讓工程師能夠處理經常被忽視的「隱形」工作，例如優化內部啟動時間或建立自動化工具來支持其他團隊成員。其結果是開發者影響範圍的擴張：他們不再僅僅是完成分配的任務，而是在積極改善周圍的生態系統。

工程思維模式的轉變

除了純粹的速度，AI 正在改變工程的「形狀」。當開發者不再需要輸入每一行代碼時，其角色從戰術家轉變為架構師。重點轉向：

定義邊界與合約： 從整體層面規劃各個組件如何銜接。
指定成功標準： 編寫提示詞（prompts）和規格說明（specs），以足夠的精確度描述預期結果，使代理（或初級工程師）能夠獨立執行。
抽象問題框架： 在深入研究「如何做」之前，花更多時間在「做什麼」和「為什麼做」。

這種演進鍛鍊了一套不同的專業能力——委派、願景分享和對失效點的預判——這些能力在管理人類與管理 LLM 時同樣具有價值。

高速開發的隱藏成本

儘管有所進展，但「AI 原型開發時代」並非沒有顯著的權衡。最直接的擔憂是技術熟練度的侵蝕。當工具處理了實作細節時，存在著失去從除錯器（debugger）或閱讀源代碼中獲得的深層、直覺性理解的風險。

「Slop」的風險與品味的喪失

社群討論強調了一個日益增長的擔憂：廉價的執行會導致「垃圾」軟體的激增。當原型開發的成本為零時，錯誤想法的進入門檻也隨之消失。

"The space of possible solutions got a lot bigger. Unless you have good taste you could wander and get lost very quickly in this vast new expanse... A novice will get into trouble faster."

存在一種危險，即原型開發的速度超過了用戶研究的速度。如果一個原型可以在一小時內建成，人們很容易會傾向於跳過與實際用戶驗證想法的關鍵過程，從而導致產品在技術上可行，但在 UX 或實用性方面存在根本缺陷。

所有權差距

另一個關鍵挑戰是「所有權差距」。與其說是寫出來的，不如說是生成的代碼通常更難維護和推理。一些工程師已採用混合工作流來應對這一點：使用代理來探索可能的解決方案並快速迭代，然後將這些更改還原，再親手實作最終方案。這確保了開發者對系統中非平凡（non-trivial）的部分保持完全的所有權和理解。

平衡速度與理智

為了在這個新環境中航行，最成功的方法似乎是對 AI 輔助的速度與手動的嚴謹性進行刻意的平衡。這包括：

刻意的手動工作： 撥出時間親手端到端地實作功能，以保持技術技能的敏銳度。
優先考慮品味而非工具： 意識到雖然 AI 可以執行，但它無法提供從多年解決現實世界客戶問題中獲得的「痛苦的智慧」。
使用 AI 進行探索，而不僅僅是執行： 利用代理來快速測試多個假設，但保持作為架構的最終仲裁者。

隨著由於創作的便利性，自定義應用程式的價值可能下降，工程師的差異化優勢將不再是「建立」原型的能力，我們將不再看重誰能建好一個原型，而是看誰能辨別「哪些」原型值得建立。