Slack Code：编程智能体正式搬进了团队频道

现在，一个编程智能体最重要的指标已经不只是“代码写得多好”，而是谁能看见它正在做什么。直到这个月，对大多数团队来说，真实答案仍然是：一个开发者，在自己的终端或浏览器标签页里单独盯着，然后希望自己过几个小时还记得智能体到底做过什么。8 月 20 日推出的 Slack Code，是目前最大规模的一次尝试，想把这个答案改成：“默认情况下，项目里的所有人都能看到。”

我读了发布公告、Slack 自己的后续文章以及相关报道。底层模型还是你已经熟悉的 Claude Code、Devin 或 Copilot。真正变化的是工作发生在哪个房间里，而这件事的重要性，比大多数报道表现出来的更高。

关键要点 - Slack Code 增加了“代码频道”：共享项目空间。团队在其中 @ 一个编程智能体，例如 Claude Code、Devin、GitHub Copilot 或 Vercel，ChatGPT 也已宣布将加入。智能体公开执行任务，团队可以查看差异、实时预览，并在任何内容发布前进行人工审批。 - 从第一天起，所有 Slack 套餐都可以使用，包括免费版，但每个智能体本身仍需单独购买访问权限。任务完成后频道会自动归档，并保留审计日志。 - 真正的变化是监督方式：智能体工作从一个人盯着的私有会话，变成整个团队都能看到的共享产物。这解决了一些归属和审查缺口，也带来新的问题，例如旁观者效应、形式主义审批，以及频道上下文本身成为攻击面。 - 这也是一次分发策略。Slack 花了一年时间搭建智能体基础能力，包括 MCP 服务器、实时搜索、Slackbot MCP 客户端，而代码频道是第一次把这些底层工作变成人人看得见的产品界面。 - “代码发布前需要人类批准”应该被当成设计目标，而不是天然保证。真正的审查流程仍然需要你自己建立。

发生了什么

8 月 20 日，Slack 在所有套餐上推出 Slack Code，包括免费工作区。根据发布报道和 TechRepublic 的文章，工作方式如下：

• 你可以在任何 Slack 对话中 @ 一个编程智能体。它会为这项任务新建专用代码频道，不管任务是修复缺陷、更新页面还是构建功能。

• 频道里的所有人都会看到智能体所依据的同一段对话，在代码差异提出时直接审查，查看实时 HTML 预览，留下反馈让智能体吸收修改，并批准最终结果。没有人工确认，任何内容都不会发布。

• 工作完成后，频道会自动归档，同时保留审计日志。

• 首发合作方包括 Anthropic 的 Claude、Cognition 的 Devin、GitHub Copilot 和 Vercel，OpenAI 的 ChatGPT 已宣布即将加入。Slack 还计划向更广泛的开发者社区开放代码频道 API，让任何自定义智能体都能接入。

谁会进入这个频道也可以配置。Slack 产品副总裁 Katie Steigman 告诉 Reworked：“你可以只让智能体把最初 @ 它并创建代码频道的用户拉进来，也可以配置为让智能体根据自己掌握的上下文，自行判断还有谁应该进入频道。”Slack 执行副总裁兼总经理 Rob Seaman 则概括了产品意图：“AI 只有真正进入团队日常工作方式时，才会创造价值。”

Slack Code 于 2026 年 8 月 20 日在所有 Slack 套餐上推出。根据 Slack 的公告，合作编程智能体，包括 Claude、Devin、Copilot、Vercel，以及已宣布将加入的 ChatGPT，会进入共享“代码频道”。整个团队都能看到智能体的对话、代码差异和实时预览，在发布前批准工作，并在频道自动归档后保留完整审计日志。

监督从私有会话里走出来了

功能列表很容易把真正重要的变化藏起来。今天大多数智能体监督，其实是一种由一个疲惫的人维持的假象。智能体在某个人的 IDE 或云沙箱里运行，最后以拉取请求的形式交付差异，而所谓“审查”，往往取决于下午 5 点那个开发者还剩多少耐心。推理过程、走过的死路、前三次失败后第四次才奏效的尝试，几乎全部消失。我审过足够多的智能体产出，知道差异本身往往反而是整个过程里信息量最少的一部分。

Slack Code 真正提出的是：让“过程本身”成为可保存的产物。频道保存智能体依据的对话、中间步骤、收到的反馈以及获得的审批，然后把整套记录作为可搜索资料归档。这确实是一种不同的监督模型，而且更接近优秀团队监督初级工程师的方式，而不是今天监督智能体的方式：看工作过程，不只看最终输出。

它还改变了谁负责监督。产品明确希望产品经理、设计师和非技术团队成员都能跟进。我谨慎支持这个方向，但有一个保留意见，后面还会再说：一屋子旁观者不等于一名审查者。看得懂代码差异不会因为“大家都在频道里”就自然发生，而“团队都能看到”也很容易悄悄变成“其实没人认真检查”。这里引出的治理问题，例如十个人都看了却没人真正拥有批准责任时，到底谁负责，正是我在智能体治理框架里反复处理的问题。Slack Code 不会替你回答，但至少把问题从隐藏状态变成了可见状态。这是诚实的第一步。

Slack Code 把智能体监督从私有会话搬到共享、可归档的频道记录里。根据 Slack 的产品文章，对话、中间步骤、反馈和审批都会保留下来，成为可搜索的工作产物。但当一个房间里有很多旁观者时，究竟由谁承担批准责任，仍然需要客户自己定义。

共享上下文有两面性

第二个重要主张是上下文。Slack 的逻辑是，一项任务所需的背景原本就存在频道里，包括缺陷报告、规格讨论、客户投诉，因此智能体应该直接在上下文所在的位置工作，而不是先让某个人把信息复制粘贴进私人提示词。这个判断是对的，而且它建立在 Slack 今年持续铺设的底层能力之上。根据相关报道，Slack 的 MCP 服务器和实时搜索 API 在 2 月正式可用，让智能体可以受治理地访问工作区消息与文件，随后 6 月又推出 Slackbot MCP 客户端。我在 MCP 服务器综述里解释过，智能体上下文真正有用的一半，就是能安全接触团队工具。频道模型基本是把这个思路推到了自然终点。

但共享上下文同时也意味着共享暴露面。一个能读频道的智能体，会读到频道里的一切，包括某人“就贴一分钟”的凭据，以及从客户那里转发来的外部内容。我认识的安全研究者几乎都会告诉你同一件事：智能体能读取的内容，就可能成为指令它行动的内容。共享频道的提示注入攻击面，毫无疑问比私有会话更大。把拥有写权限的智能体接进一个繁忙频道之前，应该认真决定它可以读哪些频道，以及它的工具究竟能碰什么。这是架构工作，不是设置页面里的小选项，也正是我在智能体架构里反复提到的权衡：能力和影响范围会一起增长。

Slack Code 的上下文优势在于，智能体直接在任务背景已经存在的地方工作。根据 Unite.AI 的报道，这一能力建立在 Slack 于 2026 年 2 月正式开放的 MCP 工作区访问能力之上。同一份共享上下文也会扩大提示注入和凭据暴露的攻击面，而发布材料并未讨论这一取舍。

归属和审查，这些不起眼的收益才最实用

这次发布里最不炫的部分，反而是我最愿意为之付费的。先说归属。在代码频道里，每一次智能体操作都挂在智能体自己的身份下面，发生在一个本来就知道每个人是谁的工作区里，而且项目结束后审计日志仍然保留。这听起来很基础。确实很基础。但它已经比多数团队今天为智能体工作提供的归属基础设施更完整。现实里，“智能体做的”和“我做的”经常最后混在同一条 git 历史里。受监管行业过去一年真正不断追问的，恰恰就是这种无聊但必要的能力。

第二是审查。代码差异和实时预览就在频道里，反馈会被智能体吸收，而且发布之前存在硬性的批准关卡。但要注意缺少什么：Slack 材料说“由一个人批准工作”，但我没看到任何内容规定这个人必须是谁、必须看到什么，或者配置的审查者休假时会发生什么。把批准做成一个勾选框，很容易产生审批表演：所有人最终都学会点那个绿色按钮。真正能从这里获得价值的团队，会把批准绑定到真实代码所有者和真实差异审查，并把智能体频道里的内容作为证据，而不是把它本身当成审查过程。

竞争背景也值得看。正如 Reworked 的报道指出，Microsoft 在 2025 年 9 月就把 Copilot 编程智能体放进 Teams 线程，Block 则在 7 月发布了开源 Buzz。聊天窗口正在成为智能体工作的竞争界面，而 Slack 的优势一点也不神秘：团队本来就在那里。协作软件里，分发能力每次都比聪明的小功能更重要。

根据 TechRepublic，Slack Code 让每个智能体在频道中拥有自己的身份，并为每个已归档项目保留审计日志。但它的批准关卡，也就是“发布前由一个人批准”，没有规定审查者身份或审查标准。根据 Reworked，直接可比的方案包括 Microsoft 于 2025 年 9 月推出的 Teams Copilot 智能体，以及 Block 于 2026 年 7 月发布的开源 Buzz。

现在可以做什么

如果你的团队使用 Slack，也已经在用编程智能体，可以先做三件事。

1. 本周： 选一个风险很低、定义清楚的任务，例如改一段文案，或者修一个复现步骤明确的小缺陷，让两三个人在代码频道里一起观察。你测试的不是智能体，而是团队的审查行为。看看是否真的有人读了代码差异。

2. 任何真实内容发布前： 用书面规则确定每个仓库的智能体工作由谁批准，以及这个人必须检查什么。如果答案是“频道里谁都可以”，那你没有审查流程，你只有一个按钮。

3. 大规模铺开之前： 限定智能体能读哪些频道，以及运行环境中持有哪些凭据。频道历史就是上下文，上下文就是攻击面。先窄后宽，用证据决定是否扩大。

常见问题

什么是 Slack Code？

它是 Slack 于 2026 年 8 月 20 日推出的一项功能，让团队可以在对话中 @ 合作编程智能体，包括 Claude Code、Devin、GitHub Copilot、Vercel，以及即将加入的 ChatGPT。智能体会为任务创建一个专门的“代码频道”，团队可以在那里观察工作过程、审查差异和预览，并在结果发布前批准。任务完成后，频道会自动归档。

我需要付费 Slack 套餐吗？

不需要。Slack Code 对所有套餐开放，包括免费工作区。但每个编程智能体的访问权限仍需向对应厂商单独购买，因此真实成本取决于你已经在为哪些智能体付费。

Slack Code 会取代代码审查吗？

不会，而且把它当成替代品反而是最大的风险。它只是把审查搬进共享、可归档的频道，并增加一个批准关卡，真正的审查质量仍取决于一个明确的人类是否认真阅读代码差异。一个人人可见却无人负责的流程，甚至可能比一个由认真审查者负责的私有流程更糟，因为前者看起来像是“有人监督”。

让智能体读取整个频道安全吗？

取决于频道里有什么。智能体能读到的一切，都可能影响它，包括粘贴进去的凭据和转发过来的外部内容。应尽可能缩小读取范围，让智能体凭据保持最小权限，并把频道内容当成不可信输入。因为从智能体视角看，它确实就是不可信输入。

最后的判断

Slack Code 不会让智能体突然写出更好的代码，那也不是它的目标。它让智能体工作默认变得可见、可归属、可审查，而且发生在团队本来就工作的地方。这三件事，恰恰是很多智能体部署悄悄缺失的部分。问题在于，可见不等于监督。频道给了你记录和关卡，但到底有没有人真正看，仍然是你必须解决的问题。接下来我更想看团队怎么配置批准者，而不是它们选了哪个智能体。这里决定了 Slack Code 会成为真正的监督机制，还是又一场形式主义表演。

如果你正在思考怎样把智能体放进团队工作流，同时不失去审查控制，这也是我经常和客户讨论的问题。欢迎联系我。

来源

• Salesforce，《Slack Code 正式发布：面向团队的智能体编程》：https://www.salesforce.com/introducing-slack-code/ （发布于 2026 年 8 月 19 日，检索于 2026 年 8 月 29 日）

• Slack，《Slack Code：团队与智能体共同构建的地方》：https://slack.com/blog/news/slack-code-channels-for-agents （发布于 2026 年 8 月 28 日，检索于 2026 年 8 月 29 日）

• Unite.AI，《Slack Code 把 AI 编程智能体放进专用项目频道》：https://www.unite.ai/slack-code-puts-ai-coding-agents-in-dedicated-project-channels/ （发布于 2026 年 8 月 20 日，检索于 2026 年 8 月 29 日）

• TechRepublic，《Slack Code：AI 编程智能体获得用于审查和监督的共享频道》：https://www.techrepublic.com/article/news-slack-code-ai-coding-agents/ （发布于 2026 年 8 月 21 日，检索于 2026 年 8 月 29 日）

• Reworked，《Slack Code 把 AI 编程智能体带进共享频道》：https://www.reworked.co/collaboration-productivity/slack-code-brings-collaborative-ai-coding-into-channels/ （发布于 2026 年 8 月 20 日，检索于 2026 年 8 月 29 日）