Lucius获数百万美元天使轮融资 专注打造企业级Context Layer

近日，AI初创公司Lucius（luciusai.com）宣布完成数百万美元天使轮融资。本轮融资由明势创投领投，蓝狮资本担任独家财务顾问。

资金将主要用于产品研发、AI Teammate工作流能力建设、全球市场拓展及团队扩充。目前，Lucius已服务超过30家客户，覆盖超过3000个社区与工作频道，并接入了Discord、官网Live Chat、Telegram、飞书、Slack等多个主流协作平台。

这家公司瞄准了一个许多团队都感同身受、却鲜有产品系统解决的痛点：为什么同一个问题的解释，每天都要在不同的群聊、客户和团队之间重复无数遍？

01 问题被回答了，判断却没有留下来

想象一个典型的社区场景：有用户问，“Pro套餐支持团队成员共享额度吗？”一个成熟的运营人员绝不会只回答“支持”或“不支持”。他需要快速判断：这位用户是否有企业采购的意向？这个功能是否已经上线？能否给出明确的时间线承诺？是否需要销售同事立即介入？

这绝非个别团队的烦恼。定价策略在社区里解释了一遍，到了销售一对一沟通时又得从头确认；一个Bug的修复时间被反复追问，工程师不得不一次次补充版本背景；某个功能能否对客户承诺，也得综合考量用户类型、当前排期和后续对接人。

表面上看，这只是在回复消息。但实际上，每一次回复都是一次复杂的判断：哪些信息可以透露，透露到什么程度；什么时候必须交由人工处理；哪些提问背后已经隐藏着购买意图。

麻烦在于，如果这次判断没有被系统性地记录下来，那么当下一个类似问题出现时，整个团队不得不重新走一遍完整的决策流程。更棘手的是，新问题很少会原封不动地重现。用户换个说法、换个提问的频道、或者带着完全不同的上下文背景，之前那个孤立的判断就很难被准确调用。

重复性问题通常被简单归为客服负担，但从组织效率的视角深究，它暴露的其实是一种“记忆缺失”：公司没有记住自己已经做过的判断。

02 创始人视角：六年技术民主化，每次都卡在同一个地方

Lucius的创始人赵赫是一位连续创业者。在创立Lucius之前，他花了六年时间深耕“技术民主化”领域，从无代码开发平台Zion（拥有40万注册用户、700万元年营收），到出海产品Momen.app，再到AI基础设施ZAI。

“每次创业都卡在同一个地方，”赵赫坦言，“用户的业务知识都在他们自己脑子里，进不了系统。我们做无代码时，就发现用户连文档都不愿意写；做AI工具时，又发现客户不愿意花时间配置和维护知识库。最终能真正用好这些平台的人，凤毛麟角。”

这段经历让他得出了一个关键结论：别再试图教用户如何使用复杂的工具，不如让AI直接“住”进他们的业务流程里，从工作中学习。

“Lucius是我第一次不再仅仅提供工具，而是直接为客户的结果负责。这位‘AI员工’不需要用户撰写文档，也不需要预先配置复杂流程。它就像一个新同事，在岗位上跟着真人边看边学，教一次，就会了。”

03 Lucius的机制：从Answer到Context的循环

Lucius与普通RAG问答机器人的核心区别，可以用一句话概括：RAG机器人负责回答问题，而Lucius负责记住判断。

当Lucius第一次遇到未知问题时，它不会贸然生成一个可能不准确的答案，而是会将问题转化为一个明确的任务，转交给相应的人类团队处理。团队给出答复后，Lucius所做的不仅仅是记录下回复内容。它会同时记录下这次回复所适用的具体场景、不能外推的边界条件、是否需要转交给销售或产品部门，以及后续的建议动作。

所有这些信息，都会沉淀到Lucius所构建的“组织上下文层”（Organization Context Layer）中。这不仅仅是一个静态的知识库，而是一个包含了具体语境、判断边界和行动指令的“组织记忆系统”。当类似问题再次出现时，Lucius会先匹配问题类型、适用条件和风险边界，再决定是直接调用记忆回答，还是继续转交人工。如果情况有变，它会主动寻求人工介入，避免旧答案被盲目套用。

这个循环的精妙之处在于，团队无需在回答问题后，再额外花时间整理文档。每一次“回答”行为本身，就成了一次“组织记忆”的生产。知识维护，变成了工作自然发生的一部分。

04 验证场景：两个案例，同一个模式

Dubbing AI是一家面向全球创作者的AI配音工具公司，其Discord社区拥有超过3万名成员。在接入Lucius之前，仅由3人组成的社区团队需要长期处理新手上路、定价与用量限制、生成失败、功能请求、账号问题等各类咨询，重复性解释几乎占据了他们的大部分工作时间。

接入Lucius后，按覆盖的问题范围统计，社区问题的自动解决率在一个月内从29%提升至88%，团队每月节省了超过100小时的重复回答时间。这些被释放出来的精力，得以转向处理更复杂的问题、深入分析用户洞察以及策划增长活动。

如果Lucius只是简单地将FAQ导入Discord，自解决率很难在一个月内实现如此跃升。真正的变化发生在第一次人工介入之后：团队所确认的答案、适用条件和转人工规则，被系统捕捉并应用于下一次相似的问题中。

如果说Dubbing AI的案例证明了Lucius在减少外部社区重复问答上的能力，那么赵赫之前创办的Momen.app的案例，则揭示了另一层价值：当社区对话被持续记录和结构化后，它能转化为产品团队决策的关键输入。

Momen.app作为一个低代码开发平台，其用户社区长期保持活跃。用户会在群聊中提问、反馈Bug、提出功能需求，也会分享自己的解决方案。过去，这些对话大多止步于“支持”场景：问题被解答，障碍被清除，然后对话结束。等到产品团队规划下一次迭代时，很难系统性地回顾：这个月用户最常卡在哪些环节？哪些需求被反复提及？哪些只是偶然的个别反馈？

在Momen.app的用户社区中，Lucius被部署在用户原本活跃的群组里，处理日常问答，并记录每一次问题背后的解决路径。根据Lucius提供的数据，在其覆盖的问题范围内，Momen.app用户群中约80%的问题可由Lucius处理，无需升级到人工。

更重要的是，这些记录可以被产品团队重新调用。在一次产品规划场景中，产品经理向Lucius询问下一次功能更新应关注的方向。Lucius并没有替团队做决定，而是基于过往的社区对话记录，整理出几个反复出现的关键点：数据删除和清理操作中的稳定性问题、对抖音小程序等平台扩展的需求、大量“这个怎么做”背后反映出的新手上手摩擦，以及定制开发服务咨询中透露出的潜在服务需求信号。

将这两个案例放在一起看，Dubbing AI更像是Lucius在社区支持场景下的“压力测试”：验证重复问题能否减少，人工时间能否节省。而Momen.app的案例则把价值向后延伸了一层：那些已经被回答过、解决过的对话，能否在产品规划时被重新激活，成为决策依据。Lucius所强调的“Context Layer”，其价值正体现在这里：聊天记录不再仅仅是过往的历史，而是公司做过判断、听过反馈、收到需求之后，所沉淀下来的一层可被随时调用的“组织记忆材料”。

据Lucius透露，在其已服务的30多家客户中，类似的模式反复出现：高频问题缺乏沉淀，购买意图埋藏在散乱的聊天记录里，功能承诺在不同沟通频道中丢失上下文。不同行业、不同规模的团队，面临的底层问题高度一致。

05 从社区问答到组织上下文系统

社区运营是最早暴露这一痛点的场景，但绝非终点。在客服、售前接待、销售调研、项目管理乃至内部协作中，同样存在着大量“判断过却无法复用”的瞬间。

“当你积累了来自用户行为数据、内部商品服务描述、团队行为偏好等维度的上下文，”赵赫解释道，“你就可以更自然地切入调研、销售、任务管理等更深层的工作场景。届时，Lucius不再只是一个回答问题的机器人，而开始像一个真正了解公司业务脉络的同事。”

融资完成后，Lucius计划持续推出新的AI角色，优先选择那些能够收集新上下文、或能充分利用已有上下文的业务场景。当越来越多的问题、例外情况、承诺和后续动作被纳入同一套组织记忆体系，AI Teammate才有机会从单纯的支持角色，走向更广泛的业务协作伙伴。

更多信息可见 Lucius 官网：luciusai.com。