800 万种子轮计划
8,000 万估值。早期材料中的计划口径。
2025 / WHERE BUSINESS AI BEGINS DATAARC · 2025
IDEA 孵化 / 早期共创 / 当时唯一产品经理
技术很厉害。
然后呢？
企业开始认真考虑 AI，
却还在问：第一步，落在哪里？
我在团队刚形成时加入，提出并推动 LivingKB。从产品 Roadmap、Demo 到真实客户 POC，把合成数据、图谱和搜索，组织成业务能理解的答案。
从一个市场信号开始 ↓LIVING KNOWLEDGE BASE点击节点，打开机器
LIVINGKB✳知识持续更新。
01 / INGEST
先把散落的资料，接进来。
接入企业文档并解析。原始信息需要先变成可处理的材料，才能进入业务知识库。
预设内容 · LivingKB 产品结构示意
SIGNALS → PRODUCT → POC → PRODUCT
把“你有什么技术”，
变成“你能为我的业务做什么”。
想用 AI 的企业，先从哪里开始？
在我们接触的客户里，“业务要 AI 化”已有吸引力。客户接着问：资料怎么接，场景怎么选，价值怎么证明？
我的判断是先找共同的入口。比起解释合成数据和图谱，企业更容易从自己的知识库理解一款产品。
于是有了 LivingKB，再用真实客户的 POC 检查它。一家教育公司的教材与题库，成为把技术变成业务结果的一次具体尝试。
01 / LISTEN BEFORE BUILDING
市场先听懂的，
是“知识库”。
初创期，我们在短时间内接触几十家客户与合作方。反复出现的业务问题，把方向指向了同一个需求：企业知识库。
CAPABILITY / 01
合成数据。语境图谱。图上推理。
这些是团队原有的重要技术能力。但采购方要理解的，仍然是它们能解决什么具体业务问题。
合成数据是“性感”的融资叙事，
也是底层的重要技术能力。
但甲方更能听懂、且愿意买单的，
是更贴近业务的“知识库”需求。
在我们接触的企业场景里，Agent 要进入业务，往往先卡在散落的资料与知识上。我选择从这里切入：先让 AI 读得懂企业，再让企业看得懂它的价值。
我的工作：抽象共性需求，定义早期 Roadmap，组织方案版本与 POC，连接算法、工程、设计和商业材料；后续组建产品与设计实习生团队。
把需求带回来的现场部分客户、合作方与生态伙伴 · 展开查看 ＋
这些标识包括当时接触的客户、合作方与生态伙伴；业务交付与 POC 数量见下方阶段记录。
02 / WHERE THE MACHINE BEGAN
一支从合成数据
起步的团队。
DataArc 从 IDEA 研究院科研序列中孵化。IDEA 由沈向洋院士推动成立，沈向洋与郭健担任项目顾问；团队以语境图谱与合成数据，面向稀缺、敏感和长尾场景生成可训练、可评测的数据。
团队现在的产品与技术体系DataArc 官方网站 ↗MY POSITION / EARLY STAGE初创期 PM。
初创期 PM。
产品判断的
连接者。
团队刚形成时加入，承担早期共创角色，也是当时唯一的产品经理。
01 产品定义02 跨团队协作03 业务验证
团队的发展，留下了这些时间戳。融资阶段记录与公开原文 ＋
三轮融资进程
进入 2.5 亿投前阶段。
数亿元投后估值
连续完成种子、种子+轮，累计融资数千万元。
早期数字来自内部融资材料；公开阶段采用 IDEA 与媒体发布口径。以上是团队的发展背景。
03 / GIVE THE CAPABILITY A SHAPE
LivingKB。
持续更新的
企业知识底座。
接入企业资料，建立语境图谱，让答案贴近业务知识库；在运行中动态合成新数据。把市场里的共性刚需与技术能力，凝练为甲方能理解的产品结构。
01 整合知识→02 检索与推理→03 持续扩充
WORKING PRODUCT / 2025
看它，真正工作。
当时采用的产品形态，类似 Manus 的多工具交互形态；底层是我们的 Living Knowledge Base。
2025 年真实产品演示录屏。1业务交付
5已完成 POC
4进行中 POC
2025 年 8 月业务快照。
每个 POC 由产品跟进，把共性需求继续沉淀进 LivingKB 与 RAGFactory。
04 / PUT IT INTO A REAL WORKFLOW
如果客户递来
四本教材，
一千道题。
某教育公司希望把教材、题库和知识点整理成可靠的知识体系，再形成可采购的应用。我们先梳理完整业务范围，然后选哲学，作为一周内可以跑通的最小切口。
04 本教材≈ 750K tokens1,000 道题01 周最小验证
- 客户目标
- 知识库 + AI 搜索 + 题目生成与练习
- 复用底座
- LivingKB + Context Graph + RAGFactory
- 场景定制
- 学科结构、教材解析、知识点关联与做题闭环
LAYER 01 / STRUCTURE
先搭一副学科骨架。
教材目录形成结构层。先调研上线科目、二三级知识点、题量与需求，再定义知识进入应用的组织方式。
基于当时教育 POC 的方案结构示意先理解业务，
再选最小切口。
哲学具有知识关联、适中难度和较小范围，适合先验证完整链路。
把行业知识，
写成产品结构。
结构层、基础层、策略层各自定义数据来源、关系与进入应用的方式。
一周跑通，
建库、检索与做题。
教材与 1,000 道题拆分建库和测试，检查复用底座在新场景里的速度与有效性。
FIRST POC / 最初的验证结果
把“可行”，变成可以检查的结果。
LivingKB 建图
LightRAG 基线：110 min平均响应
当时教育 POC 范围LivingKB 初期准确率
LightRAG 基线：64—66%首轮 POC 的交付尺度：早期 PPT 与后续记录中的 LightRAG 基线分别为 64% 和 66%，LivingKB 初期结果均为 81%。结果对应这批材料与题集，记录首轮 POC 的表现。
05 / WHAT COMES BACK INTO THE PRODUCT?
交付经验，
回到产品里。
共性回到标品，领域逻辑留在应用。下一次交付拥有更成熟的通用底座，也要保留面向业务重新设计的空间。点击一块能力，看看它去了哪里。
↖ 回到通用产品下一次交付，
下一次交付，
从更成熟的底座开始。
资料接入与解析能力继续沉淀进 LivingKB 和 RAGFactory，为下一种业务减少重复建设。
PRODUCT × DELIVERY / 交付中的产品判断先从市场里找到共性问题，
再把判断写进产品，用 POC 检查它。
最后，让每一次交付，
都把产品向前推一点。