使用手冊：我的專案，你的產品庫—

上週二我在找一個專案，卻想不起來聊天叫什麼名字——大概是「登陸頁面 v2」之類的，六週後看起來一樣沒用。這通常就是「我的專案」從錦上添花變成你真正會用到的工具的那一刻。生成超過三、四個應用程式之後，滾動聊天清單去找你做過的東西，速度會比應有的慢，而這個庫正是為了填補這個缺口而設計的。我先是出於習慣在搜尋欄打了「admin」，然後放棄改用篩選器：類型縮小到網頁應用程式，分類再進一步篩到內部工具與面向客戶的工具，然後就看到了——第三張卡片，版本標籤寫著 v3。我完全忘了自己回到那個聊天兩次。這個庫顯示的不是重複項目，而是版本沿革。v1 和 v2 並沒有消失，只是退出了預設檢視畫面，而這件事大約十分鐘後就變得重要，因為另一個專案的客戶不喜歡我在 v4 上線的導覽列變動。我打開舊的 v3 卡片，直接在原地瀏覽它的檔案樹，抓出兩個關鍵檔案，重新部署。不需要重新提示，也不需要在聊天紀錄裡挖掘、試圖重建版面原本的樣子。這就是卡片結構在你點開任何東西之前就已經有價值的地方：一張真實的截圖作為縮圖，是驗證通過後才擷取的，所以你看到的就是實際渲染的結果，而不是一個技術上完成但載入時出錯的專案。下面則是類型與分類標籤、版本號、相對時間戳記。足以在不點擊的情況下做初步判斷。而一旦你點開，選擇就很清楚地分成——

預覽會直接開啟即時運作中的專案，不需下載、不需本機伺服器。對網站而言就是已部署的實際體驗；對桌面或行動裝置專案而言，這幾乎是不安裝就能執行的最接近方式。
程式碼是檔案樹狀結構，直接可瀏覽。我常用這個功能做三十秒的直覺檢查——它是不是真的用了我要求的程式庫——再決定要不要下載。
操作選單涵蓋下載、發布、支援平台的原生安裝檔、符合資格時上架至商店，以及另存為範本。

以上這些都不需要重新開啟對話。那天我只回到原始聊天一次，是為了要求一個實際的變更，這也是這個庫唯一真的做不到的事——變更需要脈絡，而脈絡存在於對話串裡。其他一切，這個庫都能獨立處理，與聊天並行運作，而不是回到聊天的捷徑。從卡片發布某個專案，下次打開那個對話串時聊天會反映出來；從聊天裡發布，卡片也會同步更新。同一個專案，兩個入口。那天下午稍晚，一位同事問我要一個上週建構的東西的連結，我發現自己沒有把她導向對話——我傳的是卡片，老實說如果已經上線了，我會直接傳卡片上的發布網址。沒有人想被丟進陌生人的聊天紀錄裡去找一個檔案。一旦團隊每人有超過幾個專案，這件事就自然而然地分工：聊天仍然是你的私人工作坊，而這個庫則變成其他人真正會使用的東西。我那裡還放著一個週末專案做的遊戲，這也讓我想起這個庫並不是檢視同一批資料的唯一角度。遊戲會像其他東西一樣出現在「我的專案」裡，但它們也存在於我的遊戲，依遊玩模式與發布狀態篩選，如果你大部分做的都是遊戲，那裡會是更好的日常檢視畫面。同樣的邏輯也適用於 已發布，它顯示任何有網址或正在排隊上架的項目目前的上線狀態，以及 已上線，它追蹤應用程式商店或擴充功能商店的審核狀態。同一批卡片對應不同的問題——「現在什麼東西是上線的」相對於「我針對某個主題做過什麼」——而不是硬湊在一起的獨立系統。有件事第一次遇到時讓我有點意外：發布一個專案並不會將它凍結。我後來回到那個管理面板的聊天裡，要求了一項變更，得到了 v4——而已發布上線的版本仍然持續提供 v3，直到我明確重新部署為止。想通之後其實很合理。如果對一個上線中的聊天隨便提示就可能弄壞正式環境的網站，那就沒有人敢再碰已發布的專案了。那週我做的另一件事，幾乎是順手為之，就是把那個管理面板另存為範本。這已經是我用幾乎相同架構建構的第三個內部工具——同樣的版面、同樣的驗證框架、同樣的表格元件，底層資料不同而已。另存為範本擷取了結構與風格，而非特定內容，從它開始建構第四個專案，把原本要花二十分鐘的規劃討論縮短到大約五分鐘。問題在於範本是在你儲存的那一刻被凍結的——我的做法自那之後已經有所調整，而舊範本並不知道這件事。如果你本來就打算之後偏離這個起點，那沒問題；但如果你想要的重複使用能真正保持同步，直接跨專案參照檔案會比套用範本更好。

沒有任何東西會過期。六週前的那個 v1 版本，至今仍排在 v3 之下——依然可以預覽、下載、發布，可取用程度和今天早上剛建構完成的東西一模一樣。背後沒有在跑清理排程。這個庫是一個你可以直接拿來上架的檔案庫，不是一個你在跟時間賽跑的歷史紀錄頁面。

使用手冊

分享X LinkedIn Facebook Reddit Quora WhatsApp Telegram 電子郵件

← 所有文章

手冊：我的建置——你的產品圖庫

相關文章

BuildMidas 手冊：平台地圖

寫出能順利建置的提示詞

讀懂計畫（並加以修改）