從卡片到自然語言：人機溝通的進化
還記得小時候在計算機概論課上，老師提到早期計算機是透過卡片程式來控制。一疊卡片就是一串指令，放到讀卡機裡後，電腦就依序執行。後來，組合語言（Assembly）出現，能夠用一些較「可讀」的助憶碼來跟機器溝通。但是對大多數人來說，組合語言依然像天書一樣，艱澀難懂。
接著有了 C 語言，看起來已經親民許多，但還是有很多語法與記憶體管理細節需要工程師自行負責。一不小心就踩坑，需要抱著厚厚的書——例如「冼鏡光老師的名題精選百則：技巧篇」——一個例題一個例題地研究。再後來 Python 當道，語言結構與開發門檻進一步降低，開發者可以更專注在商業邏輯而非底層細節。
這樣的進化似乎顯示：人與電腦溝通的界面正不斷往「更直覺、更高階」的方式前進，甚至期望最終能用一句自然語言(或直接語音)就讓電腦自動執行任務，而不必關心程式語言本身的細節。
GenAI 的出現：程式開發的曙光
自從 ChatGPT 這類大規模語言模型（LLM）出現以後，輸入一段自然語言需求，就能讓模型幫忙產生程式碼、甚至直接接合其他系統，似乎就看到了「出一張嘴，電腦幫你完成」的苗頭。雖然距離完全免開發者之手還有一段路，但「根據自然語言快速產生程式碼」已經相當可行。對於許多初階工程師而言，這或許意味著「已經比不過 ChatGPT 了」，因此有人也開始擔心：「工程師會不會被 GenAI 取代？」
然而，開發一個軟體或系統，其實不僅僅是「寫程式」而已。前置的需求收集、需求分析、架構設計，以及後續的測試、維運、升級……都相當關鍵。其中最重要且最困難的部分，往往是需求本身。如果需求沒有釐清，程式寫得再好、再快，也無法真正解決使用者問題。反觀 GenAI 的強項雖然在快速生成程式碼，但對需求本身的理解與抽象力還是有所不足。
當前的 GenAI 開發模式：大量的 Prompt 與反覆調整
回想一下，現在多數人利用 GenAI 協助開發的實際流程，大致是：
- RD（開發者）先將需求拆解成多個小功能或小領域的描述。
- 將這些描述以 Prompt（提示）形式丟給 GenAI，讓它產生程式碼。
- 人工 Review 產出的程式碼，若不符需求或存在錯誤，就再調整 Prompt 讓 GenAI 重新生成。
- 重複以上步驟，直到功能完成。
- 進行測試、修正缺陷、最終整合系統。
上述流程中最耗時也最繁瑣之處，在於「反覆溝通」：Prompt 如果不精準，或 GenAI 誤解需求，都需要再度修正描述、嘗試多次。這些時間成本對企業與團隊來說並不低。
引入 Specification By Example：明確化需求，減少反覆
那要如何優化這種「反覆試錯」的過程？Specification By Example（SBE） 就是一個有效的方法。SBE 核心觀念在於，用自然語言或領域語言(如 Gherkin 語法) 來描述需求，並透過「具體範例」讓 PM、開發者、測試人員在討論中對「系統需要做什麼」達成共識。這些範例會包含：
- 前置條件（Given）：系統一開始的狀態或環境。
- 觸發動作（When）：使用者或外部系統所做的動作。
- 預期結果（Then）：系統預期回應或狀態的變化。
以下是一段簡單的 Gherkin 範例：
Feature: Bank Account Management
In order to keep track of my savings
As a user
I want to be able to deposit money into my account
Scenario: Successful deposit
Given a bank account with balance 100
When the user deposits 50
Then the account balance should be 150
在這裡，需求不再是抽象的描述，而是清晰定義了「當使用者把 50 元存入餘額 100 的帳戶後，系統應回應餘額為 150」。一旦 PM、RD、QA 共同確認了這個範例，就能避免許多模糊空間。
SBE 與 GenAI 的結合：減少誤解，快速生成程式
有了清楚的範例之後，GenAI 能藉由這些範例中明確的步驟、數據、與預期行為，更精準地生成程式碼與測試程式。若我們採用 Python 來實現，先把需求範例丟給 GenAI 之後，它有機會產生類似以下的程式碼：
class BankAccount:
def __init__(self, initial_balance=0):
self.balance = initial_balance
def deposit(self, amount):
self.balance += amount
return self.balance
# 測試程式碼 (pytest 格式)
def test_deposit():
account = BankAccount(100)
account.deposit(50)
assert account.balance == 150
這樣一來，SBE 提供了一個「需求的明確框架」，同時透過範例管理需求預期結果。GenAI 擅長的，是根據明確 Prompt 生成實作程式碼和測試程式碼，兩者搭配能顯著降低開發人員在溝通與試錯上的時間。
結論：SBE + GenAI = 更高效率的開發流程
在 GenAI 帶來的時代革新中，開發者真的會被取代嗎？從目前看來，大多數工作仍然需要人類在「需求」和「決策」層面進行把關與溝通。Specification By Example 與 GenAI 結合後，可以更有效地分工：人負責釐清需求、設計範例、確認邏輯；AI 負責根據準確的描述與範例生成程式碼與測試。彼此的優勢相輔相成，最終幫助團隊更快速且正確地打造系統。
- 對 PM 而言：SBE 能確保需求更容易被理解與落實，減少在開發過程中產生的誤解。
- 對 開發者(RD) 而言：GenAI 可以分擔較為繁瑣的程式撰寫與測試自動化工作，開發者則能將精力聚焦在更高階的架構設計或流程優化。
- 對 測試人員(QA) 而言：SBE 讓測試案例在需求階段就定義清楚，搭配 GenAI 生成的測試程式碼，可大大提升測試覆蓋率與效率。
因此，在這個「一張嘴就能生成程式」的時代裡，工程師並非被取代，而是角色和工作方式將進一步演化。SBE + GenAI 無疑會成為未來軟體開發流程的關鍵組合，讓整個團隊都能在正確方向上，更快速、更精準地完成軟體產品的開發與維運。
發表迴響