企业 AI 支出正在变成一笔没人说得清的账。财务部门看到的是模型 API 账单逐月攀升，IT 部门发现员工在未经审批的情况下把敏感数据粘贴进各种 AI 工具，而管理层最想知道的问题——这些钱到底换来了什么——往往得不到答案。与云基础设施不同，企业为 AI 花的钱分散在数十个工具、数百个 API 端点和无数个员工账号里，没有统一的计量层把这些碎片拼成一张完整的图景。当 CFO 问“我们上个月在 AI 上花了多少”，得到的回答常常是一串互相矛盾的表格和一句“还在统计”。
这正是 Prashant Jalan 想切入的位置。2026 年 9 月 1 日，他创办的 Guickly 宣布以 420 万美元种子轮融资正式启动，由 Engineering Capital 领投，Converge VC、Neon Fund 和若干天使投资人跟投。Jalan 此前在 Google 担任 Applied AI Lead，参与过 Google Maps 限速功能，并开发过用于优化 TPU 性能的 profiler。他在公司新闻稿中给出的创业理由很直接：“今天，组织在 AI 上的支出已经和云基础设施一样多，但与云不同，他们可能完全不知道钱去了哪里。”
这个判断指向的是一个正在快速膨胀但缺乏治理工具的市场空白。企业 AI 支出从实验性预算变成经常性开支的速度，超过了大多数组织建立内部管控机制的速度。它所定义的问题——谁来测量企业 AI 的真实成本和回报——正在成为每一家有规模化 AI 部署的公司都必须回答的问题。
| 字段 | 内容 |
|---|---|
| 公司 | Guickly |
| 轮次 | 种子轮 |
| 金额 | 420 万美元 |
| 投资方 | Engineering Capital（领投）、Converge VC、Neon Fund、天使投资人 |
| 总部 | 美国圣何塞 |
| 创始人 | Prashant Jalan |
| 官网 | https://www.guickly.com |
从 TPU profiler 到企业 AI 计量层：一个测量问题的迁移
Guickly 的产品逻辑建立在 Jalan 在 Google 积累的技术经验之上。Jalan 在 Google 期间开发过一个用于优化 TPU 性能的 profiler，这个工具的核心功能是追踪计算资源的流向——每一个计算周期、每一个字节去了哪里。他在公司新闻稿中这样解释创业动机：“当我在 Google 领导一个 Applied AI 团队、为数十亿人打造产品时，我会追踪每一个周期和每一个字节的去向。所以我决定解决这个问题。”
从技术角度看，这实际上是把底层硬件性能测量的思路迁移到了企业 AI 支出的应用层。TPU profiler 追踪的是芯片内部的计算资源消耗，而 Guickly 追踪的是组织内部 AI 工具、API 调用和订阅的消耗。两者的共同点是都需要在不干扰正常运行的前提下采集细粒度的使用数据，并将这些数据转化为可操作的决策信息。但区别同样明显：芯片测量面对的是确定性的硬件环境，企业 AI 测量面对的是分散在多个部门、多个工具、多种计费模式下的混沌系统。上述技术路径比较为编辑分析，公司新闻稿未披露具体实现方式。
Guickly 的产品功能包括：展示所有 AI 工具（包括影子 AI）、AI agent 和 AI 支出；揭示影子使用情况；按员工和工具设置预算；标记未使用的许可证和定价过高的模型等浪费。其核心价值主张是让 CXO、CIO 和 IT 负责人不需要逐个部门追问就能获得 AI 使用和支出的全景视图。Jalan 在公司新闻稿中的表述是：“领导者不应该为了找答案而追着人跑。Guickly 把答案带给他们，而不需要他们开口问。”
不过，从已披露的信息来看，Guickly 尚未公开其数据采集的具体技术路径。它如何接入企业现有的 AI 工具和 API 端点、如何识别“影子 AI”、如何在不传输敏感数据的前提下完成计量，这些关键的技术实现细节均未在公开材料中披露。公司称其“集成到企业现有环境中”，但集成的深度、支持的 AI 工具范围和部署方式都缺乏独立验证。
数据留在本地：一个面向监管行业的架构选择
Guickly 在技术架构上做出了一项明确的差异化选择：它“从不将提示词、源代码或其他机密公司信息传输到其服务器”，敏感数据“始终留在本地”。这一设计直接回应了金融、汽车物联网和制药等强监管行业对数据出境的顾虑。公司新闻稿明确提到，这一特性使其成为“金融、汽车物联网和制药等强监管行业的实用解决方案”。
这个选择的技术含义值得拆解。如果 Guickly 的服务器不接收提示词和源代码，那么它的计量功能必须在企业本地环境中完成数据采集和处理，只将聚合后的元数据——比如用量统计、成本归因、预算执行情况——传回云端或留在本地展示。这意味着 Guickly 需要在企业侧部署某种 agent 或 collector，并确保这个组件能够覆盖企业使用的各种 AI 工具和 API 端点。这种架构的优点是数据安全边界清晰，缺点是部署复杂度更高、对本地环境的兼容性要求更强，且可能限制某些需要云端集中分析的功能。需要指出的是，上述架构推演属于编辑分析，公司新闻稿未披露具体实现方式。
按座位计费的 SaaS 逻辑失效之后
Guickly 所瞄准的市场机会，根植于企业软件计费模式的一次结构性转变。公司新闻稿中有一段值得注意的论述：“传统 SaaS 模式是基于每座位许可的固定成本，而 AI 更像是一种计量公用事业，其可变公用事业成本基于消费量。”这段话描述了生成式 AI 给企业 IT 预算带来的冲击：当软件成本从“买多少个座位”变成“消耗多少个 token”，企业原有的预算编制、成本归因和 ROI 评估方法全部失效。
这个转变的后果已经在企业 IT 管理中显现。一个员工可能同时使用 ChatGPT、Claude、Gemini 和若干内部 AI 工具，每个工具都有不同的计费模式——有的按座位、有的按 token、有的按 API 调用次数。IT 部门很难追踪谁在用哪个工具、用量多少、是否重复订阅、是否存在更便宜的替代方案。Guickly 将这种现象命名为“token sprawl”（token 蔓延），并将其与“shadow AI”（影子 AI）并列为企业管理层面临的核心盲点。
从商业模式角度看，Guickly 定位为 B2B SaaS，目标客户是“拥有大量 AI 用户”的企业。公司尚未披露具体的定价模式。其早期设计合作伙伴和客户的具体名称也未披露，仅由 Neon Fund 创始人 Siddhartha Ahluwalia 在投资声明中表示“早期设计合作伙伴和客户对 Guickly 带来的独特价值表示认同”。
与 Monday.com 和 Asana 的错位竞争：一个被误读的赛道
MapCo 在一份聚合分析中将 Guickly 定位为“有望颠覆 Monday.com 和 Asana 等企业工作流自动化领域既有玩家”的公司。需要说明的是，MapCo 仅为第三方聚合分析，其权威性未在公开材料中得到验证，该定位不应视为事实。这个定位存在明显的误读风险。Monday.com 和 Asana 是项目管理和工作协作平台，其核心功能是任务分配、进度跟踪和团队协作。Guickly 的产品描述中没有任何功能指向项目管理或工作流协作。将 Guickly 与这两家公司放在同一赛道，更像是基于“企业工作流”这个宽泛标签的机械归类，而非基于产品功能的实质比较。上述定位判断为编辑分析。
Guickly 真正面对的竞争格局需要从另一个维度来理解。企业 AI 治理和支出管理是一个正在形成中的品类，参与者可能来自几个方向：一是云成本管理平台向 AI 支出的延伸；二是 AI 安全与治理平台向成本维度的扩展；三是 IT 资产管理工具增加 AI 订阅追踪功能。此外，大型云厂商和 AI 平台本身也可能提供原生的用量和成本分析工具。Guickly 的差异化在于它声称的“独立测量层”定位——不依附于任何特定的 AI 供应商或云平台。但这个定位能否成立，取决于它能否在技术覆盖面和数据接入能力上证明自己的独立性。目前可比较但尚未披露的竞争指标包括：支持的 AI 工具和平台清单、与云厂商或 AI 供应商的合作关系、跨平台聚合测量的实际覆盖范围、以及相对原生成本分析工具的增量价值。
从已披露的信息看，Guickly 尚未公开其支持的 AI 工具和平台清单，也未披露与任何云厂商或 AI 供应商的合作关系。这使得“独立测量层”的定位目前更多是一个市场叙事，而非可验证的产品事实。在竞争分析中，一个关键问题是：如果企业已经在使用某个云平台的 AI 服务，该平台自带的成本分析工具是否已经足够？Guickly 需要证明的是，跨平台、跨工具的聚合测量能力能够提供单一平台无法提供的增量价值。上述竞争格局分析为编辑基于公开信息的独立判断，并非公司或投资方披露内容。
投资逻辑：一个“白空间”机会与一个未经验证的创始人赌注
三家机构投资人对 Guickly 的投资逻辑在公开声明中表述得相当一致。Engineering Capital 首席工程师 Ashmeet Sidana 给出了两层理由：一是对创始人的长期跟踪——“我关注 Prashant 的职业轨迹很多年了，我知道他具备教育背景、经验、雄心和最重要的商业直觉来打造一家持久的公司”；二是对市场时机的判断——“企业 AI 支出正在飙升，Prashant 构建了一个简单的方式，让企业理解整个组织的 AI 使用、财务支出和访问情况。企业看到 AI 投资回报的第一步是 AI 问责制，这正是 Guickly 提供的。”
Converge VC 的普通合伙人 Anshu Agarwal 则强调了“白空间机会”和创始人的技术背景：“Guickly 集两者之长：Prashant 在 Google 应用 AI 领域超过八年的深厚技术专长，加上一个集可见性、控制和优化于一体的企业 AI 层。”Neon Fund 创始人 Siddhartha Ahluwalia 的表述更为直接：“我们相信 Guickly 将成为任何希望有效使用 AI 的企业所必需的。”
这些投资声明的共同特点是：对创始人的判断权重很高，对市场机会的描述相对抽象，对产品本身的验证证据着墨不多。这在种子轮投资中并不罕见——早期投资本质上是对人和方向的赌注。但值得注意的是，三家机构均未在公开声明中提及任何具体的客户验证数据、收入指标或产品性能基准。Ahluwalia 提到的“早期设计合作伙伴和客户”是唯一接近客户验证的表述，但没有任何具体信息支撑。
从资本结构看，420 万美元的种子轮由一家机构领投、两家机构跟投，加上天使投资人参与，是一个相对标准的早期融资结构。这个金额对于一家需要同时投入产品开发、企业销售和集成的 B2B SaaS 公司来说，意味着在 A 轮之前需要高效地证明产品市场契合度。资金用途方面，公司官方新闻稿未披露具体用途。
资金能买到的和买不到的
根据公开资料，420 万美元种子轮资金在当前的 AI 创业环境中属于中等偏保守的规模。对于 Guickly 而言，这笔钱需要覆盖几个关键方面的投入。以下资金用途分析中，公司明确披露的内容与编辑推测将分别标注。
产品开发是首要的（编辑推测）：一个能够接入多种企业 AI 工具、在本地完成数据采集和计量、同时提供预算控制和优化建议的平台，其工程复杂度不容低估。尤其是“数据不出本地”的架构承诺，意味着 Guickly 需要在企业侧部署和维护一个相对复杂的采集组件，这对工程团队的规模和能力提出了要求。公司官方新闻稿未披露具体资金用途。验证方法：后续可核验 Guickly 是否公开支持的 AI 工具清单数量、部署周期、数据采集组件的兼容性测试结果，以及是否发布客户案例或行业报告。
第二项投入是市场验证（编辑推测）。Guickly 声称已经拥有早期设计合作伙伴和客户，但未披露数量和行业分布。从种子轮到 A 轮，核心验证指标通常包括：付费客户数量、年度经常性收入、净收入留存率、部署周期和销售周期。这些指标目前全部未披露。对于一家瞄准强监管行业的企业级产品，销售周期通常较长，从设计合作伙伴到付费客户之间的转化路径需要时间和资源来验证。验证方法：后续可核验去重后的付费客户数量、可执行合同金额、收入确认金额、复购率、订单转化率，以及是否发布客户案例或行业报告。
第三项投入是竞争壁垒的建立（编辑推测）。Guickly 的“独立测量层”定位在理论上具有吸引力，但在实践中需要回答一个关键问题：当企业已经在使用某个云平台或 AI 供应商的服务时，为什么需要额外购买一个独立的测量工具？这个问题的答案取决于 Guickly 能否在跨平台覆盖、数据隐私和成本优化建议方面提供显著优于原生工具的体验。这需要持续的工程投入和客户案例积累。验证方法：后续可核验 Guickly 是否披露与云厂商或 AI 供应商的合作关系、跨平台聚合测量的实际覆盖范围、相对原生成本分析工具的增量价值，以及是否发布客户案例或行业报告。
从已披露的信息看，Guickly 尚未公布任何具体的里程碑目标或时间表。资金用途的模糊性在种子轮并不罕见，但考虑到其产品架构的复杂性和目标市场的销售周期，这笔资金能够支撑的验证窗口可能相对有限。
待验证的假设：独立测量层能否成为一个真正的品类
以下内容为编辑分析，所列假设均非事实，需通过后续披露和独立验证来检验。
Guickly 的故事建立在一个核心假设之上：企业 AI 支出需要独立的测量层，而这个测量层不能由 AI 供应商或云平台自己提供。这个假设的逻辑基础是利益冲突——如果企业依赖某个 AI 供应商的工具来评估该供应商的 ROI，结果的客观性存疑。从这个角度看，独立测量层的价值主张在逻辑上是成立的。需要说明的是，这一假设为编辑基于逻辑的推断，公司并未在公开材料中提供独立验证来支持这一假设。
但这个假设面临几个未经验证的挑战。首先是技术可行性：Guickly 能否在“不传输敏感数据到服务器”的前提下，实现对各种 AI 工具和 API 端点的全面覆盖？企业 AI 工具的数量和种类正在快速增加，从通用聊天机器人到垂直行业 AI agent，从云端 API 到本地部署模型，一个测量层要覆盖所有这些场景，其技术复杂度和维护成本可能远超预期。该假设可能面临技术可行性挑战，需通过第三方测试验证。公司称其“集成到企业现有环境中”，但集成的具体方式、覆盖的工具范围和部署的复杂度均未披露。待核验指标包括：支持的 AI 工具清单、数据采集组件的部署方式、跨平台聚合测量的实际覆盖范围。
其次是商业可行性：企业是否愿意为 AI 支出测量单独付费？在云成本管理领域，独立的 FinOps 工具已经证明了市场存在，但 AI 支出管理与云成本管理之间存在重要差异。云成本管理面对的是相对集中的云账单和资源使用数据，而 AI 支出分散在多个供应商、多种计费模式和多个组织层级中，数据采集和归因的难度更高。如果 Guickly 能够解决这个更难的问题，它可能创造一个新的品类；如果解决不了，它可能被云成本管理平台的 AI 功能扩展所吸收。待核验指标包括：付费客户数量、年度经常性收入、净收入留存率、客户案例。
第三是竞争窗口：大型云厂商和 AI 平台是否会快速补上自己的成本分析能力？如果 AWS、Azure 和 Google Cloud 在各自的 AI 服务中提供足够好的用量和成本分析，企业对独立测量层的需求可能被削弱。Guickly 的回应逻辑是跨平台聚合和供应商中立性，但这个差异化需要在产品成熟度和客户案例上得到验证。待核验指标包括：与云厂商或 AI 供应商的合作关系、相对原生成本分析工具的增量价值。
针对 Guickly 的独特分析在于：其创始人 Jalan 的 TPU profiler 背景意味着，Guickly 的技术叙事核心是“把硬件级测量方法迁移到企业 AI 应用层”。这一迁移能否成立，取决于 Guickly 是否能在企业本地环境中复现类似 profiler 的细粒度数据采集能力，同时避免把敏感数据传回服务器。公开材料没有披露 Guickly 是否拥有与 TPU profiler 同级别的采集精度或实时性，也没有披露其本地采集组件是否已在真实企业环境中完成部署测试。因此，Guickly 与通用 AI 治理工具的真正差异，目前仍停留在创始人背景和公司声称层面，而非可验证的产品能力。
从已披露的信息看，Guickly 目前处于产品早期阶段，其技术能力、客户验证和竞争壁垒都尚未经过独立第三方的检验。公司的叙事清晰、创始人的背景相关、投资人的信心明确，但这些都还不能替代一个关键问题的答案：当一家企业真正部署 Guickly 之后，它能否在 AI 支出上看到可量化的改善？这个问题的答案，需要时间和客户数据来给出。
验证边界与可复核指标
本文涉及的“首个、唯一、最大、领先”、订单、出货、性能等表述，如无另行说明，均是公司、创始人或投资方在现有公开材料中的披露口径；RecodeX未在本次采集材料中找到独立审计或第三方测试结论，因而不将其视为已经独立确认的事实。文中的产业协同、竞争位置和商业路径属于基于已披露产品与融资用途的编辑分析，不代表相关结果已经实现。
- 技术侧应核验第三方测试条件、样本规模、良率、稳定性及与可比方案一致口径的结果；
- 商业侧应核验去重后的付费客户、可执行合同、收入确认、复购率以及订单转化；
- 资本与产业协同应以工商股权、关联交易、联合开发、采购或量产文件为准。
RecodeX 极客视：Guickly 把“测量”本身变成了产品，这比再做一层 AI 应用更接近企业当下的真实痛点。但测量层的价值取决于它能否覆盖足够多的 AI 工具、能否在数据不出本地的前提下做到足够细的颗粒度、以及能否让 CFO 和 CIO 同时看懂同一张表。420 万美元买不来这些答案，只能买来验证这些假设的时间窗口。Jalan 在 Google 追踪过每一个计算周期，现在他要追踪的是企业里每一个 token 的去向——后者比前者更难，因为它发生在别人的系统里。
信息来源
本文在采集与核验阶段引用了以下公开来源，按站点去重列出；来源内容归原发布方所有，其口径不代表 RecodeX 的核实结论。