PromptQL

我是 Tanmai，PromptQL 的 CEO 兼联合创始人，很高兴能把全球首个 AI 原生工作空间介绍给你。感谢 @kevin 今天为我们做推荐！

PromptQL 背后的团队是 Hasura，我们完全是意外做出 PromptQL 的。

故事是这样的：我们想造一个能准确处理数据和工具的 AI，发现随着 AI 变强，好的上下文成了瓶颈，又发现团队里没有一个人掌握所有必需的上下文，于是我们造了多人 AI（共享线程），让大家能在同一个 AI 线程里协作，自动捕获上下文。2026 年 2 月，我们让全公司 70 人从 Slack 迁到桌面和移动端来“测试多人体验”。事情变得诡异起来——一个共享 AI 连接了所有人所有事，导致全队出现 AI 集体幻觉。我们意识到，自己造了个 AI 时代的 Slack。

现在，我们不再发私信或开会，因为 AI 都知道。

当我问“Alex 在做什么？”，它能看到 Alex 在工作空间以及 Slack、GitHub 等其他工具里的工作（当然是对我可见的部分），然后告诉我 Alex 在忙什么、卡在哪里、我能怎么帮他。我不去打扰 Alex，也能得到准确的状态报告，不需要开会。

更进一步，我还能做自己本来不会的事：当我问“帮我为客户搭这个集成”，它会调用其他之前做过并审核过集成的工程师的技能和上下文。即使我们没有显式维护一个共享技能库，我瞬间就能拥有整个团队的能力，而不仅仅是个人能力。

PromptQL 是第一个智能体工作空间，因为整个应用就是一个 AI：

当用户互相聊天时，PromptQL 会动态构建任务型智能体。它连接到数据库、SaaS 工具和内部 API，边用边学技能。

其他 AI Slack 克隆（包括 Slack 本身）只允许人类和智能体互相聊天，但那些智能体需要专门搭建并加入工作空间。我们认为这不过是通往 AGI 路上的一个小里程碑——在 AGI 时代，AI 会替你搭建智能体，并配上合适的安全和上下文护栏。

我们认为 Slack 这样的工具阻碍了团队做最重要的工作。我们需要构建共享上下文，然后借助 AI 并行处理上百个任务。我们需要以人类负责上下文、智能体负责执行的方式来协作。

专为 ProductHunt 社区，如果你和团队想试试 PromptQL，我们赠送 1000 美元 token！

感兴趣的话请在下面留言，告诉我们你的团队情况。我们会为你的团队做一个快速的 15 分钟定制入门，然后解锁这些积分——它们可以在我们所有可用模型（从 Fable 到 Sol 到 Kimi-K3）上使用。

你也可以自己注册，解锁免费积分先玩一玩。

PromptQL 已经是我们 AI 栈中一个了不起的补充。它把团队所有上下文都存到一个地方——包括各种工作流（研究、待办列表、营销、财务、工作流中的决策）。随着工作迁移到 PromptQL，我们对 Slack 的使用量每天都在减少（仍然用它来通知和闲聊）。我最喜欢的是跨模型功能——我几乎能在最新模型发布当天就用上它们，看看它们在我们的工作流上表现如何。

几个功能请求：
- 一个专门存放重复工作流的区域
- 更简单的管理员功能，包括追踪用量、花费、权限等
- 能直接在画布中编辑表格和工件
- 外部团队连接（类似 Slack Connect）

继续加油！

我在 PromptQL 工作，所以显然有偏倚，但我确实这么天天用。

任何泡在 Slack 里的人都懂那种 FOMO：十个频道同时在聊有趣的事，你不可能全看到。解决这个问题通常需要花工程时间搭个东西并维护，但在这里，这就是默认功能。任何有趣或相关的内容会自动找到你，完整上下文触手可及。你只需开一个线程，让 PromptQL 去找可能有趣的东西（当然要自己定义“有趣”），它就会安静地干活，持续给你更新。

它在工作之外也好用。我用它追踪一个新闻故事是怎么真正展开的，而不是从信息流里看到被回音壁过滤过的版本。

但我最喜欢的是现在的产品构建方式。一个线程，学习过程本身就变成了 RFC。你、队友、利益相关者和 AI 在一个地方推敲出所有东西：UX、后端约束、成本、实际实现。一个线程，一个功能的完整生命周期。我亲身经历过反复回答相同问题、解释几个月前的决策、翻老线程还原上下文的痛苦。现在，功能本身就可以被 AI 问答，因为它看着整个过程发生。对功能构建者来说，还有什么比不用解答每个“怎么/为什么”的问题、只在真正需要时被拽进来更爽的呢？

就连上线的无聊部分（监控采用率、抓问题）也变容易了。接上 PostHog 和 Grafana，它就默默接手运营角色，你只需要在需要时审批就行。

纠正/锁定机制能处理事实错误，但真正的分歧呢——两个资深员工对某件事该怎么做有着不同但同样合理的判断。共享线程是把这种分歧作为可见的张力（两种观点，两个名字都附上）呈现出来，还是最终平铺成最先被认可的那个答案，让后来读的人看不见另一个人的实际立场？

这种“共享脑更新，上下文不断累积”的框架跟其他团队 AI 工具有所不同。我很好奇一件事——当纠正和反馈回流到上下文中时，你们怎么防止权威性的纠正过度压过系统中已有的领域专长？比如，如果有人在讨论中途纠正了一个细微差别，它需要同行评审才能锁定，还是说过时的共享上下文带来的代价比错误但快速的更新更高？

祝贺发布！我很喜欢这个核心主张：人类掌握上下文，智能体执行工作。

但Slack目前已经成为肌肉记忆了。你觉得这会如何发展？完全迁移是目标吗？还是说真正的胜利在于团队上下文变得可查询，智能体基于它行动，而聊天只是它的载体？假设我们团队的内容分散在Notion、Google Drive、Jira和Slack里。第一周会是什么样？我们是完全搬过去，还是PromptQL从这些工具读取内容，我们慢慢过渡？