今天是鐵人賽的第七天，我想做個一週回顧，順便盤點一下這週與 AI 同事合作的策略與經驗。

這週的主要進度集中在計畫專案管理系統的功能設計，包括：

• 確認功能需求與架構設計
• 決定前端與後端所使用的技術棧
• 討論功能建構的順序
• 建立後端開發環境
• 撰寫 FastAPI 的應用程式骨架與驗證測試

我這週大概花了20小時在這個專案上，以投入的時間與實際產出的成果比例來看，我認為 AI 同事確實有幫助我提高開發效率，雖然在部分階段會帶來一些反效果，但整體仍是正向的提升。

技術支援夠強，問題在「怎麼用」

在「思考功能設計」與「選擇技術架構」這些抽象規劃層面，AI同事的幫助很大。這類任務通常需要前端、後端、設計等三四位工程師一起討論協作，但現在透過與AI同事討論，我得以跨過知識與技術死角，涵蓋過去不太熟悉的技術領域，這對我來說確實是一種視野與技術的擴展。

但當進入「細節調整」與「BUG 修復」時，狀況就沒那麼樂觀了。
比起我自己修，AI同事有時反而花了更多時間。如果是我自己寫的程式，要修改某個地方，我會大致知道哪個部分可能出錯；但AI同事比較像是用大部分人會改哪些地方去解決，導致很容易修改錯位置，甚至產生新的錯誤。雖然我的程式規模可能還不算大，但這樣的差異還是很明顯。

值得注意的是，當一開始習慣讓AI同事解決問題後，後續遇到小錯誤，也會不自覺地想交給它處理。
這種慣性其實會讓開發流程失控，錯估時間成本，也讓自己失去主導權。這讓我意識到：技術執行可以交給 AI，但「什麼該交給它做、什麼該自己來」這種判斷，一定得自己掌握。

合作策略筆記：這週我學到的幾件事

這週與AI同事合作的過程中，也出現了幾個以前沒注意的細節，以下簡單整理：

1. 討論切換主題時，建議先 /clear

當討論進入新的環節，而且內容和之前無關時，建議先清除上下文。這樣可以避免AI同事被舊的內容影響，產生不必要的聯想或錯誤推論。

2. 修錯誤時記憶會造成干擾

通常修復一個錯誤之後，會連帶出現新的錯誤。這時如果發現AI同事開始使用不太適合的手段（像是建議降版本）來處理，就應該考慮 /clear，重新讓它思考。因為AI同事有可能記住你在處理 A 錯誤時否決過某個方法（例如 X 方法），到了 B 錯誤時即便 X 是正解，它也會避免使用，反而影響解決效率。

3. 錯誤訊息給得太多會降低效率

一開始我以為提供越完整的錯誤訊息會越有幫助，所以常把整段錯誤 log 都貼給AI同事，甚至請它自行閱讀 log。但實際結果並不好，修復能力反而下降。我後來思考了一下，這可能是因為人與人之間問問題時，其實只會挑出版本資訊與關鍵錯誤訊息來問，而 AI 的訓練資料也多半是這種類型。如果貼整段 log，AI同事可能會被大量無關訊息干擾，影響判斷。

鐵人賽一週感想：累，但有收穫

當初會報名鐵人賽，是因為剛好有個我有興趣的主題，也想透過這樣的形式讓自己持續產出、每天前進一點。

不過實際做起來，有時真的蠻辛苦的。有些天剛好很忙，能抽出來寫文章或開發的時間不多，還是得硬擠出一些進度，當下會覺得煩躁。但真的完成當日目標後，又會有一種「我今天又往前一點」的成就感。

有時候也會因為太投入，反而花了比預期更多的時間，導致隔天特別疲累。現在也更能理解為什麼這叫「鐵人賽」，這真的不只是寫程式、寫文章，而是在跟自己的慣性、疲勞、意志力拔河。

這週下來，我確實感受到AI同事能幫我跨過一些技術盲點，加速某些階段，但也體會到：判斷力不能外包，使用 AI 需要策略。
我期待未來能進一步優化與 AI 同事的合作模式，讓我們彼此配合，發揮乘法效應，創造更優秀的成果。