热门产品

Liminal

Liminal

Liminal 是一个 AI 智能体工作空间,支持本地书写 Markdown 和 HTML 文件并实时渲染为 UI,帮助团队高效协作和共享文档。

热门评论

PH 用户
Hey Product Hunt 👋

我是Justin,Liminal的创建者,超级兴奋终于能分享我正在做的东西了!

先说明一下:这是初版。我现在发布是想看看我感受到的那些摩擦是不是别人也有。如果遇到任何bug或问题请告诉我,我会尽快修复!

简单背景故事

去年夏天,我的工作方式变了。智能体变得足够好,成了我干活的地方。Claude Code成了我的主要界面,所有工作流都流经这个智能层。我的工作从写作和执行变成了指挥一个智能体来完成。

Notion和Google Docs不是为此而生的。它们把智能体硬塞进应用里,但那不是我智能体所在的地方,而且它们的MCP又慢又贵。Claude Code用本地的markdown文件工作得更好更快——这是智能体已经会说的格式。所以我不再用Notion和Google Docs写东西了,完全转向本地markdown。

我一直在VS Code里做这些,因为那是我写代码的地方。但在那里面查看和编辑markdown很笨拙。你得用预览模式来看渲染效果,然后跳到原始侧去实际编辑。所以我在本地文件之上建了一个所见即所得编辑器。

然后我想分享点什么。没人愿意收到原始的markdown文件,Google Drive渲染得也不好。来回传文件彻底扼杀了协作的可能性。所以我在本地文件之上构建了实时协作:一个轻量级CLI监视你的工作区文件夹,并与云端双向同步。分享一个链接,你的队友就能在浏览器里打开同一个实时工作区。他们的编辑会立刻写回到你的磁盘上。

一旦这个跑通了,我原先没设计到的东西就出现了。我的智能体和队友们的智能体都在读写同一个工作区。Liminal悄然变成了一个共享的第二大脑。随着团队工作而不断更新和积累的公司知识,以明文文件的形式存放在每个智能体的本地磁盘上,它们可以直接访问。

Liminal是什么

一个面向人类、智能体和团队的协作工作空间。你的AI原生第二大脑。带上你自己的智能体。拥有你自己的文件。

它怎么工作:

🟢 与你的智能体一起工作,而不仅仅是透过它。你的智能体以markdown或HTML将文件写入磁盘。Liminal在它们保存的瞬间将其渲染成干净的UI。在浏览器中自然查看和编辑,无需与原始markdown较劲。

🟢 即时分享,没有摩擦。一个轻量级CLI实时将你的工作区同步到云端。发送链接,你的队友就进入同一个实时工作区。不用在Slack上发markdown,不用自己托管HTML,不用等Google Drive。

🟢 团队每个智能体的共享第二大脑。文件存在于本地,所以每个智能体都能直接访问团队写过、决定过、学到的一切。无需外部调用,没有延迟,不会在会话之间丢失上下文。

🟢 没有中间商,没有MCP税。直接文件访问意味着没有MCP往返,没有专有格式,没有浪费的token。上下文廉价、快速、始终新鲜。

我的请求

非常希望得到你的反馈,尤其是如果你整天用Claude Code、Codex或其他智能体:这符合你的体验吗,还是说我只是在解决我自己一个人的问题?

Justin
PH 用户
「所有拥有链接的人都能看到同一个实时工作区」这部分,是我在真正用于团队工作之前想搞清楚的——当智能体开始往共享空间写入文件时,它有时会写入只该给某个人看的内容(比如一份草稿绩效备注、客户的粗略数字等等)。有没有按文件或按文件夹的权限层?还是说模型仍然是「有链接的人能看到一切」,就像你把文件夹交给别人时底层的markdown文件一样?
PH 用户
每个人都在为个人构建第二大脑。几乎没人做过一个面向创始人加上他的智能体加上他的人共享同一个上下文的方案。这才是更难也更有趣的问题。祝发布顺利。
PH 用户
你不是在解决只有你遇到的问题。我正好用这个架构跑了几个月——一堆markdown文件,多台机器上的多个智能体读写,通过git同步,因为没有更好的办法。它悄然成了我技术栈中最承重的东西,所以摩擦是真实的,回报也是真实的。

一些在实际使用中形成的惯例,作为免费的产品意见,因为你说Liminal还没有这些:

按写入者追加只写的文件——每台机器和每个智能体都有自己的每日日志——这让冲突在结构上变得罕见,而不是事后解决。共享文件成了例外,而这些例外才值得用merge UI来处理。

一个始终加载的小索引,并严格遵守一条规则:细节放在别处。当文件到500个时,索引就是搜索:智能体grep索引,而不是整个语料库。Omri的问题才是决定这东西能否扩展的关键。

一个权威的当前状态文件,当它与旧笔记不一致时以它为准。Abdullah提出的过时问题最严重——我的原则是:笔记记录的是写的时候真实的情况,任何可操作的事情都要在智能体执行前重新验证。一个当笔记指向的东西消失时自动标记或过期条目的工具,将是这个类别中第一个真正的新功能。

另外,合并采用后写覆盖是正确的选择——这周我的两个智能体以不同的commit写了相同的知识,这让我学到:多写入者的第二大脑需要处处都有合并语义,而不仅仅是编辑器。发布得好。这个产品瞄准了一个真实存在的缺口。
PH 用户
这是一个发布,其背景故事正好与我的工作流程完全吻合——我之前也陷入了同样的VS Code预览然后原始编辑的循环,最后放弃并直接住在Claude Code里,用一个文件夹放笔记。我最好奇的部分不是同步,而是扩展性:当一个团队的第二大脑经过几个月的工作增长到几百个文件时,你实际上怎么找到正确的那个?文件夹中的纯markdown在20个文件时很好用,但到了500个就会变成一种杂乱——上层有真正的搜索/结构吗?还是仍然主要依赖智能体知道去哪里找?
PH 用户
很喜欢这个定位。

目前哪些类型的团队从中受益最多?
热门产品Justin Lam2026-07-28原文

相关内容