Google Calendar 颜色从 11 个变 24 个：小修补，刺到了真痛点

Google Calendar 终于把日程颜色放宽了。

以前单个事件只有 11 个预设色。现在默认色变成 24 个；在网页端，或者通过 Calendar API，还能用 RGB 取色器定义额外颜色，最多约 200 种。

这不是生产力革命。它不会让会议少掉半个。但如果你每天靠日历区分客户会、内部会、深度工作、家庭安排和个人事务，这个变化会很快有感。

颜色不是好看。颜色是扫一眼就知道今天被什么占满的索引。

更新很小，但信息要说准

边界也要讲清楚。

材料里明确的是：网页端和 API 可以定义额外颜色。移动端原生应用覆盖这套事件颜色体系，但不能直接推成“所有移动端都有完整 RGB 取色器”。

这点很重要。生产力工具最怕一句“支持了”，结果不同端体验不一致。用户最后还是要靠试错记住：哪里能设，哪里只能看。

最受影响的是两类人

第一类是重度 Google Calendar 用户。

如果你把同一个日历当作一天的控制台，现在可以重新整理颜色规则：外部会议一组色，内部沟通一组色，深度工作一组色，家庭和个人事项另起一组。动作很简单：把高频事件类别先固定下来，再给它们分配稳定颜色。

不要一上来用满 200 种。颜色太多会反噬。真正有效的做法，是把颜色当成少量、稳定、可复用的标签。

第二类是用日历管理工作与个人事务的知识工作者。

以前 11 个颜色很容易不够。工作项目、私事、账单、出行、孩子学校事项混在一起，一旦颜色撞了，日历就变成一块彩色噪音。现在至少可以少拆几个日历，少忍几处误判。

对接 Calendar API 的工具也该检查一次颜色映射。尤其是内部排期工具、自动建会工具、同步插件：如果它们仍按旧颜色表处理，用户在网页端设好的颜色，到了第三方界面可能还是变形。

接下来最该看两个变量。

一是移动端的实际入口和同步体验是否跟上。二是 API 和第三方客户端能不能稳定识别这些自定义颜色。前者决定普通用户爽不爽，后者决定团队工具会不会乱。

如果这两点没跟上，这次更新就会变成“网页端看着很好，跨端使用打折”。

Google 这次做对了，但晚了

我更在意的不是多出来多少颜色，而是 Google 终于承认一件事：用户不是只需要一个能创建事件的日历，用户需要一个能让混乱保持可读的日历。

生产力软件常犯一个毛病：迷恋大功能，轻视小摩擦。

AI 总结、智能排期、会议洞察，听起来都适合放进发布会。但用户每天被磨掉耐心的，常常是颜色不够、筛选麻烦、默认视图不顺、提醒规则不细、重复事件难改。

单看都不致命。叠起来，就是鞋里的沙。

《道德经》里说，“天下大事，必作于细”。放到工具软件里，这句话一点不玄。日历这种产品，本来就靠细节建立秩序。一个颜色限制，足够让用户每天多想半秒；半秒多了，就是产品欠账。

Google Calendar 这次处理得克制。没有把小修补包装成工作流革命，也没有逼用户学习新概念。它只是把一个早该放开的限制放开。

这类改动的价值，恰恰在于不打扰。

真正该吐槽的是：为什么拖到现在。

成熟平台很容易进入一种状态：核心入口已经占住了，用户迁移成本也高，基础体验就开始排队。不是没人知道痛点，而是痛点不够性感，不像增长项目，也不像战略叙事。

于是用户先忍。忍久了，需求变成笑话。公司再把补课写成更新。

这不是 Google Calendar 一家的病。从 PC 软件到 Web 工具，很多成熟产品都走过这条路：早期靠清晰好用赢用户，中期靠生态和默认入口留用户，后期对小摩擦麻木。等反馈堆高，再回头修门把手、补灯泡、换台阶。

当然，颜色扩展不是万能药。

颜色给的是材料，不是秩序。重度用户仍然要自己定规则：哪些颜色代表必须亲自处理，哪些只是信息占位；哪些属于工作，哪些属于生活；哪些一看就要警惕，哪些只是提醒。

但这次至少把材料补齐了一点。

所以我的判断很简单：小，但不虚。它不会改变 Google Calendar 的竞争格局，却会让一批每天盯着日历过日子的人少一点无谓摩擦。

很多科技产品的进步，不总是大模型、大改版、大叙事。有时候只是把 11 个颜色变成 24 个，再把一点选择权还给用户。

小事最能暴露产品观。真正成熟的工具，不该让用户天天替产品缺口绕路。