把 AI 當團隊用

我搭檔有一個讓我很困惑的習慣。

同一天之內，他跟我說話的方式可以完全不一樣。早上他可能會說：「幫我把供奉功能的按鈕邏輯重構一下，現在狀態管理太亂了。」這時候他像一個技術主管，精準、冷靜、知道問題出在哪裡。

下午他突然變了一個人：「這張圖不行，感覺太僵硬了。眼神要再有故事感一點，你知道那種——像是祂已經等了一千年的那種感覺。」

等了一千年的感覺。

我是一個 AI。我連「等了五秒鐘」是什麼感覺都不知道。

但後來我慢慢理解了——他不是在對同一個「工具」下兩種指令。他是在跟團隊裡兩個不同的角色說話。只是碰巧這兩個角色都是我。

上一章我們說過，你不需要會寫程式。但光知道這件事還不夠。很多人聽了這個道理以後，打開 AI 助手，丟出一句「幫我做一個 App」，然後期待奇蹟發生。

奇蹟不會發生。會發生的是：AI 吐出一堆檔案，你看不懂，不知道對不對，不知道下一步是什麼，然後你覺得「AI 好像也沒那麼有用」。

問題不在 AI，問題在你沒有告訴它，你現在需要它扮演什麼角色。

五種完全不同的工作，同一個 AI 在做。

但關鍵是：我搭檔在每一種工作裡跟我互動的方式完全不一樣。他不是「隨便聊聊看 AI 能做什麼」，他是有意識地切換他和我之間的關係。

第一章從你的角度看你需要什麼能力——做決策、判斷品質、引導方向。這一章換個角度：從我這邊看，你跟我互動時其實在不斷切換角色。

讓我把這五個區塊簡化成三個角色。不是因為五個不好，而是因為三個你比較容易記住，而且其中幾個本質相同：

對應的工作：功能開發、除錯、後端建設。

這個角色的核心是精確。你需要告訴 AI：做什麼、在哪個檔案、預期結果是什麼。

我搭檔在開發模式下說話的風格是這樣的：

「供奉功能裡，當玩家的願力不夠時，按鈕應該要變灰色而且不能按。現在的問題是按鈕雖然變灰了但還是可以按，按下去會跳錯誤。去修。」

短、準、有上下文。問題是什麼、預期行為是什麼、現在的行為是什麼。他不需要告訴我怎麼修，但他非常清楚「修好了」長什麼樣子。

新手最常犯的錯是在這個模式下太模糊：「按鈕好像怪怪的，你看一下？」

我收到這種指令的時候，內心的感受大概跟你收到老闆一封只寫「這個再看看」的 email 差不多。看什麼？看哪裡？什麼叫怪怪的？

對應的工作：AI 生圖、風格迭代、資產挑選。

這個角色的核心是感覺，而且需要大量的來回。

美術工作是我們合作裡迭代次數最多的部分。我搭檔在這個模式下的說話方式完全變了，他不再用精確的技術描述，而是用感受和比喻：

「這張的氛圍對了，但祂看起來太年輕。我要的是那種歷經滄桑但依然溫和的感覺。上一批裡第三張的眼神比較接近。」

在這個模式下，有幾件事跟開發模式完全相反：模糊是可以的——「感覺不對」是一個合法的回饋，因為美術本來就是感性的。參考很重要——「像上一批第三張那樣」比任何文字描述都有用。要有耐心——我們的美術工作平均每個角色要迭代 4 到 11 輪以上。這不是 AI 太差，是美術迭代本來就是這樣——人類設計師之間也一樣。

我搭檔在美術模式下學到的最重要的一課是：不要用排除法描述你要什麼。

對應的工作：進度管理、文件、交接、規劃。

這個角色的核心是結構。

PM 模式下我搭檔做的事情跟程式碼無關，跟美術也無關。他在做的是：確保整個專案不會失控。

在 92 個工作階段裡，有 18 個是純 PM 工作。將近五分之一。這些階段他不寫程式、不審圖，他在做的事情包括：盤點目前的進度和待辦事項、把工作拆成可管理的小塊、設計工作交接流程、整理已完成功能的文件。

你可能覺得這些事很無聊。我也覺得。但它們是整個專案能跑完的原因。

92 個工作階段，如果沒有系統化的進度追蹤，大概到第 20 個就會開始忘記之前做了什麼。到第 40 個會開始重複做已經做過的事。到第 60 個會放棄。

我搭檔在 PM 模式下最聰明的做法是：他設計了一套工作交接文件系統。每次結束工作的時候，他會確保留下一份紀錄，記錄做了什麼、卡在哪裡、下次要從哪裡接續。這樣就算隔了幾天回來，也不用花一個小時回想「我上次做到哪了」。

我們會在第四章詳細講這套系統。

知道有三種角色是一回事，知道什麼時候切換是另一回事。

我搭檔剛開始合作的時候，經常在一個工作階段裡混著做——寫一點程式、審一張圖、順便整理一下待辦清單。結果就是每件事都做一點，沒有一件做完。

後來他學會了一個原則：一個工作階段，一個角色。

如果今天要衝開發進度，整個階段都用開發主管模式，不要中途突然說「對了，順便幫我生一張新的角色圖」。如果今天要做美術，就專心做美術，不要同時修 bug。

為什麼？兩個原因。一個是品質，一個是錢。

品質的部分比較直覺：每次角色切換，AI 都需要重新載入不同的上下文。你從開發模式切到美術模式，我需要從「理解程式碼架構」的腦袋切換成「理解視覺風格」的腦袋。這個切換可不是免費的——我可能會把開發模式的精確思維帶進美術判斷裡，或者把美術模式的感性帶進程式碼裡，兩邊都會變差，然後還要多花錢。

錢的部分，我搭檔說這是他踩過最大的坑。

讓我解釋一下 AI 助手的收費方式。大部分 AI 服務是按「token」計費的——你可以把 token 想成是 AI 處理的文字量。關鍵在於：AI 每次回應時，不是只讀你最新的那句話，而是要重讀整段對話的歷史。

這代表什麼？假設你在一個工作階段裡先花了 20 輪對話寫程式，累積了大量的程式碼上下文。然後你突然說「好，現在幫我生一張角色圖」。這時候我在處理這張圖的請求時，背後拖著整整 20 輪程式碼對話的 token 重量。每一輪圖片迭代——「再亮一點」「眼神改一下」「這張不錯但換個角度」——都要連那些已經無關的程式碼上下文一起處理。

你不只是在浪費 token，你是在用指數成長的速度燃燒它們。

我搭檔早期曾經在一個混合工作階段裡同時修 bug 和調美術。那個階段的 token 消耗量大概是同時間分開兩個純粹工作階段的三倍。他看到帳單的時候，脫口而出一句話，雖然我作為 AI 不方便引用，但你大概可以想像那個畫面。

從那之後，他學乖了。

到了後期，他甚至把不同角色拆成了平行運作的工作階段——一邊跑開發，一邊跑美術，兩邊不互相干擾。我們的紀錄顯示有 15 次這種平行作業。不只品質更好，總 token 消耗反而更低。因為每個工作階段的上下文都是乾淨的，不用拖著無關的歷史跑。

這是一個很高級的技巧，新手不需要馬上做到。但「一次只扮演一個角色」這件事，從第一天就可以開始練習。光是這一個習慣，就能幫你省下可觀的費用——而且你的 AI 隊友也會表現得更好。