AI资讯

看完 YC Spring 2026 这批项目,我挑了 12 个最值得看的 AI 公司

作者:Fun AI Everyday0 次浏览 来源:Fun AI Everyday
看完 YC Spring 2026 这批项目,我挑了 12 个最值得看的 AI 公司

YC Spring 2026 Demo Day 这个月就开始了,所以我这两天一直在看 YC S26 这批项目。按 YC 官网公司目录筛选 Spring 2026,这一期已经有 190 多家公司。我筛选了一些我比较关注的项目,分享给大家。

YC Spring 2026 Demo Day 这个月就开始了,所以我这两天一直在看 YC S26 这批项目。

最直接的感受是:项目太多了。

按 YC 官网公司目录筛选 Spring 2026,这一期已经有 190 多家公司。

YC 现在一年做四期,分别是冬季、春季、夏季和秋季,每期大概 3 个月,最后在 Demo Day 面向投资人展示。

这篇不是要分享 YC 这批项目的完整名单,完整名单相信大家和我一样,看完也记不住。

我筛选了一些我比较关注的项目,分享给大家。

我的筛选标准比较简单:

产品要能讲清楚,场景要具体,不是一个泛泛的“聊天bot/自动化 agent”,要有具体的行业和业务场景/切入点。

最后我挑了 12 家。

它们不一定是跑得最快的公司,但至少代表了几个很清楚的方向:

网站增长、支付入口、代码协作、安全和隐私、全球合规、AI 算力、实验室自动化、养老机器人,以及更早期的生物技术。

文章配图

01|Ploy:让公司官网自己跑增长

因为我本身非常关注 AI 营销和增长,所以 Ploy 是这批项目里我最先挑出来。

Ploy 不是一个普通建站工具,也不是帮你写几句广告文案。它想做的是:

把公司官网变成一个会自己跑增长的系统。

用户接入 Ploy 后,它会先读用户现有网站的页面、设计系统、组件和品牌内容,然后让一组营销 Agent 去做后面的事:

改落地页、写文案、生成面向不同客户的页面、跑搜索优化、做广告素材、然后继续根据效果调整下一轮动作。

我个人很看好 Ploy 的切入点和业务模式。

很多公司的官网都是这样:上线以后,除非融资、改品牌、招市场负责人,否则很久不会有人动。

官网变成了摆设或者单方面的品牌传达窗口,完全失去了引流作用。

Ploy 的创始人 Bryant Chou 是 Webflow 联合创始人和前 CTO,在 Webflow 做了 12 年多。

Webflow 当年解决的就是“不会写代码的人也能做漂亮网站”。

现在,Ploy 继续往后走了一步:网站做完以后,怎么让它持续带来客户。

YC 页面里也提到,Ploy 已经被 Hex、Clay 等公司使用,超过 13% 的 YC P26 公司在用它做网站和自动化收入相关工作。

文章配图

02|Uno Wallet:每次付款时,自动帮你选最划算的那张卡

Uno Wallet 的产品很好理解:它做了一个 AI 钱包,用来替代 Apple Pay。

用户每次手机碰一下付款时,Uno Wallet 会自动判断这笔消费应该用哪张信用卡,尽量拿到更好的积分、返现或权益。

Uno Wallet 的场景是这样的:

很多人有好几张信用卡,不同的信用卡在不同的场景下(餐饮、酒店、超市、订票等)有不同的积分政策和活动。

问题是,真正付款的时候,没人愿意站在收银台前一个一个看活动或者算积分。大多数人还是会随手刷一张。

对此,Uno Wallet 的判断是:

用户不是不想省钱,也不是不想拿权益/积分,用户是不想每次付款都这么麻烦。

YC 页面写到,Uno 是第一个获得 Apple 授权、可以在 iPhone 上成为默认非接触式钱包的第三方钱包。

也就是说,它有机会进入支付入口,而不是只在给建议。

我把这个项目筛选出来分享,是因为它把 AI 放在了一个非常高频、但决策链路很轻的日常场景里。

文章配图

03|Superset:AI 时代,程序员也需要一个新的工作台

Superset 做的是面向 AI coding agents 的 IDE(集成式开发环境)。

它的定位就是帮助工程师同时管理很多个代码 Agent。

YC 页面里写得很清楚:

Superset 是一个开源 IDE,可以帮助工程师并行运行上百个 coding agents。

越来越多的工程师每天会同时打开 Claude Code、Codex 或其他 Agent,让它们并行写不同模块、修不同 bug、改不同页面。

这时候新问题就出现了:

不是“AI 能不能写代码”,而是这么多 Agent 写出来的东西,谁来管理?谁来审查?谁来合并?出了问题怎么回滚?

Superset 更像是一个面向软件团队的新工作台:

内置 Agent 管理、代码审查、远程工作区,让工程师可以在同一个地方启动任务、看进度、审 PR、处理上下文。

Superset 已经有了一些开发者社区基础。

YC 页面显示,Superset 上线 5 个月后,GitHub stars 超过 1.1 万,用户包括 YC 公司,以及来自 OpenAI、Google、Vercel 的工程师。

这个方向我觉得可以重点关注。

因为代码 Agent 越来越多以后,开发工具的竞争点会变。

以前大家比谁补全更准、谁生成更快;后面可能要比谁更能管理一群 Agent,让它们别乱跑,也别互相打架。

文章配图

04|Linzumi:把 coding agents 拉进团队群聊

如果说 Superset 更像 IDE,Linzumi 更像团队群聊。

它的产品逻辑也很好懂:

工程团队可以在聊天窗口里指挥几十个 AI coding agents。

你可以发起任务、看每个 Agent 在做什么、审查结果、决定是否合并,团队成员也能一起看到这些过程。

Linzumi 抓的这个切入点其实非常细。

当 coding agents 变多以后,很多工作不是卡在“写不出来”,而是卡在“等人判断/确认进入下一步”。

比如一个 Agent 写完了一个方案,需要你确认接口怎么改;

另一个 Agent 开了 PR,需要你看一眼;

还有一个 Agent 卡住了,因为它不知道产品逻辑该选 A 还是选 B。

如果这些信息分散在终端、GitHub、Slack、Teams 里。

Linzumi 想做的是一个共享指挥室:

所有 Agent 的工作、人的决策、为什么改方向、谁批准了,都沉淀在一个地方。

它甚至强调,这些决策最后会变成团队的事实来源,反过来生成新任务,验证已完成的工作。

Linzumi 这类产品能不能大,要看 coding agents 在团队里的使用密度。

如果未来一个工程师真的能同时指挥十几个 Agent,那这种“团队调度层”就会变得很重要。

文章配图

05|Superlog:不再只是发告警,直接发修复 PR

Superlog 做的是可观测工具,也就是:

当网站、App 或后台系统报错时,它帮工程师把日志、指标、调用链这些线索串起来,尽快找到问题原因。

make software self-healing,让软件自己修自己。

传统可观测性工具的问题,不是看不到错误,而是看到太多错误。

Sentry、Datadog、Grafana、Slack 里全是告警。

工程师真正痛苦的地方,是要判断哪个告警重要、是不是重复、和哪次部署有关、应该找谁修、修法是什么。

Superlog 的做法是,先扫描代码仓库,自动安装 OpenTelemetry;后面随着代码更新,它会持续补日志、告警和看板。

当线上出问题时,它会把错误合并成一个事件,结合日志、链路追踪、部署记录、历史 Slack 讨论等上下文,最后在 Slack 里发一个可以合并的修复 PR。

这比普通预警工具往前走了很大一步。

普通工具告诉你:这里好像出问题了。

Superlog 想告诉你:这里好像出问题了,原因大概是这个,我已经把修复代码写好了。

我觉得这个项目很适合分享,是因为可观测性市场已经非常拥挤了。

Sentry、Datadog 都不是小公司。

但 Superlog 给了一个新角度:

未来工程工具不是多给你一个后台,而是少让你打开一个后台。

文章配图

06|Tolmo:AI 写代码越快,安全团队越跟不上

Tolmo 做的是 AI 原生安全平台。

Tolmo 的业务判断是:AI coding agents 让代码变化速度变快,传统安全审查跟不上。

过去是人写代码、人审代码;现在如果一个工程师一周能产生大量 PR,靠人工逐条看,很快就会崩掉。

Tolmo 甚至提到,每个工程师每周 200 多个 PR 已经不再是离谱情况。

Tolmo 的做法是,用 AI security agents 去看代码、持续集成流程、云服务、容器、数据库和第三方服务。

它还会建立一个实时生产知识图谱,把这些东西连接起来,再让安全 Agent 自动发现问题、判断影响、尝试修复,只在必要的时候升级给人处理。

Tolmo 要和前面的 Superset、Linzumi、Superlog 这几个项目放在一起看。

它们都在回答同一个问题:

当 AI 让软件交付变快以后,传统代码开发后面的那一整套东西怎么办?谁来管?

谁来审查,谁来保证安全,谁来监控线上,谁来修 bug,谁来决定 Agent 是否可以继续往下做。

文章配图

07|Inth:隐私合规,从文档变成代码里的问题

Inth 做的是企业隐私治理。

这个方向听起来并不性感,甚至有些枯燥/无聊。

因为隐私合规过去经常是法务、合规、信息安全团队在文档里处理:政策、问卷、审计材料、供应商清单。

但今天很多隐私风险已经跑到代码里了。

比如 cookie 同意管理、用户数据删除、第三方供应商、日志记录、AI 系统、Agent 自动写出来的代码变更,都可能影响用户数据流向。

Inth 的起点是一个开源同意和隐私 SDK,叫 c15t。

YC 页面显示,c15t 已经有 300 万以上 npm 下载量,被 Zed、Infisical、Expo 等团队使用。

在这个基础上,Inth 往企业隐私工作流扩展,覆盖同意管理、用户数据请求、政策执行、供应商监督和审计证据。

Inth 是想把隐私治理变成“代码原生”的东西,而不是上线之后再补一堆合规材料。

这个项目的价值在于,它抓住了一个很容易被低估的问题:

AI Agent 越多,数据流动越复杂,隐私风险就越不可能只靠人工表格管理。

以后企业要问的可能不是“我们有没有隐私政策”,而是“我们的代码每次改动,会不会改变用户数据怎么被收集、存储和调用”。

文章配图

08|Regbase:全球法规更新,不可能再靠人工慢慢查

Regbase 做的是监管情报。

很多公司出海以后,会遇到一个很麻烦的问题:法规变化没有集中在一个好用的数据库里。

它可能藏在一个地方政府网站里,可能是一个非英语文件,可能是一份草案,可能在社交平台上发布,甚至可能都没有被 Google 收录。

尤其是金融、气候、医疗、教育、政府采购这些行业,合规团队要盯的东西非常碎。

Regbase 的做法是自动追踪不同国家、不同地区的新法律、新草案、新咨询文件和合规要求,然后再用 AI 分析这些变化对公司意味着什么。

YC 的介绍页面提到了比较具体的几个案例。

比如,它为一家销售防护设备的客户发现了美国即将到期的 4 亿美元学校安全拨款机会;

为一家全球制造商识别出 45 个国家里的 80 项温室气体披露要求;

还找到过只发布在 LinkedIn、Facebook 或 X 上的非英语法规,以及隐藏在二维码背后的监管信息。

这家公司我还在看更多材料,后面可能会单独分享。

Regbase 更像是在做全球法规变化的数据层。

先把世界各地那些难找、分散、非结构化的信息抓出来,再让企业知道哪些变化和自己有关。

切入点很巧妙,但是项目壁垒不高,要早做。

文章配图

09|Zibra Labs:把便宜算力拼成一台大机器

Zibra Labs 做的是 AI 工作负载的分布式运行系统。

它的切入点是量化交易里的回测。

量化团队要不断测试策略,把大量历史数据、参数组合和交易假设跑一遍。

问题不是简单买几张 GPU,而是怎么把不同云厂商、不同 CPU / GPU、不同价格的算力组织起来,既便宜,又稳定,还能快速调度。

Zibra Labs 说自己的系统目标是支持 100 到 5 万个节点,最多 500 万个并行任务,任务调度开销低于 50 毫秒。

Zibra Labs 还能把用户自己的云环境或本地环境里的算力调起来。

Zibra Labs 现在先从量化回测切入,但它的能力可以延伸到很多更重的 AI 工作负载,比如:

强化学习后训练、模型微调、长周期 Agent、批量推理、机器人仿真、分子动力学和科学计算。

这家公司好看的地方,是它不在上层做应用,而是解决 AI 继续变重以后绕不开的问题:

算力不只是“有没有”,还要看怎么调度,怎么省钱,怎么让不同来源的算力协同工作。

文章配图

10|Infera:实验室仪器,也需要一个 AI 操作系统

Infera 是我觉得很有画面感的一家公司。

它做的是用自然语言控制实验室仪器。

科研人员用英文描述一个实验,Infera 会把它变成可以被实验室仪器执行的流程:

检查实验逻辑、库存、仪器状态,生成不同供应商设备需要的脚本,执行实验,拿回数据,再跑分析。

为什么这个切入点很有价值?

因为很多实验室的硬件很先进,但软件很老。

Infera 在 YC 页面里举了一个很典型的场景:

一个实验室可能有 6 台左右仪器,来自 3 个以上供应商,每个实验都要写一次性脚本,数据靠手工拼,库存还可能在 Google Sheet 里。

科学家花了很多时间做人和机器之间的“胶水”。

Infera 想做的就是这层胶水。

它不是让 AI 随便编一个实验方案,而是把实验流程、仪器约束、实验室 SOP、库存状态和历史实验结果都放进一个系统里。

对于能自动化的仪器,它生成脚本去执行;对于还需要人工操作的步骤,它至少提供上下文,比如下一步做什么、哪种试剂放哪里、哪里容易出错。

这类产品其实很难做,但方向很清楚。

AI 要进入科学实验,不只是帮研究员读论文,而是要真正接到仪器、流程、数据和实验室知识里。

文章配图

11|Twolabs:做养老院里的类人机器人

Twolabs 做的是模块化类人机器人,第一站选在养老院和长期照护机构。

它的机器人 Tobi 面向的不是仓库搬箱子,而是老人照护:

喂饭、穿衣、用药提醒、拿东西、日常任务、陪伴,以及帮助老人更安全地移动。

Twolabs 的产品逻辑是 Record → Upload → Train → Deploy。

也就是说,把任务记录下来,上传数据,训练机器人能力,再部署到真实场景。

它强调模块化设计,末端执行器、传感器和部署配置都可以调整,目的就是让机器人适应不同环境和任务。

这个项目的风险其实很高,因为养老照护不是一个容易落地的场景。

它涉及硬件成本、安全责任、真实人机互动、护理机构采购、老人接受度,任何一个环节都不简单。

但它还是值得放进这 12 家里。因为它代表了 AI 创业的另一个方向:

不只在屏幕里替人写东西,而是进入线下,进入那些又累、又缺人、又需要长期陪伴的工作。

文章配图

12|FinalDose:最早期,也最激进的一个生物技术项目

FinalDose 是这 12 家里技术风险最高的一家,也最需要谨慎看待。

它想做的是一种可编程 DNA 药物。

按公司自己的说法,它希望做一个“智能药物分子”,可以识别疾病相关的 DNA 序列,识别后触发结构变化,杀死携带目标 DNA 的细胞。

这个表述非常激进。

FinalDose 认为,过去很多药物研发围绕蛋白靶点展开,但大量疾病驱动因素没有好用的蛋白靶点。

它想绕过蛋白,直接识别 DNA 层面的疾病特征。

公司在 YC 页面中提到,它的想法是“同一个分子框架,换一个 guide,就变成一个新药”。

创始团队主要来自牛津。Li-Yao Huang 是牛津生物化学 DPhil,做过 CRISPR screening 和癌症相关研究;

Steven Lin 是牛津计算生物学 PhD;Jeff Liu 是牛津肿瘤学 PhD,之前还创办过 Vivid Dx。

FinalDose 代表的是 AI 和生物技术结合里的另一种想象:不是只做研发辅助工具,而是尝试改变药物本身的设计方式。

文章配图

我把这家公司放在最后,是想提醒我们一件事:

AI 项目不全是软件/应用工具,也有不少公司在尝试更底层、更高风险的技术路线。

回到我开始筛选 YC 这批项目的标准,我更想表达的是:

现在的 AI 创业已经不适合再讲“智能”、“自动化”、“Agent”这些词了。

更重要的是,你到底进了哪个场景,替谁解决了哪件麻烦事,以及这件麻烦事以前为什么一直没被解决。

以上,祝你今天开心。

文章来自于微信公众号 “Fun AI Everyday”,作者 “Fun AI Everyday”

相关主题

读完之后

加入 AINRK 交流群

了解加入交流群的方式,与更多 AI 从业者交流。

查看交流群说明(在新窗口打开)