前言

最近在測試 Vibe coding的極限，主要採用 Claude Opus 4.5，搭配 GitHub Copilot Pro 前前後後大概燒掉將近 16 個用量，一口氣完成四個實際專案。實戰下來，我的感覺是：AI 對 prototype、小型專案或 PoC 來說非常好用，但當專案規模變大、邏輯變複雜時，各種限制與踩雷點就會一個一個浮現。

這篇文章就把這段期間最真實持態調整整理起來，分享如何和AI 一起開發

一、複雜或不明確的需求，AI 容易卡住

這是目前 AI 輔助開發最明顯的限制之一。當功能需求太複雜或描述不夠明確時，AI 常常會：

• 做到一半就中斷，需要人去按下繼續
• 太大或複雜的的功能，產出不完整的程式碼
• 反覆修改卻始終無法達到預期

另外要補充的是：就算規格寫得很詳細，AI 也不一定能一條龍直接做對，很多時候它少了專案脈絡（既有流程、不能動的邊界、隱含規則），就會在某一步開始偏航。

常見原因：

• 沒講清楚哪些不能改、哪些必須沿用
• 漏掉錯誤情境/權限/效能等「非功能需求」
• 跨模組耦合，AI 會自行腦補而不一致

實際案例： 當我請 AI 幫忙重構一個涉及多個模組、需要處理複雜商業邏輯的功能時，它經常會在執行過程中「迷路」，忘記前面已經完成的部分，或者把需求理解偏了。

建議做法：

1. 拆解任務：把大功能拆成小步驟，一步一步讓 AI 完成
2. 明確描述：給出具體的 input / output 範例，減少模糊空間
3. 設定邊界：明確告訴 AI 哪些不用動、哪些是重點

二、翻寫系統時，AI 容易產生幻覺或發散

這點讓我印象深刻。即便已經提供了舊的程式碼作為參考，如果沒有盯著 AI 的輸出，它還是可能會：

• 產生幻覺：自己發明一些不存在的 API 或方法
• 過度發散：加入原本不需要的功能或設計模式
• 忘記上下文：前後程式碼風格不一致

實際案例： 在翻寫一個舊系統的模組時，我提供了完整的舊程式碼，但 AI 還是在某些地方「自由發揮」，用了一些根本不存在的 library method，如果沒仔細看就直接用，上線肯定會爆炸。

建議做法：

1. 分段檢視：不要一次讓 AI 產出太多程式碼，分段檢查
2. 明確約束：在 prompt 中強調「只使用現有的 API」、「不要新增額外功能」
3. 人工 Review：AI 產出的程式碼一定要親自過目，尤其是關鍵邏輯

三、Agent Skill：讓 AI 不只會寫程式

這次玩下來最有趣的發現是 Agent Skill 的概念，透過 MCP (Model Context Protocol) 機制，可以讓 AI 具備「執行能力」，而不只是產出文字或程式碼。

什麼是 Agent Skill？ 簡單來說，就是預先定義好一些「技能」，讓 AI 可以：

• 執行終端機指令
• 操作檔案系統
• 呼叫 API
• 查詢資料庫
• 管理 Git 操作

實際應用：

• 請 AI 幫忙檢查 Git 狀態、建立 commit
• 讓 AI 自動執行測試並回報結果
• 整合部署流程，AI 可以一鍵執行

這讓 AI 從「顧問」變成「助手」，真正能動手做事，而不只是給建議。

四、前端開發，搭配模板效果很好

這是目前 AI 輔助開發效果最好的場景之一。只要：

• 需求不是太複雜
• 有現成的模板或 UI 框架
• 有明確的設計稿或參考

基本上可以放心交給 AI 處理，它能快速產出符合預期的前端程式碼。

適合 AI 處理的前端任務：

• 切版 (HTML/CSS)
• 元件封裝 (React/Vue Component)
• 表單處理
• API 串接
• 簡單的互動效果

不太適合的情況：

• 複雜的狀態管理邏輯
• 需要深度客製的動畫效果
• 效能優化相關的調整

五、C# 和 Java 比腳本語言燒 Token 更快

這是一個容易被忽略的成本問題。由於 C# 和 Java 這類語言的特性：

• 語法較冗長：相同邏輯需要更多行數
• 強型別系統：需要定義更多型別和介面
• 物件導向與抽象層較多：在大型專案中常見各種分層與介面（DTO / Service / Repository / Interface）或抽像(Abstract)，上下文一長就更吃 Token
• 命名空間與 import：每個檔案都有一堆引用

這導致 AI 在處理這些語言時，Token 消耗速度明顯比腳本語言快。

為了避免token 大量消耗，我會請AI先依據原本的程式脈絡撰寫Skill.md 或Instruction.md

有些比較小的專案我會採用 Next.js 全端開發，這樣比較省token

後來我選擇用 Next.js 來開發，主要原因是：

• 前後端統一語言：都是 TypeScript/JavaScript，不用在 C# 和前端之間切換
• 縮小 Context 範圍：同一個專案內，AI 更容易理解整體架構
• Token 消耗更低：相較於 C#/.NET 專案，同樣功能的 Token 消耗更少的Token
• 熱門框架支援好：AI 對 Next.js 的理解程度高，產出的程式碼品質也比較穩定

這樣做的額外好處是，當我請 AI 幫忙處理一個功能時，它可以同時看到前端元件和後端 API Route，更容易產出一致且正確的程式碼。

總結：AI 是好幫手，但不是萬能

經過這幾天的實戰，我的結論是：

AI 擅長的事情： ✅ 明確、重複性高的任務
✅ 有模板可循的開發工作
✅ 快速產出初版程式碼
✅ 協助 Debug 和 Code Review
✅ 自動化流程的整合

AI 不擅長的事情：
❌ 複雜、模糊的需求定義
❌ 需要深度理解業務邏輯的開發
❌ 完全無人監督的程式碼產出
❌ 效能調優和架構決策

最重要的心態轉變是：不要期待 AI 能一次到位．把它當成一個很聰明但需要指導的 Junior/Middle 工程師，給明確的指示、分段檢查成果、適時修正方向，這樣才能發揮 AI 輔助開發的最大價值。

後記

AI 工具的發展速度很快，今天的限制可能明天就被突破，但無論工具多強大，工程師的判斷力和經驗依然是不可取代的。善用 AI 加速開發，同時保持對程式碼品質的把關，才是在 AI 時代最務實的開發策略。