现在很多人用 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 吗？
