所谓 AI 优先的日程安排,其实是 API 优先的日程安排

市面上每一个日程安排工具都在发 AI 功能。大多数是同一个功能:角落里一个聊天框,让你输入 "周四约我和 Anna 见面",然后让模型去填一个表。

这挺好。这也不有趣。

它之所以不有趣,是因为价值不在那个聊天框里。价值在助手能够触及到的一切。如果助手只能触及到一个团队的设计师在一个产品的侧边栏里硬连出来的东西,那你不过是用一个稍微客气一点的表替换了原来的表。你真正在用的那个助手——Claude、ChatGPT、Cursor,或者将来出现的任何一个——不住在那个产品里。它住在别处,而且更强。

"AI 日程安排" 的两种模型

叫它们 embedded(嵌入式)和 agent-addressable(可被 agent 访问的)。

Embedded AI 就是这个品类现在大部分在做的:厂商自己托管一个模型,用 app 内部的词汇训练它,通过一个面板暴露出去。模型只能做厂商暴露出来的事。如果你希望它同时能和你的 CRM、你的笔记、你的代码仓库、你同事的 booking page 对话——不行,那是另一个产品。

Agent-addressable 刚好相反:厂商不发 AI。厂商发的是一个干净、有文档的表面——一个 REST API、一个 MCP 服务器、webhooks——然后让用户本来就信任的那个 agent 在上面操作。模型不是 app 的功能,app 是模型世界里的一个功能。

对任何已经有喜爱的助手的人来说,第二种都胜出。而 "会用 AI 日程安排的人" 和 "有喜爱的助手的人",这两个集合的重合部分又大又在变大。

一个判据

一个判断某个日程安排工具是否真的 AI-first 的好判据:一个 agent 能不能从 app 外面用它做点有用的事?

对 embedded-AI 的产品,答案几乎总是不能。你可以用他们建好的那个聊天面板。你不能让自己的 agent 把你的 booking 读进一份每周报告、把它们和 CRM 关联、在提议的 deep-work block 之前检查冲突、按你自己写的 workflow 代你预约。厂商的助手是唯一的助手。

对 agent-addressable 的产品,答案是能。只要 API 有足够的表面能表达用户真正的意图——"我日历上有什么"、"这冲突吗"、"建一个这个"——任何 agent 都能驱动。今天这意味着 Claude、ChatGPT、Cursor。明天意味着大家接下来去到的任何地方。工具不需要猜。

这对 WhenToMeet 意味着什么

我们 WhenToMeet 里没有聊天面板,也没打算建。那东西会 work,会 demo 得好,会让下一轮融资的 slide 更好做。但那会是这件事里没那么有意思的版本。

我们选择做的是:在 /api/v1/ 下发一个 REST API,在 /api/mcp 下发一个 MCP 服务器。两者共用同一套 key。两者都覆盖一个助手真正需要的表面:列 event、读一个 event、建一个新 event、列 booking、拉统一后的日历 feed、检查冲突、读自己的 profile。

一个带着这七种能力的 agent,基本能做到任何人对 "日程安排助手" 提过的大多数事情。而且它能在用户本来就在进行的那段对话里做,带着那段对话已经拥有的上下文。

这个品类还在搞错的地方

两点。

第一,大多数 "AI 日程安排" 功能都在为新鲜感 demo 做优化——"看,模型从一封邮件里订出了一个会议!"——而不是一个真实用户需要的那种无聊可靠性。如果 agent 偶尔把事件建到错的那一天,你就不再信任它,功能就死了。无聊的可靠性来自窄而清晰的工具,不是来自祈祷模型猜对。

第二,这个行业还在继续建住在一个 app 里的助手。而用户自己的助手是跨 app 的。两者是两件事,第二件才是大家想要的。

我们要去哪

roadmap 的短版本:扩大 API 和 MCP 工具所覆盖的表面,不增加 AI 面板。补上 agent 能读但不能写、能读但不能改的那些缺口。把表面做得足够完整,以至于除非你愿意,否则不用打开我们的 app 就能完成日程安排的活。

想今天就试,去拿一把 API key,把你的 MCP 客户端指向 endpoint,让它看看你的日历。Setup 在 docs.whentomeet.io。

真正有意思的 AI 不是我们会去建的那个,而是你已经在用的那个,指向一个干净的表面。那才是 "AI 优先" 唯一值得发的版本。