Rule Driven Develpoment-AI時代的軟體開發策略

TL;DR 摘要

當AI能夠理解需求、修改程式碼、執行測試，甚至串起整條交付流程，開發人員的價值要放在哪裡？光岩資訊資深技術顧問董大偉（David）在這場Rule Driven Develpoment分享中，提出一個核心方向：把實作逐步交給AI，人則聚焦Business Rule與商業價值。不過，寫程式變快不等於組織交付變快；要接住AI的產能，仍得靠敏捷、DevOps，以及高內聚低耦合的架構基本功。

• AI開發正從程式碼補全走向End-to-End自動化，但採用方式必須配合專案與團隊成熟度，不是越新越好。
• Coding加速會把瓶頸推向Review、測試與需求釐清；自動化品質把關和小步快跑，才是縮短交付週期的關鍵。
• Rule First、Code Second、UI Last：先掌握核心規則，再讓AI完成周邊實作，而不是從畫面出發。
• SDD不是品質保證的替代品；選擇使用就必須認真確認Spec，而足夠小的Change是講者偏好的另一條路。

從敲鍵盤到Pencils down：開發者角色的轉折

Hello World對開發者而言，往往不只是兩個英文單字，而是第一次讓電腦照著指令回應的共同記憶。董大偉以一段報到插曲開場：在樓下被要求說出活動的「通關密語」，想起Hello World之後才順利進場。這句曾經標誌著開始寫程式的問候，如今也成了重新思考開發者角色的起點。

董大偉從1984年開始寫第一支程式，大半輩子都投入技術工作，也寫過介紹不同技術的書。他笑說，待在這一行夠久，就會看到當年熟悉的技術逐一退場。但這次的衝擊不同：被改變的可能不只是某種語言或工具，而是親手敲鍵盤寫程式這件事本身。對一位寫了約40年程式的人而言，這不只是效率提升，更牽動了長期建立的工作習慣與身分認同。

這樣的轉變並沒有帶來單一情緒。他觀察身邊的開發者，有人焦慮、有人迷惘，有人興奮，也有人承受很大的壓力。他自己的適應過程同樣不是從一開始就篤定看好，而是隨著實際使用，逐步調整對未來的想像。

• 2021年開始接觸並較多使用AI輔助開發，時間比不少開發者更早。
• 2022年至2023年間，起初覺得還好；到了2023年至2024年，逐漸感到擔心。
• 2024年下半年仍抱持懷疑，也意識到未來的工作世界可能出現很大的改變。
• 到了2025年，他形容自己已經習慣。這不是變化停止了，而是開始接受世界持續改變的狀態。

他提出一個帶著試探性的想像：也許今年、明年或後年，就不必再親自敲鍵盤寫程式。這是他對工作方式變化的判斷，並不是宣告軟體開發已經不需要人。真正令人震動的是，過去最能代表開發者日常的動作，可能不再是工作的中心。

董大偉以Ruby on Rails的DHH為例，轉述其在2025年5月談到的Pencils down。這句話原本是考試時間結束時，老師要求考生放下筆、停止作答的指令；放進軟體開發的情境，就帶出「把手離開鍵盤」的雙關。依董大偉的解讀，這個比喻之所以刺耳，是因為它碰觸了資深開發者最熟悉、也最投入的工作方式。

「過去，我花40年寫程式，現在叫我把手離開鍵盤，你體會一下我的感覺。」
— 董大偉

另一個更具爭議的方向，是連人工閱讀程式碼都可能成為瓶頸。董大偉轉述Uncle Bob希望盡量不再人工看Source Code的說法，也提醒對方後面還有進一步說明，不能只截取這一句。他所強調的理由，是當程式產出的速度持續提高，人工閱讀可能跟不上；但即使如此，這樣的主張仍引發了社群熱議。這裡談的是董大偉對相關言論的轉述，而不是將其簡化成「程式不用人寫，也不用人管」。

董大偉自己的立場也經歷過轉變。2024年，他還曾在Facebook公開主張：使用AI輔助開發很好，但AI產生的Code一定要看。到了2025年，認真實作之後，他卻發現自己看不完。問題不只是願不願意仔細閱讀，而是AI的產出速度已經超過他能逐行消化的速度；若堅持每一行都以原本的方式閱讀，就得放棄部分AI帶來的速度。

「除非我放棄AI帶來的速度，否則我就是看不完AI寫的Code。」
— 董大偉

這個矛盾把問題從工具使用推向了角色與驗證方式：當親手撰寫、逐行閱讀不再能追上產出，人應該把注意力放在哪裡，又如何確認結果值得信任？閱讀能力跟不上，不等於品質把關可以取消；它意味著，不能再只靠原本的人工閱讀習慣，承接已經改變速度與規模的開發工作。

AI能力的分水嶺：從補全走向自主執行

AI在軟體開發中的參與範圍，已不再只是幫忙補完幾行程式。董大偉回顧，2024、2025年談AI開發時，重心多半放在Coding、Unit Test與Refactoring；到了2026年與企業交流時，討論已延伸到需求、UserStory的產生，以及自動化測試與End-to-End測試。從Chrome DevTools到Selenium，AI能參與的工作逐漸涵蓋整個SDLC，而不只停留在編輯器裡。

不過，能參與不等於能承擔責任。他認為，現在已很難指出哪個開發環節完全不能交給AI嘗試，但執行品質、速度與成果是否符合期待，仍可能有落差。這個區分很重要：AI的工作範圍可以擴大，責任卻不會因此自動轉移給AI。

理解這波變化，可以把工具的演進看成工作單位逐步擴大：從眼前的程式片段，到跨檔案任務，再到可自動化、可並行的開發工作。董大偉列出的路徑如下，但他特別提醒，這不是一條淘汰舊工具、只留下最新工具的競賽。

• Code Completion：以2022年的使用經驗為起點，AI在撰寫程式的當下提供補全，開發者仍在編輯器中推進工作。
• Multi-file的Agent Mode：工作範圍從單一片段擴展到跨檔案修改，逐漸以任務而非局部補全來操作。
• CLI與雲端CLI：互動不再限於編輯器內，執行環境也從本機延伸到雲端。
• Orchestration App：例如GitHub Copilot App與Codex，進一步支援automation與multi-agent並行，讓多個代理同時參與工作。

真正的分水嶺，在董大偉的判斷中落在2025年底前後。AI開發工具並非到那時才出現，但他認為，多數開發者在2025年下半年開始明顯感受到能力提升，而2025年至2026年的變化，是工具逐漸從實驗性用途走向可以正式使用。

• Reasoning Model：董大偉認為，這類模型的出現讓MCP變得更有可能實際運作，推動AI從產生程式文字，走向使用工具執行任務。
• Context Window擴大：能容納的上下文增加後，更多需要掌握較多資訊的工作開始具有可行性，也增加了處理複雜任務的可能。

模型能力與工具形態在這裡互相配合。若把Code Completion想成坐在身旁、隨時補上一句的助手，Orchestration App更像是安排多個助手分頭工作的協調介面：既能進行自動化，也能讓multi-agent並行。董大偉強調Token資源對這種工作方式的重要性，但並行能力的出現，並不等於每個任務都能無條件成功。

「AI輔助開發的時代已經過去了，現在是AI開發的輔助。」
— 董大偉

這句話描述的是工作重心的翻轉：不再只是由人寫程式、AI在旁協助，而是讓AI承擔更多實作，人協助推進開發。董大偉認為，到了2026年，如果有意採取這種方式，可以把程式撰寫、Code review乃至部署交給AI執行；但他也明確保留限制，是否適合仍取決於專案。工具具備自主執行能力，是新的選項，不是所有開發工作都必須採用的唯一模式。

「AI輔助開發的時代已經過去了，現在是AI開發的輔助。」
— 董大偉

CLI的真正價值：讓AI進入自動化流程

把「實作登入功能」交給AI，不一定要先把需求複製到對話框，再逐一指定要改哪些檔案。董大偉示範的起點，是DevOps環境裡編號1031的工單：透過MCP，AI可以取得工單資料與需求細節，接著人在Copilot環境中用自然語言要求「幫我把這個1031這個功能實現」，便能讓AI依據工單內容展開實作。操作的單位不再只是游標所在的一行程式，而是一項可能涉及多個檔案的功能。

這種便利也帶來另一種成本。依講者的使用經驗，Code Completion以局部補全為主，Token負擔相對較低；Agent或CLI若為了完成任務而反覆掃描程式碼、修改多個檔案、持續執行操作，消耗就可能明顯增加。他特別提醒，讓AI不加限制地掃描、嘗試做所有事情，很容易快速用掉大量Token。這是對任務範圍與操作方式的提醒，不是說CLI必然昂貴，也不能把個別工具的使用經驗當成通用計價規則。

另一個示範則把CLI當成可接受任務的工作者：先要求AI尋找程式碼裡的BUG，將結果寫進Markdown文件，再要求它依照文件內容修正。這份文件成了兩次操作之間的交接材料，讓「找問題」與「依據問題修改」可以分開下指令，而不只是籠統地要求AI把程式修好。

不過，董大偉強調，這不是他一直都放心採取的做法。依他的判斷，2025年以前模型能力還不夠成熟，直接讓AI找BUG再修改，可能反而改壞程式；他過去授課時也曾勸學員不要這樣做。到了2025至2026年前後，他才開始認為模型具備承接這類工作的能力。這裡的轉變，是他對模型可用程度的實務判斷，不代表只要改用CLI，就能自動確保修正正確。

CLI真正讓他興奮的地方，並不只是少開一套重量級IDE。當AI能透過命令列接受指令，開發工作就不必綁在有人坐在編輯器前操作的時刻，而能進入Pipeline，或安排在半夜與其他指定時間執行。介面的改變，讓原本即時互動的助手，有機會成為可排程的工作者。

• 減少對IDE的依附：不必先開啟重量級開發環境，也能透過CLI要求AI執行工作。
• 把任務放進自動化流程：在Pipeline或指定時間觸發AI，不再每次都由人手動開始對話。
• 安排不同類型的工作：Debug、文件撰寫與開發任務，都可以成為交付給AI的工作內容。

「我一直期待，我有一個開發者軍團。」
— 董大偉

人與AI互動的入口，也開始從鍵盤延伸到口述。董大偉分享，他看到朋友嘗試在AI對話框使用語音後，自己也做了一個語音程式，實際使用後覺得相當好用，開發時可以直接把要求講出來。但程式開發的口述並不只是一般聊天：中英文混用，再加上檔案名稱或其他特定名稱，仍會造成辨識困難。他後來也嘗試讓AI協助撰寫相關程式。這些經驗呈現的不是鍵盤已經消失，而是下達開發指令的方式正在變多：人可以口述意圖，AI則透過工具執行工作。

串起交付鏈：從需求卡片到雲端部署

AI開發的示範若只停在產生程式碼，看到的仍是交付鏈的一小段。董大偉以GitHub Copilot App與Codex相關操作展示的重點，是把修改、測試、部署、Review與修正串成同一條流程：AI不只負責寫程式，也開始參與程式寫完之後的工作。

示範從只有主線的專案開始，先建立Feature Branch，再到本機VS Code執行Fetch與同步，將分支上的程式碼帶到開發環境。接著由AI在分支上以Python撰寫BMI程式。真正值得注意的不是語言選擇，而是工具修改程式後，還會接著執行單元測試與UI測試；錄影中的操作視窗，是AI自行開啟並進行測試，不是講者手動操作。

這種UI操作也不限於Web。講者分享，Windows應用程式同樣能由AI開啟視窗並執行測試；他追問實作方式後，發現AI寫了script來操作Windows視窗。也就是說，測試不只停留在檢查函式輸出，還可以延伸到實際介面的操作。這是示範中觀察到的能力，不代表所有應用程式都已能不經設定就自動完成測試。

• 完成修改與測試後，提交Commit與Commit Message，再將變更PUSH到Feature Branch。
• 分支上的PUSH觸發預先設定的GithubAction，由Pipeline把應用程式部署到測試環境。
• 建立PR後，呼叫Github Copilot執行AI Code Review，檢視Review結果；需要修改時，再要求AI調整程式或修正BUG。
• 確認修改沒有問題後，Merge回主線並刪除分支；主線的更新再觸發後續部署流程。

在這條流程中，AI Code Review既可以使用廠商提供的工具，也可以自行串接。講者在Github與Azure DevOps的使用經驗中，已把它視為日常工作的一部分；修正工作也不必全部回到本機，可以交由雲端上的Coding agent執行。交付流程因此像一條接好的輸送帶，每個步驟的產出都能成為下一個步驟的輸入，但前提是CI/CD Pipeline已經完成相應設定。

另一個示範則把起點往前推到需求卡片。董大偉在Azure DevOps自行串起流程：人先建立需求，背後的自動化程式呼叫AI，產生user story與acceptance criteria，再由人Review。需求經過確認後，移動看板上的工單狀態，就會觸發AI拆解task與後續開發。人的操作介面，從逐一執行開發指令，轉成確認需求內容與推動工作狀態。

• 需求建立後，AI產生user story與acceptance criteria，人先Review內容，再將工單移到後續狀態。
• AI展開task，切出increment並觸發Pipeline；Pipeline透過CLI取得工單與規格書，在雲端執行開發，需要時建立分支。
• 自動化Code Review完成後，將AI Review結果寫入PR的comment，讓檢查意見留在交付流程中。
• 人若發現BUG或希望調整行為，可以直接在comment提出要求；AI讀取留言後，尋找有問題的程式碼，再透過Pipeline中的CLI執行修正。
• 完成確認並推進主線後，後續部署也由自動化流程承接。

PR的comment在這裡不只是討論紀錄，也成為人向AI下達修正要求的入口。看板卡片則不只是進度標記，而是流程的觸發器。講者甚至進一步設想，AI完成工作後可以自行移動卡片，讓人不必每一步都手動推進，而是在流程旁觀察進度，必要時介入。

「除非它做出一些有問題的事情，你再介入就可以了。」
— 董大偉

董大偉以human in the loop與human on the loop區分這兩種合作方式。前者著重人在流程中逐項核准，後者則是讓自動化流程持續運作，人站在監督位置，遇到問題再介入。這是他自行串接交付系統後採取的實作方向，而不是宣告人工Review已經沒有必要。當寫程式、測試、Review與修正都能由AI接手，問題也隨之轉變：不再只是哪些步驟可以自動化，而是這條自動化交付鏈如何確保品質。

寫得快卻交付不快：瓶頸移到了哪裡

AI究竟帶來多少效果，不能只看程式寫得多快，也要看成果能否更快交到使用者手上。董大偉在開場提到，關注焦點已逐漸從「要不要導入AI」轉向「導入後真正產生什麼效果」；談到交付流程時，他進一步釐清：個體開發速度提升，不代表整個組織的交付速度會同步提升。

「寫程式變快之後，交付跟著變快嗎？沒有。」
— 董大偉

這就像產線上的某個工作站突然加速，如果後面的檢查與出貨能力沒有跟上，增加的只是等待處理的產出。AI讓Coding更快完成，但團隊仍須確認程式是否正確、是否符合需求，以及能否安心部署到正式環境。瓶頸不是消失了，而是移到了其他地方。

• 測試與Code Review不足，造成交付等待：不做Review，團隊沒有把握上線；認真Review，又需要時間。程式碼產出越快，驗證能力不足的問題就越明顯。
• 需求與設計Review不足，造成重工風險：即使程式可以正常執行，如果需求理解或設計方向出了問題，仍可能做出使用者不需要的成果。這是較隱性的瓶頸，因為問題往往要到成果被檢視時才浮現。

這並不是AI時代才出現的新問題。董大偉回顧，過去採用敏捷開發或極限編程，當交付頻率從一週數次提高到一天數次時，團隊就已經面對過同樣的挑戰：開發速度提高之後，品質把關能不能跟上？因此，解法不只是增加一份更完整的Spec，而是回頭建立能支撐高頻交付的工程機制。

他明確點出完整的CI/CD pipeline與藍綠部署，並強調DevOps流程中的自動化、測試與各種把關機制，才是承接高速產出的基礎。規格可以協助釐清要做什麼，卻不能替代程式完成後的驗證，也不能單憑文件就保證交付品質。

另一端的需求問題，則不能只靠把Spec寫得更完整來解決。使用者一開始可能就無法清楚說出自己要什麼；若最初的理解仍有落差，再仔細確認文件，也無法保證方向正確。需要的是迭代式開發：把工作拆成較小的步伐，讓使用者較早看到成果，再透過回饋修正理解，降低一路做到底才發現必須重工的風險。

因此，敏捷與DevOps處理的是兩種相互連動的問題：敏捷透過小步快跑與迭代回饋，降低做錯方向的風險；DevOps透過自動化、測試與部署把關，讓完成的成果更有把握交付。Agentic Development可以加速實作，但不能讓團隊跳過這些基礎能力的成熟過程。

Rule First：把人的注意力放回核心規則

面對AI能大量產生程式碼的開發方式，董大偉把注意力拉回架構圖中最容易被忽略的重點：不是分了幾層，而是誰依賴誰。現場筆記將這張圖聯想到clean code書籍，但不能據此確認圖的來源；講者明確強調的是依賴方向：外層依賴內層，位於中心的核心，不應反過來被周邊實作牽著走。

沿著這個依賴方向，他提出一個鮮明的工作分配建議：人應把主要注意力放在Business Logic、Business Rule、核心entity與use case，讓AI承接UI、API、Data Access等周邊實作。這不是說周邊功能可以不顧品質，而是當AI能生成這些實作時，人更值得投入的工作，是釐清系統究竟要完成什麼、遵守什麼規則，以及核心行為是否符合需求。

BMI計算機就是一個直觀的例子。接到開發要求時，應該先思考的是計算BMI的Business Logic，還是畫面與Data Access？講者認為，合理的起點是核心商業邏輯；但vibe coding容易讓人被看得見的介面吸引，反而沒有聚焦真正決定系統行為的部分。他也以MVC提醒開發者：原本知道不該把model、view與controller混在一起，不該先做UI，換成與AI互動後，仍然需要維持這種架構上的自覺。

電梯則把這個差別說得更清楚。乘客最容易注意到的是按鍵與面板，但電梯程式的重點，不是這些可見的介面，而是背後決定系統如何運作的規則。講者認為，當AI能承接UI、API、report與其他程式實作，人最需要守住的，正是中心那塊仍須釐清的Rule。介面呈現了系統，卻不等於定義了系統。

這也是Rule First的出發點。相較於從畫面、Database First或API First開始，他建議先從Requirement展開對系統最重要的規則，再透過這些規則與AI互動，完成核心，最後生成周邊實作。Rule與Spec並不是同一件事；在他提出的先後關係中，Requirement在前，Rule接著出現，Spec則在Rule之後。

「Rule First，Code Second，和UI Last。」
— 董大偉

• Rule First：先從Requirement釐清核心規則，把系統的商業價值、Business Logic與Business Rule放在開發起點。
• Code Second：以已釐清的規則與AI互動，完成核心實作，而不是先大量生成程式，再回頭猜測它是否符合需求。
• UI Last：核心確立後，再由AI生成UI與其他周邊實作，避免可見的畫面反過來主導整個系統。

講者將這種思路稱為Rule Driven Develpoment，並提到其中有七大類規則，但沒有逐項展開。因此，重點不在背下一份分類表，而在改變人與AI分工時的判斷方式：不是只看工作價值高低、難易程度，或系統規模大小，而是看工作的性質。需要釐清商業意義、定義核心行為的工作，由人投入注意力；可以依循明確規則生成的實作，則交給AI承接。

對於擔心AI產生的程式碼不正確，講者也把焦點指向Rule，而不是只增加Spec。這個主張強調的是：必須先有清楚的規則，才能判斷程式行為是否正確；不能把文件的存在，直接當成正確性的保證。同樣地，規則也不會取代工程驗證。把核心規則說清楚、讓實作遵循規則，再透過測試與Review檢查結果，才是把AI產出轉成可用軟體時需要一起守住的工作。

「要讓程式碼正確，靠的不是規格，靠的是規則。」
— 董大偉

縮小模組與Repository，同時控制成本與風險

董大偉從「6月開始，Token變貴了」的觀察，帶出一個架構層面的成本問題：當AI每次執行任務都要掃描大量程式碼，程式庫越大，處理的內容與Token消耗也可能跟著增加。他提出的方向不是只調整提示詞，而是提高內聚、降低耦合，讓AI專注在單一模組，減少為了局部修改而反覆理解整個系統的負擔。

他轉述近期看到的Anthropic影片或文章，提到每天Merge 3萬次的案例，並特別強調這是Anthropic的說法，不是自己的數據。口述過程也曾使用commit一詞，因此這個數字應保留為講者轉述的案例，而不是已確認的統計。他同時指出，該案例採用很大的Mono Repository，但一般團隊不宜直接照搬這種規模與做法，仍得考量自己的Token資源與使用負擔。大量Merge本身，也不足以判斷每一次Change究竟有多小。

Mono Repository把程式碼集中在同一個Repository；Multiple Repository則將範圍拆分到多個Repository。董大偉偏好後者的理由，是讓AI不必為了處理一個局部任務，就面對一整個龐大的程式碼範圍。不過，他的建議有「如果可以的話」這個前提，並不是所有專案都必須採用同一種管理方式。真正困難的地方，在於系統能否切出合理的邊界，而不只是把檔案搬到不同位置。

「傳統的架構設計很重要」
— 董大偉

高內聚，是讓同一模組內的工作圍繞清楚的職責；低耦合，則是降低模組之間的牽連與相依性。若原本的職責糾纏在一起，即使拆成多個Repository，修改一處仍可能連動其他部分。因此，縮小Repository不是取代架構設計，而是更需要架構設計，才能讓分開管理、獨立建置與獨立部署真正成立。

• 以部署邊界作為拆分依據：董大偉建議，不需要一起部署的應用程式，不要放在同一個Repository裡。
• 讓各Repository能獨立建置、獨立部署，再由這些應用程式組成大系統，而不是每次修改都牽動整體。
• 讓每個應用程式專注於自己的職責，使AI處理任務時能聚焦較小的範圍，減少無關程式碼的掃描負擔。

這條路也連到服務化與微服務。董大偉坦言，自己過去不是很支持微服務，但如今若應用程式有機會服務化，他並不反對，原因之一就是讓各應用程式專注於自身職責，有助於節省Token。不過，這個方向的重點仍是職責與相依性設計；服務數量變多，不等於耦合自然變低，也不等於AI就能更有效率地工作。

縮小範圍的另一個價值，是控制「爆炸半徑」。董大偉用資安情境說明：一組帳號密碼外洩後，能影響多大的範圍，就是它的爆炸半徑。換到軟體開發，問題則變成：AI改錯一行程式，會波及多少功能或應用程式？這個類比把關注點從「會不會改錯」，移到「一旦改錯，能否把影響限制住」。

在他的判斷中，高內聚、低耦合，再搭配較小的Repository範圍，能縮小AI修改失控時的影響。關鍵不只是Repository的數量，而是切斷不必要的耦合、提高內聚程度並降低相依性。成本控制與風險控制因此指向同一個架構問題：讓AI只需理解與修改必要的範圍，也讓局部錯誤不容易擴散到整個系統。

SDD的適用邊界：規格要看，小改動也有價值

Spec Driven Development（SDD）的爭議，不必簡化成支持或反對。董大偉的立場是：它能解決一部分問題，但無法解決全部問題。他也強調自己會教授SDD，並沒有認為這種方法不好。真正需要釐清的是，規格能幫團隊確認什麼，以及採用這套方法時，人必須承擔哪些確認工作；不能因為有了Spec，就把需求探索與品質工程視為已經完成。

「如果你要用SDD,你就要認真ReviewSpec」
— 董大偉

這項要求不是形式上的點頭，而是從頭到尾認真看完，完整確認Spec之後，才交給AI執行。規格成為開發依據，也就成為人的審查責任所在。如果連規格是否符合預期都沒有確認，交給AI並不會自動補上這個缺口。講者也把這說成自己目前的態度，並未宣稱未來的工具與工作方式永遠不會改變。

相較於先審閱較大範圍的規格，董大偉更習慣另一條路：把每個Change縮到一眼就能看完、確認的程度。這來自他十幾二十年敏捷開發累積的習慣，透過小增量控制每次需要理解與確認的範圍。個人筆記也認同這個判斷：當Change足夠小，確實可以降低對SDD的需求。不過，這不等於所有團隊都不需要規格，更不是改動小就可以省略確認。

• 選擇SDD：把認真ReviewSpec視為必要工作，不能在尚未完整確認規格時，就直接交給AI執行。
• 選擇小增量開發：持續縮小Change，讓每次變更都落在人能快速看懂與確認的範圍內，而不是把大任務換個名稱就交出去。
• 選擇適合組織的方式：是否需要較完整的Spec，還要考量團隊習慣、文件需求與稽核條件，不能只套用個人的開發偏好。

企業對Spec的需求，也不全是開發效率的問題。董大偉分享，曾有公司希望導入SDD，原因是過去沒有Spec的開發過程讓人很沒有安全感；看到明確規格後，才覺得那是自己想要的工作方式。另外，有些公司的稽核要求以Spec為查核依據，而不是直接閱讀code。在這些條件下，文件有實際的組織用途，開發方法自然必須配合，而不能只用「我習慣小改動」回應。

至於SDD的不同Level，董大偉認為Level1與Level2可行；對Level3則抱持明確保留，將它視為理想，而非他認為能夠達成的做法。他並未在這段分享中定義各Level的內容，因此這項判斷應理解為講者對可行性的立場，不宜自行延伸成各層級的功能或能力比較。

文件能提供共同依據、安全感，也能回應稽核要求；但這些價值，與程式是否正確、交付品質是否可靠，仍是需要分別處理的事。董大偉選擇以小增量降低每次確認的負擔，也尊重其他環境透過SDD組織開發。差別不在於哪一方比較先進，而在於團隊是否真的執行了所選方法要求的審查與驗證，而不是把方法名稱當作品質保證。

「所以我尊重各種不同的開發方式」
— 董大偉

導入不必搶最前：讓AI放大已具備的能力

「這條線很長」是董大偉對AI導入現況的觀察：同樣面對大型語言模型，有人已經是重度使用者，感受到快速變化帶來的焦慮；也有人仍在摸索，尚未經歷相同的轉變。他在業界走訪時發現，這些認知與使用程度的差距相當大，彷彿存在不同的平行世界。因此，工具的演進不代表所有人都必須同步前進，更不代表每個團隊都應立即採用最前衛的Agentic Development。

導入節奏應該看團隊的體質，而不是只看工具的新舊。董大偉引用Github網站上的圖，說明Agile與DevOps基礎良好的企業，比較適合導入Agentic Development；反過來，如果原有基礎建設不健全，加入更自主的Agent，可能只會讓系統承受更多拉扯。新工具不會自動補齊原本欠缺的工程能力，較早期的AI輔助方式也不會因此失去價值。

不急著走到最前面，並不等於停止接觸AI。Rubin老師推薦的AI共智模式，提供了另一種實作態度：Always Invite AI to the Table。董大偉轉述書中的觀點，認為現在使用的AI可能是往後遇到的AI之中能力最差的版本，因為它仍在進步。這是對持續進步的期待，而不是保證每項能力都會如期成熟；他提到未來三五年可能實現許多科幻片中的想像，也明確將其放在個人想像的層次。

「Always Invite AI to the Table」
— 董大偉轉述AI共智模式

面對「AI變化這麼快，要怎麼學習」的問題，他的重點不是追著每個工具功能跑，而是實際使用。工具知識可能幾個月就改變，真正值得持續累積的，是在工作中試出AI能幫上什麼忙，以及哪些事情仍做不好。

• 從最不想做、最繁瑣或最無聊的任務開始，試著交給AI，觀察它能帶來什麼改變。
• 把試用放進不同工作環境與場合，不必等到全面導入最新開發方式，才開始累積經驗。
• 一次試用失敗，不必視為永久的能力邊界；隔三個月或半年再評估，因為模型能力可能已有明顯變化。

對主管而言，另一個需要避免的陷阱，是把AI帶來的生產力提升變成新一輪內卷。董大偉用加油站送水來解釋：只有一家開始送水時，可能吸引更多顧客；當所有加油站都跟著送，原本的優勢便消失，卻變成大家都必須負擔的成本。他以此類比加班：當所有人都加班，結果可能只是集體延長工時，而不是建立更好的工作方式。

因此，主管的責任是設計人與AI如何合作，而不是以AI為理由要求更多加班。董大偉將AI比喻為放大器，但放大器需要有可放大的東西，就像投資必須先有本金：若本金很少，即使市場大幅上漲，能獲得的成果仍然有限。放到軟體開發裡，這份本金就是既有的專業能力與工程基礎。

• 架構設計：練好高內聚、低耦合的基本功，累積清楚安排系統職責與相依性的能力。
• 敏捷與DevOps：把團隊的開發與交付基礎建立起來，而不是期待自主Agent直接取代這些準備。
• 工作分配：依董大偉提出的方向，逐步將實作交給AI，讓人的注意力聚焦在核心規則上。

這也讓「這條線很長」有了另一層意義：它不只是描述差距，也是在提醒開發者仍有準備的空間。不必用是否站在技術最前端衡量自己，而應一邊實際使用AI，一邊累積能被它放大的能力。

重點回顧

• 工具能力已從單點補全走向流程自動化，但真正要衡量的是能否安全、持續地交付價值，而不只是產生多少Code。
• 人的核心工作是釐清商業規則、確認需求與承擔判斷；AI負責實作的比例提高，不代表責任也能一併交出去。
• 用敏捷縮短回饋週期，用DevOps建立品質把關，再用高內聚低耦合縮小Token消耗與錯誤的爆炸半徑。
• SDD與小增量開發不是簡單的二選一優劣題：有規格就認真確認，有小Change就維持可理解、可驗證的範圍，依組織需求選擇。
• 不必為了追上最前沿而焦慮；先練好能被AI放大的基本功，再逐步提高自動化程度。

• 釐清部署策略的筆記疑問：逐字稿明確提到藍綠部署，金絲雀部署是否也在現場討論，仍需另行確認。

Rule Driven DevelpomentBusiness RuleBusiness LogicRule FirstCode SecondUI LastAI-SDLCAgentic DevelopmentCLIMCPReasoning ModelContext WindowOrchestration AppAI Code ReviewCI/CD pipelinehuman in the loophuman on the loopSpec-driven development高內聚低耦合Multiple Repository爆炸半徑敏捷DevOps