Cursor in Slack 三招升級：先出計畫、multi-repo、跨頻道實戰教學

瀏覽次數: 3

你在 Slack 上敲一句「@Cursor 幫我把登入逾時修掉」，然後就是漫長的等待——它在雲端悶頭跑，你看不到它打算怎麼改，等它回一條「PR 開好了」才發現方向根本歪了，只能重來。這是過去半年 Cursor 背景 agent 進 Slack 之後，最讓人心累的一段體驗。

2026 年 7 月 17 日，Cursor 官方 changelog 一次補上三件事：先出計畫再動手、multi-repo 環境、跨頻道讀寫。這篇就把這三招拆開講清楚機制，並給你可以照著設定的具體語法——目標是讓你今天就能把 Slack 裡的 Cursor 用得比昨天穩。

（以下設定與行為，皆依 Cursor changelog 與官方 Slack 文件整理；我沒有實際在生產環境長跑過，凡是「值得實測的點」我會標出來。）

本文大綱

背景：Slack 裡的 Cursor 到底是什麼

先對齊基本盤。Cursor 的 Slack 整合本質是把背景 agent（Background Agent）掛到 Slack 上：你在任一 thread @Cursor 加一句話，它就在雲端一個安全隔離環境裡開一個 agent，讀完整條 thread 當脈絡，動手改 code，最後把結果（通常是一個 GitHub PR）貼回 Slack。這是 Cursor 1.1 版就有的能力。

安裝路徑是：到 cursor.com/dashboard/integrations 連上 Slack，接著綁定 repo provider（GitHub）、選一個預設 repo、開啟 usage-based pricing、確認隱私設定。裝好之後，日常就靠這幾個指令：

@Cursor [prompt]——開一個新 agent，或在既有 thread 裡追加指令
@Cursor agent [prompt]——在 thread 裡強制開一個新 agent（避免被當成追問）
@Cursor settings——設頻道與個人預設
@Cursor list my agents——列出正在跑的 agent
@Cursor help——查目前可用指令

問題是，過去這套流程有三個痛點：看不到計畫、只能綁單一 repo、被鎖在原本那條 thread 裡。這次更新正是逐一解這三點。

招式一：先出計畫，讓你「早一步攔截」

這是最有感的一招。更新後，Cursor 收到指令不會馬上動手，而是先回一份計畫——它打算怎麼拆這件事、動哪些檔案、大概走哪條路。你看到計畫就能在它開跑前跳進來改方向，而不是等它做完才發現走歪。

執行過程中，它會逐步更新狀態，你在 Slack 裡就能看到它卡在哪一步，而不是對著一條「思考中…」乾等。這件事在非同步協作裡意義比看起來大：狀態可見，等於整條 thread 自動變成一份可稽核的執行紀錄，事後回頭看「它為什麼這樣改」有跡可循，也方便同事接手。UI 也順手清乾淨了：原本塞在訊息裡的一堆大按鈕拿掉，改成訊息底部一排精簡的 footer 連結，PR、表格、artifact 直接點開，訊息不再被按鈕撐爆，手機上看尤其清爽。

實戰上這招怎麼用得好？把計畫階段當成 code review 的第一道關。收到計畫別急著讓它跑，先掃一眼：它有沒有理解對需求？要動的檔案是不是你預期的？如果它說「我打算改 auth/session.ts 的逾時常數」，但你知道真正的問題在 middleware，這時候一句追問把它導回去，省下的是一整輪白跑的雲端執行。這跟你在本機 Cursor 用 Plan Mode 的心法是同一套——先對齊、再放手，只是搬到了 Slack 這個非同步場景，價值更大：因為在 Slack 你往往離開座位了，一次攔截省下的可能是好幾個小時的等待。

招式二：multi-repo 環境，一句話橫跨前後端

第二個痛點是 repo。以前 Slack 開的 agent 預設綁在單一 repo，但真實世界的功能常常橫跨多個 repo：前端一個 repo、後端一個 repo、共用型別／schema 又一個 repo。

現在你可以讓 agent 在一個具名的 multi-repo 環境裡開工。這個「環境（environment）」是在 Cursor 側預先綁好一組 repo 的雲端 agent 環境，你在 Slack 用 env=Platform 這種語法、或自然語言「用 Platform 環境」把它叫出來。更關鍵的是：任務跑到一半需要另一個 repo 時，它會跳出一個 Switch repository 按鈕，你選好要進的 repo 或環境，它就接著跑，不用整個重開。

這裡要搞懂一個容易踩坑的機制：它到底怎麼決定用哪個 repo？ 依官方文件，判定是有優先順序的，前者命中就停：

訊息裡明講——repo=acme/backend，或自然語言「in acme/backend」
近期活動——你最近用過的 repo
Routing 規則——你在 dashboard 設的「關鍵字 → repo」對應（例如關鍵字 frontend 自動路由到 acme/web-app）
頻道預設——注意，頻道設定只對公開頻道生效，且會蓋過你的個人預設
Fallback——最後才是那個安裝時設的預設 repo

實戰建議很直接：不確定它會挑到哪個，就別賭 fallback，直接在訊息裡把 repo= / env= 寫死。 尤其團隊共用一個頻道時，先把 routing 規則和頻道預設設好，再放大家用——否則兩個人在同一頻道各自 @Cursor，很容易一個打到對的 repo、一個打到 fallback，然後就是一場莫名其妙的 debug。另外，起始分支（base branch）也能在 dashboard 設；留空就是用 repo 的預設分支（通常是 main）。

招式三：跨頻道讀寫，打通脈絡與回報

第三招是打破「一條 thread」的邊界。更新後，Slack 裡的 Cursor 能從其他頻道與 thread 讀脈絡，也能把訊息／更新送到別的頻道。

這在事故處理特別有用：事故的討論在 #incident-登入逾時 裡，但你希望 agent 的工作紀錄集中回報到 #eng-bots。現在你可以讓它去讀事故頻道的脈絡、動手修，然後用 channel=#eng-bots 這種語法把更新貼到指定頻道，而不是把工程雜訊灌進事故頻道洗版。

要留意的是權限與隱私面：這套整合會要求相當多的 Slack 權限（官方文件提到 16 項，涵蓋訊息歷史、檔案操作、使用者辨識），畢竟跨頻道讀寫本來就需要更大的存取範圍。Cursor 有提供 Privacy Mode，並能設定在外部 Slack workspace 裡要不要顯示 agent 摘要。跨頻道能力越強，越該先跟你的 IT／security 對一次權限範圍再全員開通。

數據與限制：誠實地說

這次更新是功能性改版，沒有官方公佈的量化 benchmark（例如「計畫階段讓返工率降多少」這類數字，官方 changelog 並未提供），所以我不編造效益數字。能確定的是機制層面的三件事：計畫先行、multi-repo 可切換、跨頻道可讀寫。

其餘該記在心上的限制：

Cursor 官方自己在文件結尾標明「Cursor can make mistakes，請務必複查 code 與回覆」。Slack 是非同步場景，你更容易「發完就走人」，反而更需要在 PR 合併前認真 review。
它跑在雲端背景環境，不是你本機——環境的依賴、密鑰、資料庫連線是否齊備，會直接決定它能不能真的把任務跑完。這是進生產前最值得先實測的一點。
Routing 與頻道預設的交互規則（尤其「頻道設定只對公開頻道生效」）容易反直覺，私訊或私密頻道的行為要自己驗一遍。
計畫先行雖然能攔截方向錯誤，但它出的計畫本身也可能是錯的——它對 codebase 的理解仍受限於它讀到的脈絡。計畫看起來合理不代表實作就對，該複查的還是要複查。

照著做：一個把三招串起來的完整範例

把上面三招串成一次真實任務，你在 Slack 事故頻道 #incident-登入逾時 裡會這樣打：

@Cursor agent 讀這條 thread 的事故脈絡，登入偶發逾時。
先出計畫給我看，我確認再動手。
env=Platform（要同時看 frontend 與 backend）
base=main
把進度回報到 channel=#eng-bots

拆解一下每一行在對應哪個機制：

@Cursor agent——強制開一個新 agent，不會被誤判成對舊 agent 的追問。
「先出計畫給我看，我確認再動手」——明確要求它走計畫先行，把攔截點卡在執行前。它回計畫後，你若發現它想改的檔案不對，直接在同一 thread 回一句修正即可。
env=Platform——一次掛上前後端兩個 repo，避免它只綁到單一 repo、跑到一半才發現要跨 repo。真的跨到第三個 repo 時，用 Switch repository 按鈕接續。
base=main——明講起始分支，不靠 dashboard 預設猜；跨 repo 情境下這點特別容易被忽略。
channel=#eng-bots——把工程雜訊導到機器人頻道，事故頻道保持乾淨。

一個好的 Slack 任務 prompt，通常就是「一句清楚的目標 + 明講 repo/env/base/channel + 要求先出計畫」這個公式。把它存成團隊的 snippet，新人照著填空就不會踩到 routing 的坑。

對工程團隊的意義：可以照做的三步

把 Slack 當成 agent 的非同步入口，而非同步 IDE。 適合丟「調查這個 error」「開一個小修 PR」「照這個討論串的結論改」這種邊界清楚、能非同步等的任務；不適合需要你來回緊密協作的大重構。
先設定，再放大家用。 花十分鐘把預設 repo、base branch、routing 規則、頻道預設、隱私模式一次設好——這些設定決定了「一句 @Cursor」會不會打到對的地方。共用頻道尤其要先設 routing。
養成「看計畫再放行」的習慣。 這次更新把攔截點提前到執行前，團隊該把它變成默契：收到計畫掃一眼再讓它跑，把返工成本壓在最前面。

一句話總結：這次更新沒有炫技的新模型，但把 Slack 裡的 Cursor 從「黑箱背景工」變成「會先說清楚要做什麼、能跨 repo、能跨頻道」的協作者。對已經在用的團隊，值得今天就把設定重跑一遍。

來源（primary sources）：