這是一個：

SasaDaily 假設商業案例。

不是 Slack 公布的真實客戶案例。

假設有一家：

6 人網站代營運團隊。

他們不是每天都在：

重做一個網站。

真正花時間的，

反而是一大堆很小的事情。

客戶早上傳：

「活動日期幫我換一下。」

下午又說：

「手機版那個按鈕好像跑掉了。」

隔天：

「這張 Banner 換成新版本。」

再過兩小時：

「等等，首頁不要一起改。」

每一件事看起來都：

很小。

但真正麻煩的是：

需求在哪裡？

最新版本是哪一個？

誰確認過？

工程師到底該改多少？

小型網站公司的成本，常常不是寫 Code

假設客戶在 Slack 說：

這週末活動頁的「立即預約」按鈕幫我往上一點，手機上看不到。

專案經理看到。

再轉給工程師：

客戶說 CTA 要調整。

工程師問：

哪一頁？

專案經理回去找訊息。

再問客戶。

客戶又補：

桌面版不要動。

工程師收到以後開始改。

改完截圖給專案經理。

專案經理再傳給客戶。

客戶回：

我不是說這個按鈕。

真正寫 CSS，

可能只花：

10 分鐘。

前後溝通，

卻花了：

一小時。

Slack Code 想解決的剛好是這一段

Slack Code 可以讓支援的 AI Coding Agent，

直接從團隊原本正在進行的：

Slack 討論

建立一個專門的：

Code Channel。

團隊不必把需求從：

客戶對話。

貼到 Ticket。

再貼給工程師。

工程師再重新丟給 AI。

而是讓：

需求 Context。

AI Agent。

產品。

設計。

工程

進到同一個工作空間。

Slack 官方目前支援 Claude、Devin、GitHub Copilot 與 Vercel 建立 Code Channel。

假設這家網站公司怎麼使用？

例如客戶說：

手機版首頁第一屏看不到完整的活動預約按鈕。
桌面版不要改。

專案經理先不把這句話：

重新翻譯一遍。

而是直接從原本討論啟動：

Coding Agent。

Agent 建立：

Code Channel。

然後團隊先補今天教過的三格：

現在

手機版第一屏看不到完整 CTA。

要變成

不用往下滑就能看到完整按鈕。

不能動

桌面版、按鈕文字、付款流程與其他頁面。

第一層：AI 先做 Plan

Agent 先說：

它準備修改哪些地方。

這時候專案經理看：

需求有沒有理解錯。

工程師看：

範圍是不是太大。

設計師看：

是不是準備動到不該動的版面。

如果這一步就發現：

Agent 想重做整個 Hero，

現在停最便宜。

因為還沒有：

大量修改。

第二層：Agent 真正做修改

確認 Plan 後，

再讓 Agent：

執行。

Slack Code 可以把：

Code Diff

直接放進 Code Channel。

也就是工程師不需要只看：

「已經幫你修改完成。」

而可以看到：

真正有哪些程式被改。

Slack Code 的核心設計就是讓人與 Agent 可以在同一空間一起提出建議、查看變更與 Sign off。

第三層：客戶看 Preview，不需要看 Code

網站代營運最常發生的問題是：

工程師丟一個：

Git Diff。

客戶根本看不懂。

客戶真正想知道的是：

現在長什麼樣？

Slack Code 可以呈現：

Live HTML Preview

等成果。

所以專案經理可以讓：

設計。

客戶窗口。

產品

先看：

實際結果。

Slack 官方也把 Planning Document、Code Diff、Live HTML Preview 列為 Code Channel 可以呈現的工作成果。

這就把每一個角色放回自己最適合看的東西

客戶：

看結果。

產品：

看需求。

設計：

看畫面。

工程師：

看 Code。

Agent：

執行。

這比所有人都被迫：

讀工程 Ticket

合理很多。

但這家公司的核心規則是：Preview 通過，不代表直接上 Production

假設客戶看到：

手機版很好。

專案經理也說：

OK。

這時還沒有：

正式發布。

工程師仍然要確認：

桌面版有沒有被影響。

其他頁面正常嗎？

表單正常嗎？

原本功能正常嗎？

如果是電商：

結帳正常嗎？

再由指定的：

Release Owner

決定是否部署。

為什麼要指定一個 Release Owner？

因為 Slack Code 是：

多人協作。

這很好。

但多人也容易出現：

「我以為別人有確認。」

客戶說：

OK。

設計師說：

OK。

工程師說：

看起來可以。

最後到底誰決定：

正式上線？

如果沒有 Owner，

出了問題後，

大家都可能說：

「我只是看過。」

所以團隊可以直接規定：

客戶／產品

確認需求。

設計

確認畫面。

工程

確認程式與測試。

Release Owner

最後批准 Production。

角色可以是同一個人。

責任不能：

模糊。

這種流程最適合什麼需求？

最適合第一批測試的，

不是：

重寫會員系統。

而是：

小型 UI 修正

按鈕。

間距。

手機版跑版。

活動頁修改

圖片。

日期。

活動資訊。

版型小調整。

文案與頁面元素

CTA。

FAQ。

Banner。

小型 Bug

容易看到結果、

容易測試、

容易 Rollback

的問題。

為什麼這些小事反而最值得先用 AI？

因為很多網站公司真正的低效率，

就藏在：

小事情。

一個工程師花：

5 分鐘

可以修好的問題，

可能因為：

排隊。

補 Context。

來回確認。

做 Ticket。

截圖。

重新解釋

拖兩天。

Slack 自己在介紹 Slack Code 時就提到，

內部團隊發現以前容易被擱置的小 Bug 與 UI 修改，現在更容易直接從對話啟動 Agent 處理。Slack 並表示，內部目前超過 70% 的 Code Channel 會在同一天從建立走到關閉；這是 Slack 自己的產品使用數據，不代表所有公司都能做到相同速度。

這家 6 人公司可以怎麼分工？

假設團隊有：

1 位專案經理。

1 位設計師。

3 位工程師。

1 位負責人／Release Owner。

工作流可以變成：

1. 客戶在 Slack 提需求

先保留原始 Context。

2. 專案經理判斷是否適合 Agent

小型、可驗證、低風險：

進 Slack Code。

高風險：

走正式專案流程。

3. 建立 Code Channel

相關人一起進來。

4. 寫清楚驗收條件

現在。

要變成。

不能動。

5. Agent 提 Plan

人先 Review。

6. Agent 執行

產生 Diff。

7. 設計與客戶看 Preview

確認結果。

8. 工程測試

確認 Regression 與技術風險。

9. Release Owner 批准

最後才正式部署。

這樣真正省的是什麼？

不是：

工程師消失。

而是減少：

需求翻譯。

重新找 Context。

來回截圖。

重新說明是哪一版。

做完才發現理解錯。

這些都是：

看不到、

卻一直在吃工時

的成本。

假設每個小修改原本花 35 分鐘協調

以下只是：

SasaDaily 假設試算。

不是 Slack 保證數字。

假設團隊每月收到：

40 個小型網站修改。

真正 Coding 平均只有：

15 分鐘。

但是每件還要花：

35 分鐘

找 Context、

轉述、

確認、

回報。

那每月光協調時間就是：

35 × 40

＝1,400 分鐘。

約：

23.3 小時。

導入後假設協調降到每件 15 分鐘

因為：

原始需求留在 Slack。

Code Channel 保留 Context。

Plan、Diff、Preview 都在同一空間。

那就是：

15 × 40

＝600 分鐘。

約：

10 小時。

兩者相差：

約：

13.3 小時／月。

這不是「Slack Code 幫你省 13.3 小時」

再次強調：

這是：

假設模型。

不是 Slack 官方 ROI。

真正公司要測自己的：

改版數量。

需求複雜度。

人工 Review。

Agent 成功率。

重新修改率。

才能知道：

值不值得。

而且不能只看處理時間

網站代營運還要看：

一次驗收通過率

第一次 Preview 客戶就接受的比例。

重做率

AI 做完後要不要全部重來？

Context 遺漏率

有沒有漏掉客戶後來補的限制？

Regression

修 A 有沒有弄壞 B？

Production Rollback

發布後需要緊急回復的次數。

如果：

速度變快，

Rollback 卻變多，

那就不是進步。

最重要的 KPI 反而可能是「來回幾次」

例如以前一個小修改：

客戶。

專案經理。

工程師。

來回：

8 次。

導入 Slack Code 後，

大家在同一個 Code Channel：

3 次就完成。

這就是非常具體的：

營運改善。

因為網站代營運的利潤，

往往不是被：

大專案

吃掉。

而是被每天大量：

小溝通

慢慢吃掉。

哪些工作不能因為 Slack Code 很方便就直接交給 Agent？

第一類：

付款

結帳。

退款。

金流。

第二類：

會員與權限

登入。

管理員。

資料存取。

第三類：

Database

Schema。

刪除。

Migration。

第四類：

正式商業規則

價格。

折扣。

庫存。

訂單邏輯。

第五類：

高流量 Production 核心流程

只要做錯會直接：

影響大量使用者

的功能，

就不應該用：

「反正大家都在 Slack 看得到」

當安全理由。

因為 Slack Code 解決的是「協作透明度」

不是：

完整軟體安全。

Slack 官方強調 Code Channel 讓人與 Agent 可以：

plan。

prompt。

review together。

而不是各自在不同 DM 或私人 AI 工作階段裡處理。

這很好。

但真正的：

Repository 權限。

Branch Protection。

Automated Tests。

CI/CD。

Production Deployment

仍然是另一層。

所以這家公司可以設一條很簡單的分界

Slack Code 可以直接進

低風險。

容易 Preview。

容易測試。

容易 Rollback。

Slack Code 可以協助，但不能自動上線

有資料。

有登入。

有商業規則。

影響客戶操作。

直接走正式工程流程

付款。

權限。

Database。

不可逆變更。

核心 Production。

這樣 AI 才會：

加速對的東西。

而不是：

加速所有東西。

還有一個商業價值：客戶開始看得到「為什麼這樣改」

傳統網站維護常常發生：

客戶說：

「怎麼改了？」

工程師說：

「你上星期要求的。」

客戶回：

「我不是那個意思。」

如果原始需求、

後續補充、

Agent Plan、

Preview

都留在同一個工作脈絡，

團隊比較容易回頭確認：

當時到底決定了什麼。

Slack Code 完成後的 Code Channel 仍會保留為可搜尋的工作 Context。

這對網站代營運非常有價值。

因為真正昂貴的衝突之一就是：

沒有共同版本。

但不要把 Code Channel 當合約

Code Channel 可以保存：

工作脈絡。

不能因此替代：

正式報價。

合約。

變更單。

付款條件。

責任約定。

例如客戶突然說：

那你們順便幫我新增會員系統，不用加錢吧？

AI 不應該看到：

「順便」

就直接開始做。

因為這已經不是：

Coding 問題。

而是：

Scope 與商業決策。

Agent 可以做，並不代表包含在原服務範圍

這會是 AI 時代網站公司很容易踩到的新坑。

以前新增一個功能很貴，

大家會先：

報價。

現在 AI 可能半小時做完，

客戶就會覺得：

「那很簡單啊。」

但是公司仍然要考慮：

需求分析。

測試。

維護。

責任。

未來修改。

所以：

AI 降低製作成本

不等於：

服務價值變成零。

反而可能出現新的服務產品

例如網站公司可以把原本：

每次修改另外報價

改成：

Website Care Plan

每月包含：

固定數量小改。

Bug 修正。

UI 微調。

活動頁更新。

每一件都透過：

Slack Code＋人工 Review

快速處理。

高風險功能：

另外報價。

這樣 AI 不是只是：

替工程師省時間。

而可能幫公司重新設計：

收入模式。

例如原本賣「工時」

客戶問：

這個按鈕要改多久？

工程師說：

半小時。

現在 Agent 五分鐘完成。

如果公司還只賣：

工程師工時，

AI 最後可能把自己的：

收入

一起壓低。

更合理的可能是賣「結果與維護能力」

例如：

網站每月穩定有人維護。

小問題快速處理。

改版有紀錄。

每次都有 Preview。

高風險修改有人工 Gate。

這時客戶付的就不是：

「工程師敲鍵盤 30 分鐘。」

而是：

我的網站一直有人負責。

這也是 Slack Code 對小型網站公司的最大商業啟示

Coding Agent 越來越快以後，

單純：

寫程式

可能越來越不是最稀缺的東西。

真正稀缺的會變成：

理解客戶真正要什麼。

把修改範圍控制好。

快速驗證結果。

知道什麼可以上線。

出了問題有人負責。

這些才是：

服務公司的價值。

最後這家 6 人團隊應該看四個數字

1. 每件小修改總工時

不是只算 Coding。

連溝通都算。

2. 平均來回次數

客戶到工程完成共幾輪？

3. 重做率

第一次理解錯的比例多少？

4. Rollback／Production 問題

速度提升後，

品質有沒有下降？

如果四個數字一起改善，

Slack Code 才真的帶來：

商業價值。

今天這個案例真正的結論

Slack Code 對網站代營運公司的價值，

不是：

「以後不用工程師。」

更可能是：

讓原本散落在客戶訊息、工程師 AI 對話、Code Review 與 Preview 之間的工作，回到一條大家都看得到的流程。

AI 負責：

加速實作。

團隊負責：

Context。

驗收。

測試。

批准。

而公司真正應該賣給客戶的，

也不再只是：

寫 Code 的時間。

而是：

從一句修改需求，到安全變成正式網站成果的完整交付能力。

今天，和 AI 一起進步一點。

每天學會一個 AI 技巧。

每天節省一點時間。

每天提升一點能力。

SasaDaily，陪你一起成長。

推薦閱讀

今日 AI 工具｜2026/07/23：Claude Tag，把 Claude 加進 Slack，讓整個團隊共同交辦與追蹤工作

AI 一分鐘教學｜2026/08/20：Replit 要改 App 前，先開 Plan Mode，只看計畫、不先動程式

AI 商業案例｜2026/08/20：5 人客製印刷工作室怎麼用 Replit？Free Mode 先做訂單追蹤 MVP，複雜邏輯再升 Power，正式報價與付款留給人