当一家软件公司的客户提交工单，问题指向的不是“如何操作”，而是“为什么这个功能在我的环境里不工作”时，传统客服体系的结构性缺陷就暴露了。客服人员手头只有产品文档和话术脚本，工程师手头有代码、日志、配置和生产数据，但工程师的时间被排期、迭代和内部项目占满。于是工单在支持队列和工程队列之间反复横跳，客户等待时间以天为单位计算。这不是某个团队效率低下的问题，而是两个系统之间缺少一个能读懂双方语言的中间层。
Decimal AI 的创始人 Sanjeet Hajarnis 和 Kevin Raji Cherian 试图把这个中间层做成一个产品。2026年9月15日，这家总部位于旧金山的公司宣布完成400万美元种子轮融资，由 Khosla Ventures 和 Kearny Jackson 联合领投，Atlassian Ventures 与 Weekend Fund 参投。公司同时推出了所谓的 Customer Engineering Platform——一个面向技术客服团队的平台，其核心是一个名为 AI Support Engineer 的智能体，据公司披露，它能够端到端解决客户问题：从回答客户提问、执行解决账单和账户问题等支持动作，到调查代码、日志、配置、生产数据、文档和客户历史，并为工程团队生成 bug 修复供审核。
这轮融资的金额在当下的 AI 创业环境中不算大，但投资方组合和产品定位指向了一个具体而尖锐的问题：当 AI 让软件公司的交付速度指数级提升，支持需求的增长速度是否正在超过工程团队的承受能力？Khosla Ventures 合伙人 Hari Arul 在新闻稿中给出的判断是，AI 让最好的公司“指数级提升交付速度”，但随之而来的是“指数级增长的支持需求”。Decimal 的答案不是让客服人员更高效地搜索文档，而是让一个 AI 系统直接进入工程师的调试现场。
| 字段 | 内容 |
|---|---|
| 公司 | Decimal AI |
| 轮次 | 种子轮 |
| 金额 | 400万美元 |
| 投资方 | Khosla Ventures（联合领投）、Kearny Jackson（联合领投）、Atlassian Ventures、Weekend Fund；天使投资人包括前 Stripe COO Claire Johnson、Anrok 创始人兼执行主席 Michelle Valentin、前 Eightfold CCO Rimple Patel |
| 总部 | 旧金山 |
| 创始人 | Sanjeet Hajarnis（CEO）、Kevin Raji Cherian（CTO） |
| 官网 | https://decimal.app |
AI Support Engineer 的真正边界：从“回答”到“调查”的跨越
大多数 AI 客服产品的起点是知识库检索和对话生成。Decimal 的产品叙事从起点上就不同。据公司披露，其 AI Support Engineer 的工作范围包括调查代码、日志、配置、生产数据、文档和客户历史，并创建 bug 修复供工程审核。这意味着它不是在客服界面上回答问题，而是在工程师的工作现场提取证据。
Hajarnis 在新闻稿中的表述直接点出了这个差异：“客户支持不应该基于产品的二手描述来运作。客户问题的答案通常就在产品实际做了什么之中。我们构建 Decimal 是为了在工单到达的那一刻就浮出这些证据，而不是在客户经历了多次升级循环之后。”这段话值得拆解。传统客服的困境在于，支持人员对产品的理解来自文档、培训和二手转述，而真正能解释客户问题的证据——代码路径、日志输出、配置状态——掌握在工程团队手中。Decimal 的产品逻辑是把证据获取的时间点从“升级之后”提前到“工单到达之时”。
从技术实现的角度看，这种能力意味着系统需要接入软件供应商的生产环境、代码仓库、日志系统和配置管理工具。这不是一个轻量级的 SaaS 集成。Runtimewire 在独立报道中指出，产品的有效性依赖于访问软件供应商最敏感的部分运营系统。这一观察把 Decimal 的产品承诺放回了真实的产业链约束中：一个 AI 支持工程师的价值与其访问深度成正比，但访问深度本身构成了部署的最大摩擦。
公司称已使用本轮融资扩展系统可调查的技术问题范围，并加深与客户现有支持和工程工具的集成。但公告没有披露具体集成了哪些工具、覆盖哪些技术栈，也没有说明这些集成的深度和权限模型。从已披露的 Atlassian Ventures 参投这一事实看，Jira 生态的集成至少是方向之一。Runtimewire 的分析指出，Jira 恰好位于 Decimal 想要压缩的“支持到工程交接”环节，而 Atlassian 的开发者工作流生态为产品提供了分发渠道。这是一个合理的推断，但 Decimal 与 Atlassian 的具体合作条款和产品集成深度未披露。
客户数据背后的真实含义：MTTR 下降62%意味着什么
Decimal 在公告中提供了两组客户数据。Resilinc 将平均解决时间（MTTR）从6.5天降至2.5天，降低62%。Granola 现在处理两倍工单量，在聊天中解决70%的常见问题——在它们成为工单之前——并通过自动生成的 pull request 持续改进文档。此外，公司称自2026年初以来，Decimal 解决的客服交互量增长了15倍。
这些数据需要被放在正确的语境中理解。首先，它们全部来自公司新闻稿，没有独立第三方验证。62%的 MTTR 下降是 Resilinc 一家客户的内部数据，Granola 的70%聊天解决率同样如此。这些数字不能外推为整个客户群的平均表现。其次，MTTR 从6.5天降至2.5天，绝对值仍然以天为单位。这说明 Decimal 解决的可能是复杂技术问题的调查环节，而不是把整个解决过程压缩到分钟级。新闻稿标题中“在几分钟内解决客户问题”的说法，与 Resilinc 2.5天的 MTTR 之间存在明显张力。公司称其 AI Support Engineer 能“在几分钟内”解决客户问题，但已披露的客户数据中，Resilinc 的平均解决时间仍为2.5天。这可能意味着“解决”的定义在不同场景下不同——某些简单问题可以在几分钟内关闭，而复杂问题仍需数天——但公司未披露这些场景的分布。
Granola 的数据中有一个值得注意的细节：70%的常见问题在聊天中被解决，“在它们成为工单之前”。这意味着 Decimal 的介入点前移到了客户对话层，而不是工单系统。如果这一数据可靠，它指向的产品价值不是“更快地处理工单”，而是“阻止工单产生”。这是客服成本结构中的一个关键差异：工单一旦产生，就进入了支持队列、SLA 计时和升级路径，而聊天层的解决可以绕过整个工单生命周期。但 Granola 是一家客户，其数据不能代表 Decimal 的整体表现。
自2026年初以来15倍的交互量增长，基数未披露。如果2026年初的基数很小，15倍增长的实际绝对值可能仍然有限。这个数字的意义在于方向性——它说明现有客户的使用量在扩大——但无法用来判断产品的市场渗透率或收入规模。
从 Eightfold 到 Decimal：创始人的履历与产品的信任问题
Decimal 的两位创始人在 Eightfold AI 相识。Hajarnis 此前在 Eightfold 领导 AI，据公司披露，期间公司收入突破1亿美元，服务 Citibank、Morgan Stanley、Nvidia 和 Netflix 等企业。更早之前，他是 Facebook News Feed 排名系统的早期工程师，并在 Uber 构建了支撑数十亿次行程的定价系统。Raji Cherian 从零构建了 Databricks 的向量搜索产品，并在 Eightfold 领导基础设施，支撑超过10亿候选人档案与职位的匹配。
这些履历在 AI 基础设施和大规模系统方面有明确的技术相关性。向量搜索、推荐系统、定价系统和大规模匹配，都是需要处理复杂数据管道和实时推理的系统。但客服场景的独特挑战不在于技术复杂度，而在于信任。一个 AI 系统要读取生产数据、代码仓库和日志，意味着它需要获得通常只授予资深工程师的访问权限。支持、安全和工程三个部门的负责人必须同时批准这种访问。这不是技术能力能解决的问题，而是组织信任和风险治理的问题。
Kearny Jackson 联合创始人兼普通合伙人 Sunil Chhaya 在新闻稿中说，两位创始人“不是从外部构建这个产品。他们有伤疤和专业知识来弥合支持与工程之间的鸿沟，这就是为什么市场上一些技术最复杂的公司信任他们。”这是投资方的判断，不是独立验证的事实。但从逻辑上看，创始人在 Eightfold 的企业级 AI 部署经验——处理大规模数据、服务金融和科技巨头——确实与 Decimal 需要说服的客户群体有重叠。Eightfold 的客户包括 Citibank 和 Morgan Stanley，这类机构对数据访问和合规的要求极高。如果 Hajarnis 和 Raji Cherian 在 Eightfold 期间积累了处理这类约束的经验，这可能是 Decimal 在面对安全审查时的一个优势。但这一推断的边界是：Eightfold 的 AI 人才匹配场景与 Decimal 的生产环境调试场景在数据敏感度和系统耦合度上并不相同，前者的经验不能直接等同于后者的能力。
Atlassian Ventures 的参投：分发渠道还是生态绑定
Atlassian Ventures 的参投是这轮融资中最值得拆解的信号之一。Atlassian 不是一家财务投资者，其企业风险投资部门的投资逻辑通常围绕 Jira、Confluence 和 Atlassian 开发者生态的扩展。Jira 是软件支持与工程交接的核心工具：客服团队在 Jira Service Management 中创建工单，工程团队在 Jira Software 中接收 bug 报告。Decimal 想要压缩的正是这个交接环节。
Runtimewire 的分析指出，Atlassian Ventures 的参与“适合这个分发问题”。Jira 直接位于 Decimal 想要压缩的支持到工程交接环节，而产品也连接着 Atlassian 更广泛的开发者工作流。这是一个基于公开事实的合理推断：Atlassian 的投资意味着 Decimal 至少在其生态中有一个战略位置。但需要明确的是，Atlassian Ventures 的参投金额未披露，双方是否有商业合作协议、产品集成路线图或独家条款，均未在公告中说明。投资本身不构成对产品能力的验证，也不意味着 Atlassian 会优先分发 Decimal 的产品。
从竞争格局的角度看，Atlassian 自身在 AI 客服和 ITSM 领域有产品布局。Atlassian Intelligence 已经嵌入 Jira Service Management，提供 AI 辅助的工单分类、总结和建议。Decimal 的定位与 Atlassian 的 AI 功能存在潜在重叠。Atlassian Ventures 投资一个可能与其自身产品线部分竞争的公司，这在企业风险投资中并不罕见——它可能是在押注一个生态内的互补层，也可能是在观察一个潜在收购标的。但公告没有提供任何关于这种关系的具体信息。
“客户工程”作为一个品类：投资人的叙事与市场的检验
Kearny Jackson 联合创始人兼普通合伙人 Sriram Krishnan 在新闻稿中给出了一个大胆的判断：“每家面临技术问题的软件公司都会需要这个。我们认为 Customer Engineering 会像 GTM Engineering 一样成为自己的品类。”这是投资方的观点，不是市场共识。GTM Engineering 作为一个品类在过去几年确实获得了资本市场的认可——它指的是用工程手段优化销售和市场流程的职能和工具层。但 Customer Engineering 是否能够复制这一路径，取决于一个关键问题：客户支持中的技术问题是否足够大、足够痛、足够独立，以至于需要一个专门的软件层，而不是被现有的 ITSM、AI 客服或工程效率工具吸收。
Vinod Khosla 的表述更直接：“支持正在成为软件最大的隐性成本之一。Decimal 用一个理解代码和客户上下文的 AI 平台彻底改变了这些经济学。”这是投资方的判断。支持成本是否是软件公司“最大的隐性成本之一”，没有在公告中提供数据支撑。但从行业逻辑看，随着软件产品的复杂度和交付速度提升，支持团队需要处理的技术问题比例确实在上升。传统上，这些问题被升级给工程团队，而工程团队的机会成本极高。如果 Decimal 能够在不增加工程负担的情况下解决相当比例的技术工单，其价值主张是清晰的。但“如果”是关键词。
公告未提供收入、定价、留存或客户支出数据。Runtimewire 在独立报道中明确指出了这一点。这意味着 Decimal 的商业进展无法从公开信息中衡量。客户名单——Granola、Resilinc、Tealium、BuildOps、Lucidworks 和一家未具名的 Fortune 5 科技公司——说明产品已经在真实生产环境中运行，但客户数量、合同规模、付费意愿和续约情况均未披露。一家 Fortune 5 科技公司的采用是一个值得注意的信号，但未具名的客户无法独立核实，其使用范围和深度也不可知。
资金用途与待验证假设：400万美元能买到什么
公司称已使用本轮融资扩展系统可调查的技术问题范围，并加深与客户现有支持和工程工具的集成。这是一个相对模糊的表述。“扩展技术问题范围”可能意味着支持更多的编程语言、框架、云环境或数据源；“加深集成”可能意味着与更多工单系统、聊天工具、代码仓库和监控平台的对接。但公告没有给出具体的产品路线图或技术里程碑。
400万美元的种子轮在2026年的 AI 创业环境中属于中等偏小的规模。考虑到 Decimal 的产品需要深度集成、安全审查和企业级销售周期，这笔资金的主要用途不太可能是大规模市场推广，而更可能是产品工程和少数关键客户的深度打磨。从已披露的客户名单看，Decimal 的客户获取似乎依赖于创始人的企业网络和投资方的资源，而非大规模的市场营销。Atlassian Ventures 的参与可能为产品在 Atlassian 生态内的分发提供某种便利，但具体机制未披露。
Decimal 需要验证的核心假设有三个。第一，AI 系统能否在真实生产环境中可靠地调查复杂技术问题，而不产生错误诊断或危险操作。第二，支持、安全和工程负责人是否愿意授予一个 AI 系统深度访问权限，这种信任的建立需要多长时间、多少安全审查和多少成功案例。第三，客户是否愿意为这种能力支付足够的费用，使其成为一个可持续的商业模式，而不是一个被现有 ITSM 平台吸收的功能。这三个假设中，前两个是产品和技术问题，第三个是商业问题。公告提供的信息不足以判断任何一个假设的验证进度。
风险与边界：一个需要深度信任的产品在敏感系统中的位置
Decimal 的产品逻辑中存在一个根本性的张力。产品的价值与访问深度成正比：它能调查的系统越多、越深，能解决的问题就越复杂，价值就越大。但访问深度与部署摩擦也成正比：每增加一个敏感系统的接入，安全审查、合规要求和组织阻力就增加一层。Runtimewire 在独立报道中指出了这一点：产品有效性依赖访问软件供应商最敏感的部分运营系统，而公司需要说服支持、安全和工程负责人批准一个需要深度访问和高度信任的产品。
这不是一个可以通过技术优化完全消除的摩擦。即使 AI 系统在技术上能够安全地处理生产数据，安全团队仍然需要评估数据泄露、权限滥用和错误操作的风险。一个 AI 支持工程师如果能够执行“解决账单和账户问题”等动作，就意味着它拥有某种程度的写权限。如果它能够创建 bug 修复供工程审核，就意味着它能够修改代码——即使修改需要人工审核，代码变更的生成本身已经进入了软件供应链。这些能力在宣传中是产品优势，在安全审查中是风险点。
从已披露的信息看，Decimal 的客户名单中包含一家 Fortune 5 科技公司。如果这一信息属实，说明至少有一家大型企业通过了 Decimal 的安全审查并部署了产品。但这家公司未具名，其部署范围、使用深度和付费情况均不可知。一家大客户的试点部署与规模化采用之间的距离可能很大。
另一个边界是产品的可验证性。AI 系统调查代码和日志的能力，在演示环境中可以表现得很出色，但在真实客户环境中，代码库的混乱程度、日志的缺失、配置的漂移和生产数据的敏感性都会显著增加难度。Decimal 的客户数据——Resilinc 的 MTTR 下降和 Granola 的聊天解决率——提供了真实环境中的一些证据，但这些数据来自公司自述，没有独立验证，且样本量有限。从这些数据看，产品在特定客户中产生了可测量的效果；但这些效果能否在不同规模、不同技术栈、不同支持流程的客户中复制，尚未被证明。
验证边界与可复核指标
本文涉及的“首个、唯一、最大、领先”、订单、出货、性能等表述，如无另行说明，均是公司、创始人或投资方在现有公开材料中的披露口径；RecodeX未在本次采集材料中找到独立审计或第三方测试结论，因而不将其视为已经独立确认的事实。文中的产业协同、竞争位置和商业路径属于基于已披露产品与融资用途的编辑分析，不代表相关结果已经实现。
- 技术侧应核验第三方测试条件、样本规模、良率、稳定性及与可比方案一致口径的结果；
- 商业侧应核验去重后的付费客户、可执行合同、收入确认、复购率以及订单转化；
- 资本与产业协同应以工商股权、关联交易、联合开发、采购或量产文件为准。
RecodeX 极客视：Decimal 的融资故事真正的看点不是400万美元，而是一个产品逻辑的赌注——AI 客服的价值不在对话层，而在证据层。当大多数玩家在优化回答的流畅度时，Decimal 试图让 AI 直接读取代码、日志和生产数据，把支持从“转述问题”变成“调查问题”。这个方向如果成立，它切开的不是客服软件的市场，而是工程资源与支持需求之间的结构性缺口。但赌注的另一面同样清晰：一个需要深度访问敏感系统的产品，其增长曲线注定被信任建立的速度拖慢。400万美元能验证技术可行性，但验证不了组织信任的扩散速度。而后者，才是这个品类能否成立的决定性变量。