(圖片來源: DALL-E, 不過我參不透 AI 想表達啥 XDD)

九年前 (2016)，寫過一篇文章: .NET 開發人員該如何看待 Open Source Solutions?，當時會想寫這篇的動機很單純，那是個 Microsoft 新 CEO 剛上任, 策略大幅改變的年代, 所以我寫了這篇文章來說明我的看法。

到了 2023, 整個軟體資訊業，都被 AI 翻了一輪，Microsoft 大舉跟進 AI 相關應用與服務，我覺得另一個軟體開發領域的大改變來了。我去年本來也打算再寫一篇，無奈當時還是個 AI 的門外漢，應該寫不出什麼東西.. 不過累積了一年，加上最近想通了一些事情，就有了這一篇文章。

在開始講我的看法前，第一段就先來看看我的 PoC 吧，我自己刻了線上商店的 API，很單純的瀏覽商品、加入購物車、結帳這些動作。這 PoC 的重點在於，我想打造了一個安德魯小舖 GPT 的應用專案，看看 GPTs 能否完全代替店員，讓我用聊天的方式完成整個購物的過程。

這篇文章後面我的心得，跟我想表達的觀點，都可以從這個簡單的 PoC 得到驗證。想看我到底做了什麼 PoC 的，就繼續往下看；想直接看觀點的可以跳到第二段開始。

1, 安德魯小舖 GPTs - Demo

在 2023/11, Open AI 的開發者大會，發布了一個新的服務: GPTs, 我這次 demo 的主角, 就是想試試看, 搭配我自己的 API, GPTs 能替我把體驗做到什麼樣的程度?

GPTs 是以 Chat GTP 為基礎, 他允許你在這基礎上, 預先設定好它的角色設定 (只管用自然語言說明就好), 背後的知識庫 (只管上傳檔案就好, 不用理會 RAG 什麼的細節), 你也可以把自己的 API 掛上去 ( Custom Action, 只要遵循 Open API spec 就好, 寫好每個 path 的說明即可, 不用做特別設定, GPTs 會自己思考何時要呼叫你的 API)。完成之後，這個客製化的 GPTs, 就會按照你的設定, 來回應你的問題。而我這次的 demo, 就是客製了安德魯小舖 GPTs, 他是個店長, 你只要跟他對話, 他可以在線上服務你, 並且替你呼叫 API 完成整個購物的流程。

整個測試進行下來，說老實話，技術門檻很低，沒有太多新的 “技術” 要學。但是整合應用的門檻很高，困難的地方在於跟傳統的做法差異太大了，像我這種經驗充足的業界老人反而綁手綁腳的很不習慣.. (這是我的問題啊)，有很多顛覆傳統的思考方式需要適應。另一個感受就是: 我對 API 的看法又更深一層了，這個 demo 裡，API 是 AI 與現有系統的唯一溝通管道，而 API 被呼叫的方式也跟過去不同，要呼叫你 API 的是 AI，是你無法預測他行為模式的 LLM，而不是另一個 developer … 這背後帶出了你的 API 不再是 “能動就好” 的設計思維，而是要真正要讓領域專家 (我假設給了正確知識的 GPTs 就是領域專家) 能充分理解 API 運作邏輯，並且能正確使用。過去我在談的 API First 跟 Business Model，正好在這邊完全派上用場，這是這次 PoC 能順利進行最關鍵的地方。

開始看 demo 吧! 你有幾種方式可以體驗安德魯小舖 GPTs:

懶人包, 可以直接看完整對談紀錄。
技術細節，可以直接看我這次開出來的購物網站 API 規格
實際體驗安德魯小舖 GPTs, 只要你有 Chat GPT Plus 訂閱，點這個連結就可以體驗了。我只是實驗性質，API 目前架設在 Azure App Service 下，沒有 HA，隨時會關掉。資料都是存在記憶體內，服務重啟就會清空。帳號註冊登入只是個流程，只看 username，密碼亂打都可以過。

介紹完畢，接下來我就用我的情境，跑完一次整個使用的過程吧:

1-1, (問) 店裡有賣什麼?

首先，對話一開始，我就問了店裡有賣什麼:

其中看到 “已與 andrewshopoauthdemo.azurewebsites.net 進行對話”，就代表 GPTs 背後已經在呼叫你的 API 了，箭頭往下拉可以看到背後 POST 了什麼資訊.. 這邊還如預期，GPTs 中規中矩的呼叫了 /api/products, 把取得的商品資訊 (json) 轉成清單顯示給我看。 GPTs 蠻細心的地方是，商品資訊還會自動幫我摘要.. 我原本寫的內容比較囉嗦… 為了方便對照，底下是 API 原生傳回的內容:

[
  {
    "id": 1,
    "name": "18天台灣生啤酒 355ml",
    "description": "18天台灣生啤酒未經過巴氏德高溫殺菌，採用歐洲優質原料，
    全程0-7°C冷藏保鮮，猶如鮮奶與生魚片般珍貴，保留最多啤酒營養及麥香風味；
    這樣高品質、超新鮮、賞味期只有18天的台灣生啤酒，值得您搶鮮到手!",
    "price": 65
  },
  {
    "id": 2,
    "name": "可口可樂® 350ml",
    "description": "1886年，美國喬治亞州的亞特蘭大市，有位名叫約翰•潘伯頓
    （Dr. John S. Pemberton）的藥劑師，他挑選了幾種特別的成分，發明出一款美味的糖漿，
    沒想到清涼、暢快的「可口可樂」就奇蹟般的出現了！潘伯頓相信這產品可能具有商業價值，
    因此把它送到傑柯藥局（Jacobs' Pharmacy）販售，開始了「可口可樂」這個美國飲料的傳奇。
    而潘伯頓的事業合夥人兼會計師：法蘭克•羅賓森（Frank M. Robinson），認為兩個
    大寫C字母在廣告上可以有不錯的表現，所以創造了\"Coca‑Cola\"這個名字。但是讓
    「可口可樂」得以大展鋒頭的，卻是從艾薩•坎德勒（Asa G. Candler）這個具有行銷
    頭腦的企業家開始。",
    "price": 18
  },
  {
    "id": 3,
    "name": "御茶園 特撰冰釀綠茶 550ml",
    "description": "新升級!台灣在地茶葉入，冰釀回甘。台灣在地茶葉，原葉沖泡。
    如同現泡般的清新綠茶香。",
    "price": 25
  }
]

1-2, (刁難) 預算跟折扣的處理

接著我就開始出難題給 GPTs 了… 我的 API 只有提供商品單價，或是你加入購物車後，會有 API ( /api/carts/{cart-id}/estimate ) 會傳回結帳金額的試算結果。這段 code 背後有實做折扣條件的計算。背後的規則是:

18天台灣生啤酒有第二件六折優惠

不過這規則並沒有 API 揭露，因此需要推測，並且加入購物車試看看才能知道結果。所以我出了難題給 GPTs:

結果還蠻神奇的，GPTs 的理解跟推理能力還不錯，看的懂我的要求，也看得懂 API 的能力範圍，於是自己推演了邏輯，一連串呼叫了好幾次 API 幫我確認結果，最後給了我建議的採購項目。不得不說，做得比我預期好，雖然偶爾會得到錯的答案，但是看的出來 GPTs 有在努力…。

(不過，這結果沒有 100% 穩定可靠，我在測試的過程也碰過很瞎的答案.. )

我繼續刁難他。過去在做 Chat Bot 的經驗，對談只是在聊天介面下下 CLI 的指令那樣的感覺，根本不是 “對話”。這種 Chat Bot 要說上能了解你的意圖，根本就差太遠，只能說是雞同鴨講。為了確保 GPTs 真的理解我的意圖，我刻意追加了要求，用口語要求在前面的結果修正多加兩件，而品名我也刻意用同義字，只講了 “啤酒”，沒有講精準的產品品名..

結果 GPTs 的處理相當正確，呼叫了對應的 API，也給我正確的結果，並且進行了結帳的流程，呼叫了 /api/checkout/create (開始結帳) 的 API..

結帳過程很順利。我的 API 設計本來就只要求拿到支付 ID 就當作結帳完成，而 API 背後我也沒真的去檢查 ID 對不對，簡單的說你只要給個 ID 就能過關。GPTs 也正確地替我呼叫結帳完成 API, 完成結帳。並且顯示訂單內容給我:

到這裡為止，購物的主要流程都很順利地結束了。我給 GPTs 100 分，因為他替我 “腦補” 補上了我 API 沒有涵蓋的功能，這點對我來說還蠻震撼的，GPTs 補足了所有軟體的難題: 猜測使用者想要幹嘛，然後做出正確回應… 我留一些感想在後面觀點在聊，我繼續往下 demo …

1-3, (刁難) 調整訂單, 不要酒類飲料

繼續測試 GPTs 的解讀跟處理能力… 我繼續挑戰他的對談能力，這次告訴它預算，條件比照辦理，但是有小孩不能喝酒。我刻意句子沒有講不要買酒，只是隱諱地告訴他我的期待，需要靠他自己聯想，該把購物車內的酒類商品都拿掉，並且調整數量符合我的預算跟條件 (不同商品購買數量要接近一致):

碰到我這種奧客，果然錢很難賺 XDD，這次也順利結帳，成立第二張訂單，過程我就略過了 (有興趣自己看對談紀錄)。

1-4, (刁難) 整理訂購紀錄

接下來，身為一位常客 (也才買兩次)，來詢問一下買過了什麼也是很合理的… 問了訂購紀錄，GPTs 也幫我辦到了，同時也很盡責地幫我把資訊彙整了一下才回給我。我貼一下 GPTs 的回應:

我也補一下 API 回應的 raw data (json) 結果，讓大家可以對比一下.. (測試完成我就清掉了，這 API ( /api/member/orders ) 結果是我事後另外補的，資訊不大一樣各位就別計較了 XDD)

{
  "totalOrders": 2,
  "totalAmount": 2172.0,
  "orders": [
    {
      "id": 1,
      "buyer": {
        "id": 1,
        "name": "andrew"
      },
      "lineItems": [
        {
          "title": "商品: 18天台灣生啤酒 355ml, 單價: 65 x 12 件 = ¤780.00",
          "price": 780
        },
        {
          "title": "商品: 可口可樂® 350ml, 單價: 18 x 11 件 = ¤198.00",
          "price": 198
        },
        {
          "title": "商品: 御茶園 特撰冰釀綠茶 550ml, 單價: 25 x 11 件 = ¤275.00",
          "price": 275
        },
        {
          "title": "優惠: 18天台灣生啤酒 355ml 第二件六折, 折扣 ¤26.00",
          "price": -26.0
        },
        {
          "title": "優惠: 18天台灣生啤酒 355ml 第二件六折, 折扣 ¤26.00",
          "price": -26.0
        },
        {
          "title": "優惠: 18天台灣生啤酒 355ml 第二件六折, 折扣 ¤26.00",
          "price": -26.0
        },
        {
          "title": "優惠: 18天台灣生啤酒 355ml 第二件六折, 折扣 ¤26.00",
          "price": -26.0
        },
        {
          "title": "優惠: 18天台灣生啤酒 355ml 第二件六折, 折扣 ¤26.00",
          "price": -26.0
        },
        {
          "title": "優惠: 18天台灣生啤酒 355ml 第二件六折, 折扣 ¤26.00",
          "price": -26.0
        }
      ],
      "totalPrice": 1097.0
    },
    {
      "id": 2,
      "buyer": {
        "id": 1,
        "name": "andrew"
      },
      "lineItems": [
        {
          "title": "商品: 可口可樂® 350ml, 單價: 18 x 25 件 = ¤450.00",
          "price": 450
        },
        {
          "title": "商品: 御茶園 特撰冰釀綠茶 550ml, 單價: 25 x 25 件 = ¤625.00",
          "price": 625
        }
      ],
      "totalPrice": 1075
    }
  ]
}

我的 API 很囉唆的把每個折扣都列出來了，但是 GPTs 回給我的訊息，把它彙整 summary 結果給我了，還蠻貼心的，這種程度的訊息處理，沒有 AI 的輔助，自己刻 Chat Bot 會刻到哭出來吧…

接著，繼續為難店長 (咦?)，我很清楚我的 API 只有傳回訂單內容，我就要求 GPTs 幫我家總一下到底每種商品我買過幾件…

結果，如我預期做得很不錯，不但沒有重新打一次 API 重新取得結果之外，也正確地理解我的要求，幫我算好統計結果了。最後我要求把條列的內容換成表格，也一樣做到了 (看起來是用 markdown)

1-5, PoC 小結

Demo 內容就到此先告一段落，背後很多技術細節，跟我處理過程踩到的地雷，就先跳過 (有機會我再寫另一篇來聊聊實做過程)。如果你有興趣想知道，可以在底下留言問我，或是在 facebook 留言詢問也可以。

為了方便大家快速判定一下 GPTs 到底 “腦補” 了多少東西，我附上我的 API source code:

程式碼我就直接附上 GitHub Repo 了。我的目的只是 PoC, 所以裡面有很多 Anti Patterns, 請直接忽略…

我相信不少朋友只是想知道 API 做了哪些事，我特地把 swagger 打開才部署上 Azure App Service, 需要可以直接看 swagger, 我也捷了圖:

2, 軟體開發的改變

這段是整篇最抽象的部分了，不過也是我做完 PoC 最大的體悟，也是我想通 AI 成熟後，對現在的軟體開發最大的改變的想法說明。我表達能力沒那麼到位，如果看不懂我想表達的，建議看完整篇後可以再回頭來看看這一段，我相信你會明白我的想法。

我從開始學寫程式時寫的第一行程式碼 printf ("Hello World, Andrew!"); 開始，所有交給電腦處理的事情都是非常明確的，一個指令一個動作。直到現在，電腦都不大能處理邏輯不明確的操作，這 20 年來最大的差別就是操作變簡單了，但是要明確的指令這件事一直都沒變.. 這也難怪, 電腦從一開始被發明出來, 英文是 “computer” (計算機), 而不是像中文這樣翻譯成電 “腦”, 或是 “智慧” 等等這類用語，計算機就是計算，再複雜的計算還是計算，不是智慧，也不是真人。

不過 AI 在 2023 的發展，打破了這個門檻。對我這種 AI 門外漢來說，我看到的就是語言模型突然之間成熟到能理解對話內容背後的 “意圖” 了，突然之間你問他什麼內容，他都能若有其事的回答你有參考價值的答案 (正確性是另一回事，但是至少是人話了)。光是這點，就足以打破過去 20+ 年我對軟體開發的基礎認知。

2-1, 使用者體驗:

軟體發展，很長的過程都在改善 “UX” (User Experience)，都在標榜直覺，易懂，好操作。從視窗介面 (用畫面 + 滑鼠替代鍵盤)，用所見即所得代替指令 + 輸出結果的過程；進化到行動裝置後，體感操作也進來了，用觸控，裝置翻轉，鏡頭，麥克風等等操作，再次用手指 + 體感，替代滑鼠..

不過這些都是讓 “操作” 變簡單，基本上你還是在下指令。你心裡仍要清楚這 “指令” 跟預期 “結果”，只是這指令越來越簡單而已。我在教家裡長輩用手機電腦，最大的障礙不是這些操作，而是不知道要完成他的 “意圖” 該做什麼 “操作”..

舉例來說，長輩想要把一份文件傳給對方…

“我該開 email 還是 line? 我該選檔案還是複製連結? 我該打對方的電話號碼還是 …? 對方是 facetime 我怎麼 line 給他…”

這些問題沒讓長輩搞懂的話，操作再簡單都沒用，長輩們對用手機電腦就是存在著障礙… 更不用說檔案系統的目錄階層跟檔案，還有 APP 之間的關係了 (我家的長輩永遠搞不懂一個 word 檔案開了三個 word 視窗是怎麼一回事)

這就是我所謂 “使用者意圖” 跟 “使用者操作” 的隔閡。目前所有的 UX，都是在 UI 設計基礎上，去 “猜測” 使用者的意圖是什麼，而讓整個操作過程變簡單，流程縮短的持續優化過程。然而，這 “猜測” 的準確度落差很大，業界能把 UX 真正做得很好無懈可擊的案例，說真的其實不多。這到目前為止還是們非常專業，非常倚重經驗的一個設計領域。

2-2, 由大型語言模型 (LLM) 整合所有資源

而 LLM (大型語言模型, Large Language Model) 的成熟，我認為這個隔閡開始被打破了。所有在去年初次體驗 Chat GPT 的人大概都有一樣的感受吧! Chat GPT 的 UI 不怎麼樣，就是聊天而已，很陽春，但是他對你輸入的文字能很正確的猜到你的意圖，給你合理的回應，光是這點就完全把其他的 UX 做的努力甩到一邊去了。對我而言，這是所謂的 “降維打擊”，LLM 用截然不同的方式，來解決 “了解意圖” 這件事，這解決方式的差異，注定了傳統的 UX 優化，在怎麼樣是跟不上 LLM 的，只要 LLM 持續進步的話…

因此，我在這次 PoC 我親身體會到 LLM + API 的整合威力了。這次 PoC 我認為影響我想法最大的，就是我的 API 怎麼被呼叫的這個過程。過去，API 一直都不是給 “人” 看的東西，都是工程師們之間溝通用的火星文，凡人是看不懂這種外星語言的.. 然而如果你把 LLM 當 “人” 來看，他卻又有辦法在 “自然語言” 跟 “程式語言” 之間對應..。

這部分 open ai 的文件: Function calling 這篇就說明的很清楚, 各位可以不用看他的完整規格, 但是流程說明倒是可以看一下，我節錄部分:

Function calling allows you to more reliably get structured data back from the model. For example, you can:

Create assistants that answer questions by calling external APIs (e.g. like ChatGPT Plugins)

e.g. define functions like send_email(to: string, body: string), or get_current_weather(location: string, unit: ‘celsius’ or ‘fahrenheit’)

Convert natural language into API calls

e.g. convert “Who are my top customers?” to get_customers(min_revenue: int, created_before: string, limit: int) and call your internal API

Extract structured data from text

e.g. define a function called extract_data(name: string, birthday: string), or sql_query(query: string)

…and much more!

過去，UI 是由前端工程師做出來的，在 UI 之後，完全就是工程師的世界了。UI 接受使用者的操作，UI 設計人員就必須負擔把他轉譯成 “正確” API 的任務，而這 API 一路往下層傳遞，變成呼叫其他服務，或是存取資料庫等等細節。

而透過 LLM，路線不同，但是目的一樣，同樣是把使用者的輸入轉譯成 “正確” 的 API 呼叫。只是這裡的輸入，可能是自然語言，甚至是整個操作的前後情境 + 自然語言的綜合判斷。LLM 能夠理解來自多方的資訊 (只要都能對應成自然語言，也就是 Prompt)，就能做出正確地對應或是彙整。例如你丟給 Chat GPT 一篇文章，你在接著問他一些問題，Chat GPT 能 “消化” 這些文章內容，並且重新整理萃取你要的內容，甚至按照你要求，加工整理之後給你結果。要轉譯成 API 呼叫也是一樣，從自然語言歸納成呼叫 API 的步驟，逐步把每個參數從語言中萃取出來，變成正確格式 (json)，剩下就交給其他模組接手 (轉發 API) 就完成目的了。

這個安德魯小舖 GPTs 就是在做這件事，而且做得還不錯，我才開始感到震撼，未來的軟體開發，免不了一定要有個環節，必須善用 LLM 的解讀使用者意圖的能力才行。而 LLM 會扮演的是整個軟體系統的中控中心 (因為他能斷定該呼叫什麼模組，而不是單純照預先寫好的邏輯)

我所謂的 “整個軟體開發的變革” 就是指這個，未來越需要貼近使用者意圖的應用，越會依賴 LLM 當作中控中心。所有操作都先轉化成自然語言丟給 LLM，由 LLM 幫你 “思考” 該調用那些功能來滿足使用者。這 “思考” 的過程就是從前後文找出對應的 API，然後從前後文萃取出參數來呼叫。而應用程式的開發框架，也開始會配合這樣的架構抽象化，方便軟體開發人員快速堆疊建構應用程式。

所以，在未來 API 不會消失，但是 API 不再是給其他開發者看的火星文，API 的設計也必須開始合理化 & 標準化，因為未來會呼叫你 API 的不再是 developer，而是 LLM。無法被 AI 善用的 API 將會是落伍的武器，無法在下個世代發揮戰力。

2-3, 所有應用程式都會圍繞著 AI 而開發

什麼叫做 “無法被 AI 善用的 API” ?

前面 2-2 聊的問題，關鍵只有一句話，就是: LLM 負責自然語言與函數呼叫之間的轉換 ( LLM 要將自然語言轉為 API call 的順序與解析出對應參數，而要將 API 回應結果彙整給使用者 )

翻成白話，就是 AI 理解你 API 的使用方式，靠的就是 “文件”。你可以透過文件告訴 AI 該怎麼使用 API，但是你無法約束他，因此你的 API 設計是否有一致性，是否合理，是否夠嚴謹就很關鍵。你必須有很明確的流程，AI 才能長出正確的呼叫順序的腳本來執行，如果流程錯誤，你的 API 必須能辨別 (這就是我為何那麼強調狀態機)，如果你發現你的 API 有很多 “特例”，你就得花更多時間來寫文件，並且測試 AI 能否理解。

在這次的 PoC, 我就犯過類似的問題。不合理的設計，靠文件是補不完的，你能做的只有幾個:

封裝: 不合理的設計就藏起來吧，別讓 AI 看到..
文件: 如果問題不大，文件標註 “不能這樣用喔…“，也許有機會
改寫: 重新封裝一個 “設計” 合理的 API，開放這版本的 API 給 API ..

到最後，別再指望你 API 的缺陷，可以提醒其他 developer 閃開或是配合你了 XDDD, LLM 不吃這一套的，除非你有足夠的本錢來訓練你自己的語言模型 (通常是改 API 最便宜)

2-4, 各種角色的職責變化

因為這些核心流程的改變，我相信未來的軟體開發，會從很基礎的結構就開始翻過一輪。我先簡單摘要幾個我想通的變革，後面再從這些變革出發，來看看 Microsoft 的 AI 技術布局，也來看看架構師等資深人員，還有軟體開發者的角色該如何調整自己來追上這波變革。

LLM 會變成作業系統的一環:
我預期 LLM 會變得像空氣水一樣重要，他會變成作業系統的核心元件之一。不論是整合雲端的 AI service，或是軟硬體已經有能力在設備端 (edge) 就能執行 LLM 運算。作業系統會統一管理這些資源與溝通介面。所謂的 AI OS / AI PC 大概就是這麼一回事
LLM 會融入主流的軟體開發框架:
軟體開發框架會改變，勢必會讓 LLM 有個正確的位置，並且有足夠的 Plugins 機制讓應用程式能去擴充 LLM 的 “技能”，讓 LLM 充分的使用他
Copilot 會變成作業系統的主要介面:
操作介面也會改變。UI 不會消失，但是如同我的 PoC，開始會有一部分 UI 無法處理的需求，會用自然語言 (文字，語音，視覺等等) 等方式來溝通，並且讓 LLM 來引導。這就是 Microsoft 不斷推廣的 Copilot 基礎。這也會下沉到作業系統，或是主要的工具入口 (如 Office, GitHub, Visual Studio 這類特定領域的必要軟體)

未來，不論你是軟體開發的哪一種角色，架構師也好，開發者也好，你都該了解這些改變，並且能在這改變中做出貢獻 (有能力能加速這改變的過程)，你就不用擔心你會被 AI 淘汰..

3, 看懂 Microsoft 的 AI 技術布局

回到開頭講的 2016 那一篇文章吧，當時 .NET 開發人員 (越資深的體會越深刻，就是一路跟著 Microsoft 的技術路線走過來的那群人)，從一切都是 Microsoft 生態的環境 ( Windows, .NET Framework, COM+, SQL server, IIS server, Visual Studio, Office, Active Directory .. ), 突然間 .NET Core 橫跨 Linux ( 而且效能還比 windows 好 ), Container ( 完全是 Linux 生態系的技術 ) 也突然席捲軟體部署的方式, Microsoft 突然之間從 Steve Ballmer 年代的抨擊 Open Source 是毒瘤, 到 Satya 開始講 Microsoft Love Linux / Open Source ..

回顧歷史，我長期都是走 Microsoft 技術路線討生活的，我自己看到這樣改變的時刻也不少，每隔 5 ~ 8 年都會碰到一波。例如:

2000, .com 年代:
Microsoft 有追上這波趨勢, 當年的 ASP / IIS / COM / ASP.NET 技術跟工具就是那年代發展出來的)
2008, cloud / mobile 年代:
Microsoft 當時在這兩個領域只是有跟上, 並不算領導廠商。Azure 表現中規中矩, mobile 則 …
2014, cloud first, mobile first 年代:
container 當道, 世界快速的往 cloud, open source, linux, container 發展, Microsoft 換了 CEO 後有跟上這潮流, Azure 也開始走出自己的路線, .NET Core 也帶領開發人員跳出傳統的 Windows 體系, 開發工具除了 VS 之外也發展出 VS code, GitHub 也被 Microsoft 收編.. 從此 C# 開始跨入非 Windows 的領域, 直到今年 (2024) 就要超越 Java 了 ..
2023: GenAI 橫空出世的年代: (對我這種外行人來說的確是這樣), Microsoft 投資 Open AI 有押對寶, Azure Open AI service 領先, Bing / Copilot 等服務都快速地推出, Semantic Kernel 開發框架也推出, Microsoft 瞬間在 AI 的技術，服務，工具，開發框架，生態系都跑在前面..

現在 (2024)，看來又是那樣的時刻了，帶來這些改變的是 AI 已經成熟到跨入主流技術了，看過去 2023 一年的發展就知道，這趨勢不可逆了。突然之間，我開始也能體會，Microsoft 在部一個什麼樣的局了。如果你理解我在第二段闡述的變革，應該就能理解 Microsoft (以及其他公司) 到底做了什麼準備來面對這變革了:

一路以來，表面上看來 Microsoft 就是壓對 Open AI 賺了一輪，不過事情沒那麼簡單。有好長一段時間，作業系統 (OS) 的進步越來越無感了，我從 Windows 8 之後就開始沒那麼期待 OS 升級，Windows Server 也是如此 (最後有感升級是 2016, 當年為了部署 windows container)。其實手機 OS 也有類似的狀況。

但是現在我開始期待 Windows 12 了 (如果真的叫這名字的話)，因為我期待會有更多的 AI 基礎建設被放進 OS 內，我相信這會是有感的改變。我看懂 Microsoft AI 布局的三個關鍵是:

Azure Open AI Service
部署於雲端的 AI 服務, 背後的關鍵就是各種模型，在雲端上就是計算能力的表現，部署到 Edge 端就是模型優化技術能力的表現。兩者都需要 AI 的模型發展與訓練能力。
Copilot
部署於 OS ( 使用者端 ) 的使用者入口, 會演變成整個 OS / Device 的 controller。Copilot 的成功與否關鍵在是否由 OS 來主導，LLM 的運算資源是否充足 (不論用雲端或是本地端) 以及背後的軟硬體整合是否到位。
Semantic Kernel 會發展成未來 Application 主要的開發框架，決定了生態系，也決定了 LLM 能夠協作的範圍有多廣。市場上另一個發展中的框架: LangChain，也是常被擺在一起比較的熱門專案

這三者的關係則是緊密相扣，互相發展加成。一個一個來看彼此之間的關聯…

其他還有些空缺，我猜應該會有對應的計畫，只是現在還沒看到。應用程式開發，一直都是 Microsoft 擅長的領域。從單一應用開發框架 Semantic Kernel 開始 ( SDK )，我相信一路往上，都會有對應的架構或是基礎建設的.. 我的想法是:

AI Application Develop Framework (SDK):
Semantic Kernel, 已經 release 1.0 了
OS Support for AI Application (OS):
還沒看到, 我猜 windows 12 會看的到端倪, 動作快的話今年應該就看的到了
Cloud AI Application Infrastructure (PaaS):
還沒看到, 也沒有時間表, 我猜 Azure 之後應該會有一整套的 PaaS 可以使用
Cloud AI Service (SaaS):
已經看到類似的服務了 - Microsoft Copilot for Service

3-1, 大型語言模型 (LLM) 服務

Microsoft 身為 Open AI 的大股東, 對 GPT 模型有最優先的掌握度。你想使用 GPT4 的模型，只有兩個管道，一個是買 Open AI 的 API 服務，另一個就是買 Azure AI Service … 這資源讓 Microsoft 能優先於其他對手端出 AI 相關的應用 ( 就看 Microsoft 各種 Copilot, 在 2023 通通都出現了一樣 )。

這些 LLM 遲早會不斷的縮小，小到足以在終端設備 (手機或是 PC) 端就能離線執行，同時終端設備的計算能力也能追上 LLM 的執行需要的話 (我就假定這發展 Microsoft 也會領先好了)，那麼 Windows 應該又會開始變成所有人的首選了。回到前面我的 Demo, 最讓我覺得驚喜的改革，是軟體開始有能力了解使用者的 “意圖” 了。想看看如果 LLM 已經能跑在本機端，應該不可能每個 APP 都裝一套，而是整個作業系統會開始提供這樣的服務。

從這邊想，開始就能理解過去 Wintel 組合的模式又要出現了，只是組合可能會不同，但是 OS 有 LLM 的能力，而 PC 有對應的 NPU 也勢在必行。未來的 Wintel 是否還是 Intel 我就不知道了，會是 AMD / nVidia / 高通也都說不準。但是現在市場上開始喊 AI PC, 大概就是這走向了。

作業系統的發展，向來都是需要應用程式互相搭配的，接下來就來聊聊下一個: Copilot

3-2, 輔助工具 / 引導工具 (Copilot)

前面我做的 Demo, 主體是在 Chat GPT 的平台下，用 Custom GPT 能力，串上我自己開發的 API 組合出來的 application. 使用者操作的應用程式，不是直接用我的 API 或是我的 APP，而是 Open AI 的 Chat GPT, 而 Microsoft 在發展的 Microsoft Copilot, 或是 GitHub Copilot, 其實都是走同樣的路線。

如同現在沒人在記網址了，要找網站就直接開 search engine… 當你對 Copilot 上癮之後，你也開始會懶得自己去開 APP 來用了。你會用各種方式去告訴 Copilot 你想做什麼，然後由 Copilot 替你決定要上網搜尋，或是轉發 API，或是替你叫用某個 APP，或是給你什麼資訊或建議.. Copilot 將會扮演整個設備的中控中心，代替你調度所有你設備本身的資源，應用程式，或是連上網使用雲端的服務。

想像一下，如果像我 Demo 這樣的應用，未來主流的服務都用同樣的方式整合在 Chat GPT 上，會是什麼樣的光景? 想想就覺得可怕，因為現在看來已經是完全可行的技術了，只差整合而已。只是我不覺得 Open AI 的 Chat GPT 會變成以後大家必定使用的 “入口”，夠格扮演這角色的還是作業系統大廠 Microsoft (Windows) / Apple ( iOS / MacOS ) / Google ( Android / ChromeOS ) 比較有機會。而現在看來領先的就是 Microsoft Windows + Copilot 最被看好

3-3, AI 應用的開發框架

最後一個，開發框架。我雖然對這個安德魯小舖 GPTs 的 Demo 感到驚艷，但是我不覺得未來的平台會是 Chat GPT, 只是 Chat GPT 門檻最低，是拿來做 PoC 的首選而已。在做這個 side project 時，我體會到一件事:

過去是以 UI 操作驅動整個應用程式的發展，因此會發展出 MVC 的開發框架。V (View) 就是對應 UI 的操作部分，而 M (Model) 則是對應到 View 需要對應的資料結構，C (Controller) 則是回應 UI 運作的邏輯與背後的流程。不光是 Microsoft, 各個主流的 Web 開發框架大致上都不脫離這模式。

到了 AI 的時代，有了 LLM 的加持，UI 不再是唯一的操作方式，直接或間接透過自然語言開始是另一條可能的方式。而操作與邏輯的綁定關係，也變得更靈活 (相對的就是更不明確)。想看看，如果 Model 都已經變成一個一個的 Prompt, Controller 還能知道收到 Prompt 後該怎麼回應嗎? 該寫檔案? 還是該發出 email? 還是該執行交易?

因此，要發揮 LLM 的威力，充分整合到你的應用內，你需要一個能透過對話方式驅動整個應用程式的發展框架。我之前在這門線上課程，看到這張圖，我覺得很貼切:

LLM 扮演了 Controller 的角色，或是講得更精準一點，Orchestration 會更貼切。他接收各種來源的自然語言要求，了解之後會判斷該如何回應。LLM 需要決定該轉發什麼樣的要求給後端的服務 (不論是 search engine, 或是 api, 或是 access database) 等等。LLM 扮演了 “理解語言背後的意圖”，翻譯成精確的指令，轉發 API 給其他系統。並且把得到的結果再度翻譯成自然語言，或是需要再次轉發成後續的指令。LLM 是 “精確運算” 與 “模糊的語意分析” 之間的橋樑，這是傳統的應用程式最難突破的環節，也是融合 AI 應用的核心。

未來軟體開發，會是圍繞著 LLM 為核心，在外圍搭建 UI, 服務, 靠 LLM 統控操作流程 (orchestration), 探究為何 LLM 做得到? 他就是專精在自然語言的處理，只是 Chat GPT 很巧妙地運用他來整合語言對談與 API 而已。

我在設計安德魯小舖 GPT 的過程中，最關鍵的兩件事:

開發能被 GPTs 使用的 API:
並非阿貓阿狗寫的 API 都可以直接丟上來, 多少還是有些差別的。主要就是認證方式要標準化 ( APIKEY or OAuth)，並且提供 swagger 定義檔, 餵給 GPTs 設定，讓他知道我有哪些 API 任他使用
善用 Prompt:
告訴 GPTs 該怎麼回應使用者的詢問，而 API 本身也用自然語言告訴 GPTs 他是幹嘛用的，讓 LLM 能理解何時該呼叫他 (就是在 API swagger 的 description, 就是給 LLM 的 Prompt)

這兩者打通之後，LLM 就搖身一變，變成控制中心了，也因此，未來的 APP 或是 Service, 應該都是為了成為 LLM 的助手而生的。所以，應用程式都會沒落了嗎? 不會的，他還是會存在，但是超大型的應用應該會越來越少，超複雜的多步驟流程也會逐漸消失，UX 的改善大部分都會落在 LLM 身上，而 APP 與各自的 UI 則會專注在更精確範圍內的應用了，例如填表單，或是特定的觸控操作等等。

很明顯的，MVC 不再適合處理這樣特性的應用程式了，AI 相關的應用程式開發必須要有更合用的開發框架。如果把這張圖，濃縮成單機版本，範圍限定在單一 AI 相關的應用程式開發框架的話，那目前的最佳選擇，就是我一直提到的 Microsoft Semantic Kernel 了。如果不是限定於 Microsoft Solution (C#), 也有另一套 Python 走向的套件: LangChain。挑哪套都沒關係，重要的是要看懂框架的設計，是要引導開發人員正確的使用 LLM …

同時，我也預期 (雖然現在還沒看到)，就像 MVC ( Model / View / Controller ) 進化到 SK ( Semantic Kernel ) 一般，Windows 勢必也會有作業系統層級的架構 (例如軟體安裝就會註冊支援的行為到 Microsoft Copilot，類似當年的 COM+)，Azure 也會有分散式架構的版本出現 (能整合 LLM 的 API Management ?)。架構上的演化，勢必會有 Application 開發框架層級, 作業系統層級, 開發者服務層級 (PaaS)，應用軟體層級 (SaaS) 對應的 solution..

開發者層級: 就屬 Semantic Kernel / Lang Chain
作業系統層級: 還沒看到規範出現
服務基礎建設 ( PaaS ): 還沒看到規範，目前看到 Open AI API 已經有類似架構出現，但是還未成標準，也未見 PaaS 廠商出來整合
應用系統層級 ( SaaS ): 已有看到 Microsoft 推出接近定位的服務: Microsoft Copilot for Service .

這些服務的發展，我也不知道最終會長什麼樣子，不過看懂 AI 會帶來什麼改變後，很明顯這邊的缺口遲早會有對應的東西近來填補。如果你看清楚趨勢，就可以預先構想 & 持續關注這些服務的發展，盡早做好準備來面對了。

3-4, 整合三者的應用模式

幾個月前，我在思考應用程式該怎麼跟 LLM 有效的結合? 一個是要有明確的規格跟流程，另一個都是用很模糊的輸入 (對 code 而言，prompt 只是 string, 所有 input 都是 string, 跟全部是 object 其實沒兩樣)，那麼兩者的處理協作方式到底該是什麼樣貌? 研究了 GPTs, 剛好也看到 Microsoft Semantic Kernel, 我發現這就是以後的應用程式分層架構了..

看懂 Semantic Kernel 的這兩張圖就夠了，這張講的是 AI infrastructure / models 與 Plugins / Copilot 之間的協作，Semantic Kernel 就是扮演把這些全部串在一起的框架。如果安德魯小舖 GPTs 我用 Semantic Kernel 改寫成單機版，那麼我的 API 就是圖上的 Plugins 了，我不管用什麼技術刻出來的 UI，就是對等 Copilot 的位置了。而不論我是跑本機板的 LLM，或是使用 cloud 的 AI service, 我用 connector 串聯它們，就是底下的 foundation models / AI infrastructure 了

從另一個角度來看，這張圖更清楚。Model 只是按照 prompt 幫你算該回應什麼內容，對話過程是 application 應該自己維護的，在 Semantic Kernel 架構中的 Memory 就是指能記住對話過程的 “記憶”，Semantic Kernel 會協調 Memory / Model / Plugins, 自己處理這些元件之間的協作。

目前 Semantic Kernel 只是為單一應用程式開發而設計的框架，但是事實上規模放大到分散式的高度來看，即使是 Open AI 的 Chat GPT，他 GPTs 的運作機制也類似，只是它們的範圍是跨網路的。真正落實他們的技術跟協定可能不同，但是抽象化的觀念應該都是一致的。

Semantic Kernal 再深入的技術細節，我就不在這多做介紹了，基本上他就是把能善用 LLM 的軟體開發方式抽象化，變成一個能抽換擴充的機制。目前，Semantic Kernel 看到的還是在 Application 內的 AI 應用開發框架，作業系統層級的通訊協定還沒看到，不過我猜也快了，如果真的有 windows 12, 應該可以看到一些蛛絲馬跡。

接下來 (如果搞得定的話)，我打算把安德魯小舖 GPTs 的應用，用 Semantic Kernel 的架構改寫一次，到時再來分享技術細節。這邊各位先有概念就好，就像 MVC 架構一般，LLM 加持驅動的應用程式，他的基本架構就是 Semantic Kernel 描述的這樣。你思考你的應用程式要包含 LLM 處理能力時，務必要先了解這開發框架背後的精神。

講到這邊，我開始能串起來了。應用程式只要用 Semantic Kernel 開發, 甚至變成 OS 內建的服務，安裝軟體會變成安裝 Plugins / Planner, 而 AI OS / AI PC 則提供了足夠的 LLM 運算能力，讓你的 Application 能充分使用這些 AI 資源；最後 Copilot 變成作業系統的標準 (主要) 操作介面，統合起本地端與雲端的各種資源…

4, 架構師、資深人員該怎麼看待 AI ?

架構師必須引領你的團隊，將系統逐步改造成 AI Ready 的應用程式

回到個人，看懂了是一回事，那麼你 (包含我) 自己該怎麼面對? 該做什麼準備? 我自己的看法是:

基本上躲不掉了，就去面對吧! 同樣的以我這次的 Demo 來說，我看到了幾點，尤其是越資深的人員，對軟體的設計越有話語權掌控權的人越該注意.. 你必須好好的思考 LLM 該用在什麼地方。

以我這次的 PoC 案例，我先有了構想之後，我的順序是開出 API，做出最基本可以動的實做，就盡快設定 GPTs 完成第一版上線測試了。過程中第一個難題就是 API 開的不夠好，不夠直覺 (簡單的說就是不符合標準或是商業模型)。當 API 無法讓 LLM 望文生義，你就必須用更多的 Prompt 引導他怎麼用 API。然而努力下來，最有效率的方式還是讓你的 API 變得更合理點才是正途，最後調對 API 設計之後，我的這些 “修正用” 的 Prompt 都刪掉了，運作的比原本的還好..

另一個角度，相較於開發人員寫的程式碼，執行成本 LLM 還是非常貴的。你應該用 AI 省開發時間，但是要把 AI 用在 run time, 就必須用在刀口上，不要什麼都丟給 AI 來做，舉例來說以後妳不提供瀏覽商品加入購物車的網站，只提供對話方式交易就是個不明智的選擇。

因此，我歸納成這幾點我認為重要的觀點:

4-1, 分清楚 LLM / API 的邊界:

架構師必須搞清楚，那些應用要用 “計算” 來解決，那些應用要用 “意圖” 來解決?

LLM 很有彈性，能理解語意，運算成本很高；相對寫 code 必須有明確規格，難以理解語意，運算成本相較 LLM 非常低。試想你寫一行 code 算 1 + 1 = ?, 可能是幾個 CPU 指令就完成的事情，你問 Chat GPT 1 + 1 = ?, 不知道要砍掉多少顆樹才算得出來..

以我的 demo 為例，請 GPTs 替我評估預算內該怎麼買最好，過程中我就吃了不少苦頭，即使用上 GPT4, 我仍然有一定的機率會碰到 GPTs 回給我的答案不是最好的答案，但是我跟他抱怨後他重算一次就對了 (傳說中的 AI 也會偷懶?)，我明明只是抱怨，沒有教他啊，可見他本來就會，只是沒有做出我要的選擇而已…

以這案例，如果預算評估，對你是很重要的任務，必須精準執行，無法忍受 LLM 有一定的出錯機率的話，你就該考慮這部份別依賴 AI，該自己寫 API 讓 AI 呼叫才對。這些判斷，需要有經驗的人來操刀，架構師是合適的角色，要能看懂這些分界與區別，你才能做出正確的判斷。

以 “計算” 為主的任務，像是交易，必須精準有效率正確地進行，應該維持傳統的方式測試開發。你只要顧好他能不能做到 AI Friendly 就夠了。

以 “意圖” 達成為主的任務，像是 Copilot，必須盡可能地找到各種解決方案，應該維持以 LLM 為核心嘗試找出各種可能的建議，這種就需要 AI 來輔助。

而架構師，必須要有全局觀，要有能力替你的公司或是團隊，做出正確的判斷與決定。

4-2, API 的設計必須精準合理:

架構師必須清楚，API 該如何對應領域的問題，用統一並解精準的設計開放服務介面，掛上 LLM 的擴充機制

有聽過我 .NET Conf 2023 的演講，我的主題就是這個。只是在做這個 demo 之前，我只能說好的 API 有很多好處，但是我還無法講出有哪些狀況下，這些是絕對必要的? 直到我做了這個 demo… 未來的 API 會越來越重要，服務不再是 UI first, 而是 API First…

因為，掛上 LLM 後的 API ( Plugins ), 呼叫你 API 的不再是其他開發者了, 會變成 AI 來呼叫你的 API。你已經無法 “預測” 或是 “約束” 對方該怎麼呼叫。這時你只剩兩條路可以選擇，一個是把你的 API 設計的合情合理，完全符合現實世界的運作邏輯 (就是我常講的 OOP 精神: 模擬世界加以處理)，你只要用 Prompt 就足以交代 AI 該怎麼使用 API。另一個就是把你的 API 做到邏輯無懈可擊，滴水不漏。不論 AI 用什麼順序呼叫，傳遞什麼參數給你，都不會發生意料之外的結果。這個非常吃嚴謹的設計，我曾在 API First 不斷強調 “有限” 狀態機的重要性，就是預防這種錯誤。因為狀態機的變化是 “有限” 的，你才能在這範圍內精準地控制各種行為，不會暴走，這樣的 API 設計才是 AI Friend 的設計。

AI 會解決很多過去 UI / UX 難解的問題，這會有兩個效應，一個是原本由 UI / BL 負責的體驗改善，會大幅往 LLM 靠攏偏移。而抽走這些流程的處理，你的 API 就只會剩下最核心最關鍵的 Domain API 了。就拿我這次示範的 “安德魯小舖 GPTs” 當例子，我的 API 真的精簡到不能再精簡了，精簡到你拿掉任何一個 API，就連最基本的成立訂單都做不到。

有哪些是原本該提供的 API，但是因為有了 LLM 輔助可以不需要再提供的? 最明顯的就是 BL 層，以案例來說如果需求有這麼一條，要按照客戶預算規劃採購內容的話，一定會有一組 API 對應這些需求。但是在這示範案例中，LLM 完全把這塊扛了下來…。就眼前來看，已知的需求可以不需要再開發了，就未來來看，也許有更多你目前想像不到的需求，LLM 也可以有足夠能力替你處理。唯獨最關鍵的是: 你的核心購物 API 一定要能精準確實可靠的處理好結帳的需求。

這就回到我一直在強調的 Domain API Design，API First，API 必須精準對應 Business Model 這些議題要探討的: 要開對 API。因此，API 不再是能動就好，而是要精確，可靠，合理，做到 AI Friendly，才是能在未來世界有競爭力的服務。OOP，DDD 等等領域相關的設計，以及開發的基礎工程能力，會越來越重要。因為你沒掌握這些設計原則，你幾乎不可能設計出 AI Friendly 的 API 規格的。

4-3, UI 應該以 Task 為單位拆解

架構師 / 產品負責人必須清楚，UI 該如何對應領域的問題，拆解並且正確的描述，掛上 Copilot 的擴充機制

這次的 demo, 也讓我體認到這件事。這個 side project 我花了三個禮拜，但是有兩個禮拜都卡在 “我賭氣不想實做 OAuth…” XDDD

因為我原本的 API 就有實做簡單的認證機制，有 Login, 要給帳號密碼才會給你 Access Token, 然後其他 API 有必要參數，必須提供能通過驗證的 Access Token 才能呼叫。結果我想，我就 Prompt 多做補充說明，讓 GPTs 弄懂就好了…

結果全然不是這麼回事，不合理的 UI 流程跟 API 設計，會大大阻礙 AI 的理解，認證授權這類行為，就是屬於需要精確執行的，你讓 LLM 來負責這環節就是不智之舉，我花了兩個禮拜嘗試各種方案要搞定他 (很長的故事，以後有機會另外寫文章來聊聊)，最後都是失敗收場。

最後，我花了一天，自己刻了個符合 OAuth2 的介面出來，再修修補補一個晚上就搞定了。你看我的安德魯小舖 GPTs, 版本已經來到 v5.0.0, 大概就知道我經歷多少失敗了 XDD, 不過, 這些門檻都不是有多困難的技術要克服, 而是你要想清楚該怎麼善用 AI 而已.. 想清楚 Copilot 或是 Chat GPT 掌控 LLM 的主要操作介面，充分配合發揮它的威力來設計你的軟體服務跟 UI，會是下個世代的重要課題

4-4, 挑選正確地軟體開發框架

架構師必須挑選合適的開發框架，並且一一的把系統的各個元件擺在框架上正確的位置上。

第四個，是搞懂 AI 世代的開發框架，目前我看到最具代表性的就是 Microsoft Semantic Kernel. 當然就像 MVC, 是抽象的架構, 而 ASP.NET Core MVC 是一套廣為使用的開發框架，而你該掌握的是你的 Application 該有哪些 Model? 有哪些 View? Controller? 不是一開始就毫無設計，直接套用 ASP.NET Core MVC 硬幹…

在 AI 的世界裡, 我暫時找不到其他框架，就先拿 Semantic Kernel 當代表吧。Semantic Kernel 區分了 Kernel, Skill, Planner, Memory, Connector, 這些就是 AI 整合到應用程式內的標準結構，我在設計安德魯小舖 GPTs 時，嚴格的來說也是用這框架去設計的，只是 GPTs 給了我很低的門檻跟設定畫面來做這件事 (連設定畫面都有 GPTs 來幫助我，我用聊的他就會幫我設定好了)，我幾乎只是靠 Skill (掛上我的 Custom Action) 跟 Planner (只靠 Prompt 描述) 就完成了，Memory GPT 內建我完全不用煩惱，Knowledge 也內建了，我只管上傳檔案就好。

身為架構師，親手做一次是必要的，但是更重要的是你務必掌握這框架背後的精神，未來有需求你能夠正確的對應，並且正確的把它們組裝起來。你應該替你的服務或是產品，仔細思考長遠的發展中，你該怎麼樣在這樣的框架下，逐步累積你的元件，這才是 “架構” 師的主要職責。

5, 開發人員該怎麼看待 AI ?

回到開發人員，我想這是比例最大的一個族群了。這些角色重視的是要有實做能力，因此我在這邊就列舉一些我認為在 AI 世代，要成為一個稱職的開發者，必須具備或是強化的能力:

5-1, 熟悉能提高工作效能的工具

這整篇其實我沒講太多工具，不過回顧 2023 年，被談的最多的就是 “工具” 吧。我大都在講 AI 會怎麼改變整個軟體的生態與結構，談的是那些軟體不善用 AI 根本做不出來 (例如我這個 demo, 沒有 AI 根本不可能) 的服務與應用。但是這改變不會明天就到位，會在未來幾年逐步發酵。目前談的最多的，是善用 AI 的新工具，來加速你目前的工作效率。

短期內 (至少還有一到三年吧)，軟體開發仍然會是以目前主流的架構為主，但是每個人手上的工具應該都會升級，例如接下來你會問 Chat GPT, 而不是查 Stackoverflow,,, 你會開始善用 GitHub Copilot, 而不是不斷的查文件, 然後複製貼上。寫文件或是寫 email 也是，開始有越來越多工具可以幫你彙整、抓重點、翻譯、修改建議等等，這些都是用新工具更有效率做好現在的事的範圍。

未來這種工具會越來越多的，別多想，只要在你負擔的起的範圍內就盡量使用吧。但是享受它的同時，請切記你要累積你的基礎知識，別囫圇吞棗，你不要 GitHub Copilot 給你的建議，你完全看不懂他是幹嘛的就按下 Tab, 請你務必看懂他，如果看不懂，也請多問問 GitHub Copilot Chat / Chat GPT, 給你更多的說明。

5-2, 熟悉必要的 Tech Stack

除了用 AI 工具提升自己效率之外，如果你團隊的架構師已經看懂這局勢了，你們也勢必會往 AI 應用程式的開發框架發展。這時，身為開發者，必定會需要具備一些這類技術的實做能力。我列舉幾個我認為重要的:

Prompt Engineers, 雖然離用自然語言寫完全部的程式還很遠，但是就如同我這次的 demo, 我只寫了能做關鍵動作的 API, 其他都是靠 LLM 跟 Prompt 完成的。未來世界你必須有 Prompt 的輸出能力，你才能做好 LLM 跟 API 之間的黏著劑
Vector Database / NoSQL Database, No SQL 是基本的，我就不再多說了，另外為了搭配 RAG 等內容的索引跟儲存，挑一個合適的向量資料庫，並且熟悉他的管理與操作是必要的
Semantic Kernel 的實做與開發能力, 前面也聊過很多了，不再多說。當這已經是主要的開發框架時，用他的規範，累積 Plugins, Planners 等等能掛上 Semantic Kernel 的原件，將會是 AI 世代的軟體開發團隊資產。

5-3, 深化領域的設計與開發能力

這部分，就回到了我過去兩年不斷的在談 API First, 要先從領域的角度開出正確的 API spec 開始的論調。領域的 API 重要性會越來越大，過去談了很久的 Headless, 終究沒有變成 “必要” 的設計，還是有很多產品服務，把 UI 跟流程的設計擺在第一位，API 只是 option.

不過，如果真的到了我想像的世代，那就要反過來了，你的服務沒有 API, 無法變成 LLM 的 Plugins 的話，那你的服務就要變成孤島了。LLM 才是真正的 “Headless” 的推手, 使用 API 的 “Head” 會是 LLM, 而不是只有其他的 Application.

回到 “領域的設計與開發”，講白了就是 API / DDD, 或是你要說微服務也行 (但是必須在正確的 DDD 設計前提下拆分出來的微服務才算數)。UI 不會消失，但是改善 UX 的任務勢必會有越來越多的比例轉向 Copilot / LLM 來負責，而 UI 的比重降低 (被 Copilot 分掉)，流程的比重降低 (被 LLM 的解析能力分掉，例如我這次 demo 的預算規劃等等，已經不在 API 的範圍內了)，剩下的 API 開發只會剩下核心關鍵的部分，而且會越來越重要，比重也會越來越大。

所有的領域都會開始去蕪存菁，不需要經驗照著範本寫的程式碼，以後都會消失了，會留下來的都是需要高度經驗與精準的開發能力的。前面提到精確的 API 設計就是其中之一，而架構師設計出來的規格，身為開發人員，你也應該要有對等的工藝水準來把它做出來。

這些不是新東西，而是過去開發 API 本來就會需要面對的知識與技巧。我預期這會越來越重要，會是以後 Backend Developer 的主戰場，如果你還停留在刻畫面，搭配 CRUD API 的開發方式的話，盡早讓自己升級吧! 我有很多這方面的文章，可以多看看 XDD

6, 結論

最後總結一下，其實這整篇的想法，過去一年陸陸續續都有從我腦袋裡冒出來過，只不過都還很片段…，直到在 2023/12 聽了董大偉老師的那場分享，看到老師用 GPTs 實做了 “請假系統” 後，我才驚覺，原來 GPTs x API 才是真正的改變…

這串 PO 文，我就附上連結，可以看一看我當時聽完那場演講的感想:

安德魯的部落格貼文

2023 軟體開發的熱門話題，通通都離不開 AI。我除了使用 AI (包含 ChatGPT, GitHub Copolot 等等工具之外)，我也在思考我該做些什麼，讓 AI 能融入在我負責設計或開發的系統內，讓其他人也能感受到價值?

其實過去這一年我想了很多，但是一直都還很片段，不像過去我在聊架構跟底層設計時，能從頭到尾每個細節都能連貫起來那種充分掌握的感覺。

不過，特地在 2023 的最後一刻，我想貼一下這 PO 文，總結我在 2023 最後一個月的突破。一切都要感謝董大偉老師 ‧NET Walker 大內行者在 .NET Conf 2023 的那場演講… 讓我想通了 AI + API 帶來的改變..

……

隔天老師也補上他的看法:

.NET Walker 大內行者貼文

我要拿安德魯的部落格在 2023年最後一天所寫的這篇文章，作為我 2024 的第一篇分享。不只是因為， Andrew 在這篇文章中多次提到我，更因為大概沒有任何人能比 Andrew 這篇文更清楚的說明，為何去年底，我會在 .NET Conf 2023 的講台上如此用力地說 : LLM 已然改變了整個軟體開發的走向。

當天我沒法說清楚講明白的，Andrew 在這篇文章中，都寫了出來。不僅如此，Andrew 還把我心裡想的，都實作了出來。

身為開發人員，你也和我們一樣，感受到身處的世界，所發生的震動了嗎?

這篇分享(包含範例)很值得你細細琢磨，你會看到軟體開發即將出現的變革，會理解為何去年我在台上如此聲嘶力竭。仔細思量，你也將會在今年，找到屬於你自己的新做法和新方向。

2024，我們來了。

然而，這些改變需要時間，我不知道還要多久可以發展到想像中的樣子，但是應該應該會在我退休以前實現吧 XDD, 因此我也沒有閃躲的機會，必須好好的面對這改變。AI 一定會帶來很多改變，甚至是很多我們現在根本無從預測的影響。

現在: 即使你還在用一樣的方法從事目前的領域，也請務必盡可能地善用 AI 來提升你的產能。雖然 AI 相較於其他運算，是很貴的，但是對於人力的投入來看只是千分之一的投資而已。對於工具的使用，別考慮了，只要有幫助都值得投資，一來有明顯成效，二來你會更理解 AI 是怎麼協助你的

未來: AI 不會一直停留在 “更好的 GitHub Copilot，協助你寫出現在這世代的程式碼” ..，總有一天，你現在在做的事情也會改變，到時就不是善用工具來加速你現在在做的事而已，而是你開始得面對新的想法，用新的工具做出成果。這天不會太久，從現在起你該為了將來做準備。

如果你跟我一樣，角色是架構師 (或是其他類似角色，能夠影響或決定軟體開發方向的人)，現在就是改變的時間點了，你必須做好準備，替你的團隊思考將來該改變的方向是什麼。

安德魯的部落格

[架構師觀點] 開發人員該如何看待 AI 帶來的改變?

1, 安德魯小舖 GPTs - Demo

1-1, (問) 店裡有賣什麼?

1-2, (刁難) 預算跟折扣的處理

1-3, (刁難) 調整訂單, 不要酒類飲料

1-4, (刁難) 整理訂購紀錄

1-5, PoC 小結

2, 軟體開發的改變

2-1, 使用者體驗:

2-2, 由大型語言模型 (LLM) 整合所有資源

2-3, 所有應用程式都會圍繞著 AI 而開發

2-4, 各種角色的職責變化

3, 看懂 Microsoft 的 AI 技術布局

3-1, 大型語言模型 (LLM) 服務

3-2, 輔助工具 / 引導工具 (Copilot)

3-3, AI 應用的開發框架

3-4, 整合三者的應用模式

4, 架構師、資深人員該怎麼看待 AI ?

4-1, 分清楚 LLM / API 的邊界:

4-2, API 的設計必須精準合理:

4-3, UI 應該以 Task 為單位拆解

4-4, 挑選正確地軟體開發框架

5, 開發人員該怎麼看待 AI ?

5-1, 熟悉能提高工作效能的工具

5-2, 熟悉必要的 Tech Stack

5-3, 深化領域的設計與開發能力

6, 結論

Facebook Pages

Edit Post (Pull Request)

Post Directory

[架構師觀點] 開發人員該如何看待 AI 帶來的改變?

1, 安德魯小舖 GPTs - Demo

1-1, (問) 店裡有賣什麼?

1-2, (刁難) 預算 跟 折扣的處理

1-3, (刁難) 調整訂單, 不要酒類飲料

1-4, (刁難) 整理訂購紀錄

1-5, PoC 小結

2, 軟體開發的改變

2-1, 使用者體驗:

2-2, 由大型語言模型 (LLM) 整合所有資源

2-3, 所有應用程式都會圍繞著 AI 而開發

2-4, 各種角色的職責變化

3, 看懂 Microsoft 的 AI 技術布局

3-1, 大型語言模型 (LLM) 服務

3-2, 輔助工具 / 引導工具 (Copilot)

3-3, AI 應用的開發框架

3-4, 整合三者的應用模式

4, 架構師、資深人員該怎麼看待 AI ?

4-1, 分清楚 LLM / API 的邊界:

4-2, API 的設計必須精準合理:

4-3, UI 應該以 Task 為單位拆解

4-4, 挑選正確地軟體開發框架

5, 開發人員該怎麼看待 AI ?

5-1, 熟悉能提高工作效能的工具

5-2, 熟悉必要的 Tech Stack

5-3, 深化領域的設計與開發能力

6, 結論

Facebook Pages

Edit Post (Pull Request)

Post Directory

1-2, (刁難) 預算跟折扣的處理