工程師的責任

說穿了軟體開發這件事，就是軟體交付的各種變化型態。從古老的瀑布式開發，到後來全球風靡的敏捷開發，總之就是有人點菜，我們出餐而已，但是我們理解這個訂單，到怎麼製作餐點，到如何讓客戶不斷回頭點菜的循環，讓整個軟體開發產業可以輪迴。

Bug的存在不是污點不是錯誤，他就是Bug

有些工程師會覺得寫出有bug的程式是一個屈辱，但bug的存在他就是一個系統性必然會發生的事情，所以我們看待Bug應該從管理的角度去看待，怎麼管理bug，怎麼有系統的控Bug的發生，才是軟體開發的核心，以心態來說我們要用很中立的心態去想他，但為何會突然提到Bug呢？待我娓娓道來。

Bug的管理有一個很專業的職位叫做QA，全名是Quality Assurance，中文叫做品質保證，簡稱品保，這個職位不是只是不段的測試各種情境，然後把bug揪出來，實際上他是在整個開發流程都要導入的一種很哲學的思想，甚至這個職位他會需要知道開發流程，知道整個開發有可能會出錯的點，能不能承受出錯後的風險，要在設計的時候就做到安全保障，在製作完成之後要使用哪些方式測試來找到問題，目的只有一個，產品出去之後的品質要夠好。

我其實不在意我搭的高鐵是人蓋的還是機器人蓋的

所以照理說我們把QA做好，全部都用AI開發應該都沒問題，那我們要怎麼做呢？

第一個：TDD Test-Driven Development

我們在許多地方應該都可以聽過這個有名的開發法，其實道理很簡單，所謂Driven就是要求你先寫測試，再去開發功能，最後用自動化測試的方式確保的你的程式碼是會正確運行的。聽起來這是在工程師開發的時候很合理，但在AI開發的時候這件事會帶過我們什麼好處呢？

大家應該知道現在的AI也就是所謂的LLM大型語言模型，基本上還是建立在文字接龍這件事情上面。也就是每個字產生的時候還是透過猜測、選擇機率最高的字來接龍，所以依照這個模式去想的話，若模型的參數不夠大，或者是模型本身的能力不夠好，寫好的程式可能連跑都會有問題，所以用TDD的方式，我們可以讓AI反覆讓他測到綠燈為止，這就是我們可以在AI裡面套的一個紅綠燈模組，直到所有項目都變成綠燈了，那代表這個程式可以順利跑過。

第二個：BDD Behavior-Driven Development

BDD是行為驅動開發，這是從TDD慢慢演化而來的，他是用簡單的Gherkin 語法：Given/When/Then，來描述整個程式的行為，基本上他就是自然語言寫出來的東西，例如：

Feature: 鏡頭型錄過濾
作為使用者
我想要只看到我的機型實際支援的鏡頭
這樣才不會選到用不了的鏡頭

Scenario: 非 Pro 機型不顯示望遠鏡頭
Given 使用者的裝置是 iPhone 16（非 Pro）
When 使用者打開鏡頭型錄
Then 型錄中不應出現望遠鏡頭
And 應出現廣角鏡頭

Scenario: iPad 不顯示超廣角鏡頭
Given 使用者的裝置是 iPad
When 使用者打開鏡頭型錄
Then 型錄中不應出現超廣角鏡頭

以上就是用自然語言寫出來的行為，這個東西我們人類可以看得懂，AI也很會寫，所以我們就可以在開發之前就可以想像，這些東西我們都有照顧到，如果沒有BDD很容易會出現，假如使用者沒有支援的鏡頭，也許就跳一個彈跳視窗讓使用者離開，雖然這兩這件事都可以達到不讓使用者使用沒有支援的鏡頭，但體驗上就會有很大的差異，所以我們也為了讓AI可以很確切的讓我們想要開發的東西更可靠，事先的準備也是非常重要的。

第三個：SDD Spec-Driven Development

我們在開發程式的時候，經常會遇到很多我們其實沒有想到的規格，有時候AI就會幫我自己想好，但往往都是你已經開始用的時候才發現這不是你要的東西，所以在AI真的開始工作之前，我們最好就能把想要的規格都想好，甚至怎麼實作，用什麼方法實作都可以讓我們先看過，大致上有過概念讓AI再去發揮，我們就更可以在後續的開發給上更多的建議。所謂的Spec就是我們的規格，當規格越詳盡，AI就越能知道要怎麼做，所以用規格來管理開發也是AI coding裡必須要有的概念。

實際上要怎麼用這些東西來開發，就請見下回分曉