和 AI 結對寫程式一年後的幾點體會

去年這個時候，我開始認真把 AI 工具放進日常的開發流程。一年過去，有些期待落空，有些收穫是一開始沒想到的。這篇短文整理幾個對我來說最真實的體會。

工具不會替你思考，但它會逼你把想法說清楚。

這句話是我在第三個月左右寫在筆記裡的，到現在仍然覺得是最準確的總結。

真正改變的事

最大的改變不是寫得更快，而是更願意開始。 以前遇到不熟的領域，光是查文件、搭環境就會消耗掉大半動力；現在可以先讓 AI 產出一個能跑的草稿，再從那個草稿往下修。

我目前的工作流程大概是這樣：

具體來說，我會依照下面的順序進行：

1. 先把需求寫成文字。 包含目標、限制條件、不要做的事。這一步花的時間最多，但也最值得。
2. 讓 AI 產出第一版。 不追求完美，只要能跑起來。
3. 自己逐行讀過。 看不懂的地方就問，直到能用自己的話解釋為止。
4. 重構成自己的風格。 命名、拆檔、註解，這些是我的責任，不是工具的。
5. 寫下這次學到的事。 通常就是一兩句話，累積起來很可觀。

仍然要自己來的事

有些東西一年下來我確定還是得靠自己：

• 決定要做什麼。 AI 很擅長回答「怎麼做」，但「該不該做」永遠是人的問題。
• 理解程式碼的每一行。 看不懂就不要合併，這條底線我沒有放鬆過。
• 維護長期的架構。 工具看得到眼前的檔案，看不到半年後的擴充需求。
• 對結果負責。 出了問題，沒有人會接受「是 AI 寫的」這個理由。

其中第二點最容易被忽略。速度帶來的誘惑很大，但累積一堆自己不懂的程式碼，之後的維護成本會全部還回來。

幾個實用的小習慣

• 提問時附上完整的錯誤訊息與相關檔案，而不是描述「壞掉了」。
• 一次只問一件事，避免對話越拉越長之後失焦。
• 遇到不確定的 API 用法，要求它引用文件而不是憑印象回答。
• 定期回頭看自己寫的 prompt，會發現很多可以模板化的部分。

延伸閱讀

如果你也想建立類似的流程，Astro 官方文件 是很好的練習題材：範圍小、文件完整、回饋快。我自己就是用它來實驗這套工作流程的，過程記錄在 用 Astro Content Collections 打造 Markdown 部落格 這篇。

一年不算長，這些體會之後大概還會再改。到時候再回來補充。