一个 Pre-IPO 投资平台如何在不扩运营团队的情况下扩展客户支持

关于 Jarsy

Jarsy 是一个代币化的 Pre-IPO 股权投资平台，让普通投资者也能买到 SpaceX、Anthropic、Stripe 这些公司的股份，最低 10 美元起投。平台在 Discord 和 Telegram 上运营，服务数千名活跃用户。

他们遇到了什么问题

Jarsy 横跨 fintech、crypto 和私募股权三个领域，用户支持的复杂度远超一般 SaaS。

每天 100 多个问题涌进来。代币化机制、手续费结构、IPO 锁定期、储备证明——小团队根本接不住。

所有人都在灭火。每多花一小时处理用户问题，就少一小时做社区运营和用户激活。团队知道该做什么，但腾不出手。

产品更新的速度比文档快。新功能、价格调整、政策变动不断，一个月前写的答案可能已经过时了。知识库永远追不上产品。

招人也不现实。产品太复杂，新人要花很长时间才能准确回答问题。再加上产品变化快，“招到人”和”能放心用”之间的差距越来越大。

Lucius 怎么解决的

Jarsy 把 Lucius 部署到 Discord 和 Telegram 上，负责日常用户支持。同时通过 Slack 和一名人类团队成员协作。

Lucius 接管了一线支持，全天候在两个平台上回答用户问题。

人类队友不需要盯着每一条消息。Lucius 遇到没把握的问题时，会先自然地回复用户，同时把问题标记出来给人工审核。人工确认或纠正后，Lucius 下次就知道了。

Lucius 不靠静态 FAQ 工作。它从文档、历史对话、实时交互和管理员输入中学习。产品变了，它的知识也跟着变。

核心痛点：知识冲突检测

知识库最怕的不是重复——重复最多浪费存储。真正危险的是：有一条旧的是错的，你不知道。

每条新知识进来，系统会做四件事：

维度	问什么	决策
内容重叠	新旧说的是不是同一件事？	高度重复 → 跳过
信息增量	新的比旧的多了什么？	有增量 → 考虑更新
信息冲突	新旧之间有没有矛盾？	判断谁对，替换旧的
场景差异	是不是不同场景？	不同场景 → 都留

第三个——信息冲突——是最难也最重要的。

怎么做的：先用 embedding 快速筛出候选知识条目，再用 LLM 做语义级对比。候选多的时候智能分批，控制单次 context 长度。旧知识不会被删除，而是标记为 archived 并记录谁替代了它，像 Git history 一样可以回溯。

举个例子：有用户问 SpaceX Live 和 Presale 的区别，两个客服答了不同版本，都被抽成知识入库。系统检测到冲突，判断后者更准，自动替换。之后再有人问，给的就是那条更准的。没人手动干预。

效果

两个平台全天候有人回。用户几分钟内就能得到回复，不受时区限制。

团队从灭火模式里解放出来了。日常问题交给 Lucius 后，人可以去做社区运营、活动策划这些一直想做但没时间做的事。

知识不用手动维护了。旧知识和新信息矛盾时，Lucius 会提醒团队。以前这是纯手动活，现在是自动的。

最后算下来：一个 AI 加一个人，干了一整个客服团队的活。Jarsy 不需要额外招人，回复质量反而更稳定。

客户评价

“Lucius 持续学习，并且会主动提醒我们旧知识和新信息之间的冲突。它帮我们发现哪些内容过时了，这是我们之前很难做到的。” — Jarsy 团队