從瀏覽器對話到 AI + BDD：我的 AI 輔助開發演進史
最近參加了 AI + BDD 的工作坊，讓我開始回顧這段時間以來，我們使用 AI 輔助開發的方式一直在變化。每個階段都會根據專案需求和團隊狀況調整使用形式，而這些轉變背後，其實反映了整個 AI 開發工具的技術演進軌跡。這比較不像是心路歷程，而是一種使用形式上的紀錄，因為我們會有各種形式轉變來符合工作現況。
第一階段：瀏覽器對話時代
在最初的階段，我們主要透過瀏覽器與 AI 互動。當時的架構是 AI Kernel 透過 without Environment 到 Browser，形成隔離式的網路互動。AI 被完全隔離在網路另一端，我們透過 Conversation 和 Prompt 進行人機協作，溝通管道相當有限。
這裡的「without Environment」概念是指 AI 並不會直接觸碰到我們開發者使用的環境。AI 完全無法觸碰開發者的本地環境，包括 IDE、檔案系統、執行環境，只能透過瀏覽器進行純文字對話。
核心痛點：Context 搬移的負擔
這個時期的開發者會開始使用 AI 來解決日常問題，像是直接詢問 AI「我目前的程式遇到了困難」，然後貼上一段程式碼詢問是不是有哪邊漏看了，或是不給 AI 程式碼，直接詢問「什麼情況下我應該怎麼實作」。幸運的時候問題就可以得到解決，不幸的時候只好摸摸鼻子回頭自己想。
最大的痛苦是必須人工不斷替 AI 以及我的環境做 context 搬移，要把情境資料一再移除和重建。具體包括手動複製檔案內容、設定檔給 AI，反覆描述專案架構和相依關係，解釋錯誤發生的環境背景。AI 看不到完整 call stack 和檔案間關聯性，缺少執行時的 runtime context，每次都要重新建立 context。
這就像是「隔著玻璃窗的技術顧問」，AI 很聰明但完全碰不到你的工作環境。
Prompt 演進與心流效應
由於缺乏環境 context，我們會努力提供豐富的情境。為了讓 AI 理解邊界條件和預期行為，我們從簡單的 One-shot 演進到 Few-shot 的詳細範例描述，補彌 AI 無法看到完整程式碼庫的限制。
有趣的是，由於實際情環境的缺乏，我們努力在補彌情境以便讓工作可以順暢進行。在這個時期我發現我的工作異常專心，很容易進入心流，因為我正努力地向 AI 解釋我到底在做什麼、我希望它幫忙我什麼，以及我目前遇到的挫折。
這種「被迫專注」產生了意外的心理效益：強迫自我釐清思路、語言化思考、專注當下問題。類似小黃鴨除錯法的效果，在向 AI 描述問題的過程中，常常自己就想通了。
被動的技術演進
這個階段到下一階段的轉變，推動變化的不是使用者。技術演進的主導權不在開發者手上，我們只是隨著技術發展的節奏，成為「被動適應的人類」。工具廠商推出新功能，我們就學習新的使用方式。
第二階段：Copilot 混用時代
進入了 Copilot 時代，出現了關鍵的架構突破：AI Kernel 多了一條路徑「The Context → with Environment → Editor」，AI 可以 Access FileSystem，直接接觸開發環境。從 Browser 對話變成 Editor 內的即時協作。
環境感知與有限信任
AI 終於可以看到檔案系統，獲得專案 context 和環境感知能力。協作方式從「隔空問答」變成「肩並肩寫程式」，不再需要手動複製貼上 context，AI 可以直接在編輯器中提供建議。
但在這個時期，我們對 AI 的信任並不是太多，所以它背負的權限只有簡單的程式碼自動完成，大家按著 Tab 生成程式碼，進行很基礎的文字接龍。這個階段很像是「試用期員工」，AI 有了看到工作環境的能力，但我們還不敢讓它做太複雜的事情。
混用策略的動機
在這時候大部分開發者比較傾向於混用瀏覽器以及 VS Code Copilot。混用的理由主要是瀏覽器上有更多 AI 供應商，我們可以隨心所欲選擇不同來源，像除了 ChatGPT 還有 Claude、Grok、Google Gemini 等。
VS Code Copilot 的限制是通常綁定特定 AI 模型，選擇較少。混用的策略考量包括：不同 AI 有不同強項，可以交叉驗證答案品質，避免單一依賴。儘管我們現在知道後續 Copilot 已經成為某種模型入口網站，但在那個時候選擇還是挺有限的。
錯過的平行發展
同時間我並沒有注意到各種 AI Editor 已經大放異彩，例如 Cursor 或是 Windsurf，它們直接在 VS Code 之上去實作自己的 Plugin。這些東西是我一直到今年也就是 2025 年初才開始接觸的，我想保守一點應該算年中。
Prompt 的情境適配
進入 AI Editor 時代後，我們給的 Prompt 反而不長了，因為 AI 自然擁有各種檔案的範例，只要提醒它參考某個檔案就可以了。從複雜的情境描述變成簡潔的「參考 user_model.py 的模式，幫我寫一個 order_model.py」。
當然我要說的是，每個使用情境下你應該提供的 Prompt 風格會不一樣，所以不是說以前的東西不再需要了，只是我在回憶的時候意識到了這件事情。在 IDE 環境下，我們用更少的提示獲得更多成果。
第三階段：專用 AI Editor 時代
社會化的信任轉變
在這兩個階段之間的過渡期，它不只是代表著技術的演進，而是代表著人們越來越相信使用 AI 能夠提升生產力。這不是單純的 FOMO，因為已經有部分人獲得好處了，剩下的人我們當然也要追趕上去獲得同等福利。
接觸 Cursor、Windsurf 主要是因為它們提供比 Copilot 更好的回應速度。開發過程中 AI 回應速度直接影響工作流暢度，太慢的回應會打斷思考節奏。
權限擴張的集體現象
在 AI Editor 出現之後，我們釋放了更多權限。AI 可以自己決定要不要建立檔案，並且把檔案放在適當的地方，同時取了適合的名字，再省下了很多開發者在開發過程中會猶豫的內容。至少資訊科學領域的兩大難題：命名以及讓快取失效的問題，它解決了一半了。
這個擴張我不確定是不是漸進式，而是當我意識到這現象已經發生的時候，大部分的人都願意這樣使用。但儘管我說大部分的人，僅限於我周遭的好朋友或是熟悉的人，也許我該稱它為同溫層。
當然大家是依循著各自公司的政策使用 AI 的，如果公司不讓你這樣用，那至少他們會在家裡私下的時間這樣使用，因為現在工作上用不到不代表以後工作上用不到，總是要熟悉一下跟上時代。
Context Window 的系統性解決
但是在 AI Editor 的用法上帶來新的問題，但它其實不是新的問題，因為 AI 模型的 Context Window 限制，我們常常得反覆重啟對話來重新描述我正在做的工作內容。
實際上這情況還是可以接受的，反正我每次啟動成本不高，它只是比較煩人而已。所以這時候發展出的 Prompt 技巧就是所謂的 Memory。
所謂的 Memory 就是要求 AI Editor 在計劃階段開始實作前，先把它寫到實體的檔案上，並且列出各個實作項目的進度。它是一個簡單的 ToDo List，它只要看到做完了就打勾，一旦這個 ToDo List 的內容都打勾了，就是完工了。
各家的 AI Editor 大致上都有實作一些幫你簡化啟動情境的設施，像 Cursor 就有提供 Cursor Rules (.mdc 格式)。搭配著 Cursor Rules 以及使用檔案紀錄的 Memory，我們可以克服了 Context Window 必須重啟的問題。
不過，有些開發者發現這些長期性的規則不一定總是被使用或是被回想起來，所以偶爾還是要提醒 AI 回想一下它是不是應該遵守什麼原則。
第四階段：AI + BDD 時代
最終於進入到 AI 以及 BDD 的階段，也就是我最近所處的階段。應該是說我認為這大概是我今年開始主流的實作方式，因為我們用 Memory ToDo List 來管理工作進度，它缺少了一個關鍵的功能，就是它雖然能夠用 PlanMaster 來規劃內容，但我們沒有一個好用的檢查方式確認是不是完工，至少檢查的方法並不是精確的，無法提供明確的成功或失敗回應。
從「做過了」到「做好了」
換句話說，我們過去在 ToDo List 裡面打個勾，只是 AI 跟我們說它做過了，但它並不知道它是不是做好了。現在換成以 BDD 為起手式的話，包含我們要完工的測試案例，它就可以有信心地說它做過了也做好了。
過去的 ToDo List 時代，AI 的回答是「我做過了」，實際狀況是 AI 不知道是不是做好了，驗證方式是人工測試、主觀判斷。現在的 BDD 時代，AI 的回答是「我做過了也做好了」，信心來源是測試案例通過了，驗證方式是自動化測試、客觀標準。
關鍵差異是：以前勾選等於「我寫了程式碼」，現在通過等於「程式碼符合需求並且測試驗證過」。AI 的信心提升從「我覺得做完了」變成「測試證明我做對了」，從主觀判斷變成客觀驗證，從不確定變成有信心。
完整的品質保證流程
因為我們有堅實的測試程式可以去驗證內容，當然在配合我們既有的軟體開發流程，進行 PR Review 來審查我們的功能是不是符合 Definition of Done。
這形成了三重保障：AI + BDD 驗證的自動化驗證，PR Review 的人工審查，Definition of Done 的標準確認。我們對工作的完工率以及成功率會更有信心。
BDD 的抽象價值
抽象來說，BDD 它是試著把 context 的顆粒度提升到更好的精細度，以及品質內容輸出的優化。當然中間會涉及到你如何寫 BDD feature file 這件事暫不討論，但我們已經知道過去的 ToDo List 可以有更好的優化方向。
Context Contributor：協作品質的提升
以我個人而言，這個優化方向叫做成為更好的 Context Contributor。
概念的核心
Context Contributor 的概念是要提供更多多元的情境來源，因為不是所有的情境都可以方便集合到我的執行環境上。例如你正在苦惱怎麼設定 Nginx，你可以把情境拉進來讓 AI Editor 或 Agent 一起思考。當然我們要加個警語：你不應該在正式環境上做這件事情，請使用你的實驗環境實驗，把事情參數化了再寫成正式的部署檔案。
Context Contributor 是概念，可以有多種實作方式。像我自己實作只是用的簡單的 HTTP Service 來代替而已，提供 RESTful API 或簡單的 endpoint。優勢包括技術門檻低、整合容易、除錯簡單、擴展彈性。
演進的方向
從最初的「情境搬運工」（手動複製程式碼給 AI，努力描述問題背景），到「情境混用者」（Copilot + 瀏覽器雙軌並行），再到「情境管理者」（Memory 檔案、Cursor Rules），最終成為「情境貢獻者」：透過 BDD 提升情境品質，建立可自我矯正的協作框架，不只消費情境而是持續優化情境。
在我經驗中，這種演進不只是技術的進步，更是工作方式的根本轉變。我們正在學習如何成為更好的 Context Contributor，為 AI 協作建立更可靠、更有效的框架。
展望與結語
所以到現在為止，我目前正在朝這個階段努力及練習，試著把各種工作轉換成這樣子的形式。所以在下個階段我們必須要在各種領域找到軟體開發裡面的 BDD 的工具組。我們不是追求形式上的貨物崇拜，而是要串起一個完整可以自我矯正的 context。
回顧這段 AI 輔助開發的演進，我發現我們不只是被動地跟隨技術發展，而是在每個階段都嘗試找到最適合的協作方式。從最初的瀏覽器對話到現在的 BDD 驗證，每一步都在解決前一階段的痛點，同時也帶來新的挑戰。
但這樣真的比較好嗎？我想了想，可能是因為我們逐漸從「AI 工具使用者」進化成「AI 協作品質的貢獻者」。我們不再只是消費 AI 提供的功能，而是主動設計和優化整個協作流程，讓人機協作產生更高的價值。
在我經驗中，這種演進不只是技術的進步，更是工作方式的根本轉變。我們正在學習如何成為更好的 Context Contributor，為 AI 協作建立更可靠、更有效的框架。