这是一个：

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，正式报价与付款留给人