这意味着开发者不必先让代理在幕后完成全部工作,再把一个最终的拉取请求(pull request)交给其他人审阅。团队成员可以在过程中介入、纠偏和补充上下文。
Slack设想的治理方式仍然由人承担最终责任:团队可以要求人工批准或签字确认后,才能将代码合并到生产环境。不过,现有材料没有独立说明这一合并闸门的具体配置方式,因此其精确实现细节仍缺乏充分证据。
Slack希望把编码变成整个产品团队都能参与的公开协作流程,而不再只是某位开发者和一个AI代理之间的私下对话。产品经理可以跟进需求是否被正确理解,设计师可以查看页面或界面预览,其他非工程成员也能围绕结果直接评论。
Slack的说法是,要把软件开发带出“私人标签页”,让人类和代理在同一个公开工作空间里共同编写、审查并交付代码。 对团队而言,频道因此不仅是消息窗口,也成为协调任务、保留背景信息和推动审批的工作界面。
Slack公布的示例流程可以概括为:先在团队对话中发现一个漏洞,或提出新功能、网页改动需求;随后@一个编码代理,例如Claude Tag或ChatGPT;代理创建对应的Code频道并开始工作;团队再在频道中查看对话、代码差异和实时预览,提出修改意见,最后审批结果。
首发合作集成包括:
不过,现有证据没有给出具体的数据保留期限、导出机制或审计日志规格,因此不能进一步断言Slack Code具备哪些精确的合规或审计功能。
Slack Code的定位是利用现有Slack工作区的管理和安全环境,而不是另建一个独立的协作产品。但目前材料不足以核实究竟有哪些权限、安全控制或合规层级会被继承,企业在实际部署前仍需查看官方配置说明。
Salesforce首席执行官Marc Benioff在发布信息中写道:“不要独自编程。Slack Code已经上线。人类和代理,同一个频道,同一项工作。”他还表示,这次与Anthropic、GitHub、Cognition和Vercel代理的合作是“真正的多人协作编程”。
如果未来开放更多Slack API,代理理论上可以在共享频道中协调编程之外的任务,例如营销活动或法律文件审阅。但目前提供的证据并未确认Slack已经承诺相关API路线图、发布时间或具体产品范围,因此这些只能视为一种可能的延伸方向,而不是已公布的功能计划。
从现有发布内容看,Slack Code最明确的价值在于“让代理工作可见”:AI不再只把代码结果交给一名开发者,而是在团队能够共同理解和把关的地方推进任务。