Slack Code 把审批搬进了频道——但你仍然要指定一个人来批

发布了什么

Slack Code 把一项 AI 编码任务变成一个专属频道。你 @ 一个智能体，工作在众目睽睽之下进行，频道为它保留四个视图。

把商业条款和架构放在一起读，策略就清楚了。Slack 不是在跟 Claude Code 或 Devin 竞争；它站在这五家的下游，占住了它们要抵达一个团队都必须经过的那个位置。生成的利润仍归智能体厂商。而"工作在此变成团队的工作"的那个界面，归 Slack。

瓶颈确实挪到了复核

任何大批量跑过编码智能体的人都见过这一幕。一个每天开十二个 PR 的智能体，如果团队只合得进四个，就什么也没增加；把智能体从编辑器里拆出来并不创造吞吐——它只是把队列搬到了人这边，这正是后台编码智能体整篇的论点。生成在 2025 年的某个时刻就不再是约束了。验证从来都是。

所以一个全部价值主张就是"复核在这里发生"的产品，瞄准的问题是对的，而那四个标签页是对这个问题的一次像样的分解。每个标签页都是一件不同的产物，复核成本天差地别，而这个差别是整份公告里最有用的东西：

• 计划是便宜的闸门。两分钟的阅读就能抓住"找错了文件、用错了路子、划错了范围"，此时一行代码都还不存在。这是任何智能体产品能提供的杠杆率最高的检查点，也是大多数团队跳过的那一个。
• 预览是一个便宜的判据，但只对一小类工作成立。如果改动是看得见的，那么"看"胜过"读"。如果改动是一处权限校验或一次数据库迁移，预览就只是装饰。
• diff 是昂贵的闸门，而且它的成本增长是超线性的。复核的工作量不随行数增长，而随"读者必须同时装在脑子里的相互作用数量"增长。橡皮图章正是从这里开始的，而频道让它更容易发生。

一个把计划页放在显眼位置的产品，无论有意无意，都是在帮你的忙。批准一份计划是一次真实的决定。在下午五点、一个还有另外十一个人的频道里批准一个六百行的 diff，是一种仪式。

十二个人都看得见的批准，等于谁都不必去批

下面这部分，任何一篇报道里都没有。把审批从终端搬进频道，改变的是它的社会结构，而且方向和公告暗示的相反。

在终端里，那个审批提示只发给一个人，而这个人同时也是写下需求、掌握意图、并且三周后会被追问的那个人。身份、上下文与问责在构造上就是同一个人。这不是什么设计成就——它是界面的一个副产品——但它值一大笔钱，而它正是共享频道最先让出的东西。

这种失效模式在软件之外早有名字。当一项请求发给一群人而不是某个人时，每个成员采取行动的概率都会下降，而且群体越大效应越强——人人都假定有更合适的人会去处理。编码频道还加上了更难缠的一层：批准是一种主动承担风险的行为，于是激励的坡度恰恰把懂这段代码、看得出哪里会出事的人推开。真正去点"批准"的，会不成比例地是那个觉得这个 diff 看着没问题的人——而一个 diff 看着没问题的程度，与你对周边系统了解得有多少成反比。

由此得出两件事，都不算新奇：

• 在运行开始前指定审批人，而不是等 diff 落地之后。一个人，写在频道主题里或开场那条消息里，对应这一件工作。这不花任何成本，却把终端白送的那个性质买了回来。问责与归属讲清了具名角色为何必须事先存在才有意义。
• 让围观者当复核者，而不是审批者。频道里的其他人确实有价值——评论、抓漏、指定审批人缺的那块上下文——而这份价值完全不需要给十一个人一个按钮就能保住。可见性是特性。权限的弥散是一个你可以拒绝的副作用。

这个问题的一般形态，包括多人同时对同一个智能体说话时会发生什么，在共享与多用户智能体里；如何做一个真能拦住东西的闸门，在审批与确认交互设计里。

你顺手还造了一份审计轨迹——放在一个按聊天保留策略清理的系统里

一个 Slack Code 频道会攒下多数工程组织想要多年却从未拥有的东西：改动的缘由就贴在改动旁边。Git 记录 diff 与提交信息。它不记录提出需求的人的原话、智能体提出的那份计划、某人在串里提出的反对意见，也不记录审批人读的是预览而不是 diff。这一切现在都在一个频道里。

这是一份真实的治理收益，而它带着两处值得先修好的缺陷：

• 保留期。这些频道受你工作区的消息保留策略支配，而那条策略是管理员在想着"聊天"而不是"变更记录"时配的——在某些套餐下，更早的历史干脆够不着。如果一次生产改动的理由只存在于那里，你的审计轨迹的寿命就由一个与它无关的决定定下了。请像给变更记录设保留期那样，给编码频道设保留期——见保留期与法律保全。
• 位置。"谁批准了什么"这份记录，应当能从提交出发够得到，而不是只能靠在另一个产品里搜索。由集成写入的一条从 PR 指向频道的链接，是一行修复，把两半接了起来。

正方立论

把这件事读成"给终端工作流刷一层聊天漆"很容易，而这种读法太廉价了。这里有三样东西确实比大多数团队现在的做法更好。

第一，工作对那些本来永远不会打开终端的人变得可读。一个能看到实时预览、然后说"这不是我们设计的空状态"的设计师，是在唯一便宜的时刻抓住了一个缺陷。第二，智能体这一层被当作复数对待：五家厂商在同一个界面里、按任务挑选，比任何单一厂商的控制台都更接近团队真实的工作方式——而且智能体单独定价，对"价值到底在哪儿"是诚实的。第三，带徒弟。私下在终端里做完的智能体工作谁也教不到；一个初级工程师读一位资深同事的计划页，学到的正是这份工作里最难教的那部分。

这些都没有被审批问题抵消。它只是意味着，审批问题值得花十分钟定条规矩，而不是耸耸肩。

该做什么

如果你下周就要打开它

在第一次运行之前写下三行频道约定：每件工作在开头就指定一名审批人；在允许智能体动手写代码之前，由这个人复核计划页；频道保留期按你的变更记录保留期设置，而不是按聊天默认值。这就是全部规程，它把大部分弥散风险转成了一条人们不用动脑就能遵守的规则。

如果你已经在大批量跑编码智能体

去量这个产品瞄准的那件事。"无需人工编辑即合并的比例"与"从提出到决定的时间"能告诉你复核队列是否真的在清空；"开了多少个 PR"什么也告诉不了你。如果采用了共享复核界面之后这两个数字没有改善，那你增加的是观众而不是产能——而解法在上游，在让每次运行能自我验证，见后台编码智能体。

如果你自己在做智能体产品

留意 Slack 认定值得占住的是什么。不是模型，不是循环，不是工具：是人做决定的那个界面。复核成本才是你的界面真正在优化的指标——为复核而设计把这个论证讲透了——而真正重要的设计问题只有两个：你把哪件产物摆到审批人面前，以及审批人是一个人还是一群观众。

延伸阅读

本站：

• 后台编码智能体——脱离编辑器为何把瓶颈搬到了复核端。
• 审批与确认交互设计——如何设计一个真能拦住东西的闸门。
• 共享与多用户智能体——多个人共用一个智能体时会变什么。
• 智能体的交互设计：为复核而设计——复核成本才是界面真正优化的指标。
• 人在回路——检查点该放在哪，以及橡皮图章的陷阱。
• Claude Code vs Codex CLI vs Antigravity CLI vs OpenCode——这个界面之下的那些终端智能体。

来源：

• SiliconANGLE — Salesforce introduces Slack Code to bring agentic team coding into the open
• Computerworld — New 'Slack Code' turns AI coding into a team activity
• TNW — Slack launches Slack Code, where teams and AI agents build together
• Salesforce Ben — Salesforce brings vibe-coding to Slack with new Slack Code