一、專案的真實推進歷程
一個專案的起點，通常只是一個模糊的初步想法。沒有完整規格書，沒有詳細設計，就這樣開始了。
從那個模糊的起點，工程推進的節奏大致是這樣走的：
整個過程需要大量的持續觀察、監工、推進，以及心力投入。這不是寫完就結束的工作，是一直在跑的系統——你不看，它就會悄悄跑偏。
中間會遇到很多分岔點，特別是大型程式碼變動或重構的時候，這種時刻很容易因為趕進度而跳過一個關鍵動作：
很多決策是不可逆的，事後才後悔已經來不及了。
關鍵抉擇之前，也需要凝聚多家 AI 助理的經驗與意見，交互詰問，讓不同視角的問題都浮出來。這個動作看起來慢，實際上可以避開很多後期才爆炸的問題。
能做到這樣，才能真正啟動 40 倍槓桿的效益——讓沒有專業程式設計背景的人，也能完成多項功能的模組化程式串接任務。這不是誇張，是我們實際跑過的個案數字。
二、文件才是資產，不是記憶
開發過程中，有一件事非常重要，但很多人（包括 AI 助理）都會忽略：
最重要的資產是文件，不是個人的記憶，也不是 AI 助理的記憶。
程式碼是一翻兩瞪眼的事情。你說「我記得某個功能是這樣設計的」，那沒有用。把那個功能模組調出來，看哪一行寫了什麼，那才是真正的內容。
這個原則同樣適用於 AI 助理。AI 助理很容易煞有其事地亂掰一通，聽起來很有道理，但查了原始碼才發現根本不是那回事。它們也容易偷懶，把輸出內容簡化，把細節省略掉，讓你以為問題已經處理好了。
不要放任 AI 助理胡亂地承諾與答應，然後你就真的信了。
這種工作態度的底線很簡單：有疑問就查，查了才算數。
三、多 AI 協作的現實：信任不是平均分配的
當我們引入多家 AI coding assistant 之後，開發流程確實改變了，但很快就發現一件事：這些工具的信任程度根本不在同一個水準。
高機率一次就把程式碼寫對的，到目前為止我只能信任 Claude + Claude Code 這個組合。原因直接講：
較高的一次就寫對的機率
較穩定的架構一致性，不會今天寫的跟昨天的衝突
大範圍把程式碼改壞的風險相對低
其他工具呢？Antigravity、Cursor、Gemini CLI、OpenCode 這些，我還是怕怕的。第一是額度很快就衝完了，第二是大面積把程式碼改爛掉的慘痛經驗，依然記憶猶新。
| 工具 | 信任程度 | 實際問題 |
|---|---|---|
| Claude + Claude Code | ★★★★★ 核心信任 | 週配額有限，到週五才重置 |
| OpenCode / Cursor | ★★★☆☆ 輔助使用 | 額度消耗不穩定；曾有大面積改壞的經驗 |
| Gemini CLI / Antigravity | ★★☆☆☆ 評析參考 | 架構一致性較弱，適合做交叉意見 |
四、額度用完，專案就停擺
這不是假設情境，這是真實發生過的事。
到週五額度才會回歸，現在才到週二晚上，已經用光了，專案立刻就停擺，無法往前推進。深感可惜。
這個問題的本質不是「工具不夠好」，而是一個結構性依賴問題：整個開發節奏，過度依賴單一高信任 AI。一旦那個 AI 的資源出現限制，系統就卡住了。
就算是成本考量，也要顧及可靠度。這是一個需要刻意設計的問題，不是碰到了再說。
五、訣竅：建立可交接的工程結構
解法不是換工具，是換思維——從「依賴單一 AI」換成「建立可交接的工程結構」。
核心做法是：留一些 Claude 對話額度，專門用來產出交接文件，確保品質足夠讓任何其他 AI coding assistant 接手。
但這件事有難度，不是把文件寫好丟過去就行。完整的流程大概是這樣：
不是在找一個更強的 AI，而是讓幾個 AI 互相檢驗、互相補位。
六、實測結論
我試過了。
上下級（規劃者 AI vs. 編碼 AI）程度不要差太多，良好的文件確實可以推進不是太複雜的修修改改任務。當規劃型 AI 與執行型 AI 的能力差距在合理範圍內，且交接文件品質足夠清晰的時候，中等複雜度的開發任務，是可以穩定流轉的。
這個結論不複雜，但要做到並不容易。
軟體工程的核心，始終是可驗證性、可追溯性，以及可交接性。
這三件事，不會因為有了 AI 助理就自動解決。
#AI協作 #軟體工程 #知識管理 #PCPiLOT
Comments