Slack Code 详解：AI 编码不再是开发者的“私人对话”

与普通聊天记录相比，Slack Code 试图把更多开发信息直接放进频道。具体能力取决于代理集成，但成员通常可以在对话、代理计划、代码差异和输出结果的实时预览之间切换。

这样一来，团队看到的不只是“代理说了什么”，还包括它准备如何处理任务、实际改动了哪些代码，以及最终产出了什么。

产品经理和设计师也能进入开发闭环

Slack Code 的另一大卖点，是让产品经理和设计师无需直接进入开发者终端，也能参与软件构建过程。他们可以在共享频道中描述用户问题、补充产品背景、查看可见的结果，并提出修改意见；工程师则负责技术评估和具体实现。

例如，产品经理可以在 Slack 中报告一个漏洞并说明预期行为。编码代理随后调查问题、提出修复方案，工程师再检查生成的代码差异，判断改动是否适合当前代码库。团队之后可以决定是否继续创建或推进拉取请求（pull request），或者再进行一轮修改。

这并不意味着 AI 代理会成为最终决策者。Slack Code 改变的是协作发生的位置，让代理的工作更容易被更多相关人员看到、质疑和检查。

人工审批仍是关键环节

Slack Code 的定位更接近“可见性与协作层”，而不是允许未经审查的代码自动上线。团队可以针对可能产生重大影响的操作设置人工审批，包括可能进入生产环境的代码变更。

这一点尤其重要：代理或许能生成看起来合理的修复方案，却未必充分理解业务要求、安全限制或线上运行风险。共享频道为工程师及其他责任人提供了一个集中讨论的地方，他们可以质疑方案、要求返工，并在任务继续推进前留下明确的决策记录。

可搜索的历史记录与 Slack 管理能力

代码频道旨在保留代理工作背后的完整上下文。任务结束后，频道可以归档，但其中的对话和工作历史仍可搜索，从而形成一份记录：团队提出了什么要求，代理产出了什么内容，人类又如何审查和决定。

由于整个流程运行在 Slack 内，组织可以继续使用现有的 Slack 身份体系、权限、治理机制、安全设置和管理员控制，而不必为每一项编码代理任务另建一套协作基础设施。

实际意义在于，需求、讨论、技术审查、决策和代理活动能够继续留在任务最初发起的项目对话中，减少信息在不同工具之间来回丢失的情况。

发布时支持哪些代理？是否所有 Slack 用户都能用？

Salesforce 表示，Slack Code 在发布时覆盖 Slack 的各类套餐。首批合作代理来自 Anthropic、GitHub、Cognition 和 Vercel；Salesforce 和 Slack 也将 ChatGPT 列为可以参与其中的代理之一。

不过，不同代理的实际体验可能并不完全相同。计划展示、代码差异、实时预览和审批操作等功能，取决于具体代理提供的 Slack 集成能力。因此，“受支持”并不代表所有代理都具备完全相同的控制项。

Salesforce 想把 Slack 变成什么？

在 Dreamforce 上，Salesforce 将 Slack Code 描绘成一种让软件开发成为“团队运动”的方式，同时把 Slack 定位为多个 AI 代理提供商之间的协调层。它并没有要求团队采用单一的 Salesforce 编码模型，而是希望让来自不同厂商的代理进入同一个工作界面。

Salesforce 还表示，未来计划更广泛地开放底层 API，让组织能够创建自定义代理和共享频道，用于软件开发之外的工作，例如协调营销活动或审查法律文档。

需要注意的是，这些例子代表 Salesforce 描述的扩展方向，并不意味着所有非编码工作流在 Slack Code 发布时已经普遍可用。

结论：Slack Code 的区别不只是“能写代码”

Slack Code 的核心逻辑很直接：在对话中提及编码代理，为它创建一个项目专属频道，再让团队共同查看、引导、审查和审批工作。

它真正想解决的问题，不是 AI 能不能生成代码，而是 代码生成过程是否对团队透明。对于已经依赖 Slack 协作的团队来说，这种方式可能让产品和设计人员更容易跟进 AI 辅助开发，同时保留工程师的技术审查责任。

当然，最终效果仍取决于每个代理集成的成熟度，以及团队是否建立了清晰的审批标准。Slack Code 提供的是一种更公开、更可追踪的 AI 编程方式，而不是对人工判断的替代。