Vide coding 的混亂與誤區
最近許多軟體團隊開始嘗試用 AI 幫忙寫程式,但用的方法卻五花八門。常見做法是靠 prompt(提示詞)、語音描述甚至錄螢幕影片來告訴 AI 要做什麼。但這樣做的結果常常很混亂:AI 生出的程式碼對不對心裡沒底、沒辦法自動化測試、更無法重複取得相同結果,整個開發流程變得像在摸彩。有工程師戲稱,現在很多人在玩的「即興開發」(vibe coding)根本像是在賭博,下 prompt 就像拉下拉霸,運氣好才能中一個能跑的功能。然而在專業軟體開發中,這種賭運氣的方式注定走不遠。
痛點很快就浮現了:如果我們只是丟個 prompt 讓 AI 自己發揮,得到的程式碼品質參差不齊,有時甚至連能不能執行都不知道。團隊投入大量時間反覆試錯,卻無法建立可靠的開發流程。有開發者分享他的慘痛經驗:一開始覺得用 ChatGPT 和 Cursor 對談就能「變出」功能,結果沒幾個月,幾乎全靠 AI 拼湊出來的產品開始崩潰,技術債壓得團隊喘不過氣。這說明了光靠靈感式的 prompt 開發,短期也許快,長期卻暗藏風險。
那麼 AI 程式開發要如何走上正軌呢? 要讓 AI 在開發流程中大規模發揮作用,唯一的正道是規格驅動(spec-driven)的做法,而不是靠 prompt 玩票式地碰運氣。OpenAI 工程師 Sean Grove 打過一個比方:「寫 prompt 像是即興表演,寫規格才像照樂譜演奏的交響樂。」意思是說,隨興的 prompt 就像爵士即興,結果難以重現;相反地,一份清楚的規格就像總譜,整個團隊和 AI 都能依此協調運作。總之,別把 AI 當成魔法許願機,我們應該把它納入正規的工程體系,讓開發流程跟傳統寫程式一樣穩健可靠。
為什麼不能靠 Prompt?問題出在哪裡
許多人可能會想,AI 那麼強,直接問它「請幫我寫一個可以怎樣怎樣的程式」不就好了嗎?可惜事情沒有想像中簡單。光靠 prompt 有幾個根本性的問題:
- 無法驗證正確性:AI 產生的程式碼對不對,不能只靠直覺或肉眼看幾行就算數。軟體碼是否符合需求,必須透過測試等客觀手段驗證。然而用隨機 prompt 得來的程式,往往缺乏明確的驗收標準。AI 生成程式碼其實是機率性的猜測,不見得一次就完全正確。沒有驗證機制的情況下,我們很可能拿到一份看似可行、實則隱藏 bug 的程式碼。
- 無法版本控制:傳統開發中,需求規格和程式碼都會納入版本管理,但 prompt 式開發卻很難重現過程。很多團隊用完 AI 就把 prompt 丟在對話記錄裡,後續也沒有保存。OpenAI 的 Sean Grove 曾形容,現在大家的做法就像「把原始碼碎紙機絞碎,卻小心翼翼地版本控管編譯後的二進位檔」,我們保留了 AI 生出的程式碼,卻沒有保存產生它的「來源」(提示內容)。如此一來,日後想查為什麼某段程式要這樣寫,根本無跡可循,更別說不同人之間協作接手了。
- 無法自動測試或交付:由於缺少明確規格和測試案例,AI 產出的程式碼沒辦法直接丟進自動化流程。傳統 CI/CD(持續整合/部署)流程需要有測試來保證每次修改都符合預期,但如果我們只給 AI 一段口頭描述,拿到的程式既沒有對應的測試,也沒有驗收準則。這意味著每次 AI 產生程式後,工程師都得親自跑一遍看看,無法像平常那樣自動化驗證,整個開發流程也就無法流水線化。
- 高度仰賴上下文:透過錄影或語音對 AI 下指令,很容易遺漏關鍵細節。人跟人用口語溝通本來就會有模糊地帶,更何況 AI 只看得到文字或聽得到聲音,很多背景假設它其實並不知道。MIT CSAIL 的一項研究把現今人機互動形容成「一條細得可憐的溝通管線」──我們丟給 AI 一點要求,它回吐一大串碼和幾個膚淺的測試,但 AI 並不真正理解我們更大的意圖。用非常非結構化的方式給需求(像一段隨意的對話),AI 只抓到片面的上下文,最後產出的東西往往牛頭不對馬嘴。
- 團隊知識無法傳承:如果開發過程都藏在某個工程師腦中(或他的 prompt 歷史裡),團隊其他人就難以介入和接手。想像一下,小明用語音跟 AI 搞定了一個功能,但除了他自己,沒人完整了解他到底跟 AI 說了什麼、取了哪些捷徑。等小明休假或離職,別人要維護那段 AI 寫的碼時,只能一臉問號地猜當初的用意。這種知識孤島現象讓團隊協作非常困難,每個人各自跟 AI 乾瞪眼,缺乏共同語言和紀錄,長遠來看專案會變得不透明且難以維護。

以上種種問題,歸根究柢在於:Prompt 是即興演出,而我們需要的是交響樂總譜。Prompt 式開發缺少正式的「源文件」來記錄需求和邏輯,導致無法驗證、難以協作,也無從建立穩定的自動化流程。
什麼是規格撰寫?解決了什麼問題?
談了那麼多 prompt 式的缺陷,那所謂規格驅動到底是什麼?其實概念並不新奇,就是回歸軟體工程的一條黃金定律:在寫程式碼之前,先寫規格(Spec)。所謂規格,就是對功能需求和業務邏輯的正式書面描述文件。它詳細闡述我們要讓軟體做什麼、怎麼做、做到什麼程度。一般一份完整的 Spec 會包含以下要素:
- 背景與目的:這個功能為何存在,要解決什麼問題。
- 功能需求:具體列出軟體應該具備的行為或特性。
- 流程與邏輯:如果有操作流程或演算法,逐步描述清楚,必要時附上流程圖。
- 輸入/輸出:定義函式或模組預期接受的輸入、輸出內容與格式。
- 限制條件:任何邊界條件、錯誤處理、性能要求等都要寫明。
- 驗收標準:怎樣算實作成功?可能以測試案例或使用情境來說明,只要軟體通過這些測試就表示符合需求。
簡而言之,Spec 就像是軟體的說明書+合約。有了這份說明書,人和 AI 就都有清楚的依據:人類開發者依規格檢查 AI 工作是否正確,AI 則根據規格執行實作。這正好對應前面那些痛點:
- 可驗證:因為有驗收標準和測試案例,AI 寫出的程式能不能達成規格裡訂的條件,一試就知道。
- 可版本控管:規格本身就是文件,可以像原始碼一樣納入版本控制,任何修改需求都留有紀錄,不會像口頭指令轉瞬即逝。
- 可自動化:有了規格,我們可以預先寫好自動測試,AI 每產生新程式,就跑一次測試確認是否符合規格,順利的話甚至可自動部署。
- 上下文明確:Spec 提供了完整的背景和細節,AI 不會因為一兩句模糊的提示就誤解。在 AI 工具中,我們可以把整份規格檔案提供給模型,確保它隨時參考完整語境。
- 團隊共享:規格文件是給整個團隊看的,共同維護、討論,知識不再只有某個人懂。就算負責的人更換,新同事讀懂規格就能接手工作。
值得強調的是,在規格驅動的流程中,人跟 AI 的角色有了新的分工:人負責定義問題,AI 負責執行解法。也就是說,人類工程師最重要的產出已經不再是程式碼本身,而是寫給 AI 看的規格。OpenAI 的研究員 Sean Grove 就直言,傳統的程式碼其實只是規格的「有失真投影」而已,我們應該把規格視作真正的源頭資產。他甚至強調,未來「誰寫規格,誰就是程式設計師」。因為只要規格寫得完整清晰,用什麼語言、哪種技術實作都可以交給 AI 去完成。
這股Spec-writing的風潮其實已經在業界萌芽。今年各大公司和技術社群也開始倡導「規格先行」的 AI 開發方法。例如,AWS 在 2025 年推出了一個名為 Kiro 的全新 AI 開發環境,就是完全圍繞「先寫規格再產出程式碼」的理念設計。傳統的 AI 助手等你寫 Code Prompt,但 Kiro 要求團隊先定義好需求規格,AI 再根據規格來自動構建和測試程式。再看開源社群這邊,許多開發者開始將測試驅動開發(TDD)和 AI 結合,強調測試其實就是一種可執行的規格:只要 AI 產生的程式通過所有預先寫好的測試,那就表示符合需求。甚至有人用Specification-as-Code這個詞,意思是把規格寫成機器可讀的程式碼(例如單元測試、介面定義等),讓 AI 在開發時有明確的指引和約束。
再從工程管理的角度看,文件為先的文化也越來越被強調。DevOps 業界人士 Laura Tacho(現任 DX 平台的 CTO)指出,現在許多公司的內部文件非常雜亂,對人類尚且不夠友善,對 AI 就更加難懂。她呼籲企業開始採取「AI 第一」的文件策略——寫文件時就要考慮給 AI 讀,如果你的文件不是結構清晰、純文字的形式,AI 根本沒法用它來幫忙。換句話說,未來的軟體文件不僅是給人看的,同時也要寫給 AI 看。這其實就是規格驅動思維的一部分:讓知識以結構化、機器可理解的方式存在,才能充分利用 AI 的力量。

所謂規格撰寫(Spec-Writing),就是用正式、結構化的文字描述我們想讓軟體達成的所有事,藉此把人的意圖完整地傳達給 AI。這種方法補上了 prompt 開發的種種缺口,讓軟體開發回到一個可控、可預測、可協作的正軌。
規格驅動帶來的五大好處
從實務角度來看,導入規格驅動的 AI 開發,有以下幾個明確的價值:
好處 | 說明 |
---|---|
可追溯性(Traceability) | 每一項功能為什麼要這樣做、是誰決定的,都能在規格和版本歷史中找到根據。因為規格文件跟程式碼一樣納入版本控制,開發過程中的討論、修改都有跡可循。大型團隊特別看重這點——AWS 推出的 Kiro 平台之所以強調規格先行,正是因為企業級開發需要高度的流程透明和稽核能力。日後若出現問題,可以回溯當初的規格討論,了解決策背景,減少“為什麼這麼做”的問號。 |
可驗證性(Testability) | 有了規則,就等於同時有了撰寫測試的藍本。規格裡訂的驗收標準,可以直接轉化成一組自動化的測試案例。在規格驅動流程中,通常開發者會先寫好這些測試(或由 AI 協助產生),作為對規格的「執行檢驗」。接下來 AI 生成的程式碼必須通過這些測試才能算完成。如此一來,每當 AI 胡亂發揮導致測試不通過時,我們立刻就知道哪裡不對,而不用人工去翻每行碼找 bug。TDD(測試驅動開發)本來就提倡先寫測試再寫碼,現在不過是換成由 AI 寫碼,更凸顯了寫測試的重要性。總之,規格+測試這套組合拳,讓我們對 AI 寫出的程式是否達標心中有數,一切以跑綠燈(通過測試)為準。 |
可交接性(Team Scalability) | 當規格成為開發的核心產出物時,團隊協作會順暢許多。大家對需求細節和邏輯的理解都以規格文件為依據,不再依賴個人記憶或私人筆記。知識不再私藏在某位工程師腦中,而是寫在文件上給全體成員檢視。這對人員輪替或團隊擴編特別有幫助:新進來的工程師只要讀規格就能明白目前系統該做什麼,甚至連 AI 模型也可以透過同一份規格和人類保持同步。OpenAI 內部就採用所謂的「Model Spec」(模型規格)來對齊跨部門團隊,這其實是一系列 Markdown 文件,工程、法務、產品各部門的人都會共同維護,連 AI 模型的行為準則也寫進去。這種做法讓規格變成團隊共同語言,就算人來人往,文件永遠比人腦更可靠。 |
一致性(Determinism) | 許多人有過這種經驗:不同人用 ChatGPT,得到的答案可能略有差異;或者同一問題問兩次,AI 回答也不太一樣。這種不一致在團隊協作中會很困擾。但規格驅動能大幅改善這種隨機性,因為AI 永遠依照同一份規格執行。比如在 Kiro 這類工具中,團隊把完整規格輸入後,AI Agent 在整個開發過程中都持有這份規格作為上下文,不會因換了一個使用者或換一台電腦就漏掉要求。大家共用同一個「真相來源」(即規格文件),AI 產生的結果自然較為穩定可控,不會出現對甲產出一套碼、對乙又產出另一套碼的情況。從工程角度看,一致性意味著減少不可預期行為,也就降低了風險。 |
加速 AI DevOps 流程 | 當我們具備規格、程式碼、測試三大要素,就可以搭建完整的自動化流水線。想像一下一個閉環:由規格產生程式碼,接著自動跑測試驗證,再自動部署到雲端。以往這需要多人協作、反覆人工作業才能完成,但有了 AI 參與,我們可以在每個階段都自動化。規格→程式碼→測試→上線,每一步都有 AI 幫忙處理繁瑣細節,人類則專注在監督和決策。實務上已經有工具開始實現這種端到端流程。例如 Kiro 會根據規格自動繪製系統設計圖(資料流程、介面定義等),切分出一連串待辦任務,包括產生單元測試、整合測試、文件更新甚至部署腳本。開發人員只需要在關鍵節點上按下確認,便能讓 AI 依照規格一步步完成開發、測試到部署。這樣的AI DevOps不再停留在幻想,而是實際可行的工作流,大幅縮短從需求到上線的路程。 |

以上種種,好處歸納起來其實就是一句話:讓 AI 融入我們成熟的工程體系,而非把工程拖入 AI 的即興狀態。規格驅動給了我們一個握柄,讓我們可以駕馭 AI 的威力,而不用每天提心吊膽擔心 AI 又給我亂寫了什麼。
案例演練:Spec-Driven AI 工程流程長怎樣?
說了這麼多,實際要怎麼做呢?讓我們腦補一個理想的 規格驅動 AI 開發流程,看看團隊協作會是什麼模樣:
- 撰寫規格:產品經理或開發人員先在 Git 存放庫中建立一份 Markdown 規格文件,詳細寫出新功能的背景、需求點、流程及驗收條件。例如何時輸入什麼,預期輸出什麼,都寫清楚。團隊成員共同審視這份規格,確認沒有模稜兩可的地方。如果不知道怎麼下手寫,甚至可以請 AI 根據經驗產生一版初稿規格,再由人來潤色補充。
- AI 理解規格並生成方案:接著,團隊將規格提交給 AI 開發助手(例如 AWS Kiro、Cursor IDE 等)。這些工具會解析文字規格,例如運用某種需求語法(像 EARS)把需求拆解成一系列任務和設計要點。AI 可以自動產出系統設計圖、資料模型、介面定義等技術方案,確保在動手寫程式前,大家對整體架構和模組切分有共識。這一步可以看作 AI 幫我們做了傳統的系統設計和詳細設計工作。
- AI 根據規格產出程式碼與測試:有了完整的規格和設計,AI 代理(Agent)開始寫程式碼。它會按照既定的模組切分,一個個功能去實作。同時,AI 也能根據驗收條件自動生成對應的單元測試和整合測試,確保每個功能點都有測試覆蓋。例如 Kiro 會為每個任務產生相應的程式碼以及驗證該程式碼的測試,甚至連說明文件也一併更新。在這階段,AI 等於同時扮演了工程師和測試人員的角色。
- 持續檢查與調整:開發人員並不需要乾等 AI 給結果,而是全程監督。像 Cursor 這類 IDE 會即時顯示 AI 產出的程式碼差異,你可以逐行查看修改。如果發現 AI 產生的程式不符合規格(例如檢查發現某條業務邏輯實作錯了),開發者可以在規格或程式碼層面做出修正。修正後再次執行 AI Agent,直到所有測試綠燈通過。這其實就是 TDD 的 red-green-refactor 迴圈,只不過紅綠燈是 AI 在跑,人類在後面指揮而已。
- 自動化部署與交付:當所有測試通過、產品功能符合規格之後,接下來就交給持續部署管道(例如 GitHub Actions)去自動部署上線。由於我們一開始就把規格和測試納入了流程,AI 產出的程式碼品質是有保證的,部署起來也比較放心。更進一步的,自動化管道也可以反過來通知 AI,例如部署過程有錯誤,AI Agent 能根據日誌自動修復並更新規格,進入下一迭代。整個流程就像一座軟體工廠:規格是生產藍圖,AI 是生產線機器人,測試是品管單位,而工程師則是工廠經理,確保一切按照藍圖順利運轉。
上面的流程聽起來很理想,距離完全實現或許還有挑戰,但已經有苗頭可循。比方說,AWS 的 Kiro 平台目前就在嘗試自動串連這些步驟,把傳統開發中規劃、撰碼、測試、部署各環節用 AI 串起來。另一款開發者工具 Cursor IDE,允許你在左側撰寫需求說明,右側 AI 即時產出對應的程式碼和解說。甚至 OpenAI 自家的 ChatGPT Code Interpreter 也能在 sandbox 環境執行你給它的指令碼,未來結合 GitHub Actions 等工具,完全可以做到 AI 寫完程式就自動跑起系統,測試通過後部署。可以想見,再過一兩年,這類 Spec → Code → Tes t→ Deploy 的一站式 AI 工程流水線會越發成熟,工程師需要做的就是把關規格和架構,剩下重複性勞動都交給 AI 來加速完成。
寫那麼詳細的規格不就很慢嗎?
你或許此時心中冒出一個疑問:「老實說,我們以前寫需求文件是很耗時間的,現在每改一點都要改文檔,搞這麼多規格會不會拖慢開發?我們乾脆邊做邊改不是更快嗎?」 這其實是對規格驅動的一個典型擔憂——感覺像回到過去瀑布開發寫大厚文件的日子,而且AI不是很強嗎,為啥還要人類寫這麼多字?
首先,要破除一個迷思:「快」不等於「好」。軟體工程從來都不是看誰寫得快,而是看誰控制得好。快速產出一堆程式碼很容易,但產出可維護、可擴展、不出亂子的程式碼卻需要嚴謹的流程和控制。寫規格在表面上增加了前期工作量,但它換來的是後期開發的可預測和少走冤枉路。就像蓋房子先畫藍圖,看似多花時間,其實避免了邊施工邊改設計導致的返工。特別在 AI 幫你寫碼的情況下,你更需要 upfront 控制輸入(也就是規格),否則 AI 把垃圾進->垃圾出的速度只會更快。
再者,撰寫規格不一定慢,甚至可以更快。我們完全可以讓 AI 來協助寫規格的初稿。例如你丟一段概要給 ChatGPT,請它依模板展開成完整的需求規格,接著你再修訂潤色。AI 擅長基於大量知識去列舉可能需要考慮的情況,反而能幫忙覆蓋一些你沒想到的角落。寫規格變成人機協作的過程,而不是傳統上 PM 一個人關起門來寫一星期。很多工程師其實害怕寫文件,但有 AI 幫忙,寫文件的門檻已經降低許多。所以與其說 spec 驅動讓我們慢下來,不如說它要求我們改變工作模式:先花一些腦筋把問題想清楚,再透過 AI 加速落實。而這種“磨刀不誤砍柴工”的做法,長遠看節省的時間和成本遠遠超過前期投入。
最後一點,也是最現實的:寫 spec 是避免日後災難返工的保險,更是團隊要做到大型協作的前提。當然,小專案你可以不上測試、不寫文檔,幾百行程式碼壞了就全重寫無妨。但系統一但變大,團隊一擴張,如果還是無規格無紀錄地 Wild West 式開發,幾乎可以保證後期會付出成倍代價來還債。許多開發者都有過教訓:剛開始圖快沒紀律,結果幾個月後系統爛到無法維護,只好推倒重來。與其到那時懊悔,不如一開始就把規格和測試當成開發不可或缺的一部分。更何況,正如前面強調的,規格驅動是讓我們有機會真正把 AI 納入 CI/CD 流程的關鍵。如果沒有規格作基礎,AI 永遠只能當個玩票工具,而無法成為嚴肅工程的一員。
所以當有人質疑「真的需要寫那麼詳細的規格嗎?」,我的回答是:你其實不是沒有在寫規格,你只是不把它寫下來而已。 你腦中對需求的理解、你在會議中跟同事討論的決定,其實就是非正式的規格。如果不記錄下來共享給AI和團隊,那只能依賴個人記憶和臨場反應,這無疑增加了溝通成本和出錯機率。把它寫下來雖然花點時間,但這是對品質和效率的投資,而非浪費。

Spec-Writing 不是為了寫文件而寫文件,而是為了更快更穩地達成目標。別被短期的速度迷惑了眼,工程的本質是控制與演進,有了好的規格,AI 這把快刀才能真正為我們所用,而不是傷了自己。
讓 AI 成為工廠,而非賭場
在這個 ChatGPT 當道的時代,很容易陷入「隨便丟個需求讓 AI 去生碼」的誘惑。剛開始你可能覺得神奇又高效,但久了就會發現這種賭運氣的開發方式問題叢生。真正能長期讓 AI 發揮價值的,是把它納入我們現有的工程流程,把規格當作與 AI 溝通的介面和契約。不要再把 AI 視為魔法師,不能只憑 prompt 即興發功;我們要把 AI 視為工程流水線上的得力助手,透過嚴謹的規格告訴它做什麼,然後讓它高速執行。
可以預見,未來最出色的開發團隊,一定是那些精通寫規格、善用 AI 執行的團隊,而不是只會「prompt-and-pray」(丟提示詞然後祈禱)式開發的團隊。工程師的價值將越來越體現在問題分析和規格設計上;至於搬磚寫碼的部分,交給 AI 就好。如果你還抱著僥倖心理覺得 AI 可以免去寫規格的麻煩,那恐怕只會在未來的軟體革命中掉隊。
最後引用 OpenAI 那場演講的一句話與各位共勉:「下一次你要啟動專案時,不要急著跳進寫程式,跟以前一樣,先從一份清楚、可執行的規格開始。」讓我們一起讓 AI 成為程式工廠的生力軍,而不是賭場裡碰運氣的機器。在正確的方法論引導下,AI 的潛力才能被真正釋放,我們軟體開發的未來也將因此被改寫。
參考資料
- The New Code: Why Spec‑Writing Is the Real Superpower in the Age of AI
- From prompts to specs: AWS’s Kiro signals the next phase of AI coding tools
- SpecDriven AI: Combining Specs and TDD for AI‑Powered Development
- AI in Specs: Enhancing Product Specification Writing
- AI can write code, but can it beat software engineers?
- Can AI really code? Study maps the roadblocks to autonomous software engineering
- DX CTO Says Companies Should Rethink Corporate Documentation, Write Things AI Can Easily Read
- How Test‑Driven Development (TDD) Builds Trust in Code Generative AI
- Test‑Driven Agentic Development: How TDD and Specification‑as‑Code Can Enable Autonomous Coding Agents
- Vibe Coding Dead? Devs Switch to Specs Driven Development
- Developers aren’t worried that gen AI will steal their jobs, Stack Overflow survey reveals