GitHub Copilot 支援 OpenAI o1：寫程式碼也能慢思考，複雜 Bug 好修了

如果你平時在 VS Code 裡用 GitHub Copilot 寫程式碼，大概早就習慣了 GPT-4o 的節奏：按一下 Tab 補全幾行樣板程式碼，或者讓它解釋個簡單的 API，速度飛快，但真遇到繞圈子的演算法死鎖、邊界條件處理，它偶爾還是會自信滿滿地寫出一堆跑不通的邏輯。

現在 GitHub 打算把那個會「思考」的外援放進編輯器裡了。

GitHub 宣佈面向開發者開放預覽申請，允許在 GitHub Copilot 和 GitHub Models 中測試執行在 Azure 上的 OpenAI o1-preview 與 o1-mini。通過申請的開發者，可以在 VS Code 的 Copilot Chat 介面裡直接用這兩個新模型替換預設的 GPT-4o，也能在 GitHub Models 的演練場裡線上測試。

敲程式碼時隨時切換「思考模式」

這次上線的核心，是把 OpenAI o1 的內部思維鏈能力搬到了結對程式設計場景裡。

按照 GitHub 官方的測試反饋，o1-preview 在處理程式碼約束和隱藏邊界條件時表現明顯更好。它的回答不是單純吐出最可能的下一個字元，而是帶著推理過程逐步拆解，這讓定位死鎖原因和複雜邏輯缺陷變得容易不少。

在日常寫程式碼時，你並不需要把所有對話都交給反應較慢的 o1。GitHub 在 VS Code 的 Copilot Chat 裡允許在不同模型之間自由切換。

說白了，生成樣板程式碼、寫測試模板或者問個語法，繼續讓 GPT-4o 頂在前面；一旦遇到複雜的底層架構設計、效能最佳化或者翻看晦澀的報錯日誌，切到 o1-preview 或 o1-mini 讓他多推導幾步。此外，開發者在 GitHub Models 的遊樂場測試滿意後，還能直接把模型接入到自己正在開發的應用裡。

為什麼重要

對一線開發者來說，這個更新非常實用。以前在編輯器裡遇到複雜的邏輯 Bug，往往得切到網頁端開啟 o1，貼進去一大串上下文讓它算半天，再把程式碼搬回專案裡。現在直接在 VS Code 內無縫切換，徹底省掉了來回複製程式碼的折騰。

如果你是 Copilot 的日常使用者，我們建議儘早去排隊申請試用。特別是在處理併發、記憶體管理這類邊界嚴苛的任務時，o1 的推理優勢能夠立竿見影地幫你省下大量調程式碼的時間。

從行業角度看，GitHub 這一步也給 AI 輔助程式設計指了一條務實的路。過去各家工具都在比誰打字更快、補全延遲更低，但大模型發展到現在，純拼響應速度已經解決不了程式碼層面的深層邏輯硬傷了。

我們認為，GitHub 允許使用者按需切模型的做法很聰明。它承認了不同編碼場景需要不同成本和延遲的模型，而不是硬要把一個慢模型或者快模型塞給所有需求。不過這種做法的隱患在於，複雜的推理模型對提示詞更敏感，如果開發者只是隨手丟一句話過去，可能會白白等上幾十秒甚至遭遇答非所問，如何引導開發者正確提問，依然是個待解的體驗難題。