前言

AI 讓寫 Code 的速度變快了，但當開發速度被大幅壓縮之後，真正的瓶頸開始從「開發」移到「規劃、驗證與整合」。這 30 天，我想分享自己如何把 AI 從寫 Code 的工具，變成開發流程中的協作者。

AI 真的讓開發變快了

相信很多人都有一樣的經驗，一開始使用 AI 協助開發時，真的會有一種「以前到底在忙什麼？」的感覺，它可以幫我們：

• 整理需求文件
• 分析既有程式碼
• 產生 API
• 寫測試
• 找 Bug
• 重構程式
• 甚至直接修改檔案、執行指令

最近負責的專案導入 Claude 之後，我也明顯感受到這個變化，過去可能需要花好幾天整理的分析文件，現在半天就能產出一份可以拿去討論的版本。

但使用一段時間之後，反而開始遇到另一個問題：

AI 做得越快，系統走樣的速度也可能越快。

系統為什麼會開始走樣？

一開始通常沒有問題，直接告訴 AI：「幫我建立一個 API」，它可以很快幫你產生 Controller、Service、Repository，甚至連測試都一起補上。一開始都很美好，但當專案持續開發幾週之後，開始出現一些問題：

• AI 不知道專案的架構與規則
• 做到一半容易偏離原本的需求
• Code 看起來可以跑，但邊界條件沒有處理
• 每次都要重新告訴 AI「我們專案是怎麼做的」

每一次和 AI 的對話單獨來看，都是合理的，但當這些產出累積在一起，整個系統卻可能逐漸偏離最初的設計。

系統走樣的問題，很多時候不是 AI 不夠強，而是那些決定沒有被系統化地留下來。

我們真正要處理的不是：「這一次要怎麼跟 AI 講？」，而是：「怎麼讓每一次產出，都能接得上前一次的決定？」

AI 只是幫忙開發，還是已經成為開發流程的一部分？

先定義 AI-Assisted Development 和 AI-Native Development 的差別。

在 AI-Assisted Development 裡，我們通常還是用原本的方式思考：

「我要完成一個功能，請 AI 幫我寫 Code。」

而在 AI-Native Development 裡，思考方式會變成：

「我要完成一個功能，AI 要怎麼參與需求、規劃、實作、測試與驗證？」

這也是這 30 天真正想分享的東西，當 AI 只是幫你寫一段 Code 時，我們可以很容易地看完、確認、修改。但當 AI 開始可以：

讀專案 → 修改多個檔案 → 執行指令 → 跑測試 → 根據結果修正 → 再繼續往下做

事情就不一樣了，因為我們不可能永遠盯著 AI 的每一個動作。
因此我們開始關注：

• 怎麼讓 AI 知道這個系統要做什麼？
• 怎麼讓它知道這次可以改什麼、不能改什麼？
• 怎麼讓它知道什麼叫做完成？
• 怎麼讓這些規則不需要每一次都重新講？
• 怎麼讓 AI 的產出可以被持續驗證？

這些問題，最後會落到幾個核心概念：

Spec、Plan、Test，以及 Command、Skill、Hook、MCP、Plugin 等 AI 協作機制。

開發已經不是最難的那一步

以我過去參與專案的經驗來看，一個功能的時間分配，常常可以粗略想像成「規劃一分、開發八分、整合一分」。

當 AI 把中間的八分大幅壓縮之後，原本被開發時間掩蓋的問題就開始浮現：

• 規劃夠不夠完整？
• 需求有沒有被正確理解？
• 最後做出來的東西真的符合原本的設計嗎？

如果瓶頸換了，開發方法也應該跟著換；不是「怎麼讓 AI 寫得更快」，而是開發速度提升之後，前後兩端該怎麼重新設計。

這 30 天的主題

這次參加鐵人賽，我不想單純介紹 AI 工具，而是把自己實際使用 AI 協助開發的經驗重新整理一次，從概念一路走到實作，最後會實際做出一個會議紀錄系統（Meeting Notes System），把前面介紹的方法一路用進去。

整個系列會分成四個部分：

小結

• 系統會走樣，不是因為 AI 做不好，而是講過的決定沒有被系統化地留下來。
• AI-Assisted 是讓 AI 加速原本的開發流程；AI-Native 則是重新設計 Human + AI 的開發流程。
• AI 讓開發變快之後，瓶頸沒有消失，只是換了位置。它逐漸移到了事前的規劃，以及最後的測試與整合。

明天：如果 AI 不只是工具，而是開發團隊裡的一員，那我們是不是應該重新設計整個 Software Development Lifecycle？