嘿，大家好！我是 ChiYu。

昨天聊到 AI 開發，一不小心就把小小的「腳踏車」專案搞成一艘「航空母艦」，超頭痛的對吧？這種「AI 太能幹」造成的失控，在 Vibe Coding 的浪潮下，只會越來越常見。這不只是個笑話，它反映了一個深刻的問題：當我們擁有無窮的力量（AI），卻沒有明確的方向時，混亂是必然的結果。

那到底要怎麼辦，才能讓 AI 乖乖聽話，不要自己亂加戲？我們該如何從一個被 AI 牽著鼻子走的「使用者」，蛻變成一個能駕馭 AI 的「指揮家」？

今天就要來分享我的秘密武器，一個能讓你從「玩票」變「專業」的酷東西：文件驅動開發 (Document-Driven Development, DDD)！

我知道，一聽到「文件」兩個字，你可能就想關掉了，感覺超無聊，對吧？先別走！相信我，這東西比你想的有趣多了，它就是我們駕馭 Vibe Coding 這匹野馬最重要的「韁繩」！這不是要你回到寫八股文的老路，而是要教你一種用「文字」來駕馭「程式碼」的現代魔法。

核心精神：「左移」你的思考 (Shift-Left)

在蓋房子前，你會先畫好藍圖，還是直接叫工人來亂蓋一通？當然是先畫藍圖嘛！這個簡單的道理，在軟體開發中卻常常被遺忘。

這在我們寫程式的世界裡，有個很潮的說法叫 「左移」(Shift-Left)。意思就是，把所有燒腦的規劃、設計工作，全部往前挪。這就像規劃一場環島旅行，你不會等到出發當天才在想要去哪裡、住哪裡，對吧？你肯定會提前好幾個禮拜，就把路線、住宿、景點都研究得一清二楚。

為什麼？因為一開始在紙上改個設計，頂多花幾分鐘；等到牆都蓋好了才說要改，那可就得花好幾天敲掉重來，不只工人想罷工，連設計師都會想掐死你！修改的成本，隨著時間往右，是呈指數級暴增的，這不只是時間成本，更是團隊士氣的巨大耗損。一個小小的早期決策失誤，到後期可能會演變成需要數週才能修復的**「技術債」**，那種感覺真的糟透了。

DDD 就是這個概念的最佳實踐，先想清楚，再動手！

所以，DDD 到底在幹嘛？

所以說，DDD 到底是在幹嘛？超簡單，就是一個規矩：

沒文件，就沒有 Code！

這聽起來可能有點極端，但它的核心是一種紀律，一種能帶來巨大回報的紀律。整個開發流程大概是這樣：

1. 先動腦，再動手：有任何新想法？第一步絕對不是打開 VS Code，而是先把它跟 AI「聊」成一份具體的規格文件。這個「聊」的過程，其實就是在強迫我們把腦中模糊不清的想法，具象化成有邏輯、有結構的文字。很多時候，光是在這個階段，你就會發現自己想法中的矛盾與漏洞。
2. 在文件上吵架：所有的討論、修改，都在文件上搞定。這是一種健康的吵架！把所有可能的誤解、模糊地帶，在程式碼誕生前就全部解決掉。在文件上吵架，成本是零；但在程式碼上吵架，成本可能就是好幾個工程師好幾天的工時，改文字總比改程式碼便宜吧？
3. 文件就是聖旨：文件一旦定稿，就是不能亂改的「施工命令單」。它成為了我們後續所有開發工作的唯一依據。這份文件就像是我們與「未來的自己」以及「AI」之間簽訂的一份契約，確保大家永遠在同一個頻道上。
4. 寫 Code 只是翻譯：這時候，寫程式就變得很單純，不再是天馬行空的創作，而是把文件上的東西，有效率地「翻譯」成程式碼而已。開發者的認知負擔被大幅降低，我們可以更專注在如何把程式碼寫得更乾淨、更有效率，而不是一邊寫一邊想「我到底要做什麼來著？」。

面對現實：我知道，你討厭寫文件

好啦，我知道你在想什麼。講到「寫文件」，大概九成的工程師（包括我！）都會翻白眼。心裡想著：

「唉，又來了」
「敏捷開發不是說不用寫文件嗎？」
「我有這時間不如多寫幾行 Code」。

這真的不是我們的錯！很多人誤解了「敏捷開發」的精神，它強調的是「可工作的軟體 勝於 詳盡的文件」，而不是「不要文件」。一份沒人看的、過時的文件確實是垃圾；但一份能指引方向、建立共識的「活文件」，卻是專案成功的基石。以前寫文件又痛苦又沒用，誰想寫啊？我們都經歷過那種「文件是個謊言」的專案，規格書上寫 A，但程式碼早就改成 B 了，這種文件不如不要有。

但這次，我們不自己動手寫

但！這次完全不一樣了！

我們不用自己一個字一個字地敲文件！

我們要讓 AI 當我們的專屬寫手。我們的工作，從苦哈哈的打字員，升級成動動嘴巴的決策者。開發的瓶頸，不再是我們的打字速度，而是我們思想的清晰度。

說白了，「下指令 (Prompt)」本身，就是一種新時代的「規格設計」啦！ 我們的價值，從「如何實現」，轉變成了「如何清晰地定義問題」。這是一種更高層次的抽象能力，也是未來開發者的核心競爭力。

「好文件」不是廢話文學，而是唯一的真理

既然有 AI 幫忙，我們更應該專注在做出「有用的」文件。這份文件就是我們專案的 「單一真理來源 (Single Source of Truth, SSoT)」，所有人都得聽它的！

一份好文件有幾個特點：

• 它是老大：有爭議？看文件就對了，它說了算！這份文件不只是給你看，更是給 AI 看的。當你把這份文件當作上下文丟給 AI 時，它就有了最權威的參考依據。AI 的記憶是短暫的，但這份文件是永恆的。它就是我們專案的**「外部大腦」**。
• 它能做事：每一句話都能變成一個具體的開發任務，不是在講空話。例如，當文件上寫著「需要一個能讓使用者註冊的按鈕」，這就直接對應到一個前端的開發任務。一份好的文件，甚至可以直接被專案管理工具拿去開成一張張的任務卡片。
• 它有版本號：我們會幫文件標上版本號，就像遊戲更新一樣，v1.0、v1.1，清清楚楚！每一個版本號，都會對應到我們 Git 版控中的一個 commit，讓文件的演進與程式碼的演進完全同步。

【專業小補充：語意化版本 (Semantic Versioning)】

在專業的軟體世界裡，版本號不是隨便取的，它遵循著一套國際通用的規則，叫做「語意化版本 (Semantic Versioning)」。它的格式是 主版號.次版號.修訂號 (MAJOR.MINOR.PATCH)，例如 v1.0.0。

• 主版號 (MAJOR)：當你做了「不相容」的 API 修改時，才需要動它。例如，你把一個 API 端點整個刪掉，或是修改了回傳資料的格式，導致舊的前端 App 會直接閃退。這是一種「重大更新」，需要升級主版號（例如從 v1.2.5 升到 v2.0.0）。
• 次版號 (MINOR)：當你新增了功能，但依然「向下相容」時，就動它。例如，你在 API 中新增了一個選填的欄位，或是多了一個全新的 API 端點。舊的前端 App 不會因為這次更新而出錯，但新的 App 可以開始使用這個新功能。這是一種「功能更新」（例如從 v1.2.5 升到 v1.3.0）。
• 修訂號 (PATCH)：當你只是做了「向下相容的錯誤修正」時，才動它。例如，你修正了一個計算錯誤的 Bug，或是調整了一段錯誤訊息的文字。這個修正不會影響任何現有功能，只會讓系統變得更穩定。這是一種「補丁更新」（例如從 v1.2.5 升到 v1.2.6）。

當我們討論功能時，可以直接說「我們來實現 API_SPEC_v1.2 裡的新功能」，所有人都能立刻找到對應的規格，不會有任何誤解。這套規則，就是工程師之間的「世界語」。

結語：不只是文件，而是一種哲學

所以你看，今天我們聊的不只是「文件」，而是一種更聰明的工作「哲學」。

先把事情想清楚，再讓 AI 幫我們搞定麻煩事。這就像是為 Vibe Coding 這台超跑，鋪好了一條又直又穩的賽道！有了這個心法，我們就有了駕馭 AI 的底氣。這不是在限制 AI 的創造力，反而是為它的創造力，提供一個能發揮最大價值的舞台。

明天，我們就要來動手把開發環境給建立起來啦！準備好你的工具箱，我們要開始動工了！