Day 30：尾聲

這 30 天來，分享了我和 AI 交手（！？）的經驗。那麼平常我到底是怎麼用 AI 的呢？這邊就跟大家分享幾個情境。

大規模的功能開發

這個最花時間。不管是從無到有，還是已經有可以參考的現存程式，我通常會先花時間在網頁上的 claude.ai 跟它談——如果有資料表，也會一併提供給它。重點是從「分割功能」開始逐項討論：它會對我的需求提出質疑、同時幫我確認需求，我則是反駁（或是被它反駁）。談到收斂之後，我會要它訂一份修改計畫，裡面包含資料表 DDL、作業流程說明、範例程式（如果有寫的話）、驗證方法……等，並且在文件中明訂通過準則，驗證通過後才交給我。相關文件就留存在 HackMD 筆記上。

接下來回到工作機，呼叫 Claude Code，要它先去讀那份筆記，再開 /plan 模式檢查修改計畫的內容；確認無誤後才建立分支，開始修改與測試。它自己的測試通過後，才會回到我這裡做人工測試，最後 push 到 git、上 CI 主機。

小規模的除錯

小規模的除錯通常就直接開 Claude Code，一樣先進 /plan 模式，描述錯誤訊息、提供截圖，由它自己修。先開 /plan 的原因是——它通常會順手掃過整份專案，確認有沒有同樣的問題。修正前，我會要求它以出錯的那個案件做測試，通過後我這邊才驗收；當然，我自己還會再測一次，而且會拿「原先失敗的案例」和「原先成功的案例」各測一次。如果真的在忙，測試這一步就放給 AI 自己跑、自己截圖。

我另外還會要求它在 git push 時，把本次調整的項目記進記憶裡。若判斷其他專案可能也有相同問題，就把這個問題留存到 HackMD 筆記上；之後操作其他專案時再掃過整份筆記，把屬於該專案的未解問題一併處理掉。

弱掃、滲透測試修補

這部分因為都會附報告，所以流程是：把報告的截圖丟給 claude.ai，要它綜合整份報告裡的待修項目，提出修改方案建議、列成一份修改計畫。這份計畫裡最重要的，是要求它做一組 TODO List 的勾選項目——改完一個勾一個。之後回到 Claude Code，讀取剛剛產出的文件，逐項修改，一樣改完一個勾一個。它修改完畢後，自己再逐項測試，用 curl -I 確認是否滿足報告的要求，最後上 git、部署到主機。

小技巧：不太可能把整份報告直接餵給 AI（尤其 claude.ai 一次吃不了太多頁）。建議做法是把報告轉成單頁圖檔，再用 ZIP 工具打包成單一檔案後上傳。

結論

可以看到，不管是哪種情形，我幾乎都會花時間要 AI 先訂計畫，甚至提供各式文件去參與規格的訂定。畢竟，只有我知道我要的是什麼、知道你（AI）該幫我做到什麼程度、也知道哪些蠢事不能幹。這也是這 30 天一再強調的主題：AI 負責答，我負責讓答案可信！ 希望這 30 天的發文，能幫到螢幕前的你，別再被 AI 的幻覺搞到了。

完賽心得

30 天的連續發文，終於結束了。這次鐵人賽，基本上就是我跟 AI 拌嘴（！？）的實錄——相信明眼人也看得出來，這系列的文章是 AI 寫的。這次用 AI 幫忙寫文章，確實輕鬆很多。

AI 很強大，這點無庸置疑。這兩年明顯感覺到它幫我做了很多以前做不到的事：以前寫不出來的東西，問 AI；以前排除不了的問題，收集 log 之後問 AI；以前架不起來的環境，叫 AI 寫一份手冊、我照著做。但 AI 也是會幹蠢事、也是會腦霧的——所以才要人盯著。

這幾年最多人問的那句：「會被 AI 取代嗎？」我這樣用下來的心得是：會，但不會在這十年內。在 AI 學會人性與通靈之前，只要你有足夠的知識與經驗，就完全不用擔心被取代。那如果你缺乏知識與經驗呢？那就從 AI 身上汲取你要的知識，並把它內化成自己的。維持進步，才是最不用擔心被取代的方法。

本次的遺珠之憾

這次我把範圍框在「協作」上，所以忍痛放掉了不少素材，例如：

1. 各種套件、plug-in、skill 的實測紀錄：很多網路上說超好用的東西，拿來玩過之後被我一個個打臉，連 AI 都說「這東西的廣告效果寫得比內文還好」。
2. 跟 AI 針對開發架構、環境架構的討論：k8s 的建置方式、資料庫 Stored Procedure 在 AI 時代的定位、前後端完全分離的優劣……這類純討論、並得出階段性結論的紀錄。
3. 各式各樣的問題排除與程式寫法：純粹我問它答的文章，因為少了「協作」的精神，就沒拿出來；但其中有些程式範例，其實寫得很不錯。

以上只是冰山一角的遺珠，之後有機會再寫出來。我們有緣再見了！