三個月前，我曾寫過一篇關於 AI 開發工作流程的文章。沒想到短短幾個月，因為 AI 技術的快速進展，我的工作流程又有了天翻地覆的改變。這篇文章紀錄了這段期間的變化，並分享針對不同開發情境可採用的方法。

根據我自己的實務經驗與今年的開發心得，我將 AI 協助開發的方式分成四種：

1. Tab Auto Completion（自動補齊）
2. Chat Coding（聊天開發）
3. Vibe Coding（直覺開發）
4. Spec Coding（規格開發）

這四種方法沒有絕對的優劣，差別主要在於使用情境、開發者的技術程度，以及對 AI 成本的控管。以下分別說明適用場景、對象、成本與工具選擇。

1. 自動補齊

適用對象：會去 Google 找語法複製貼上，且對語法具有基礎認識者

適用場景：一個或是數個函式能完成的功能

花費成本：0 元

工具選擇：VSCode + GitHub Copilot

自動補齊是最簡單的方式。在編輯器中輸入註解或函式名稱後，AI 會根據提示自動產生程式碼建議，按下 Tab 就能直接完成程式碼。這對於經常撰寫小功能或快速測試語法的人非常實用。

例如在 WordPress 開發中，常用的功能像是載入 JS/CSS、隱藏前台工具列、列印錯誤日誌等，都可以透過自動補齊快速完成。缺點是 AI 有時「猜錯」需求，導致建議的程式碼不符合需求。

要使用自動補齊功能的前提是要在程式編輯器內進行作業，並使用相關的擴充功能來實現自動補齊，我目前選擇的是 VSCode 搭配 GitHub Copilot，後者每個月提供 2,000 次的自動補齊額度，對於要做一些小功能是綽綽有餘了。

2. 聊天開發

適用對象：對程式語法具有基礎認識者

適用場景：開發包含前後台的完整功能

花費成本：每月 20 美元起

工具選擇：VSCode + ChatGPT Desktop

三個月前我的工作流程就是採用這個方法，我從想法開始跟 AI 進行討論，然後請它幫我分析技術的可行性，再到實際寫出程式碼，最後我再把程式碼貼到 VSCode 裡面執行，由於我很熟悉 WordPress 外掛開發，因此我可以從它給的程式碼中學習到很多知識：

另外我還請它記住我的開發習慣，讓它產出的程式碼方便自己易於閱讀，並且符合 WordPress 的程式碼規範，這種做法可以很大程度的掌握 AI 產生出的程式，如果發現他寫的東西有誤可以即時修正，再搭配自動補齊能讓開發速度翻個兩倍。

我是使用 ChatGPT 的專案功能進行開發，在專案中可以下提示詞以及上傳相關的開發文件，並且專案內的對話都有記錄，能在每次提問時讓它理解之前詢問過的上下文，避免又要重頭開始問。

使用這種方法的缺點也很明顯，首先是要在不同的視窗切換，我要把在 ChatGPT 產生的程式碼貼到 VSCode 裡面，我要自己找該貼到哪個檔案裡面以及貼的位置，然後要自己手動測試每段程式碼是否能正確運作。

其次是它提供的程式碼我有可能會進行調整，為了讓它好理解，我需要再次把我修改過的東西貼給它，AI 才能根據我的情況產生我所需要的程式碼。然後最麻煩的問題是當程式已經開發到一個規模了，單純手動貼上讓它理解會花費不少時間。

幸好現在有很多服務都有在 VSCode 裡面提供聊天介面，並且可以針對程式碼的內容進行自動理解，這樣問出來的程式碼品質會更好，這類服務有 Github Copilot、Cline、Roo Code、Augment 等等，而且現在都有直接幫你改程式的 Agent 模式。

雖然這些服務很方便，但每個都要額外的月費，對於已經有訂閱 ChatGPT 的我就懶得再花錢訂了，這樣聊天開發的模式也適用在 Gemini 或是 Claude 的桌面版上，目前我會採取這種開發方式的情境是我想要學習整個流程與程式碼，透過邊問邊做的方式來讓自己學習不同領域的開發。

想知道更多關於聊天開發的實作可以參考這篇文章：https://oberonlai.blog/wordpress-ai-develop/​

3. 直覺開發

適用對象：沒有程式基礎、只想實現想法的人

適用場景：各種應用程式與網站

花費成本：每月 20~100 美元起

工具選擇：Cursor + Claude sonnet 4 模型

自從語言模型發展出推理模式後，AI 寫程式的能力獲得飛躍式的成長，其中最強大的就是 Anthropic 推出的 Claude 模型，丟一段需求給它，它會自己思考、推理、實作甚至是測試，任何人只要有想法，就能以飛快的速度開發出雛形。

為了要驗證這樣的開發模式能做到什麼程度，我打造了一個社群平台，這個平台我用了自己完全沒用過的技術，看不懂裡面任何一行程式碼，就只是照著 AI 給我的建議執行，然後不到兩小時，就把這個平台的核心功能完成了：

我做的事情就是用紙筆畫一下雛形，然後條列出我希望這個平台有哪些功能，把這些需求丟給它之後，跑不到五分鐘所有功能就完成了，這種體驗一整個讓我多巴胺爆表，每天瘋狂的不停把想法丟給它執行，一天完成數十個功能是正常發揮，跟以前花了好幾天可能只能完成一個功能完全是不同的境界。

終於可以理解為何這樣的開發方式會爆紅，它不是在開發，而是一種想到什麼做什麼的流程，你不需懂任何技術、相關領域的知識，不需任何人的協助，就能把想法落實放到市場上驗證，對於創作者來說這是不可思議的奇蹟。

但這樣做的風險也是顯而易見，當發生 AI 無法解決的問題時，自己便束手無策，就算想要問人也不知道該從何問起，最嚴重的是那些表面上看不到的，也就是發生在底層架構的安全性以及效能問題，都只能在遇到時才有辦法意識到。

另外一個風險是模型的使用成本，我當時是採用 Cursor 這套 AI 編輯器開發，它是改良版的 VSCode 並與 AI 功能進行深度整合，它提供的操作介面更適合完全沒有開發經驗的使用者，其他類似的服務還有 Replit、Loveable、Firebase Studio 等等，差別在於他們是線上服務，而 Cursor 是本機軟體。

當時 Cursor 的月費很划算，每個月都有 500 次的請求額度，超過才需要根據使用量付費，當初自己預估開發完這個平台應該不會超過 50 鎂，但在前陣子他們改變定價模式後，光是十天的用量就超過 50 鎂：

所以後來為了節省成本，我改用 Claude 的訂閱方案，並搭配他們的 Claude Code 來進行開發，每個月 20 塊美金就能有一定的使用額度，這額度比 Cursor 提供的佛心得多，但每天也時有使用額度上限：

額度用三個條件來限制：使用費用、Token 使用量與訊息量，這三個條件只要其中一個先達標就會無法使用，然後每五小時會還原一次，如果想要有更多的使用額度只能升級每月 100 美金起的 Max 方案。

如果是還在接案時期的我一定會立刻升級，但現在為了開發產品在還沒穩定收入前要省一點，後來我計算一下我的工作時間，發現到我的用量大概在下班前 30 分鐘會用完，所以我會改用 API 的方式來補足，每天大概會再花費 1~3 美金，以一個月的工作天數計算，月費 20 + 3*22 (工作天) = 86 美金。

再加上就算每天工作也不一定會用到 Claude，整體算下來還是會比固定月費來得划算，在它使用成本還沒有下降之前，只能先這樣擋著了。

除了使用成本以外，還有一個問題是直覺開發最困擾我的地方，那就是功能的膨脹。像我在開發社群平台的時候，我只有在一開始描述我希望的功能，縱使我覺得已經描述的很詳細並且還附上手稿，但還是有許多模糊的規格。

這些模糊的地帶 AI 就會自由發揮，這樣的結果導致成品乍看很不錯，但細看有非常多的細節需要調整，像是多餘的功能、UI 的流程、整體風格不一致等一堆問題，更不用說 AI 把我要的 A 功能做成 B 的狀況也是屢見不鮮。

我實際算了一下，產生初版只花了 2 小時，完成基本核心功能是 2 天，剩下的功能追加以及除錯花了 30 天，雖然跟以前全部自己開發比起來絕對是快上好幾十倍，但還是希望可以降低這種不確定性，然後把多餘功能所浪費的 Token 省下來，花在我真正需要的地方。

4. 規格開發

適用對象：想開發但完全無相關經驗者

適用場景：要長期經營的產品

花費成本：每月 20 美元起

工具選擇：VSCode + Claude Code

回想自己在接案的時候，為了釐清客戶需求，都會經過需求訪談、確認驗收標準、拆解任務等階段，在思考直覺開發的不確定性時，就在想有沒有可能把這樣的流程導入到直覺開發之中，理想的情況是當我提出需求時，讓 AI 可以先問我一些相關問題，協助我釐清我沒想清楚的部分。

而程式碼編輯器 Kiro 剛好就實現了這樣的功能，它能在開始工作前協助我進行文件的規劃，分成三個階段：Requirements、Design、Tasks，分別對應到使用者故事、系統結構設計以及代辦任務：

這樣的功能讓我大開眼界，就在嘗試看能否用 Claude Code 來還原這樣的規劃流程，結果就在 Threads 上看到一位日本工程師成功設計出這樣的指令，用了之後覺得實在太適合我了，於是我再修改一下提示詞變成適合台灣人用的版本。

要使用這個流程需要準備以下事項：

• 本機安裝 Claude Code
• 理解 Claude Code 的 commands 功能
• Kiro 的規劃文件架構

安裝 Claude Code

先安裝 node 與 npm，然後一行指令安裝 Claude Code：

npm install -g @anthropic-ai/claude-code

更多基本用法可以參考官方文件：https://docs.anthropic.com/zh-TW/docs/claude-code/overview​

Commands 功能

Claude Code 可以把一組提示詞甚至是語法存成 Commands，這樣只要輸入斜線 + 關鍵字，就可以直接呼叫這組提示詞進行動作，省去重複輸入的時間。Commands 功能會放在專案目錄底下的 ~/.claude/commands 裡面，檔案名稱就是 commands 的名稱：

commands 還可以帶有參數，像是 spec-init add-featrue 裡面的 add-feature 就是參數名，可以在呼叫的時候帶入參數提供給 AI 作為參考之用。

Kiro 的規劃文件架構

分為 specs 以及 steering，specs 裡面有上述提到的 Requirements、Design、Tasks，也就是關於該功能的規劃文件，而 steering 是開發指南，也就是要提供給 AI 知道的背景知識，像是產品簡要、開發架構或是程式碼規範之類的文件。

如果需要整合外部服務的 API 也可以把它放進 steering 之中，也就是與實際開發相關的基礎知識都能放在這邊，像我如果是開發 WordPress 外掛有需要用到區塊編輯器時，因為這部分網路資料版本落差很大，我就會把最新的官方手冊複製起來後放在這邊。

實際執行規格開發

主要分為以下 6 個步驟：

1. 複製存放庫
2. 執行 steering-init 了解專案環境
3. 執行 spec-init 產生需求文件架構
4. 執行 spec-requirements 產生需求文件
5. 執行 spec-design 產生架構設計文件
6. 執行 spec-tasks 產生代辦清單文件

1. 複製存放庫

先開啟專案的空資料夾，然後下載該存放庫：https://github.com/oberonlai/cc-spec，或是使用指令 git clone https://github.com/oberonlai/cc-spec.git .下載，如果你的資料夾已經有檔案了，那就下載存放庫後把裡面的檔案複製進去就好。

複製完成後可以先點開 CLAUDE.md 這個檔案，這個檔案是 Claude Code 的開發指南，會告訴它在每次執行時要做哪些事，這份檔案定義的規格開發的流程與邏輯，沒有特別需要的話不用修改它，我有請它英文思考中文回應，讓產出的文件比較好閱讀。

其次是 .claude/commands 資料夾，裡面存放的就是相關指令，具體有哪些我們透過接下來的實作來逐步說明。

2. 執行 steering-init

這個動作是讓 Claude Code 先理解專案資料夾的內容，如果是空資料夾的話也沒關係，它會建立 .kiro 資料夾並產生 steering 文件，因為這階段我們還沒告訴它任何的需求，所以產出的文件可能不會太準確，稍後再來更新它即可。

3. 執行 spec-init

接下來要請 AI 根據我們的需求產生文件，使用的指令是 spec-init “功能描述“，這邊以這個外掛為例：

送出指令後它會問你一些相關的問題，協助釐清我們沒想到的部分：

將問題複製起來到文字編輯器並回答完成後再貼給它，AI 就會把我們的需求一併整合到需求文件。這個步驟完成後就會看到在 .kiro/specs/功能名稱/ 的資料夾底下就會多出四個文件，每個新功能都會是獨立的資料夾。

除了上述提及的 Requirements、Design、Tasks 外，spec.json 是用來控管文件審核進度的檔案，它長得像這樣：

可以看到 approvals 下面有每個文件的狀態，分為 generated 以及 approved，這代表文件是否產生完成以及是否審核過，每個階段都要把 approved 手動改為 true 之後，才能執行下一個階段。

4. 執行 spec-requirements

前置作業完成後就要來產生需求文件，執行 /sepc-requirements feature_name 就會產生這個功能，記得 feature_name 對應到的是 spec.json 裡面的資料，以上述為例，feature name 就是「ai-auto-slug-plugin」。

產出的需求文件會長這樣：

這邊會根據我們的需求以及回答結果整理出使用者故事、功能需求以及非功能性需求，仔細看過沒問題後，把 spec.json 裡面的 requirements 階段的 approved 改為 true：

5. 執行 spec-design

接下來進入架構設計的環節，一樣是 /spec-design ai-auto-slug-plugin，產生的文件如下：

它會根據需求文件產生流程圖、資料夾結構、類別名稱以及方法，這時候就能先檢視整個外掛架構以及是否有遺漏掉相關檔案，確認都沒問題後一樣把 spec.json 裡面的 design 階段的 approved 改為 true。

6. 執行 spec-tasks

最後是拆解代辦清單，執行 /spec-tasks ai-auto-slug-plugin，產生文件如下：

確認沒問題後一樣去修改spec.json 裡面的 tasks 階段的 approved 改為 true，到此規劃階段就已經完成了，就能著手進行開發，但在開發前會建議先跑一次 steering-update 把指南文件重新整理過一次，讓 AI 實際在寫的時候有最新版的參考資料。

實際開發的部分我會分階段執行，像是請它先執行第一部分，完成後我先驗收，看有沒有遇到什麼問題，都沒問題再繼續執行下一部分。

小結

以上四種方法都有各自對應的情境：

• 自動補齊 - 小修改
• 聊天開發 - 中修改
• 直覺開發 - 小創作
• 規格開發 - 大創作

我的話如果是要修改之前做過的專案，主要都會是用前兩者方式，如果是想要做一些自己玩的小工具，就會採用直覺開發，未來想做產品的話，我一定會採用規格開發。規格開發還有很多潛力，像是整理成視覺設計或是手機應用程式開發的版本，效果應該都會比直覺開發來得好。

7/26 的 WordPress 桃園小聚我會現場實際 Demo 這些開發流程，有興趣的朋友可以來現場交流喔：https://www.meetup.com/taoyuan-wordpress-meetup/events/309238278/​

​

​