GitHub intelligence 登場：Copilot 開始替團隊記住工作慣例

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

GitHub 在 2026 年 10 月 28 日宣布名為 GitHub intelligence 的新架構層，官方對它的定位是「從 GitHub 資料圖長出來的上下文與學習層」，一次打包三種能力：Copilot Memory 記住你和工作方式、Dreaming 在背景整理這些記憶、程式碼搜尋讓代理跨出本機目錄找相關實作。三者的成熟度刻意拉開：Memory 在所有付費 Copilot 方案正式開放，Dreaming 是需要自己打開的公開預覽，程式碼搜尋則讓 Copilot 用既有的 GitHub code search 跨出本機目錄。把官方公告和三份官方文件一起讀完，這次更新真正值得記住的設計判斷只有一句：記住是自動的，治理和忘記是另外交付、而且要你自己動手的。

Pin

這不是記憶功能第一次出現。Copilot Memory 的前史將近一年：2025 年 12 月先對 Pro 與 Pro+ 開放早期存取，2026 年 1 月進入公開預覽，3 月起 Pro 與 Pro+ 使用者預設開啟，6 月擴及 Business 與 Enterprise 的使用者偏好，9 月連自動修安全問題的 agentic autofix 都接上了記憶。10 月 28 日的新聞本體，是把這條醞釀已久的功能線推到正式版，再和 Dreaming、跨儲存庫搜尋組合成一個有名字的層。換句話說，對多數付費使用者來說，改變早已悄悄發生，這次是狀態升級加上治理工具一次補齊。

記憶的正式版：記什麼、誰看得到

官方文件把記憶拆成兩種性質完全不同的東西。儲存庫層級的事實描述一個程式碼庫本身，例如「這個儲存庫用 Vitest 跑單元測試」，共用給有讀取權且能用記憶功能的協作者；使用者層級的偏好描述你個人的工作方式，例如「套用變更前先說明你改了什麼」，跟著你走遍所有儲存庫。誰能看、誰能建、誰能刪，兩者的答案都不一樣：儲存庫事實要有寫入權的人才能建立、有讀取權的人就看得到；使用者偏好只有你自己的互動能建立，也只有你能刪。

Pin

企業讀者要特別停下來看的一行：在 Copilot Business 與 Enterprise 方案上，組織或企業管理員也能檢視、匯出、刪除成員的使用者偏好。你的「個人」偏好在企業帳號裡不是私域，這是啟用前最該讓團隊知道的隱私邊界。

入口的落差同樣實際。八個入口都會建立記憶：Copilot app、CLI、VS Code、雲端代理、程式碼審查、Slack、Teams 與 GitHub Mobile（Teams 端的代理整合先前介紹過）。但能跟記憶互動的只有三個（app、CLI、VS Code），管理集中在個人 Copilot 設定頁，可以檢視或刪除已存的偏好。在 Slack 裡記下的慣例，要回到設定頁才能管。

預設記住誰：方案與入口的開關落差

正式版最影響日常的決定是預設值。Copilot Pro、Pro+ 與 Max 的使用者偏好預設開啟，可以在個人設定裡關掉；Copilot Business 與 Enterprise 預設關閉，要組織或企業擁有者先把政策打開，成員才能用。儲存庫層級的事實走另一套預設：除非企業、組織或單一儲存庫的設定明確限制，否則一律允許，組織的儲存庫存取範圍預設涵蓋所有儲存庫。個人訂閱者的偏好其實已經進入記憶，企業成員則取決於管理員的決定。

同一個帳號在不同入口的行為也不一致。VS Code 的本地開關預設關閉，要在應用程式設定裡自己打開；CLI 的互動工作階段本地開關預設開啟，用 /memory off 可以整機關掉，但非互動的程式化執行預設不帶記憶，每次都要加 –enable-memory 參數。程式碼審查與 agentic autofix 跟著儲存庫設定走，而且永遠不套用使用者層級偏好，你的個人習慣不會改變程式碼審查的判斷方式。CLI 還有一道精細的界線：只有根代理能存放與投票記憶，子代理只能讀。想關掉某一個入口的記憶，不等於全部都關了，這是管理時最容易誤判的地方。

記憶會自己退場：投票、到期與系統防護

GitHub 對「記憶愈積愈多怎麼辦」的答案，是一套自動退場機制。Copilot 用內部投票系統評估每條記憶的有效性：驗證成功的升票，證明錯誤或過時的降票；降票超過門檻的記憶不再使用，閒置一段時間後刪除。票數刻意不顯示在介面上，設定頁的清單按有用程度排序，Copilot 學會不用的記憶會從清單消失，但消失不代表已刪除，它可能還存在直到到期。不想讓某條記憶再出現，唯一確定的動作是明確刪除。

時間軸也寫死在文件裡：記憶預設 90 天沒有升票強化就到期，企業與組織可以把儲存庫事實的期限調在 7 到 180 天之間，組織與企業都設時取較低值；使用者偏好恆用預設期限。單純讀取不會重置到期，只有升票會。儲存庫事實甚至可能來自未合併就關閉的 pull request，官方也坦承這類事實只靠指示 Copilot 回頭對照目前程式碼，但不保證抓得出每一條過時事實。

防護是系統層的。系統會拒絕儲存內含 token、金鑰、憑證等機密的記憶；含已知模型控制字元的記憶同樣過不了這一關，官方明說這是對提示注入的防禦；官方指示 Copilot 不儲存敏感個人資訊、機密內容與短期任務指令，因為記憶的設計目標是留住長期為真的事。每條記憶都帶引用，指向佐證它的程式碼或你當時說過的話。要留意這些是檢查與指示，不是保證，機密本來就不該進對話。

Dreaming 把整理外包給背景，正式檔案仍走審查

Dreaming 是這次最實驗性的部分：它在背景回顧符合資格的工作階段與 pull request 審查回饋，主動維持記憶與儲存庫指引的新鮮度，官方強調它更新的是上下文，不是底層模型。它做三件事：個人記憶整理依你的代理對話更新個人偏好；儲存庫自訂管理庫級記憶，並對既有的技能與自訂指令檔提出改善；程式碼審查自訂把團隊反覆接受的審查回饋整理成之後審查的指引。

重點在於改動怎麼落地。對記憶，Dreaming 直接新增、更新、刪除，不逐條徵求同意；對已進版本管理的指令與技能檔案，它只能開 pull request 提案，合併前檔案不動；審查指引則在內部更新，不經過 PR。有資格進入審查的檔案範圍官方列了八類，包括 .github/copilot-instructions.md、.github/instructions/、.github/agents/、AGENTS.md、CLAUDE.md、GEMINI.md、REVIEW.md 與 .github/skills/，而且它不一定每個檔案都碰，也不是每次執行都產生變更或開 PR。也就是說，「自動」只到記憶層為止，會影響整個團隊的正式規則仍然留在人的審查裡。這條分界和 GitHub 最近一週對代理自動化的整體走向一致：先前的輔助權限把模型判斷插進同意流程、共享自動化把工作流移交儲存庫共有，這次是把「經驗變成規則」的最後一哩同樣留在 pull request 上。

執行結果也有一個固定的查看位置，而且不在設定頁。GitHub.com 上的設定只控制開關，個別執行產出要在 Copilot app 側欄的 Automations 裡點 Dreaming 分頁，看每次執行的狀態（執行中、完成、失敗）與記憶更新標籤（新增、更新、移除）。排程由 GitHub 管理，打開後不會立刻看到第一次執行；官方也明說這裡不是完整的活動歷史，沒有復原按鈕。

先看門檻再開：模型、資料落地與每次計費

Dreaming 的第一道門檻就會刷掉一批人。初始預覽需要能存取 GPT-6.1 Sol 模型且政策允許，Copilot Pro 方案明確不在範圍，也不支援啟用資料落地的 GitHub Enterprise Cloud；官方只說 eligible paid plans，哪些方案算合格要對照自己的方案與模型政策確認，企業成員另要先確認部署形態。儲存庫自訂與個人整理還要求工作階段同步：CLI 與 Copilot app 預設會把本地工作階段存上雲端，但組織政策要把「將本地工作階段儲存在雲端」設成至少可從雲端檢視，曾手動關過同步的人要先把設定清回來。官方還提醒一個反直覺的細節：後來才補齊前提條件的人，要把 Dreaming 關掉再開一次才會生效。

Pin

成本模型是這份文件裡最誠實也最常受忽略的一段。每次 Dreaming 執行都消耗 AI 額度，計入既有 Copilot 用量，不是獨立帳務項目；重點在於「每次」包含沒有產生任何變更的執行，也包含處理閒置儲存庫的執行。成本隨處理量與啟用的使用者、儲存庫數量成長，官方建議擴大啟用範圍前先設好花費控制，並明說僅設警示不會擋用量、單人預算未必涵蓋儲存庫層級的用量、也無法為單一 Dreaming 安裝設獨立預算。把整理工作外包給背景之前，先把它當成一項會持續計費的服務來評估。

回頭路的成本也比想像高。企業政策有三種狀態：交給組織決定（起始全部關閉，組織可開也可再關）、到處啟用（組織不能關）、到處停用。政策允許不會自動打開個人的 Dreaming，使用者仍要自己去開，而且不能覆蓋上層的停用政策。最需要記住的是官方明文：關閉 Dreaming 不會復原它做過的變更、不會刪除它建立的資訊、不會關閉它開的 PR、不會還原它刪掉的記憶，進行中的執行還可能跑完；關掉個人的 Dreaming 也不會停止組織儲存庫上的執行。把它當成「先開了再說」的實驗，事後收拾的清單會比開啟時長。

跨儲存庫搜尋與 93% 的讀法

跨儲存庫搜尋處理另一種缺口。軟體專案很少只活在一個儲存庫裡，GitHub 程式碼搜尋讓 Copilot 不用本地 clone 就能找相關的程式碼、設定、schema 與文件：可以搜精確文字與符號、用正規表示式比對、按儲存庫、路徑或語言過濾，語意搜尋還能按行為找，官方的例子是「重試失敗的付款」，在不知道檔名、函式名、甚至不知道哪個儲存庫的情況下找到相關實作。公告用 /research 指令示範了一個典型調查：問「這些元件怎麼重試失敗的扣款、哪裡可能重疊」，Copilot 會跨儲存庫檢視實作與呼叫者。搜尋範圍是組織裡的儲存庫，落入內容排除政策的內容會先經過濾，才進到代理的對話裡。

語意搜尋的底層是儲存庫索引。帶儲存庫上下文的對話會自動觸發索引，大型儲存庫第一次最多花 60 秒，之後新對話開始通常幾秒內就會更新到最新變更；索引數量沒有上限，官方明言索引不用於模型訓練。一個企業要留意的細節：VS Code 可以對非 GitHub 的儲存庫（例如 GitLab 或本地專案）做語意索引，代價是把資料上傳到 GitHub，這個功能政策預設關閉，只有 GitHub.com 帳號能用。

最後是那份改善數字。GitHub 的量測方式是：在公開預覽期間經審查、且代理確實用上記憶的 Copilot CLI 工作階段中，93% 顯示更遵守開發者偏好，42% 顯示工作流程更有效率，並把改善歸因於工作階段上下文裡包含的記憶。這是 GitHub 自家的量測，樣本數與審查準則都沒有揭露，它描述的是特定樣本裡的觀察，這兩個百分比只描述那批經審查的 CLI 工作階段，既不是所有開發者的平均值，也不能直接當成工時節省率。想驗收的團隊可以自己選一個可觀察的指標：交代過的慣例，隔幾次新對話後還需不需要再講第二遍。官方也給了記憶與自訂指令的分工原則：重要規則（安全要求、必要審查步驟）寫進看得見、可審查的自訂指令；會把指令檔撐長的累積細節交給記憶；兩者都不保證 Copilot 每次照辦。把合規規則外包給自動記憶，不在官方的建議裡。

還沒有答案的部分：Dreaming 的執行排程頻率由 GitHub 決定，文件沒有給出時間表；GPT-6.1 Sol 什麼時候涵蓋其他方案、資料落地企業有沒有替代路徑，官方都還沒說。93% 與 42% 的量測方法細節也未揭露。這幾項跟一個月內的官方文件更新節奏一起回來看，是判斷這層記憶架構下一步走向的最短路徑。