【Day 30】與AI 同事的合作挑戰：從期待到現實的150小時

17th鐵人賽

elliot_coding

2025-08-30 21:06:46

92 瀏覽

分享至

今天是鐵人賽第30天，也是這個主題的最後一篇文章了
我請AI同事幫我整理至今已完成與未完成的功能。
我將詳細內容列在文章最後。
先來講講這次參加鐵人賽，與AI同事合作的感想。

這三十天與 AI 同事一起打造系統，原本我以為以目前 AI 的能力，應該可以提前完成，結果證明我還是太天真了 XD。
這段時間大概投入了 150 個小時左右，但最後成果還是只能算半成品。

如果只是要做一個 DEMO，前端的確能很快展現成果。尤其在請 AI 同事生成 UI 時，我能強烈感受到它的威力；不過一旦進入功能串接，以及一些比較複雜的處理（例如同步與非同步的設計），開發就變得相當辛苦。

若是我自己從零開始建置系統，我會知道前面功能的脈絡，後續也能順著這個方向繼續開發。但 AI 同事不同，雖然前面部分也是它生成的，卻常常像是換了一個人接手，完全不顧之前的設計，導致在功能整合時摩擦不斷。
我雖然已經盡量要求 AI 同事產生文件，並在每次合作前請它先閱讀文件，但實務上效果有限。

舉例來說，我請它執行測試時，需要先進入虛擬環境（venv），它卻常常無視說明，直接就執行 XD。即便我把這些守則寫進 Gemini 的長期記憶，它還是常常忘記。
我記得在用 AI API 時，可以用 system prompt 與 user prompt 分開設定，如果未來能把這些規範寫進 system prompt，或許會比較不容易被忽略吧？只是這樣 token 消耗應該會很快 XD。

當然，這些都是我目前在使用能力相對較低的 Gemini Flash 模型時的體驗，如果改用更強的 Gemini Pro，甚至未來更進階的模型，說不定能改善不少問題。

目前我覺得體驗最佳的合作模式，是先請它產出範例文件，再要求它依照範例去撰寫其他主題內容。這種方式 AI 同事比較不會「走偏」。
程式碼或許也能採取類似做法：先寫好虛擬碼，再讓它依照虛擬碼去完成實作。感覺這樣會比直接生成更順利，只是與我原本的期待差距頗大。原本以為人工與 AI 的分工比例能落在 2:8 或 3:7，但實際上得反過來：人工需要介入到七成，才能獲得比較理想的開發體驗。

最後，還是要感謝 IT 邦鐵人賽，讓我的惰性稍微被壓制 XD。雖然在比較忙的時候確實會有點壓力，但整體來說，這段經驗還是相當愉快的。

TaskWhisker 專案高維度功能檢核清單

已完成功能 (Completed Features)

後端 (Backend)

[x] 基礎架構與環境設定：專案初始化、依賴管理、Docker Compose 配置。
[x] 使用者與權限管理：使用者註冊、登入、JWT 認證、角色與權限管理、令牌撤銷、錯誤處理、UUID 轉換。
[x] 核心專案管理：專案的 CRUD 操作、依賴關係處理。
[x] 任務管理：任務、任務狀態、標籤、評論、附件的 CRUD 操作。
[x] 時間追蹤：時間記錄的 CRUD 操作。
[x] 輔助功能與數據準備：通知、創意、筆記、會議記錄等模型的建立與 API 端點。
[x] 資料庫遷移：Alembic 初始化與遷移。

前端 (Frontend)

[x] 基礎建置與開發環境：Vite 專案初始化、Tailwind CSS 配置、Pinia、Vue Router、VeeValidate、Axios 設定、ESLint/Prettier。
[x] 認證與使用者管理介面：登入、註冊、個人資料頁面、登出功能、認證守衛、註冊成功頁面 (UI 已重構為純 HTML + Tailwind CSS)。
[x] 核心專案與任務管理介面 (部分)：儀表板、專案列表、專案詳情頁面基礎結構、專案與任務創建/編輯模態框 (UI)。