Cursor 3.11 實戰：用 Side Chats 岔題不弄髒主線，加上真的能用的對話全文搜尋

瀏覽次數: 3

本文大綱

主線 agent 跑到一半，你突然想岔題問一句——然後整條對話就髒了

用 coding agent 寫過稍微大一點的任務，你大概都遇過這個場景：Cursor（或 Claude Code）的 agent 正在跑一個多檔案 refactor，跑到一半你腦中冒出一個問題——「等等，這個改法會不會影響到 webhook 那條路徑？」

這時你有兩個爛選項。一是直接在同一條對話裡打斷它問，結果 agent 的注意力被你拉走、context window 被你的岔題塞滿，回來繼續 refactor 時它已經對前面的計畫記憶模糊。二是另開一個全新 chat 問，但新 chat 對你正在做的事一無所知，你得把背景重貼一遍才問得出有意義的問題。

Cursor 在 2026 年 7 月 10 日釋出的 3.11 版，就是專門來解這個「岔題污染」的問題。這版兩個主打功能——Side Chats（側邊對話） 和 對話搜尋——表面上像是 UI 小改，但它們動到的是 coding agent 日常使用上兩個很實際的痛點：怎麼在不弄髒主線的前提下岔題，以及怎麼在幾百上千條歷史對話裡把你要的那一條找回來。

以下機制都是從 Cursor 官方 changelog 讀到的。我沒有實跑過 3.11，所以凡是我推測的地方都會標明；能照做的操作我直接給指令。

背景：agent 對話的「單線程」困境

過去在 Cursor 裡，一條 agent 對話基本上是一條線性的 thread。這個設計對「一件事做到底」很好，但它有兩個結構性問題。

第一個是 context 是共享且單向累積的。你在同一條對話裡問的每一句話、agent 讀過的每一個檔案，都會留在這條 thread 的上下文裡。當你為了岔題塞進三段無關的討論，主任務的 signal 就被稀釋了——agent 更容易「忘記」你最初交代的約束。

第二個是 歷史對話難以回溯。跑久了你手上會累積幾十上百條 agent 對話，但它們過去只能靠標題和關聯的 PR 編號來辨識。「上禮拜我修那個 OAuth token 過期 bug 的對話在哪？」——如果你當時沒特別命名，基本上只能一條條翻。

Side Chats 解的是第一個問題，對話搜尋解的是第二個。兩個放在同一版本推出，剛好補上 agent 工作流裡「分岔」與「回溯」這兩塊。

運作原理一：Side Chats——從主線 fork 出一個有記憶的分身

Side Chats 的核心概念很簡單：在主線 agent 對話旁邊，另開一條「知道主線在幹嘛」的側邊對話，讓你岔題而不打斷、不污染主線。

從 changelog 拆解，它的機制有四個關鍵點：

1. 三種開啟方式，記一個就好。 官方原話是「Use /side, /btw, or the plus button at the top of the chat panel to create a new side chat.」也就是三條路都通到同一件事：

在輸入框打 /side
在輸入框打 /btw（by the way，語意很直白——「順帶一提」）
點 chat 面板頂端的＋按鈕

這三者功能相同，/btw 只是給你一個更口語的入口。實戰上我會建議固定用 /btw，因為它剛好對應你當下的心理狀態：主線在跑，你「順帶」想確認一件事。

2. 側邊對話會自動繼承主線的 context。 這是它跟「另開新 chat」最關鍵的差別。changelog 明確說側邊對話「automatically inherit context from the main chat」——你不用重貼背景，它已經知道主線正在改哪些檔案、討論到哪。所以你可以直接問「剛剛那個改法會不會動到 webhook.ts 的簽章驗證？」，它有足夠上下文直接回答。

3. 預設專注在「讀、搜、答」，不亂動你的碼。 官方描述是「By default, side chats focus on reading, searching, and answering.」注意這裡的用字是 focus on，不是「僅限於」——changelog 並沒有把側邊對話寫死成唯讀。我的理解是：預設行為偏向調查型（讀檔、搜尋、回答問題），這正好符合它的定位——你開側邊對話是為了「問問題、探路、驗證決策」，不是為了在旁邊偷改一份碼。但它沒有明講絕對不能編輯，這點若你要拿它做會動檔案的事，值得自己實測確認邊界。

4. 它是「durable full agent conversation」，而且能用 @ 帶回主線。 這是我覺得最被低估的一點。側邊對話不是問完即丟的彈窗——它是一條完整、可持久、日後能回訪追問的 agent 對話。更重要的是：你在側邊得到的結論，可以用 @ 提及（at-mention） 引用回主線 thread。

這就構成一個乾淨的工作流閉環：主線繼續跑 → 你 /btw 開側邊問「這個 migration 要不要先鎖表」→ 側邊調查完給你結論 → 你回主線 @ 那條側邊對話，把結論餵給主線 agent 當作新約束。主線的 context 從頭到尾只吃到「一句結論」，而不是你整段探路的過程。

照著做：一個典型的 Side Chat 招式

假設主線 agent 正在幫你把一個 REST endpoint 改成分頁：

主線讓它跑，不要打斷。
你想到一個疑慮，在輸入框打 /btw，開側邊對話。
在側邊問：「目前這個 endpoint 有沒有被前端某個 infinite scroll 元件依賴？改成分頁會不會 breaking？」——因為它繼承了 context，它知道「這個 endpoint」指哪個。
側邊調查（讀前端、grep 呼叫點）後回你：有兩個地方會受影響。
回到主線，@ 引用這條側邊對話，補一句：「照側邊那條的發現，順手把這兩個呼叫點也一起改掉。」

整個過程主線 agent 沒有被你那段「探路對話」灌爆，它只拿到最後的行動指令。這就是 Side Chats 真正的價值：把「探索」和「執行」在 context 層面切開。

運作原理二：對話搜尋——單條精讀 + 跨對話翻找，兩層各一把快捷鍵

對話搜尋分成兩個層級，對應兩種完全不同的需求，記住這兩把快捷鍵就夠用：

第一層：Cmd+F——在「目前這一條」對話裡找字。 這解決的是「這條對話很長，agent 到底在哪一段說要用 optimistic update？」。changelog 說你可以在啟用中的對話裡搜尋，並且能 jump between matches（在多個命中之間逐一跳轉）以及看到 match 計數器。這跟你在瀏覽器或編輯器裡按 Cmd+F 的體驗一致——它把「翻閱一條長 transcript」變成「直接跳到關鍵字」。

第二層：Cmd+K 在 Agents Window 裡——跨「所有歷史對話」翻找。 這解決的是「上禮拜修 OAuth 那條對話在哪」。你在 Agents Window 用 command palette（Cmd+K）搜尋所有 agent transcript。這裡有兩個技術細節值得注意：

它建的是本地索引。 官方原話：「Cursor builds a local search index that scales search to thousands of conversations with snappy performance.」也就是索引在你本機建，號稱能擴展到「數千條對話」而且維持流暢。對隱私敏感的團隊，「local」這個字是有意義的——你的對話全文不是丟到遠端才能搜。
搜尋範圍超越「名稱與 PR 編號」。 原話：「Find past agent chats faster with search results that go beyond names and PR numbers.」過去你只能靠標題和 PR 編號辨識一條對話；現在搜尋會進到 transcript 的內容裡。也就是說，你可以搜對話「講過什麼」，而不只是它「叫什麼名字」——這強烈暗示是對話全文層級的索引。

照著做：找回一條你忘了命名的舊對話

開 Agents Window，按 Cmd+K。
直接搜你記得對話裡「出現過的內容」關鍵字——例如某個函式名 refreshAccessToken、某個錯誤訊息片段、或某個你當時討論的技術詞。因為它搜的是內容不只是標題，這比硬記標題有效得多。
命中後進去，再用 Cmd+F 跳到那段具體討論。

兩層搭起來就是：Cmd+K 找到「哪一條」，Cmd+F 找到「哪一段」。

數據與限制：誠實說清楚

先把有據可查的講清楚，避免灌水：

版本與日期：Cursor 3.11，2026/7/10（來源：官方 changelog）。
索引規模：官方稱本地索引可擴展到「thousands of conversations」並維持「snappy performance」。注意這是 Cursor 官方的說法，沒有給出具體的延遲數字或索引大小上限，「數千」和「流暢」都是廠商措辭，實際體感要自己在大量歷史對話下測。
側邊對話的能力邊界：changelog 只說「預設 focus on 讀/搜/答」，沒有明說它是否能編輯檔案、能否呼叫全部工具。若你打算用側邊對話做會改動檔案的事，這是需要實測確認的灰區。
平台與快捷鍵：文中的快捷鍵是 Cmd（macOS 寫法）。Windows/Linux 對應鍵位（通常是 Ctrl）changelog 未逐一列出，以你本機實際鍵位為準。

我沒有實跑 3.11，以上凡是機制描述都來自 changelog 文字；凡標「暗示/推測」處，代表官方沒把話講死。

適用場景與 trade-off：什麼時候該用、什麼時候別用

Side Chats 該用的時候：

主線在跑長任務，你臨時想 sanity-check 一個決策，又不想中斷或污染主線。
你想在「真的動手改架構」前，先探幾條路（research alternatives without committing to a pivot），比較完再決定要不要讓主線 pivot。
你需要一個「可回訪」的調查 thread——因為側邊對話是持久的，不是問完即丟。

Side Chats 別硬用的時候：

如果你的岔題其實會直接改變主線的做法，那與其在側邊繞一圈再 @ 回來，不如直接在主線講清楚。側邊對話的價值在「切開探索與執行」，當兩者本來就該合在一起時，多開一層反而是負擔。
需要側邊大幅編輯檔案時要謹慎——它預設不是為此設計的。

對話搜尋的 trade-off： 幾乎沒有壞處，它是純增益功能。唯一要建立的新習慣是——現在你可以放心用內容去搜對話，所以不必再糾結「每條對話都要取個好名字」。過去命名是為了日後找得到，現在全文可搜之後，命名的邊際效益下降了。

對工程團隊的意義：三個可以馬上落地的動作

把 /btw 訂為團隊的「岔題規範」。 在團隊的 Cursor 使用約定裡明確寫一條：主線 agent 執行中，任何 sanity-check、探路、確認性問題一律開側邊對話問，問完用 @ 帶結論回主線。這能顯著降低「長任務跑到一半被岔題帶偏」的失敗率——這是很多人用 coding agent 做大任務時最常見的翻車點。
改掉「靠標題找對話」的舊習慣。 既然 Cmd+K 搜的是內容，教團隊直接用「對話裡出現過的函式名、錯誤訊息、技術詞」去搜。這對接手別人 agent 對話、或 review 別人怎麼讓 agent 改一段碼時特別有用。
把「side chat → @ 回主線」當成一種輕量的 context 管理術。 更廣義地看，Side Chats 其實是 Cursor 幫你做的一種 context window 管理：把探索過程隔離在別條 thread，只讓精煉後的結論進入主線。同樣的思路你在別的 coding agent 上也能手動模擬（開新 session 探路、只把結論貼回），但 Cursor 3.11 把它做成了一等公民的操作。理解這個「隔離探索、精煉回注」的原則，比記住哪個按鈕在哪更重要。

總結一句：3.11 這兩個功能都不是炫技，而是把 coding agent 日常最磨人的兩件事——岔題會弄髒主線、歷史對話找不回來——各補上一塊。照上面的招式設定好，你這週就能把它們用起來。