可以少做，但不能亂做

三個多禮拜裡，我完成了兩套系統，並且讓它們正式上線。這句話單獨看起來很像一段適合拿來總結效率的成績，但實際情況沒有那麼俐落：我白天仍然有八小時的全職工作，能用的時間散在工作以外的空檔裡。它不是一段可以全心投入、每天穩定推進的開發期，而是一段不斷重新進入狀況，再把手上的一小塊往前推的過程。

我在這兩個專案裡承接的範圍很廣。從理解一個還沒有被完整寫下來的需求開始，把它轉成產品流程，接著處理介面、資料結構、權限設計、程式實作與部署。範圍廣不代表每一部分都做得同樣深入，而是每一部分的決定最後都會互相牽動，我必須讓它們至少能在同一套邏輯裡運作。

兩套系統，處理的是同一個問題

第一套可以把它稱為「共筆地圖系統」。任何人都能在公開頁面瀏覽互動地圖；會員可以投稿故事或設定，把內容放到地圖上的特定位置；管理者則需要維護資料、審核投稿，決定哪些內容可以被公開看見。

第二套是「視角式知識庫」。同一個世界裡，不同角色知道的事情並不相同。讀者要依照自己所處的角色視角與目前的解鎖狀態，讀到同一份世界設定的不同部分；管理端則負責維護內容、安排資訊出現的條件，避免讀者提前取得不該知道的資訊。

表面上，一套在處理地圖與投稿，另一套在處理知識與閱讀權限；但我實際面對的核心很接近：不同身分看見什麼、可以做什麼，以及哪些資訊絕對不能出現在他面前。

我想做的不是功能很多的第一版

這個問題直接決定了我怎麼劃第一版的骨架。共筆地圖不是先做一個可以拖曳、點擊的畫面就算完成，而是從第一版就分開公開瀏覽、登入後投稿，以及管理者維護與審核三種使用方式。視角式知識庫也不是把全部資料送到畫面，再把不該出現的部分藏起來；我得先決定每個角色依照視角與解鎖狀態可以取得哪些內容，從資料離開系統之前就守住界線。

我並不排斥 MVP。相反地，在時間有限的前提下，縮小範圍幾乎是必要的。只是我希望拿給團隊操作的 Demo 已經相對成熟，可以成為下一輪迭代的起點。對我來說，成熟不是功能很多，也不是畫面沒有缺點，而是主要流程能走完，資料、權限與規格沒有各自往不同方向生長。可以少做，但不能亂做。

把身分和資訊邊界先切清楚，不會讓 Demo 第一眼看起來多出什麼功能，卻決定了它能不能繼續往下改。若第一版只顧著讓畫面動起來，之後才補這些界線，新增功能時很容易變成替原本的混亂再加一層例外。這樣的骨架不保證方向一定正確，但至少讓後續修改有清楚的起點。

做得出來，不等於一開始就想得準

團隊實際操作之後，給了回饋，也提出原先沒有出現在需求裡的想像。這些回饋之所以有用，是因為大家面對的是一個可以點、可以走流程、可以看出限制的東西，而不只是抽象地討論「希望未來有什麼功能」。可操作的 Demo 讓討論有了共同的對象。一個很具體的落差，是共筆地圖原本朝整體封閉的方向規劃，後來才重新拆開閱讀與參與的邊界。這不只是把入口打開；哪些資料可以公開、哪些操作需要身分，都要跟著重新劃定。

但我不能倒過來把這件事說成「需求都有先釐清」。第一版主要仍建立在我對需求的想像上。我把零散資訊轉成自己認為合理的結構，再用這個結構做出可操作的版本。實際使用後，主要流程大致符合需求，核心方向沒有被推翻，但仍有需要修改的地方與額外建議。這裡面有我推演需求的能力，也有剛好猜中的運氣。它提醒我：做出一個結構完整的版本，和確認這個版本真正對應團隊的工作方式，是兩件不同的事。

這次重新劃界，也讓我直接碰到成熟 Demo 的代價：先前做好的資料和操作邊界必須一起調整，不只是換一句說明或多開一個入口。完成度越高，產品邊界改變時牽動的範圍也可能越大。這是我現在還不能用一句「先做再說」或「先把需求問完」解掉的拉扯。

AI 讓產出變快，也讓偏差變快

這兩套系統能在這段時間裡上線，AI 參與了大量工作，包括整理需求、協助實作與除錯。當我能把需求、規格或 bug 說清楚時，我會先定義要解決的問題、選擇解法並做關鍵決定，再把其餘可拆解的工作交給 AI 協助。這讓我能在零碎時間裡延續進度，不必每次都親手完成所有細節。

最明顯的摩擦也出現在資訊邊界上。如果我只給出「不同的人看到不同內容」這句要求，AI 可以很快做出看起來有所區分的畫面，卻無法替我決定哪些資料根本不該送到這個使用者手上。我要重新把角色、可讀資訊與允許操作的界線說清楚，它才有辦法把權限落在正確的位置，而不是只處理畫面上看不看得見。

但 AI 放大的不只有產出。方向錯了，它也會很快做出一套沿著錯誤前提展開的東西；問題沒有界定好，它可以在局部反覆修補，讓人以為一直在前進；產出增加之後，需要閱讀、驗證與整合的內容也跟著增加。它會放大我鑽牛角尖的速度，也會把原本藏在一句模糊描述裡的錯誤，擴張成跨越好幾個層次的修改成本。

所以這次真正節省時間的，不只是讓 AI 寫得更快，而是我能不能在有限的注意力裡，判斷現在該定義什麼、哪些決定不能外包，以及什麼時候應該停下來重新描述問題。這部分沒有因為工具變強就消失，反而變得更重要。

還沒有整理成方法論的結尾

三個多禮拜完成兩套正式上線的系統，對我來說是一個具體結果，但我不想把它包裝成一套可以複製的成功方法。它證明我能在限制裡把事情推到可用，也讓我看見這套做法仍有很多地方靠我一個人判斷與承擔；這次核心方向大致猜對，其中也有運氣。

我還在摸索的，是怎麼在下班後有限而破碎的時間裡，更早和團隊對齊需求，又維持第一版應有的結構品質；怎麼讓回饋提早發生，卻不為此增加一套自己承受不了的會議、文件與流程負擔。

要怎麼在「早點確認方向」和「先做出足以被操作的東西」之間找到可持續的節奏，我還沒有答案。這不是一個漂亮的結論，但它是我做完這兩套系統之後，最需要繼續處理的問題。