如果要問我，前兩篇的「FDT｜和 AI 一起做專案」的故事，是從哪一天開始的？
答案其實不是寫下第一行程式碼的那一天。甚至不是我第一次讓 AI 幫我寫程式的那一天。
真正的起點，大概是在 2026 年 3 月中末。
隨著當時的 Coding AI Agent 系列工具，如火如荼地席捲整個軟體開發工程業界，我非常認真地理解到：
「未來的軟體開發，一定不再是工程師自己一行一行把程式碼硬寫出來，而是由人負責定義問題、設計系統、做高階決策，再讓 AI 大量參與設計、實作與驗證。」
那麼，現在的我，有沒有辦法真的走一次這樣的流程？
那時候的我，其實有一點天真。我一直相信一件事情：
「沒有什麼知識與技術，是找不到公開資料學習的。差別只在於，你有沒有心，以及有沒有時間。」
於是我沒有先買訂閱任何的付費版AI方案，而是很自然地拿 Gemini、GPT、Claude 的免費網頁版開始。一開始，其實沒甚麼問題的，直到……
________________________________________
# 從「請 AI 幫我想」開始，一切看起來都很順
最初的工作其實相當單純：蒐集專案需要的技術素材、找文獻、整理資訊、比較不同方案、分析題目、界定專案範圍，再請 AI 幫忙把想法整理成一份初步的專案設計。這個階段，我覺得 AI 幾乎像是一個隨時可以討論事情的研究助理。我丟資料進去，它幫我整理。我提出一個想法，它幫我拆解。我不知道某個技術應該怎麼選，它可以一次列出好幾條可能的路徑。甚至連原本需要花很多時間讀完，再慢慢整理脈絡的資料，也可以先讓 AI 幫我做第一輪濃縮。
所以我很快就產生了一個錯覺：
「既然連專案設計都可以這麼快，那接下來的實作應該也不會太難。」
問題從這裡開始，因為專案一旦真的開始變複雜，事情就不再只是「回答得對不對」。
________________________________________
# 當專案開始長大，聊天視窗開始裝不下整個專案
隨著設計逐漸深入，原本的一份草稿，慢慢變成一整組文件。主專案文件、細節附件、參考資料、文獻索引，甚至開始有程式碼與環境設定。每一次修訂，又會牽動其他地方。這時候我第一次很明顯地感覺到，AI 的回答開始出現細節遺漏。有時候它記得前面討論過的原則，卻忘了後面新增的限制。有時候某一份文件已經修改了，另外一份文件卻還停留在舊版本。有些內容單獨看完全沒問題，但放回整個專案裡，就開始互相矛盾。
一開始我的直覺是：「那就重新開一個 Chat。」
但很快發現，這個方法只能把「舊對話太長」的問題洗掉，卻沒有解決真正的問題。
因為真正需要被記住的，不是某一個 Chat 裡說過什麼。而是：「這個專案到底相信什麼？」
於是我第一次開始碰到一個後來對我影響很大的概念：「讓專案本身成為 AI 的上下文。」
我開始把已有的文件、程式碼與索引整理起來，嘗試用類似 LLM Wiki 的方式，把原本散落在不同地方的資訊集中。
甚至連文件格式，我也開始刻意整理。能結構化的地方就盡量結構化，逐漸嘗試用 YAML 等方式描述；而正式的專案文件則開始大量採用英文。
目的其實很簡單：「我想讓 AI 讀到的是「專案本身」，而不是某一次聊天留下來的印象。」
________________________________________
# Notebook 出現之後，我第一次覺得「也許真的可行」
後來，我開始使用網頁版 Gemini 搭配 Gemini Notebook。這一次，感覺明顯不同。我可以把不同類型的專案文件、GitHub 內容與相關資料分門別類放進同一個脈絡裡，再請 Gemini 對這些資料進行整合。接著，再拿整理後的設計，交給 GPT、Claude 等不同模型交叉討論。
這個過程讓我慢慢找到一種比較像工程工作的方式。不是問 AI：「你覺得我的想法好不好？」而是開始問：
「這份設計和其他文件有沒有衝突？」
「這個決定會不會影響後面的模組？」
「如果之後部署環境改變，這個方案還成立嗎？」
我開始把 AI 當成不同角度的審查者，而不只是答案產生器。
那個階段，我甚至曾經產生過一種自信：現在專案的設計應該已經收斂得差不多了。於是，我開始進入實作。然後，又一次撞牆。
________________________________________
# 文件可以對齊，不代表 AI 已經看懂你的開發環境
我原本採用的方式很理想化：AI 根據專案設計文件，產生下一步的實作指引。
我則在自己的電腦上，一步一步照著做。做完，再把結果告訴 AI。然後進入下一步。
看起來很合理。而且在專案剛開始的時候，也真的可以運作。直到本機環境開始慢慢長出東西…… Container、設定檔、基礎程式碼、測試環境、目錄結構…… 這些東西開始形成一個真實的開發現場。
這時候我才真正發現：「文件可以放在同一個 Notebook 裡，不代表 AI 就真的掌握了我的開發環境。」，它知道我「應該有什麼」，卻未必知道我「現在實際有什麼」。
某個檔案是不是還存在？
前一步的指令到底有沒有成功？
某個環境變數是不是和設計文件寫的不一樣？
某個腳本到底被執行過幾次？
前一步的指令到底有沒有成功？
某個環境變數是不是和設計文件寫的不一樣？
某個腳本到底被執行過幾次？
這些事情，如果沒有被明確餵回去，AI 很容易按照「理論上的專案狀態」繼續往下推演。而實際環境，早就開始偏掉。於是，專案又出現了熟悉的那兩個字：「飄移」。
只不過這一次，不再只是文件飄移。是「AI 認知中的專案」和「我電腦裡真正存在的專案」開始分開了。
________________________________________
# 三個月過去了，我連真正的實作都還沒開始
時間很快來到 2026 年 7 月。回頭一看，我突然意識到一件有點尷尬的事情：「我已經研究、整理、設計、比對了三個多月，卻還不能說自己真正開始完成那個專案。」
這其實是一個很好的教訓，因為當時我做的每一件事情看起來都很合理：
蒐集資料合理；
整理文件合理；
讓多個 AI 交叉審查合理；
建立 Notebook 合理；
一步一步產生實作指引，也合理。
但全部加在一起，卻沒有把我真正送進「專案正在前進」的狀態。
那一刻，我開始重新思考：
也許我真正缺的，不是再多一份文件，而是另一種工具。
________________________________________
# 此時不拿出魔法小卡，還等什麼時候？
其實這件事情多少有點現實，這幾個月裡，我在現職工作環境也接觸到公司提供給 RD、IT 部門使用的 Coding AI Agent 工具。像 GitHub Copilot Chat 這類工具，讓我第一次比較具體地感受到：「真正進入開發環境裡的 AI，和只存在於瀏覽器對話框裡的 AI，是兩件不太一樣的事情。」
它能夠接觸程式碼、理解檔案結構、參與實際修改，也能更貼近工程師每天真正工作的上下文。於是我開始問自己一個很現實的問題：
「如果我想把「AI 協作開發」當成自己下一階段職涯能力的一部分，卻連市場上真正成熟的 Coding AI Agent 都沒有完整使用過，那我將來要怎麼跟面試官說，我真的做過這件事？」
工欲善其事，必先利其器。既然這個專案本身就是用來探索下一代開發方式，那麼工具本身，也應該成為探索的一部分。
所以我最後放棄了「全部免費」這個堅持。開始認真評估 Claude Code、Codex、Google Antigravity 等工具。
我比較的，不只是「誰寫程式比較快」，而是：
它能不能真正進入專案上下文？
能不能讓 AI 的操作更接近真實工程流程？
能不能讓人類保留對任務邊界、驗證結果與最終決策的掌控？
最後，我選擇了 Claude Code。也是從這裡開始，我才真正進入這一系列故事的下一章。而時間也已經來到七月中末……
________________________________________
# 真正困難的不是「讓 AI 幫我做事」
現在回頭看 4 月到 7 月這段過程，我反而很慶幸自己沒有一開始就一路順利。因為那三個月讓我親自體驗了一件事情：「AI 可以很快，但「很快」並不等於『掌握全局』」。
你可以讓 AI 很快整理資料、很快提出方案、很快寫出程式碼。但如果上下文沒有被管理，任務沒有邊界，環境沒有被驗證，而人又沒有持續確認實際結果，那麼速度越快，可能只是讓錯誤更快累積。
也正因如此，後來我開始使用 Claude Code，真正把專案往前推進之後，我對「AI 協作開發」的期待已經和三個月前完全不同。
我不再期待 AI 幫我把所有事情想好。我開始在意的是：
它提出的假設能不能被驗證？
它做出的決定是否符合目前 Task？
如果結果和預期不同，誰會先發現？
一個看起來合理的方案，真的執行之後會發生什麼？
它做出的決定是否符合目前 Task？
如果結果和預期不同，誰會先發現？
一個看起來合理的方案，真的執行之後會發生什麼？
而最重要的是：
當 AI 說「這樣應該沒問題」時，我有沒有辦法自己證明它真的沒問題？
當 AI 說「這樣應該沒問題」時，我有沒有辦法自己證明它真的沒問題？
後來的答案，慢慢變成了這一系列文章真正的核心。因為我接下來遇到的，已經不再是「怎麼讓 AI 幫我做專案」。而是另一個更麻煩、也更有意思的問題：
「當 AI 真的開始參與一個專案之後，人到底應該負責什麼？」
這個問題，直到我真的開始做第一個 Task 之後，才終於有了答案。而故事，也從那裡開始真正變得有趣。
從這篇文章發布的時間點來看，上述內容在業界當中應當都已經算是老生常談。但是「聽他人的話常談」與「身歷其境」，層次上還是有差異。而這篇文章想記錄的，自己也親自感受過這個技術典範轉移的過程。
________________________________________
延伸閱讀
以防自己忘記，總要將自己做了哪些努力與學習給記錄下來：1. Codex、Claude Code、Antigravity——三個 AI 寫 code agent 的真實比較與選法
2. EP-80｜LLM Wiki：讓 AI 把資料變成第二顆大腦 - Raven AI 週報
