Manus 的 changelog 里藏着一个数字。2025 年 12 月 29 日宣布加入 Meta，2026 年 4 月 27 日被监管叫停收购，9 月 1 日恢复独立运营——命运悬置的这八个月里，它发了 29 个版本（官方自计：宣布到叫停 11 项，叫停到独立 18 项）。整条时间线 63 项重大更新摊在约 572 天上，平均 9 天一发，监管风暴期间节奏没断过。
同一周的另外两家是另一种节奏。xAI 的 Grok 模型层一周多换一版（4.7 上线才一周，4.8 已宣布完成训练），Team Bots 那个五人团队 reportedly 一天合 100 多个 PR。而 Meta 的 Muse 是极端反面：原定今年 4 月发布，一路憋到 9 月 8 日，上线前两周它还在连贯性测试里挣扎、说不利索英语。
三种节奏，三种活法。最近我给 AI 产研团队定了三条迭代标准，这三家正好是它的注脚：
- 产品层：每天能端到端对外发布 1 次，支持的任务质量和数量有 10% 的增量；
- 工具层：支撑高速迭代的工程师软件工具，5 分钟能用起来，出问题 15 分钟能解决；
- 基建层：工程基建上必须用最好的工具。
这三条乍看是三个独立的 KPI。但我越想越觉得，它们其实是同一条：一个能日发的团队，它的每一层时间常数必须压到上一层的十分之一。发布是果，工具 SLA 是因。
三家的节奏，先摆在一起
| 产品 | 迭代节奏 | 驱动层 | 发布形态 |
|---|---|---|---|
| Manus | 63 项 / 572 天 ≈ 9.1 天一发；命运悬置八月发 29 版 | 产品功能层 | 对外正式发布 |
| Grok / Team Bots | 模型一周多一版；五人团队 100+ PR/天（reportedly） | 模型层 + 工程层 | PR 密度高，对外发布另算 |
| Muse | 憋约 5 个月（4 月推迟到 9 月）；底层 Muse Spark 模型约 49 天一版 | 组织 dogfood | 一次性大发布 |
注意一个容易混淆的点：PR 密度 ≠ 对外发布。Team Bots 一天 100 多个 PR 是工程吞吐，不是 100 次对外发版。Manus 的 9 天一发才是真·对外节奏。把这两个数混为一谈，就会得出「日发很容易」的错觉——其实从「代码合进去」到「对外发一版」之间，还隔着测试、灰度、回滚预案这一整条管线。我说的「每天端到端对外发布 1 次」，指的是后者。
「10%/天」在数学上只有一种读法
先处理最容易被当成口号的那条：「任务质量和数量有 10% 的增量」。
如果把它理解成固定标尺上的复利，数学上立刻崩掉：
1.1^7 ≈ 1.95 一周后是基线的 2 倍
1.1^30 ≈ 17.4 一个月后 17 倍
1.1^90 ≈ 5313 三个月后 5000 倍
1.1^365 ≈ 1.28e15 一年后 10 的 15 次方倍
# generated by hugo AI
没有任何固定标尺上的「质量」能有这个导数。所以「每天 +10%」要成立，只有一种读法：标尺本身每天在长——10% 是相对当天的评测集而言的。
这恰好和我在 数万名员工，是一块活的评测集 里写的严丝合缝。活评测集不只是评测手段，它是「10%/天」这句话唯一的度量基础：没有活 eval set，「质量有 10% 增量」是不可证伪的口号；有了活 eval set，它就是每天可测的通过率、可覆盖的任务数。Muse 上线前那两周「终于开始考出好分数」，考的就是一块被数万员工每天喂新 case 的活标尺。
反过来算一个更有用的数：要让一年翻 10 倍，每天只需要 0.93% 的增量。「日发 +10%」真正难的不是那个 10%，是「每天」——是发布管线的边际成本被压到近零，让发布本身不再是一个需要鼓起勇气的事件。
日发是被工具层 SLA 物理决定的
现在到全文的核心。三层时间常数排开看：
层级 时间常数（反馈延迟） 相对上一层
──────────────────────────────────────────
产品层 1 天 = 1440 min ——
任务层 ~150 min（2.5 小时） ÷10
工具层 ~15 min ÷10
──────────────────────────────────────────
两个锚点：工具层 15 分钟排障、产品层 1 天发布
1440 ÷ 15 ≈ 96 ≈ 10² → 中间自然落出一个任务层（~2.5 小时）
# generated by hugo AI
这不是巧合。这三条标准里的两个锚点——工具层「15 分钟排障」、产品层「1 天发布」——相差约 96 倍，几乎是 10 的平方。两个数量级的落差，意味着中间必然有一层：1440 ÷ 10 ≈ 150 分钟，约 2.5 小时，这就是任务层该有的反馈延迟。「15 分钟」这个数不是随手拍的，它正好是「日发」对工具层时间常数的物理要求。
反过来看就清楚了：如果排障要 2 小时，一次线上事故就吃掉你大半个发布窗口，日发在物理上不可能——这不是意志问题，是时间常数问题。很多团队做不到日发，以为是发布纪律不够、不够勤奋，真正的原因是工具层太慢：环境起不来、日志查不到、回滚要半小时。发布层的瓶颈，永远在工具层。
这就是为什么 Nat Friedman 带 Muse 时干的那几件事，现在看全是在压工具层时间常数：他的座右铭是「Slow is fake（慢是虚伪的）」；他推动团队放弃部分笨重的内部开发工具，直接换用 Vercel 等外部服务；OpenClaw 在开发者圈走红后，他写内部备忘录《The Claw Is The Law》，一口气采购数百台 Mac mini 专门给团队跑这款产品。这些都不是「改善福利」，是把「上手一个新工具、复现一个问题」的时间常数往下压——5 分钟能用起来，15 分钟能排障。
「最好的工具」= 社区最厚的，不是 benchmark 最高的
第三条「必须用最好的工具」最容易被执行歪。如果不给「最好」下定义，团队会把它理解成「最新最炫」——然后恰恰违反了第二条的 15 分钟排障 SLA。
因为 15 分钟能排障的前提是：踩坑的人多、答案搜得到、生态成熟。 一个刚发布三个月、benchmark 惊艳但社区稀薄的新工具，出问题你搜不到任何帖子，15 分钟根本排不掉。所以「最好」的定义被第二条 SLA 反向锁死了：
最好的工具 = 社区最厚、踩坑记录最多的那个，不是参数最高的那个。
这和我在 能上春晚的项目，和能赚钱的项目 里说的「乏味的改进」是同一条判据：能稳定跑在生产里的成熟技术，胜过 demo 惊艳的新技术。工程基建上「用最好的工具」，本质是用最厚的社区给你的 15 分钟 SLA 兜底。
慢一定是死吗？Muse 这个反例
到这里必须正面回应一个反驳：你鼓吹日发，可 Muse 憋了 5 个月，反而一上线就登顶 App Store 免费榜（Sensor Tower 测算头两周约 280 万次下载，全球口径）。慢工出细活，日发是不是浮躁？
这个反例很硬，得认真拆。
第一，Muse 的慢不是「打磨」的慢，是被安全性卡住的慢。 Meta AI 产品副总裁 Vishal Shah 对路透社说，推迟主要是为了安全性，那几个月才让它达到「能交到普通用户手里的最低标准」。这不是「慢工出细活」的主动选择，是个人 Agent 要接管用户邮箱、日历、支付权限时不得不付的代价。
第二，Muse 翻盘靠的恰恰是「高频发布」，只不过发布对象是内部数万人。 数万 Meta 员工连续数月高频使用、每天喂新 case——这在结构上就是「每天端到端发布给一个真实用户群」。Muse 没有违反日发，它把「对外」换成了「对内」，把发布频率藏进了 dogfood 循环里。
第三，也是最关键的：Manus 在监管风暴里八个月发 29 版没断气，说明发布节奏是组织的生命线。 命运悬置、收购被叫停、前途未卜的那段时间，它没有停下来等尘埃落定，而是继续每 9 天一发。我在 Team Bots 最贵的不是 Bot 里写过 Manus 这条命运线——当 9 月 1 日翻牌时刻到来，它手里还有一个每 9 天迭代一次、没断气的产品。发布节奏一旦断了，再想接上，成本远高于一开始就别断。
所以慢不是原罪，但「慢」必须是被一个明确的、值回票价的东西换来的（Muse 换来的是安全性 + 数万人的活评测集）。没有这个东西的慢，就是 Manus 命运线里那种「停下来等」——而等，是会死的。
三条标准，其实是一条
把三条标准合起来看，它们不是并列的 KPI，是一条因果链：
工具层反馈延迟（~15 min 排障）
↓ 决定
任务层反馈延迟（~2.5 h 跑通一个闭环）
↓ 决定
产品层节奏（每天对外发布 1 次 + 10% 增量）
↑ 度量基础
活评测集（让「10% 增量」可测而非口号）
# generated by hugo AI
中间那个任务层，对外的产出形态就是我在 如何判断你的团队真的工程 AI 化了 里验收过的「5 人天端到端闭环」——注意别把两个数搞混：2.5 小时是任务层的反馈延迟（多久知道这一步对不对），5 人天是它的产出预算（端到端交付一个完整特性要多久），后者由许多个前者叠成。软件工厂 3.0 里展开过这条闭环——它是工具层和产品层之间的传动轴。工具不够快，任务闭不了环；任务闭不了环，日发就是空话；没有活评测集，日发的「+10%」无从度量。
所以如果你也想让团队日发，别从「要求大家每天发版」开始——那是从果上用力。先量你的工具层时间常数：新人多久能跑起来第一个任务？一个线上问题从发现到定位要多久？如果这两个数不是 5 分钟和 15 分钟量级，你的产品层就不可能日发，再怎么催都没用。
发布是果，工具是因，活评测集是尺。 三条标准，一条链。
你的团队，卡在哪一层的时间常数上？欢迎留言讨论。
事实核对自：Manus 63 项更新时间线（据「十字路口 Crossing」公众号转述的 Manus 官方博客自整理 changelog，自选性偏差已知，「29 版」「9.1 天一发」为本人据公开条目计算）；Grok 4.7→4.8 节奏与 Team Bots 五人团队 100+ PR/天（reportedly）见 xAI 发布材料及多源转述；Muse 推迟、上线前两周连贯性、数万员工 dogfood、Vishal Shah「为安全性推迟」、Nat Friedman「Slow is fake」/Vercel/数百台 Mac mini，核实自 Business Insider 独家（2026-09-25）+ Reuters 内测报道；Muse 登顶 App Store 免费榜为事实，「头两周约 280 万下载」系 Sensor Tower 全球口径测算（经头条综述转述，与 #424 采用的美加 iOS 切片 180 万为不同口径，不可直接比较）；Muse Spark 模型版本约 49 天一版据 Meta 官方博客版本日期计算。三家「迭代速度」均为各自官方或媒体口径，未独立复现；「三层时间常数 ÷10」「任务层 ~2.5 小时」为本文据用户给定的两个锚点（工具层 15 分钟、产品层 1 天）反推的框架性估算，非任何厂商公布数据。