現在很多人用 AI 寫程式，
工作流程大概是：
工程師打開：
Claude。
Codex。
Copilot。
Devin。
或者其他 Coding Agent。
自己跟 AI 聊一陣子。
AI 改完程式。
最後才丟給團隊說：
「我做好了，你們看一下。」
問題是，
其他人通常只看到：
最後結果。
卻不知道：
AI 一開始收到什麼要求？
做了哪些假設？
中間改了哪些東西？
有沒有誰早就知道：
這個需求理解錯了？
Slack 最新推出的：
Slack Code
就是想改掉這件事。
Slack Code 是什麼？
最簡單理解：
它把原本：
一個人＋一個 AI Coding Agent
的私人工作，
改成：
整個團隊＋AI Agent
一起工作的專案空間。
Slack 把這個空間叫：
Code Channel。
當一個開發任務變得比較複雜時，
團隊可以在 Slack 裡叫進支援的 Coding Agent。
接著建立一個專門處理這件工作的 Code Channel。
裡面不只是：
聊天。
還可以看到：
計畫。
程式變更。
Code Diff。
Live HTML Preview。
團隊意見。
最後審核。
也就是：
AI 做事的過程開始被看見。
它真正要解決的不是「AI 不會寫程式」
現在 Coding Agent 已經非常會寫。
真正的新問題反而是：
寫太快。
假設產品經理跟工程師說：
把首頁增加一個免費試用按鈕。
工程師自己去叫 AI 改。
十分鐘後：
完成。
看起來非常有效率。
但設計師可能不知道：
按鈕位置改了。
行銷可能不知道：
文案被改掉。
另一位工程師可能不知道：
Agent 順便動了登入流程。
速度很快，
但是團隊 Context：
斷掉了。
Slack Code 的想法是：讓 AI 回到大家都看得到的地方
例如某個 Slack 頻道正在討論：
「手機版註冊按鈕太小。」
以前可能有人回：
我等等改。
接著他離開 Slack，
開 Coding Agent。
二十分鐘後才回來。
現在可以直接把 Agent：
叫進來。
由 Agent 建立：
Code Channel。
然後大家一起看到：
它準備怎麼修改。
誰知道額外限制，
就直接補上。
第一個重要功能：Plan 不再只給一個人看
AI Coding 最大的風險之一，
就是：
一開始理解錯，
後面每一步都做得非常漂亮。
例如需求其實是：
「只改手機版。」
Agent 卻理解成：
桌面與手機全部一起改。
如果只有一位工程師跟 AI 工作，
團隊通常等到：
完成
才發現。
Code Channel 把工作計畫放進共同空間後，
其他人就有機會在真正大量修改以前說：
「等一下，這個假設不對。」
第二個功能：Code Diff 可以直接被看見
Code Diff 最簡單的意思就是：
哪裡被改了？
不是只看到 AI 說：
「修改完成。」
而是看：
原本什麼。
現在什麼。
Slack 官方描述的 Code Channel 可以直接顯示：
Code Diff。
也就是團隊不必只相信：
Agent 的文字摘要。
可以進一步檢查：
真正變動。
第三個功能：Live Preview
這個對非工程師特別重要。
設計師未必想看：
程式碼。
行銷人員更不一定需要理解：
React。
CSS。
API。
但他們看得懂：
結果。
例如 AI 改完網站後，
Live Preview 直接讓團隊看到：
按鈕位置。
手機畫面。
表單。
頁面結構。
這樣非技術同事也可以說：
「這不是我們想要的。」
而不必先學會看：
Code Diff。
這就是 Slack Code 最特別的地方
它不是讓每個人都變成工程師。
而是讓不同角色可以在：
自己看得懂的層級
參與 AI 開發。
工程師：
看 Code。
設計師：
看 Preview。
產品經理：
看需求。
其他同事：
補充 Context。
AI Agent：
真正執行。
第四個功能：一個專案一個 Code Channel
一般 Slack Thread 很適合：
快速問答。
但是 Coding Agent 如果持續執行：
幾十步。
Thread 很快會變成：
一大片訊息。
Slack Code 會針對比較完整的開發工作，
建立專門的：
Code Channel。
這個空間只處理：
這一件事。
完成後，
它會：
自動封存。
但是內容仍然可以：
搜尋。
為什麼封存後仍保留很重要？
因為三個星期後，
有人可能問：
「這個登入流程到底是誰改的？」
以前答案可能是：
「應該是 AI。」
但：
誰叫它改？
當時要求什麼？
誰看過？
為什麼這樣決定？
可能沒人記得。
如果工作都在 Code Channel 裡，
至少可以回頭找到：
討論。
指令。
變更。
審核過程。
Slack 把它形容成類似：
Audit Log。
這對 AI 時代非常重要
未來公司真正麻煩的問題可能不是：
「誰寫了這段程式？」
因為答案可能經常是：
AI。
更重要的是：
「誰要求 AI 這樣改？」
以及：
「誰最後確認可以上線？」
AI 可以是執行者。
責任流程仍然需要：
人。
Slack Code 現在支援哪些 Agent？
Slack 在 8 月 20 日正式發布 Slack Code。
官方目前表示，
已正式可搭配：
Claude。
Devin。
GitHub Copilot。
Vercel。
Slack 也把 OpenAI 列為合作夥伴，
但官方最新可用性說明仍寫：
ChatGPT 支援即將推出。
因此目前不能直接寫成：
所有使用者現在已經可以正式用 ChatGPT 建立 Slack Code Channel。
這個時間差要分清楚。
使用方式其實很接近日常 Slack
假設開發頻道有人說：
客戶回報手機版結帳按鈕消失。
以前：
建立 Ticket。
分配工程師。
工程師開 Coding Tool。
完成。
Review。
現在可能變成：
直接叫 Agent。
Agent 建立：
Code Channel。
然後：
第一步：
讀 Context。
第二步：
提出計畫。
第三步：
開始修改。
第四步：
出現 Code Diff。
第五步：
產生 Preview。
第六步：
工程師與團隊確認。
這就是：
AI Coding 工作流被搬進團隊對話。
最有意思的是：非工程師也開始能參與
例如產品經理發現：
「訂閱頁面價格文字錯了。」
以前他通常：
建立 Issue。
描述問題。
等工程師有空。
現在某些簡單問題，
可以直接：
叫 Coding Agent。
先讓 AI 準備修改。
真正的工程師再：
Review。
Slack 官方甚至直接舉例：
非技術同事可以用自然語言描述問題，
讓 Agent 準備修正，
再 Tag 工程師進來審核。
這不代表「人人都可以自己改 Production」
這一點非常重要。
讓非工程師：
提出修改。
和：
讓非工程師直接把修改部署正式系統
是兩件完全不同的事。
Slack Code 本身的價值，
反而是：
把人拉回：
Review。
Slack 官方表示，
高風險變更可以：
route to a person for approval。
也就是：
AI 做到某個階段，
再由人：
批准。
這和前幾天介紹 Replit Plan Mode 的差別在哪裡？
Replit Plan Mode 解決的是：
AI 改 App 前，我自己先看它準備怎麼做。
Slack Code 更偏向：
AI 改東西時，整個團隊怎麼一起看。
兩個方向其實可以串起來。
第一層：
AI 先 Plan。
第二層：
人看 Plan。
Slack Code 再加上：
第三層：
其他相關的人也能及時加入。
因為 AI 最危險的錯誤有時不是技術錯誤
例如 AI 把：
Button 做好了。
程式沒有 Bug。
測試也通過。
可是產品經理才知道：
這個功能根本：
下星期才要發布。
或者法務知道：
這句文案不能這樣寫。
或者客服知道：
客戶其實不是要求刪功能，
只是要求：
換說明方式。
這些不是：
Coding 問題。
而是：
Context 問題。
所以「多人一起看」不是拖慢 AI
表面上看，
AI 自己直接改最快。
但是如果：
十分鐘做完。
兩天後才發現需求錯了。
重新做一次。
那不叫快。
真正有效率的是：
在最便宜的階段發現錯誤。
Plan 階段發現錯：
便宜。
Preview 發現錯：
還可以。
Production 才發現：
成本最高。
Slack 公布一個值得看的內部數字
Slack 表示，
目前超過：
70% Code Channels
可以在：
同一天內
從建立一路走到完成並關閉。
這是 Slack 自己的產品使用數據，
不是獨立研究，
也不能理解成：
「任何公司導入 Slack Code 都會一天完成專案。」
比較合理的意思是：
很多適合 Code Channel 的工作，
目前屬於：
Bug。
小功能。
UI 修正。
快速迭代
這類可以在短時間閉環的任務。
所以它最適合的第一批工作，不是「重寫整個公司系統」
第一次測 Slack Code，
比較適合：
小型 Bug。
文案修改。
簡單 UI。
內部工具調整。
單一功能。
容易 Preview 的工作。
因為：
做錯容易看出來。
容易回復。
審核範圍也比較小。
不建議第一天就丟這種任務
例如：
把我們全部會員權限系統重新設計。
或者：
重寫付款流程。
或者：
改整套 Production Database Schema。
雖然 Agent 可能真的：
做得到。
但這種高影響工作，
不是只因為：
現在大家看得到
就突然變安全。
「大家都看得到」不是安全保證
這和我們前幾天一直談的 AI Agent 原則一樣。
Code Channel 提高的是：
透明度。
不等於：
正確性。
全公司可能都看著 AI：
做錯。
如果沒有人真的理解：
哪裡錯，
它還是會錯。
所以最好的使用方式不是：
「反正 Slack 有紀錄就讓 AI 自己跑。」
而是清楚設定：
誰負責需求。
誰負責 Code Review。
誰負責最後批准。
Slack Code 還繼承原本 Slack 權限與管理控制
對公司而言，
這點非常重要。
Slack 官方表示，
Slack Code 使用既有的：
權限。
Admin Controls。
也就是企業不需要把 Code Channel 當成：
完全脫離原本 Slack 治理的一套新系統。
但是：
Coding Agent 本身還能存取哪些：
Repository。
資料。
服務。
仍然要看：
各個 Agent 的實際授權。
所以公司真正應該問的是「這個 Agent 能碰什麼？」
不要只問：
Slack Channel 誰看得到。
還要問：
Agent 可以：
讀哪個 Repo？
改哪個 Branch？
能不能開 PR？
能不能 Merge？
能不能 Deploy？
能不能碰 Production？
這才是真正的：
權限邊界。
最好的第一個 Workflow 可以非常簡單
假設公司網站有一個：
手機版按鈕跑掉。
第一步
在 Slack 說明問題。
第二步
Tag Coding Agent。
第三步
進入 Code Channel。
第四步
先看它理解的問題與 Plan。
第五步
再讓它修改。
第六步
看 Code Diff。
第七步
看 Preview。
第八步
工程師 Review。
第九步
人工批准後再進正式流程。
這才是：
團隊版 AI Coding。
它甚至可能改變「誰可以提出產品改善」
以前很多小問題會消失，
不是因為：
沒有人看到。
而是大家會想：
「這個太小了，不值得叫工程師。」
例如：
按鈕距離。
一行錯字。
簡單排序。
小型內部工具。
Slack 自己就表示，
以前一些：
Bug Report。
小型 UI 修改
常被放著。
現在可以直接從原本討論裡啟動 Agent。
這可能讓：
小改善
更容易真正被完成。
但要小心另一個反效果：改得太容易
當任何人都可以：
叫 AI 改，
公司可能從：
「小問題沒人做」
走到另一個極端：
「每個人都一直叫 AI 改。」
今天：
Marketing 改一下。
下午：
Product 再改。
明天：
Sales 覺得不好再換。
如果沒有：
Owner。
需求排序。
Review。
最後可能只是讓產品：
改得更亂。
所以 AI Coding 的瓶頸可能從「寫程式」轉成「決定要寫什麼」
以前工程師時間很貴，
自然形成一道限制：
不是每個想法都會立刻實作。
如果 Agent 把 Coding 成本大幅壓低，
真正新的稀缺資源可能變成：
判斷。
到底什麼應該做？
什麼不應該做？
哪個版本才是正式需求？
誰可以批准？
這些問題：
AI 不會因為 Coding 變快就自動消失。
這就是 Slack Code 最值得注意的地方
它真正看到的問題不是：
「AI 需要一個更好的聊天視窗。」
而是：
AI Agent 開始真的做工作以後，人類需要一個共同看得見的工作空間。
也就是：
AI 不是另一個偷偷工作的外包工程師。
而應該像團隊成員一樣：
工作有 Context。
過程看得見。
修改有人 Review。
完成有人負責。
如果你不是工程師，有沒有用？
如果你完全沒有：
軟體專案。
網站。
內部工具。
那 Slack Code 當然不是今天最需要的產品。
但如果你在：
小型 SaaS。
網站公司。
新創。
產品團隊。
設計工作室。
數位行銷公司。
電商。
一人公司＋外包工程師
工作，
它真正值得看的不是：
會不會 Coding。
而是：
你和工程師之間的需求，有沒有一直在傳話中變形？
如果答案是：
有，
Slack Code 的多人協作方向就非常值得注意。
今天第一次用，只做一件小事
不要：
重寫 App。
挑一個：
看得到結果的小問題。
例如：
一個 Bug。
一個按鈕。
一個簡單 UI。
然後全程保留：
Plan。
Diff。
Preview。
Review。
看看團隊最後真正省掉的是：
Coding 時間，
還是：
溝通時間。
今天真正值得記住的一句話
Slack Code 最大的變化，
不是：
「AI 又更會寫程式了。」
而是：
AI 寫程式這件事，開始從一個人的私人對話，變成團隊可以一起看、一起改、一起批准的工作流程。
AI Coding 如果繼續變快，
真正稀缺的東西可能不再是：
寫 Code 的速度。
而會變成：
誰提供正確 Context。
誰發現錯誤假設。
誰有權批准正式變更。
這才是 AI Coding 真正進入公司的下一階段。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
推薦閱讀
AI 一分鐘教學｜2026/08/20：Replit 要改 App 前，先開 Plan Mode，只看計畫、不先動程式
AI 快問快答｜2026/08/20：Replit Plan Mode 已經把修改步驟列完整，就代表照著 Build 一定不會弄壞原本 App 嗎？
