CRM 三十年都在「先建字段、再填数据」，为什么总让人不满意？Lightfield——Tome 创始团队做的 AI-native CRM——把这个顺序颠倒了过来：先完整保存客户真实互动，再让 AI 按需生成结构，数据模型还能自我重构。

摘要：CRM 三十年都在「先建字段、再填数据」，为什么总让人不满意？Lightfield——Tome 创始团队做的 AI-native CRM——把这个顺序颠倒了过来：先完整保存客户真实互动，再让 AI 按需生成结构，数据模型还能自我重构。用本体论的视角看，这是把 CRM 的数据本体从设计前的输入变成了运行时的输出。本文拆解它的机制，对照 Palantir Ontology 讲清取舍，并给出证据边界。

在 CRM 这个赛道上，几乎没有比 Keith Peiris 更敢说话的人。他在接受 VentureBeat 采访时说：「CRM，从类别上讲，也许是地球上最复杂、满意度最低的软件。CRM 公司有数千万用户，你很难找到一个真正热爱产品的人。」

这句话的底气，来自他做过一个真正被用户热爱过的产品：AI 演示工具 Tome，一度有 2000 万用户。2024 年，他把团队缩到核心工程师，砍掉了这个明星产品，花一年时间在暗处重做——做出了 Lightfield，一个宣称「不用填字段」的 AI-native CRM。

一、三十年，我们都默认 CRM 该先建字段再填数据

要理解 Lightfield 在干什么，先要看清传统 CRM 的底层假设。

从 1980 年代开始，CRM 的产品形态就是一套结构化的数据录入系统：先由管理员定义字段和下拉框——客户阶段、潜在客户来源、成交原因、联系人职位——然后销售人员每次互动后，把对话「翻译」成这些字段里的值。KPI 看板、销售漏斗、预测报表，全部建立在这套人工录入的数据之上。

问题在于：对话本身是丰富、模糊、不断演化的，而字段是固定、稀疏、非此即彼的。把一场 40 分钟的客户会议压进「阶段：提案中」「预算：未知」两个下拉框，会议里提到的换人风险、预算松动、时间窗口，全部在录入瞬间丢失。Peiris 说得很直接：「传统 CRM 强制每一次互动穿过预定义字段——它们在把丰富、微妙的客户对话压缩成结构化的数据库条目。」

更麻烦的是结构本身会过时。创业第一天设计的「线索来源」「客户规模」字段，半年后业务模型变了，字段却锁死了销售流程的表达方式。CRM 三十年的低满意度不是执行问题，而是 schema-first 的架构假设问题：字段先于事实、录入先于理解。

本文用「数据本体论」的视角来拆解这件事。先做一个定义：本体论，在软件语境里，就是「对领域里有哪些东西、它们是什么关系、能执行什么动作」的显式化描述——落到 CRM 里，就是数据模型、字段语义与对象动作。我们要论证的判断是：Lightfield 把 CRM 的数据本体从设计前的输入，变成了运行时的输出。 需要提前说明，这是本文作者的分析视角——Lightfield 官方并没有使用「本体论」这个词。

二、Lightfield：Tome 团队关掉 2000 万用户产品去做的事

先给这个新玩家一个快照。

Lightfield 由 Tome 创始团队 Keith Peiris 与 Henri Liriani 在旧金山创办。Tome 曾是 AI 演示文稿赛道的明星，拿到过约 4300 万美元融资（Coatue 领投），用户一度达到 2000 万。2024 年团队决定转向销售场景垂直深做，2025 年 11 月 Lightfield 公开可用。官网截至 2026 年 8 月显示已有 5000+ 公司在使用；2025 年 11 月 GA 时，报道口径是 100+ 早期客户，其中一半以上每天使用超过 1 小时，并称 100+ YC 公司已成为其客户。

定价上，官网 2026 年 8 月的口径是按积分订阅：Starter 按量付费（0.04 美元/积分，含 5000 免费积分），Pro 849 美元/月，Growth 1999 美元/月，Enterprise 定制，各档位不限制席位。安全方面 SOC 2 Type II 已完成，ISO 27001 标注「即将到来」。Lightfield 还公开承诺不拿客户数据训练模型。

为什么值得关注？因为「AI 时代的 CRM」分两种：一种是在 Salesforce 上加一层 AI 助手，另一种是从数据架构层面重做。Lightfield 显然属于后者，而销售团队实际用起来的效果（见第五节）给出了第一批证据。

三、从先验本体到后验本体：数据模型变成了运行时产物

现在拆核心机制。Lightfield 用三件事推翻了「先建字段再填数据」。

第一，原始无损存储。 系统自动记录并转录销售通话、抓取邮件往来、跟踪产品使用，维护一条「关系时间线」——公司与客户每一次触点的完整时间序列。它存的是原始证据（谁、何时、说了什么、回应了什么），不是事后总结。官方博客的原话是：「摘要、字段和看板是派生视图——不是真相源。现实优先，其余一切从它计算而来。」（"Summaries, fields, and dashboards are derived views—not the source of truth. Reality comes first. Everything else is computed from it."）

第二，按需派生结构。 字段不是录入时预先定义好的，而是 AI 从原始互动里按需提取、生成出来的：需要某个新维度时，系统自动补上字段并回填历史数据。Peiris 的原话是：「如果你意识到需要不同的字段、或者想整体重组 schema，系统可以自动 remap 并重新填充。你不会被第一天、在你几乎还不了解销售流程时做的决定锁死。」

第三，状态与历史同时维护。 官方称之为 versioned customer memory：不仅记录客户当前在哪（阶段、状态），还记录它是怎么到这里的——谁在什么时候改变了什么态度、为什么。官方用四个词概括：chronology（时序）、attribution（归因）、causality（因果）、state（状态演化）。

用本体论的术语翻译这三件事，就是：传统 CRM 是先验本体——结构在数据之前被人工定义，事实必须适配结构；Lightfield 是后验演化本体——结构从事实中生长出来，且可以随业务自我重构。本体的定义时机，从「开工前的一次性设计」，变成了「运行中持续演化的产物」。这是整篇文章的核心判断。这里要说明一个视角细节：本号「数据本体论」系列讨论的多是结构视角——术语、对象、逻辑三层如何建模；本文用的是时机视角——结构在设计期定义，还是在运行时生成。两者互补：结构视角回答「本体由什么构成」，时机视角回答「本体何时被定义、由谁维护」。

先验本体 vs 后验演化本体：字段从真相源变成派生视图

四、为什么是故事而不是图：上下文工程的选择

到这里，一个懂技术的人会问：为什么不用知识图谱？把客户、公司、联系人连成图，不是更「结构化」吗？

Lightfield 官方在 2026 年 2 月的博客里专门回答了这个问题，标题是《LLMs also prefer stories to graphs and databases》（大模型也喜欢故事，胜过图和数据库）。他们的实验发现：模型在知识图谱上表现不佳，「把关系抓得太紧，缺少对概念为什么相连、数据整体主题是什么的理解」。客户关系尤其如此——CISO 一开始说没预算没时间，你讲清楚能解决更大的问题后，他的预算和优先级都变了。「图真的妨碍了建模人的可塑性。」

所以他们的数据组织方式不是一张静态语义图，而是一条实时更新的故事化时间线：围绕人和公司，把邮件、通话、会议、决策写成一串有时间顺序的叙事，和结构化数据一起喂给模型。模型（和人一样）从故事里动态调整每个细节的权重，从时间线里理解变化。

知识图谱 vs 时间线故事：为什么模型更喜欢故事

这里要澄清一个容易混淆的点。Lightfield API 文档里的 context graph（上下文图），指 CRM 对象（账户、机会、联系人）之间的关系拓扑，同时记录当前状态与 how/when/why 的变更历史。它是对象关系索引，不是替代故事化时间线的语义推理图。

在上下文之上，还有一层 agent。每个 CRM 对象都带可配置属性，属性上有自然语言定义，说明它代表什么、应如何被填充；agent 基于时间线上下文推理，然后写回：更新字段、创建记录、起草跟进邮件、总结会议。也就是说，结构不仅由 AI 生成，还由 AI 维护——这就是为什么说它是一个「活的」数据模型。官方将 Automations（自动化）定位为开放测试版，API 则公开 beta，提供 HTTP、Python、TypeScript、Go、CLI 和 MCP 访问。

五、对照 Palantir：先验本体重治理，后验本体重敏捷

「本体论」这个词在企业软件里还有一个重量级玩家：Palantir。把两者放在一起看，取舍就清晰了。

Palantir Foundry 的 Ontology 是组织的操作层：把数据源映射为 objects（对象）、属性、链接（语义层），再叠加操作类型与函数（动力层），用于支撑决策与治理，并常被描述为组织的数字孪生。值得一提的是，Palantir 正是现代本体论中「动作与视图」这半边的开创者——本号系列也沿用了这一结论。它是重型企业级先验本体：先由治理团队定义对象与关系，再让业务在之上运行，强调一致性、可审计、细粒度权限。

Lightfield 则是轻量自演化本体：结构由 AI 从原始互动中按需生成、随时重构，强调可塑性、敏捷、免建模。两个维度的差异可以总结为：本体何时定（设计期 vs 运行时）、谁来维护（治理团队 vs AI agent 加人审）、确定性优先 vs 可塑性优先。

这不是优劣之分，而是适用场景之分：金融、制造等强合规场景需要 Palantir 式的先验治理来保证可审计；早期创业团队没有专职销售运营，schema-first 的维护成本是负资产，后验演化更适合他们。Humble Ops 联合创始人 Radu Spineanu 在被问及选型时说，Salesforce 和 HubSpot「是为另一个时代建造的」，它们假设公司有专门的运营团队来配置工作流和维护数据质量——而早期公司没有。

早期客户也给出了第一批效果证据。据 Voker.ai 联合创始人 Tyler Postle 在报道中的自述：他用 Lightfield 的 AI agent，在一次两小时会话里复活了 40 多个停滞了六个月的机会，其中 10 个在两天内变成活跃机会并进入 POC；对潜在客户的响应时间从几周几个月缩短到一两天。Spineanu 则提到杀手级功能是问「谁还没跟进」——「大多数交易死于疏忽，而非拒绝」，这个功能本季度至少防止了三个交易变冷。这些是创始人自述，未经独立验证，但方向一致。

必须同时交代代价。官方承认 LLM 幻觉无法完全消除，因此设计了人审机制：向客户发送通信、或更新关键字段前需要人工批准。存放全部对话也带来隐私集中风险；schema 自由演化则对大型组织的字段级治理构成新挑战。可扩展性与大规模治理能力，目前还没有被充分证实。

六、三个启示：建模时机后移，本体成为运行时产物，人在回路仍是护栏

把机制、对照和证据收束成三条判断。

启示一：建模时机后移。 当「结构由 AI 生成」的成本足够低，schema 可以从设计期决定变成运行中演化——这是值得所有团队重估的变量。

启示二：本体成为运行时产物。 对象属性带自然语言定义、agent 按需生成并维护结构——本体不再是一纸设计，而是随业务运行重算的输出。这呼应了一个观点：本体论的本质是在技术形态与语义形态之间建一层翻译，只是这层翻译如今由 AI 持续维护。

启示三：人在回路仍是护栏。 幻觉无法消除，自动写回再快，最终发送前仍需人批准。

把「字段」从源头干掉，不是不要结构，而是把字段从真相源降级为派生视图。你的团队该不该跟进，先想清楚：数据本体应该先验，还是后验？