.NET Walker

11/29 ，我在 .net conf Taiwan 2025 的分享，題目是 『變革👉面對變革』，主要想談的是 LLM 在軟體開發領域(SDLC)中，這三年所帶來的改變。以及，如何面對。 關於『如何面對』這個部分，因人而異，我也就不想在這邊多說些什麼了。 但從 2022/11/30，一直到今天(2025/11/30)，AI對軟體開發帶來哪些改變，我倒是整理出了一些影片，也是我在這次會場中分享的部分內容，做為這一季也是 .net conf 2025 我自己場次的小總結，也分享給大家。 有些影片沒有聲音，原因是那是用來配合我在在講台上的講解所錄製，大多不長，讀者可以自己腦補體會一下。 我想表達的是， LLM在SDLC的每一個階段，都已經留下了深刻而無法抹滅的痕跡。不管你願不願意，未來AI都會與你一起開發系統，沒有例外。 開發階段AI帶來的改變(AI輔助開發): 這一段我想說的是，從2023年到2025年，AI在程式碼撰寫這個領域，介入的愈來愈深，愈來愈廣。從『只是這樣?』，到『原來可以這樣』… 2023年盛行的 Code Suggestion(程式碼片段生成或建議) https://youtu.be/gPGE-Tze_sk 2024年盛行的 Agent Mode(IDE內的大範圍生成) https://youtu.be/v6PI9Fbt7Oo 2025年開始的 CLI(命令列模式大範圍修改或生成) https://www.youtube.com/watch?v=MnbEhg3JWq4 當天做的一個現場小調查，你會發現，在今天，軟體開發就等同於AI輔助軟體開發，幾乎沒有例外： 需求設計階段AI帶來的改變： 如果你願意，AI也可以產生需求規格。甚至，從產生需求規格一路自動到完成開發… User Story/AC 自動生成 https://www.youtube.com/watch?v=AxtYwBUMIyM 搭配MCP，從規格自動完成功能開發 https://www.youtube.com/watch?v=Yp9UImcfWfs CI階段AI帶來的改變： AI的大幅度介入，將會讓人類成為開發的瓶頸，而有趣的是解決這個瓶頸的鑰匙，也是AI。現在透過AI，可以協助人類做 code review，在測試左移(shift ...

今天在 Build School 上課時發生了一件事，讓我想了想之後，還是決定寫篇文。 事情是這樣的。 上課時，我問學員：「如果有一個敏捷團隊，裡面大概 5-7 位成員，在一個迭代中同時開發 3-5 張需求卡片，你們覺得應該切幾個 feature branch?」 本來以為會聽到各種答案。 有人會按功能切、會按人頭切、或是按模組切…，因為我曾經聽過各式各樣的回答。 結果，他們所有人異口同聲：「只切一個分支。」 我愣了一下。「只切一個？」 「對，一個。」 這群學員才剛學 Git 沒多久，怎麼得出這個『違反常理』的結論的？上了這麼多年課，每次談到這個議題，學員都還可以跟我糾結半天，討論到底要不要用 Git Flow。 後來，助教跟我解釋，原來他們之前讓學員自己做了實驗。 什麼實驗? 實驗很簡單，因為反正要做專題，所以把學員幾個人分一組，讓他們用不同的分支策略跑幾個迭代。有些組按人切分支，有些按功能切，有些混著切。然後看看哪種方式最順。 結果呢？ 用多分支的組，第一個迭代還算順利，大家各寫各的，感覺井然有序。但整合的時候就開始出事了。功能 A 做完了，但要等 B 跟 C 才能 merge。有人幾天沒事做，只能坐著等。 到第二個迭代，問題更大。大家在自己的分支上寫了一段時間，最後 merge 時才發現衝突一堆。有些衝突好解，但有些是邏輯上的衝突，或是使用了同樣功能的不同套件，兩個人改了同一個模組的不同地方，單獨看都沒問題，合起來就爆了。 第三個迭代，有人開始崩潰。明明功能做完、測試也過了，但因為流程卡在 release branch，要等到迭代結束才能部署。一個小 bug 改了五分鐘，卻要三天才能上線。更慘的是，有人說：「程式碼寫完過了很久才整合，開始忘記當初為什麼要這樣寫了。」 最後，讓他們自己試試看：如果大家都在同一個分支上開發會怎樣？ 結果出乎所有人的意料之外。 衝突變少了(其實是變多了，但因為每天都在整合，有問題馬上發現，立刻解決，所以花在解決衝突的時間反而變少了)。部署變快了，一個小功能做完，就能立刻上線。整個團隊的節奏順暢很多，不用再有人乾等。 助教說：「他們自己體驗過就懂了，不用我們特別去教。」 聽完之後，我想了很久。 DORA 指標 其實他們體驗到的，就是 Google 研究出來的 DORA 指標在講的事情。 ...

開場 去年在 DevOps Days Taipei 研討會中，我有分享過類似的概念，當時我還無法實現。而且我覺得當時我提出這個想法的時候，很多現場聽眾目光裡閃爍著的，其實是略帶懷疑的眼神。 什麼概念呢? 我一直希望，能不能在 PR 過程中，Reviewer 只要寫下 Comment，就能有個 AI 工程師在背景直接幫我們改 code？ 或是能有一個夜班的 AI 工程師，可以隨時待命，接手白天人類的工作，在晚上完成一些例行性的任務。 現在，這個夢想終於實現了。而且比我想像的還要好用。 讓我們先聊聊 Git 版控時的 PR 流程。如果你有再用 Git 做團隊開發，我相信你一定知道 Pull Request 是整個開發協作的核心。開發者提交程式碼、reviewer 進行逐行檢查、留下 comment、來回討論、最後 approve 或是 request changes。這個流程很務實，也很必要。 但一直有一個問題。 不知道你有沒有算過，從 reviewer 在 PR 上留下 comment，到開發者真正動手修改，中間會經過多久時間？ 有時候是幾小時（如果大家都很閒），有時候是一整天（因為有會議、或其他工作），有時候甚至會拖到一兩天（可能是 Developer 沒收信、甚至根本是單純忘了上去看）。這段時間，PR 就這樣卡在那裡，什麼都不能做。CI/CD pipeline 也只能乾等。 更煩的是，有時候那些 comment 其實都是些「小修改」：改個函示名稱、加個錯誤處理、調整一下格式、補個註解。這種事情，說難不難，但要開發者停下手邊的工作、重新進入 context、再去改這些小東西，說實話，挺浪費時間的。 所以我一直覺得： 如果可以讓 AI 先做初步修改呢？ 那會如何? 主要不是為了取代開發人員，而是在 reviewer 提出建議後，讓 AI 先試著去處理那些「機械性」的修改。再由人類負責審核、判斷、給建議；AI 負責執行、修改、產出結果。這不是挺完美的分工嗎？ 實際操作 好，概念介紹完畢，來看看實際上如何運作。 假設今天有個 PR，reviewer 檢查後發現了一些需要改進的地方。就像平常一樣，在程式碼旁邊留個 comment。可能是「AI: 這一段應該要加上錯誤處理或Log」、「AI: 這個OOO變數名稱不夠明確」、「AI: 請加上OOO的...