BuildMidas 手冊：平台地圖

讓我帶你走過一個真實的帳號，從頭到尾，而不是逐項描述側邊欄。假設是一位自由接案者，在平台上的第一週，正在為一個小型客戶建構習慣追蹤應用程式。以下是這個專案在儀表板中移動的過程，依實際發生的順序——以及每一站分別是幫上了忙還是浪費了五分鐘。

提示

他們打開AI 建構器，輸入了類似「幫我做一個習慣追蹤器」的內容。這是一個合理的第一句話，卻是一個糟糕的最終提示。回傳的不是程式碼——而是一份用白話文寫成的計畫，如果你讀到「看起來還可以」就停下來、點下核准，得到的東西在字面上確實回應了「習慣追蹤器」這幾個字，但在其他所有重要層面都是通用的。這位自由接案者的客戶不要社群功能、只要本機儲存、預設要是深色模式。這些都沒有出現在第一個提示裡。它們反而在核准前以三次編輯的方式加進計畫：刪掉計畫自己發明的「分享你的連續紀錄」功能，換掉儲存方式那一行，把預設主題改成深色。三十秒的編輯。最後產出的專案就會符合需求，而不只是符合「習慣追蹤器」這幾個字。

大家常常跳過的計畫步驟

我見過其他使用者在這一刻栽跟頭——沒讀就核准第一份計畫，三次迭代後才發現自己在重複解釋本該在計畫階段就設定好的限制條件。計畫這一步存在的意義正是為了避免這種情況。它幾乎不花什麼成本，卻是整個流程中唯一能用你自己的語言與代理協商，而不是事後在程式碼裡除錯它輸出結果的環節。

建構成果實際落在哪裡

一旦生成完成，習慣追蹤器就會以卡片形式出現在我的建構——這個資源庫頁面可依類型篩選，也是這位接案者在累積五、六個建構專案後，第三週開始會最常打開的頁面。它不會出現在展示區；那個頁面是人工精選、不會自動列入的，而客戶專案未經公開發布，這正是正確的預設狀態。它也不會出現在範本中，除非接案者主動想到要把它存為範本——這裡其實很值得這麼做，因為習慣追蹤器的骨架正是接案者未來替下一位客戶套用不同品牌重建時會用到的東西。大多數人要到第六個建構專案才會發現「另存為範本」這個功能，並懊悔沒在第一個專案就這麼做。

已發布，或更進一步的部署

接下來是發布方式的問題。這裡有三個真正的選項，而不是同一個選項掛三個名字。已發布提供免費子網域，幾秒內即可上線、零設定——在客戶仍在審閱、可能要求重新設計的階段，這是正確的選擇。網域管理則適用於客戶自己的網域已準備好可以指向此建構專案的情況，而這一步還有另一個作用：在此連接網域不只是變更網址，也讓側邊欄下方的分析頁面有東西可以掛載。部署位於設定中，是當客戶堅持建構專案必須架設在他們自行掌控的基礎設施上時所用的 SFTP 路徑——設定較繁瑣，且接案者將不再擁有正常運作時間的保障，這是一個值得明確討論、而非意外發現的取捨。

就這個建構專案而言，先選擇「已發布」。日後從子網域轉為自訂網域是輕而易舉的事。反過來，若客戶專案被取消，要撤銷自訂網域的部署，善後工作遠比其價值來得麻煩——事實上，這位接案者就在先前的專案上為此吃過虧，這正是「預設選擇已發布」這個習慣的由來。

上架應用程式商店的插曲

這位客戶還想要在應用程式商店上架，因此這個建構專案會經過發布上架頁面，而不是止步於「已發布」——這個頁面之所以存在，是因為商店審核的非同步性質是網頁部署完全不會遇到的。提交到某個商店可能要等上兩天；提交到另一個商店可能二十分鐘內就通過。「發布上架」讓你不必開五個瀏覽器分頁、對應五個不同的商店後台，各自有自己的登入方式和狀態用語，就能追蹤這一切。

沒人事先提醒的空白頁面

網域連接一週後，接案者打開搜尋成效來查看狀況。結果是空的，看起來還有點淒涼——沒有圖表、沒有數字，只有一個要求連接帳戶的提示。這並非故障，而是誠實的呈現：目前還沒有資料，因為搜尋成效、Google Analytics和商店分析都仰賴設定中的 Google 帳戶連接，而且都不會回溯補齊資料。同步只會從連接的那一刻起向前計算。第一天就連接網域，到第二週就有一週的歷史資料；因為忘記而拖到第十天才連接，第十天當天就得從零開始。這位接案者連接了網域，卻沒連接 Google 帳戶——這是看似該合而為一、實則分開的兩個步驟。

這裡真正付出代價的不是那張缺失的圖表，而是最佳化代理也是讀取這同一份資料——若要求代理在毫無搜尋成效歷史資料的情況下提升某頁面的排名，它只能依據一般最佳實務，而非這個網站的實際數據來運作。跳過這項連接不只是讓某個儀表板頁面留白，更限縮了代理能發揮的能力上限。

無需開口就自動出現的簡報

兩週後，機會探索出現一張卡片：一份標記出客戶網站內容缺口的機會簡報，並附有「建構此專案」按鈕。當它剛好命中你本來就會採取行動的方向時，確實非常有用。但「機會探索」在設計上本就偏向數量多於精準——產出的簡報比任何人能實際採用的都多——所以正確的心態是把它當成建議收件匣，而不是要清空的待辦佇列。這位接案者每隔幾天瀏覽一次，大部分都略過不理，這正是預期的使用方式，而非跟不上進度的失敗。

早該在第一天就處理好的設定

走到這一步，接案者已經動用了四個設定頁面，卻從未主動打開過設定選單——每一次都是因為別的東西是空白的才被發現。

Google 帳戶是最值得提前設定的一項。它是三個獨立儀表板頁面背後共用的單一連接點，靠親身踩雷才發現這件事——三個不同的空白頁面、三次「哦，原來我要先連接東西」的瞬間——正是第一天花五分鐘完成設定就能避免的摩擦。

自始至終都在那裡的兩樣東西

浮動的詢問 AI按鈕從頭到尾都在這些頁面上，而它並非一個功能受限的常見問答機器人——它能代替你連接帳戶、啟動建構專案，或解釋某個頁面為何是空白的。這位接案者的客戶不諳英語，需要在通話審閱時把整個介面切換成其他語言；導覽列上的地球圖示可即時切換全部二十種語言，且不會中斷正在進行中的建構。這兩者都不需要像本篇其他內容那樣靠嘗試才能發現——它們本來就一直在那裡。

這正是整個帳戶前兩週最誠實的總結——不是「先讀文件，再開始建構」，而是反過來。在有卡片出現之前，「我的建構」只是個抽象概念；在有網域餵入資料之前，「搜尋成效」只是個空白狀態。在做第一個建構專案前先讀懂整體架構固然有幫助，但唯有等某個真正的習慣追蹤器落在其中某處，這張架構圖才真正有意義。