Show HN：Struct – 一个以信息流为中心的聊天平台

原文 ↗ Hacker News 讨论 ↗

一款新的以信息流为中心的聊天平台 Struct，试图通过让每次对话都成为线程，再以可自定义的信息流呈现，并辅以 AI 生成标题、摘要和搜索，来取代 Slack 和 Discord 这类传统按频道组织的工具。评论者对它在减少信息丢失和信息过载方面的潜力很感兴趣，尤其适用于长期项目和社区支持，但也提出了对 OpenAI 依赖、隐私与合规透明度、缺乏成熟集成和 API，以及再次形成信息孤岛的担忧。讨论还反映出人们对“AI 驱动”产品的普遍疲劳、对实时聊天与论坛式沟通的不同偏好，以及让组织从既有工具迁移出来的现实难题。

总体反响与概念

  • 许多人觉得“信息流 + 线程”的方式很有吸引力，尤其是在突出重要对话、减少 Slack/Discord 的混乱方面。
  • 也有人觉得统一的“All Threads”信息流会让人不堪重负，更喜欢按频道分隔。
  • 不少人指出，它更像论坛/Discourse/Zulip，或者“带实时聊天的留言板”，而不是经典的 IRC 风格聊天。

线程、信息流与 UX 设计

  • Struct 主要把频道当作权限组；对话则以线程形式存在于信息流中。
  • 自定义信息流（按标签、人物、频道）被认为很强大；批评者担心分心，以及失去清晰“房间”概念。
  • 一些用户觉得界面缺少人情味和在场感；有人建议更多展示头像/在线状态。
  • 与 Zulip 的比较：有人认为 Zulip 早就有“全部消息”/收件箱视图，但 Struct 团队强调的是一种不同的、以信息流优先的实时设计。

AI 功能与担忧

  • 积极评价：摘要和自动线程标题被广泛认为是很强、很实用的 AI 用例；对多年聊天历史做 AI 搜索也很有吸引力。
  • 负面评价：不少人对“AI”营销感到疲劳，担心不可靠和幻觉，也不喜欢依赖 OpenAI。
  • 用于跨过去线程问答的 AI 机器人是可选的；核心差异化被定位为信息流/线程，而不是 AI 本身。

隐私、安全与合规

  • 一开始在“Privacy”文案上出现的复制错误引发了怀疑；后来确认这是 CMS 失误并已修正。
  • 有人提出数据会发送到 OpenAI、无法自托管、法律实体信息不清晰，以及对 GDPR/SOC2 的期望。
  • 团队表示 OpenAI 的商业条款禁止使用客户数据训练，并且计划提供 SOC2 以及更好的透明度。

集成、迁移与生态

  • 大家对 Slack 集成非常感兴趣，这既是迁移路径，也可作为“Slack 的 Superhuman”客户端；它已经在同步线程，支持部分历史导入，并计划提供导出工具。
  • Discord 集成已经存在，但目前只索引线程，不索引频道聊天；Slack 的频道聊天会自动线程化。
  • 还有人请求 Teams、Matrix 以及更广泛的插件/API 生态；Teams 集成被考虑过，但被认为是个艰难市场。
  • 很多人强调，离开 Slack 的关键在于深度的应用/机器人集成。

定价与商业模式

  • 定价按组织计费，包含基础费用和按使用量计费的 AI token 费用；一些人称赞这种透明度，并认为它比 Slack 更便宜。
  • 也有人要求更清晰的表格、具体使用示例，以及明确的每月上限，以避免意外账单。
  • 围绕 SSO 是否应作为通用 SaaS 定价中的“高级”功能展开了讨论；有人认为 SSO 应该是默认配置，也有人认为它作为高阶套餐功能是合理的。

技术实现与可靠性

  • 分享的技术栈包括：Go、Postgres、OpenAI 加 Microsoft embeddings、Typesense、React/Next.js、Hetzner 托管，以及 Tauri 桌面应用。
  • 有人报告 OpenAI 超时以及 Windows 安装程序/重定向问题；团队承诺改进错误处理和签名。

关于沟通的更广泛反思

  • 有人质疑，优化更好的工具是否真的是正确方向，还是说减少沟通/会议本身才更重要。
  • 也有人认为实时聊天和 O(N²) 的团队沟通会一直存在，因此结构化与检索比单纯减少沟通更重要。