AI 輔助開發的三個時代：從 Copilot 到 AI Engineering System

作者： -

前幾天有好友轉 PO 了某貼文，內容提到他們公司想要讓 PM 能直接在 Jira 上撰寫需求，然後直接觸發 AI 自動開發，完成後自動開 PR，最後工程師只需要 code review 即可。

原 PO 問，這樣可行嗎? (真是個有趣的孩子…)

剛好，適逢 Codex App 在 Windows 上正式釋出，來談談這個議題。

這三年，我幾乎是死盯著 AI 輔助開發的發展。

走到今天的感覺是：
上面那個流程 不只可行，
而且很可能在兩年內會成為軟體開發的主流。

回頭看三年 AI 輔助開發的演進

讓我帶你回頭看一下這三年 AI 輔助開發的發展。

你如果從 2023 年開始觀察到今天，大概分成這三個階段：

  1. Copilot (副駕) 時代 ( 2023-2024 )
    → AI Assistant（你寫，AI幫你完善）

  2. Claude Code / Copilot CLI 時代 ( 2025 )
    → AI Agent（你說，AI幫你寫程式）

  3. Codex App / Copilot Workspace 時代 ( 2026+ )
    → AI Engineering System（從需求啟動，AI 自己進行多 Agent
    協作，幫你直接完成交付）

換句話說，開發流程正從：

Developer 寫 code -> PR -> 交付

走向

Stakeholders/Developer 定義問題 -> AI Agents 實作 -> Developer Review -> AI 完成交付

AI 輔助開發的三個階段

我把上述提到的 AI 輔助開發三個階段，整理成一張生態圖，大概是下面這樣：
圖片

第一階段：AI in IDE（讓你寫得更快）

代表工具：

  • GitHub Copilot
  • Cursor
  • Windsurf

核心功能：

  • Autocomplete / inline suggestion
  • 小範圍程式碼生成
  • 即時問答 與 片段的程式碼重構

這階段本質上是「效率增幅器」，主角仍是工程師本人。

第二階段：AI Developer / Terminal AI Agent（幫你做得更多）

代表工具：

  • Claude Code
  • Copilot CLI

核心功能：

  • AI可理解整個 repo
  • 可以跨 檔案/模組 修改程式
  • 可自動執行 測試、除錯、重構

這階段開始把 AI 從「補全工具」推到
「可交辦任務的工程師夥伴(AI team member)」。

目前大部分的開發人員在這個階段。

第三階段：AI Engineering System（直接完整交付）

代表工具：

  • OpenAI Codex App
  • Copilot Workspace

核心功能：

  • Issue -> Plan -> Code -> PR -> Deploy 的 end to end 流程
  • 可多 Agent 並行的執行多種任務 (開發、測試、部署)
  • 可在 背景(或雲端)執行 且 具有 Sandbox 隔離
  • 人類可進行任務管理、追蹤、稽核

這階段的目標已經不只是開發(程式碼)，
而是旨在幫助團隊，從需求直接快速穩定的交付 “成果”。

AI 開始接管「從需求到交付」

如果你開始嘗試今天剛釋出的 OpenAI Codex
App，你就會發現，這已經不是「AI
幫你寫程式碼」這麼單純了，而是可以做到：

「AI 直接從需求幫你做到完整交付」。

接下來，開發流程中最重要的事情不是寫程式，

而是：

「定義任務、編排代理、審核結果」。

未來開發流程的三個核心工作

  1. 把需求寫成 AI 可執行的 Issue（規格化）
  2. 把 AI PR 審查流程制度化（Review Gate）
  3. 把測試與 CI/CD 變成 AI Agent 的護欄（Guardrails）

軟體工程正在被重新定義

AI 已經改寫了軟體工程中 原有的做法 與 分工方式。

從
人類寫程式碼，AI 幫你補全
到
人類定義問題，AI 幫你解決

這不僅是工具的升級，
已經是整個軟體開發流程的革命。

留言

張貼留言

這個網誌中的熱門文章

GitHub Copilot SDK：當你的程式碼有了自己的靈魂

作者： -
圖片
上個月協助客戶做技術評估時，他們的 CTO 會後跟我聊了個問題。 「你知道我們團隊最近在研究把 AI 整合進現有的系統與開發流程…」他闔上記事本(實體，有紙張的那種)，帶著思索的表情說到「你知道的，其實就自動化一些日常任務，像是程式碼掃描、Code Review、各種文件生成、自動化測試、應用程式部署、以及運行狀況檢查…這些。我們一開始看了 OpenAI API、後來也研究過 GitHub Copilot CLI、但最近又出了 GitHub Copilot SDK，老實說，不太確定該選哪個?」 他頓了一下，「還有，開發人員是不是常用一個 GitHub Copilot Agent? 它和 GitHub Copilot CLI 是什麼關係? 我們的開發主管說他每天都在用 GitHub Copilot, 但我不確定這幾個東西到底是不是在做同一件事…」 我打開投影片準備跟他慢慢解釋，心裡想「呵呵，你不是第一個問的…最近有太多人對這些新工具"們"感到困惑。很正常，你沒搞混我才覺得奇怪…」 GitHub Copilot SDK 是啥？ 最近我發現，只要聊到 Copilot，幾乎一定會卡在這個地方。 先講結論：GitHub Copilot SDK 是 GitHub 提供的一套 “開發套件” ，讓開發人員可以在自己的程式裡面整合 GitHub Copilot 的能力。 注意，是 整合 GitHub Copilot 的能力 ，而非在程式碼裡面整合 LLM(大語言模型) 的能力，兩者完全不同。 要在程式碼裡面整合 LLM(大語言模型) 的能力，三年前的 OpenAI API 就可以做到了。 GitHub Copilot SDK 是讓開發人員可以直接利用 GitHub Copilot 的 AI 能力來執行特定任務、調用工具，甚至讓 AI 自己進入一個工作循環，持續執行任務，並且持續改進，直到該任務真正完成。 你應該曾經在 VS Code 裡面用 GitHub Copilot Agent Mode 來產程式碼。那個嚴格來說叫做 Copilot Extension，是安裝在 VS Code、Visual Studio 裡面，自動幫你補全(或生成)程式碼的幫手，也就是現在大部分開發人員已經在用的那個 AI輔助開發工具。(也就是坊間所謂的 AI ...
Read more »

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

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

使用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 »

使用 Render.com 作靜態網站的自動化佈署

作者： -
圖片
最近在上課時，為了讓不想花錢申請 Azure 雲端服務的學員，也能夠實際體驗 CI/CD 的開發流程，我一直在尋找一個 免費、簡單 的網站部署的平台。希望用戶只要有 GitHub 帳號，就能將 repo 內的網站經由 GitHub Actions 自動佈署到雲端。 試過幾個方案之後，最後選擇了 Render.com 。它不但提供免費的靜態網站託管，還能輕鬆與 GitHub 整合，自動化部署流程幾乎沒什麼難度，非常適合教學與初學者練習使用。 什麼是 Render.com Render.com 是一個現代化的雲端平台，提供簡單、快速且免費的網站服務。​透過與 GitHub 的整合，開發者可以輕鬆地將靜態網站自動部署到 Render，並利用 GitHub Actions 進行持續整合與部署（CI/CD）。 Render 支援多種服務類型，包括： 靜態網站（Static Sites） ：​適用於 HTML、CSS、JavaScript 等前端資源，透過全球 CDN 提供快速、安全的內容傳遞。 Web 服務（Web Services） ：​支援 Node.js、Python、Ruby 等後端應用程式的部署。(但不支援 .net) 私有服務（Private Services） 、 背景工作（Background Workers） 、 排程任務（Cron Jobs） ：​適用於內部服務、非同步處理及定時任務。 如何從 GitHub 部署靜態網站到 Render Render 本身直接支援自動化佈署，你可用 GitHub 帳號申請Render.com ，並且直接建立一個靜態網站： 你可以在建立站台的時候，直接選擇要從哪一個 GitHub Repo 進行佈署: 在選擇好後，你可以配置該網站關聯的資料來源位置(選擇Repo中的資料夾): 設定完成之後，只需要一鍵就能佈署完成： 如果要變成自動化呢? 我們可以在 GitHub Repo 中設定 Action，來進行網站的自動化佈署。 由於Render.Com 提供一個自動化佈署的 WebHook(本質上就是一個API)，只要呼叫該API， Render.com 就可以自動從 GitHub repo 中取得最新的程式碼，並且佈署到伺服器端： 也因此，只要我們為其配置一個 GitHub Acti...
Read more »