.net conf Taiwan 2025 Recap

作者： -

圖片

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在程式碼撰寫這個領域，介入的愈來愈深，愈來愈廣。從『只是這樣?』，到『原來可以這樣』…

  1. 2023年盛行的 Code Suggestion(程式碼片段生成或建議)
    https://youtu.be/gPGE-Tze_sk
  2. 2024年盛行的 Agent Mode(IDE內的大範圍生成)
    https://youtu.be/v6PI9Fbt7Oo
  3. 2025年開始的 CLI(命令列模式大範圍修改或生成)
    https://www.youtube.com/watch?v=MnbEhg3JWq4

當天做的一個現場小調查，你會發現，在今天，軟體開發就等同於AI輔助軟體開發，幾乎沒有例外：
圖片

需求設計階段AI帶來的改變：

如果你願意，AI也可以產生需求規格。甚至，從產生需求規格一路自動到完成開發…

  1. User Story/AC 自動生成
    https://www.youtube.com/watch?v=AxtYwBUMIyM
  2. 搭配MCP，從規格自動完成功能開發
    https://www.youtube.com/watch?v=Yp9UImcfWfs

CI階段AI帶來的改變：

AI的大幅度介入，將會讓人類成為開發的瓶頸，而有趣的是解決這個瓶頸的鑰匙，也是AI。現在透過AI，可以協助人類做 code review，在測試左移(shift left)的路上，更進一步…

  1. PR 之後的自動化 Code Review (ADO)
    https://youtu.be/Pqa2XxVQhUI
  2. GitHub 中的自動化 Code Review
    https://www.youtube.com/watch?v=osQXFayDN9Y

測試階段AI帶來的改變：

2023年時，AI在測試領域還不成氣候，到了2025年底，AI已經可以搭配MCP進行全自動化UI測試，毋須錄製腳本，就像你有一組 QA 測試團隊，你只要開口說，它們就直接做…

  1. 測試案例(Test Case) 自動生成
    https://www.youtube.com/watch?v=GJLuuCabtHY
  2. 從測試案例進行自動化UI測試(使用MCP)
    https://www.youtube.com/watch?v=I9D_qA4VioM
  3. 從測試腳本(md格式)進行UI自動測試(使用MCP)
    https://www.youtube.com/watch?v=0aalWCXDX8o

in Pipeline AI帶來的改變：

CLI，是自動化的關鍵。
2025年底，以CLI面貌出現的LLM，將可以直接整合在 DevOps Pipeline 中，夜裡，AI測試大軍可以自動幫你掃程式碼品質、修bug、寫文件，全自動化開發幾乎就在眼前。

  1. 在 Pipeline 中運行 GitHub Copilot CLI 自動找出bugs
    https://youtu.be/Yv098gEp_fE
  2. 在 PR 流程中，透過 PR Comment 使喚 AI 自動修復bug
    https://www.youtube.com/watch?v=fb6zpibBToA

Sam Altman 說：『到了 2025 年底，軟體工程會和你過去所看到的截然不同。』

你覺得呢?

留言

張貼留言

這個網誌中的熱門文章

為何想做CI的你，根本不該使用 Gitflow?

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

開啟 teams 中的『會議轉錄(謄寫)』與Copilot會議記錄、摘要功能

作者： -
圖片
在 Teams 中有一個非常好用的功能，可以透過 “謄寫” 把 Teams 的語音會議變成逐字稿，這部分當然是用到語音識別(語音轉文字)的AI技術。 開始謄寫與自動會議紀錄 當啟動一個會議之後，主席可以透過底下這個『開始謄寫』功能來開啟： 這個功能之所以重要，是因為他也是 Teams Copilot 要能夠順利使用的基礎。我們可以透過 Teams Copilot 進行會議的摘要、總結、整理、或是進行會議內容的詢問，而這後面用的則是LLM(大語言模型)的能力： 這功能對於需要參加很多會議的主管、或是在開會遲到的同仁，都是很方便的功能，可以透過詢問Copilot快速地進入會議狀況。 開啟 “謄寫” 功能 然而，這一切的基礎 “謄寫” 功能卻不是每一個機構都有預設開啟，如果你發現你的 “謄寫” 功能是灰色的(無法點選)，就意味著你的組織沒有開啟(或沒有為你開啟)這個功能。 那組織的管理員該如何開啟此功能呢? 很簡單，只需要到 Teams 系統管理中心，點選 『設定和原則』 --> 『會議』： 進入 『會議』 的設定之後，找到『會議錄製』–>『轉錄』 將其『開啟』即可: 如此一來，組織內的同仁就可以順利的使用 Tteams 會議中的語音轉文字(謄寫)功能，也可以使用 Copilot 來查詢會議的內容囉。 Enjoy it~
Read more »

使用LM Studio輕鬆在本地端以API呼叫大語言模型(LLM)

作者： -
圖片
最近上課常被問到，如何在地端環境搭建出大語言模型(LLM)，並且呼叫其API。 一開始我不太理解為何會有這樣的需求(因為在地端自行搭建運行LLM的成本不一定比較低，即便可能比較安全)，但被問多了，也就開始遍尋相關的解決方案，看看有沒有什麼最簡單的方式，可以讓開發人員在地端測試大語言模型? 後來我選擇 LM Studio ，它就是一款設計來運行大型語言模型（LLM）的平台，有個算是挺優雅的整合環境，讓一般 end-user 或開發人員，都可以輕易地在 local 端進行模型的部署和測試。 LM Studio 本身支援多種模型架構和框架，當然，最重要的是，它是免費的。 下載安裝 都很容易，我就不多說。 安裝好之後，你可以看到首頁中已經呈現了許多 Hugging Face上的模型： 這顯然是因為Hugging Face是大部分免費開源模型的集散地。 你可以搜尋自己喜歡的模型，透過LM Studio下載到local之後，就可以直接載入(下圖一)： 隨手設定一下 system prompt(上圖二)，然後，就可以直接對談了。(上圖三) LM Studio會使用你的GPU進行運算(如果有的話)，你會發現，原來有好的設備(GPU)，運行的速度可以如此之快。 Local Server 對於開發人員來說，它還有個超級更友善的功能。 LM Studio本身還提供一個 local server，可以幫你把模型包裹起來讓你直接透過API呼叫該模型的功能，例如： 上圖是我們開啟 LM Studio中 Local Server功能後的結果，你可以透過 localhost 的 1234 port 來呼叫這個被 LM Studio 運行起來的大語言模型。(有沒有發現，我們用的也是 chat/completions API) 透過Postman簡單提供一下 JSON Body: { "model": "LM Studio Community/Meta-Llama-3-8B-Instruct-GGUF", "messages": [ { "role": "system", "content": "你是AI助理，請一律用繁體中...
Read more »

VS Code的字體大小

作者： -
圖片
身為.net developer，這年頭是什麼code都得要會寫的年代。 而雖然我的NB還沒從Windows淪陷為Mac OS，但寫Node.js和Python免不了要用VS Code，這是一種愛的表現。 但歲月不饒人，盡管微臣非常熱於配合，但VS Code預設字體的大小在我還沒錢買大尺寸螢幕的狀況下，實在讓老臣難以適應。當下的第一個反應是什麼? 當然是 Ctrl+滑鼠滾輪往上推…哇靠，沒用。看…這設計…恩，千錯萬錯一定是我的錯。 只好從選單 file –> Preferences –> Settings: 在出來的視窗中，你可以看到 editor.fontsize: 沒錯，改它就行了。改不動? 喔，不好意思，我沒仔細看說明，要copy到右邊是吧，沒問題，copy->paste->modify->Save…搞定。 好簡單啊…連ctrl+(mouse scroll up)都用不到了呢… 咦?這是一篇抱怨文嗎? 沒有，誰說的? 免費的tool我們還有什麼好抱怨的呢…要感恩啦。 啊….對了，如果你還是堅持要使用 Ctrl+滑鼠滾輪，請找關鍵字… "editor.mouseWheelZoom"
Read more »

原來使用 .net 寫個 MCP Server 如此簡單

作者： -
圖片
MCP 的重要性與意義 MCP 的重要性在於它建立了一個標準化的架構，讓開發者能夠快速建構出給 AI Agent 呼叫的各種功能。 舉例來說，假設我們希望實現一個 可以透過自然語言對談的請假功能 ，傳統上我們必須建立一個前端 Chat Bot 作為 UI、還得撰寫後端 API、資料驗證邏輯、資料庫存取介面…等，另外還要設計 Chat Bot 的對話邏輯，才能把請假功能整合到Chat Bot的對談訊息中。 但在 MCP 的架構下，這樣的流程可以大幅簡化。 開發者只需要實作幾個「請假功能」的介面（Tool Interface），接著定義好運行這個功能需要輸入哪些參數（例如請假人、開始時間、代理人、事由…etc.），並透過 JSON 來描述這些參數的格式與驗證邏輯。接著，AI Agent 便可以在對話過程中，自動根據對談前後文理解使用者意圖，挑選出適合的Tool來運行，主動發出呼叫的請求。如此一來，大幅簡化了AI Agent開發的難度。(本質上就是 Function Calling 的概念) 而 .net 又把這個難度降低到人人可以開發的程度，底下是一個使用 .net 開發的 請假功能 MCP Server，並且使用 GitHub Copilot來呼叫的例子： 其實我之前用 Semantic Kernel做個類似的範例，只是如今 .net 讓它變得更簡單，而且輕易地可以透過MCP架構讓不同的 MCP Client端呼叫使用。 如何用 .NET 撰寫 MCP Server 要使用 .NET 撰寫 MCP Server 非常簡單，受益於 Microsoft.Extensions.Hosting 和 ModelContextProtocol 套件，我們可以在幾分鐘內輕鬆地實作 MCP Tool 和 MCP Server 。 以下是MCP Server的完整程式碼： using Microsoft . Extensions . DependencyInjection ; using Microsoft . Extensions . Hosting ; using Microsoft . Extensions . Logging ; using ModelContextProtocol . Server ; using System ...
Read more »