昨日回顧與今日目標

在 Day 28 的探討中，我們審視了在專業環境中使用 AI 的倫理、版權與隱私議題，並認識到作為一個負責任的開發者，我們需要擁抱 AI 的能力，也要理解其邊界。

今天，我們將不再學習新的知識點，而是要將這 28 天所學的一切，應用到一個最真實的場景中。

今天的目標：以第一人稱的視角，體驗一位開發者在 AI 協作模式下，高效、穩健地度過一個典型的工作日 (大家就當看故事就好)。

09:00 AM - 站立會議 (Stand-up Meeting)

咖啡在手，我，Kevin 和 Jake，三名 Go 後端開發者，加入了線上的每日站會。
產品經理 (PM) Sarah 帶來了一個好消息和一個壞消息:

• 好消息是，VIP 功能反響熱烈，她希望乘勝追擊，增加一個新的 VIP 專屬優惠。
• 壞消息是，QA 團隊的 Leo 發現了一個緊急的 Bug。

我的 JIRA 看板上多了兩張票：

• BUG-1337: 優惠碼輸入框在處理包含 emoji 的字串時，會導致服務 panic。
• FEAT-2048: 為 VIP 會員新增一個專屬折扣：購物滿 200 元，可以額外再減 20 元。

新的一天，新的挑戰開始了。

10:00 AM - 任務一：修復 Bug，從測試開始

處理緊急 Bug，最忌諱的就是直接修改程式碼。在沒有測試保護的情況下，很容易「按下葫蘆浮起瓢」，所以我決定先從修復 BUG-1337 開始。

定位問題程式碼

我很快找到了處理優惠碼的函式 ApplyCouponCode(code string)。果然，這是一段沒有任何測試的 Legacy Code，裡面有一些字串處理邏輯。

詠唱 AI，進行程式碼通靈 (Day 23 技能)

我不敢直接修改，打開 IDE，選取 ApplyCouponCode 函式，然後對 Copilot Chat 下達指令：

"你是一位逆向工程師，我不敢修改這個沒有測試的舊函式。請為它編寫一套『特性測試』，用來鎖定它當前的行為。"

幾秒鐘後，AI 為我生成了一套 _test.go 檔案，裡面包含了多個測試案例，描述了舊函式在處理正常、空字串、特殊符號等情況下的行為。我執行 go test，所有測試都是綠燈。很好，第一層測試建立完畢。

復現 Bug，點亮紅燈

現在，我要把 QA 報告的場景轉化為一個會失敗的測試。我在 AI 生成的測試檔案中，手動增加了新的測試案例：

t.Run("should not panic with emoji coupon", func(t *testing.T) {
    assert.NotPanics(t, func() { ApplyCouponCode("優惠碼😊") })
})

再次執行 go test -v ./...，紅燈亮起！ 測試失敗，並報告了一個 panic。我成功地在本地穩定復現了這個 Bug。

詠唱 AI，輔助修復

我將 panic 的錯誤訊息和code stack trace 貼給 Copilot Chat：

 "我的這個新測試失敗了，顯示在處理包含 emoji 的優惠碼時發生了 panic。請幫我分析ApplyCouponCode函式，並修復這個 Bug，讓它能健壯地處理 Unicode 字元。"

AI: `舊程式碼中可能使用了 for i := 0; i < len(code); i++ 配合 code[i] 的方式來遍歷字串，這在處理多位元組的 UTF-8 字元（如 emoji）時是不安全的。它建議我將其修改為 for _, char := range code 的方式。

綠燈，任務完成

我接受了 AI 的建議，替換了程式碼，再次執行所有測試，不僅新的 Bug 測試通過了，所有舊的特性測試也依然安然無恙，這證明我的修復是精準的，沒有引入任何新的迴歸問題。
我將程式碼提交，然後在 JIRA 上將 BUG-1337 拖到「完成」列，出門買個吃到等等繼續。

02:00 PM - 任務二：ATDD 驅動新功能開發

下午，我開始處理新功能 FEAT-2048。 這是一個全新的業務需求，非常適合用 ATDD 的流程來確保我完全理解了 PM 的意圖。

與 PM 對話，詠唱 .feature (Day 25 技能)

我找到 PM Sarah，確認了幾個邊界問題（「是正好 200 元就減，還是大於 200 元才減？」）。接著，我會打開專案中的 features/cart_discount.feature 檔案，對 AI 下達指令：

Prompt: "你是一位業務分析師，請在現有的 Gherkin 場景下，再增加一個新的 VIP 折扣場景：一個 VIP 使用者，購物車總價為 250 元時，經過兩次折扣後（先打九折，再減20），最終價格應為 205 元。"

執行 godog，看到引導 (Day 25 技能)

AI 幫我生成了新的 Gherkin Scenario，我執行 godog，控制台提示我，它不認識一個新的步驟：Given I am a VIP user。

實現步驟，驅動 TDD (Day 26 技能)

我來到 features/cart_discount_feature_test.go，實現了這個新步驟，它會在測試上下文中設定一個 isVIP 的旗標。
這個改動，自然地要求我的 cart 核心邏輯需要能接收 isVIP 這個參數。於是，我轉到 cart/cart_test.go，啟動了 TDD 的內循環。

• 紅燈： 我增加了一個新的單元測試 t.Run("VIP user with high value cart", ...)，assert 一個 VIP 的 250 元購物車，FinalPrice() 應回傳 205。這個測試立刻失敗了。
• 綠燈： 我將這個目標交給 AI："我的 FinalPrice 函式需要考慮 VIP 狀態。請修改函式，增加對 VIP 會員的邏輯判斷，讓這個新的 VIP 測試案例通過。"
• 重構： AI 修改完程式碼後，我審視了一下，發現折扣邏輯的 if-else 變得有點複雜。我再次請求 AI："請幫我重構這個函式，讓折扣計算的邏輯更清晰，也許可以把不同的折扣規則抽離成一個策略列表？" AI 給出了一個使用策略模式的建議，我看後覺得很有啟發，便採納並微調了它。

ATDD 驗收通過 (Day 26 技能)

當 cart 套件的 TDD 循環全部完成後，我回到專案根目錄，自信地再次執行 godog。所有場景，包括最新的 VIP 場景，全部變為綠色！

05:00 PM - 收尾與反思

一天的工作接近尾聲。我把今天的所有修改發一個PR，並在在填寫描述時，我使用了 Copilot Chat 的 /explain 功能，為我的變更自動生成了清晰的註解和說明，這讓 Code Review 的同事能更快地理解我的思路。

最後，靠在椅子上，手上拿著一杯25年山崎威士忌 ，回顧這一天：從修復一個 Bug，到開發一個全新的、由業務驅動的功能，每一步都清晰、穩健、高效。測試不是負擔，而是我安全感的來源；AI 不是威脅，而是我用錢換來的能力的放大器。
這就是新時代開發者的工作流——穩健、高效、且始終與業務價值對齊。

今日總結

今天，我透過一個故事，將整個系列所學的知識進行了一次性的整合。我們看到了一位現代開發者，是如何在一天中，靈活地運用特性測試、TDD、ATDD 和 AI 協作，來遊刃有餘地應對真實世界中的各種挑戰。
我想這不再是遠景，而是目前我們該邁進的開發的樣貌。

預告：Day 30 - 完賽總結 - 重新定義我的開發流程
我們的旅程即將到達終點。明天，我們將進行最後的回顧與展望。我們將總結這 30 天的學習。