近期忙碌到我現在才有時間關注『微軟BUILD開發者大會』，或者說，相較於去年大家對於AI的經驗程度，今年似乎就是一個高原期，很多東西去年就知道了。
以下是關於微軟BUILD開發者大會的關鍵內容整理：
- AI主導一切
- 微軟BUILD大會的主題幾乎全圍繞AI，幾乎所有重大公告都與生成式AI（GenAI）相關，唯一例外是Windows Subsystem for Linux（WSL）的開源。
- 重要公告：
- AI代理工廠願景：微軟目標成為AI代理工具的平台，推出Azure AI Foundry，預估未來將有13億個AI代理（但「代理」定義模糊）。
- Copilot Chat擴展開源：採用MIT許可證，方便開發者打造類似Copilot的擴展或改進Copilot。
- MCP支援：支援Model Context Protocol，擴展AI代理功能，連接GitHub、Figma等工具。
- Grok進駐Azure：xAI的大型語言模型（LLM）Grok將在Azure上提供，之前僅限於X平台。
- NLWeb：微軟開源項目，旨在將網站轉為AI應用，鼓勵更多網站建立AI介面。
- AI安全與合規：推出Microsoft Purview數據安全SDK，防止LLM存取敏感數據，並提供審計功能。
- 反饋：部分與會者對AI主題的過度聚焦感到疲乏，認為忽視其他核心基礎設施議題。
- Copilot定位為「同儕程式設計師」
- 與其他新創公司（如Devin、Magic.dev）宣稱AI可取代開發者的立場不同，微軟強調GitHub Copilot是協助開發者的工具，定位為「同儕程式設計師」，提升生產力而非取代人力。
- 展示Copilot在開發生命週期（從規劃到部署及值班）的進階功能，強調開發者仍需負責監督AI工作。
- AI代理應用於日常工作
- 微軟展示真實、即時的Copilot功能，與其他公司（如Apple、Devin）的誇大展示形成對比。
- 展示場景：模擬一個簡單的會議活動頁面項目，展示Copilot如何協助：
- 資訊收集：為新加入團隊的開發者提供程式碼庫上下文。
- 建立PR：根據指令自動改進Readme並開啟PR，UI清楚顯示代理代表開發者操作。
- 指派任務：可將任務指派給Copilot Agent，生成需審核的PR。
- 遵循編碼規範：參考copilot-instructions.md檔案，確保代理遵循項目風格和規範。
- 連接外部工具：透過MCP支援Figma等工具，實現如將設計轉為React程式碼。
- 草擬提交訊息：自動生成提交訊息，節省開發者時間。
- 回應程式碼審查：代理可根據PR評論執行操作（如生成架構圖）。
- 原則：
- 開發者主導，Copilot為「可靠助手」。
- 卸載瑣碎、耗時的工作，讓開發者專注於核心產品開發。
- 使用copilot-instructions.md提供持續上下文。
- 限制：AI代理不像人類能從互動中學習，上下文有限，需明確指令。
- Copilot在真實世界中的挑戰
- 微軟在內部對複雜的.NET程式碼庫進行Copilot測試，公開展示其「dogfooding」過程。
- Copilot在複雜程式碼庫中表現不如資深（甚至初級）工程師，偶爾出現滑稽錯誤，但微軟的透明度受到讚賞。
- 微軟的真正目標
- 透過GitHub和Azure，微軟致力於維持其作為大多數開發者的首選平台，並為其他新創公司提供在其平台上開發工具的空間。
- 過度樂觀的AI預測有其策略邏輯：避免因過於保守而錯失機會（如Google未充分利用Transformers，導致OpenAI崛起）。
- 其他觀察
- 不追隨AI熱潮的企業正獲得回報。
- 多數公司正在增加而非減少開發者招聘。
- 招聘初級工程師可能是一個明智策略。
- 微軟的展示雖真實，但場景過於簡單（簡單網頁項目），未反映大型、複雜程式碼庫的現實挑戰。
總結：
微軟在BUILD大會中展現了對AI的全面投入，特別是透過Copilot強化開發者生產力，而非取代人力。雖然展示了AI代理在簡單任務中的潛力，但其在複雜場景中的局限性仍顯而易見。微軟的策略是維持平台主導地位，並以透明方式推進AI工具的實際應用。
我是凱文馬拉穆，我們下次見
