Slack Code

原文 ↗ Hacker News 讨论 ↗

Slack 新推出的“Slack Code”功能旨在把聊天应用变成一个协作中心，让团队能够在频道内直接与 AI 辅助的软件开发代理协作。评论者意见分化：一些人认为，随着工作、项目跟踪和 AI 代理在 Slack 中汇合，这是不可避免的一步，或许能让非工程师也能原型开发并交付小改动。另一些人则批评它充满营销话术、SaaS 臃肿，质疑其相较传统 IDE 和 Git 工作流的真实易用性，并对又一个“代理式编码中心”感到疲惫，担心它会让定价更复杂，却没有解决开发者的核心需求。

总体反应

  • 许多人并不买账；不少人原本期待的是一些简单改进，比如原生语法高亮代码块或更好的工作流，而不是完整的“在 Slack 里写代码”体验。
  • 有些人认为这是顺理成章的一步：Slack 想成为工作的中心场所，包括 AI 代理和编程，尤其是在企业场景中。
  • 另一些人则把它看作“又一个编程代理”，更偏营销包装，而不是实质上的新东西。

感知价值与使用场景

  • 支持者认为它可以：
    • 让产品/运营/PM 在不等待工程师的情况下进行原型尝试或问题分流。
    • 将代码讨论、diff 和代理活动带到团队已经在使用的同一个地方。
    • 自然适配 Salesforce/Slack 的组织元数据以及 Slack 里已经存在的其他工具。
  • 怀疑者则认为，真正严肃的工作仍然属于 IDE/GitHub，觉得 Slack 更适合沟通，而不是作为主要开发环境。

AI 编程与工作流趋势

  • 多条评论描述了这样的工作流：AI 生成大部分代码、测试，甚至审查工作，而人类负责引导和批准。
  • 据说一些团队在代理式配置下交付速度快得多，客户也接受工程师并不完全理解每个实现细节。
  • 还有人仍然偏好“打开编辑器、输入、运行 make”，觉得自己被不断变化的工具折腾得很疲惫，但忽略这些工具也并没有明显吃亏。

关于代码质量和可靠性的担忧

  • 一派表示“没问题”：bug 水平和以前差不多，只是交付更快了。
  • 另一派担心：
    • LLM 会制造越来越纠缠、越来越难以推理的代码库。
    • 工程师可能会依赖 LLM 来理解自己的系统。
    • 长期成本和访问限制（token 预算、供应商控制）可能会与技能退化发生冲突。

工具与 SaaS 疲劳

  • 有几位表达了对重叠 AI 产品的“生态疲劳”（Slack Code、Buzz、Claude Code、IDE 代理、Jira/Atlassian 工具、Teams/GitHub）。
  • 对 SaaS 定价和加价销售策略的批评很强烈，同时也希望 AI 加上开源能让自托管替代方案更可行。

UI 和功能愿望 / 不清楚之处

  • 有些人只想要：
    • 更好的语法高亮代码块（目前在 UI 中还不容易获得）。
    • 更少痛苦的 Slack 工作流（例如分支/重新汇合路径）。
    • 简单的代理能力，比如读取/编辑消息和画布。
  • Slack Code 实际上如何连接到 GitHub/基础设施被认为并不清楚；有人怀疑它更多只是为现有的云托管代理做前端，而不是提供深层的新能力。