Engineering-Management

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 是因。

上周我在准备和团队 9 月初的一次对焦，主题是工程 AI 化。

预对齐时有人说：「我们 AI 用得挺好的——一半的 PR 是 AI 写的，Copilot 全员开通，还有人用 Claude Code 重构了老模块。」

我问了一个问题：「那挑一个 5 人天的真实需求，从提 Issue 到验收关闭，让 AI 端到端跑一遍给我看。」

会议室安静了几秒。安静不是因为没用过 AI，而是因为这条链路从来没有人完整走通过。AI 写过代码的片段，但片段之后是谁在收尾，说不清楚。

这个安静就是分界线：AI 写过代码，不等于工程 AI 化。

上个月一个团队找我聊数字员工落地。

他们已经有 12 个 agent 在跑了。销售助手、客服助手、HR 问答、会议纪要……每个都是独立项目，独立部署，独立维护。

CTO 说：「我们想扩到 200 个。」

我问：「现在 12 个的权限怎么管的？」

他愣了一下：「每个 agent 一个 API key，配在环境变量里。」

「记忆呢？A 部门的 agent 会不会读到 B 部门的会议纪要？」

「……应该不会吧。」

「两个 agent 对同一件事判断冲突了，谁说了算？」

沉默。

12 个靠人盯，200 个靠什么？

而且这 12 个跑在半年前的模型上。模型半年一换代，agent 策略周级迭代——你还没把 12 个理顺，底座已经换了。这不是「多部署几个」的问题。这是架构问题。

上个月一个客户请我们做数字员工。

老板看完 demo，很兴奋。大模型能写邮件、做总结、回答制度问题，他觉得万事俱备。

「给销售、采购、客服各配一个数字员工，下个月上岗。」

工程师于是创建了几个角色，写了几段提示词，把聊天窗口换成了公司 Logo。

数字员工似乎就诞生了。

星期一早上，销售总监问它：「今天该先跟哪个客户？」它不知道。采购问它：「这批货该不该拒收？」它不知道。客服问它：「这个投诉要不要升级？」它也不知道。

老板很失望：「不是说好什么都会吗？」

什么都会。这四个字，是数字员工项目最常见的死因。

上周面试一个候选人。简历很漂亮——三年 LLM 应用开发，做过 RAG、做过 Function Calling、做过多轮对话系统。

我问他：「你平时自己写代码用什么工具？」

他说：「IntelliJ，偶尔用 Copilot 补全。」

我又问：「你上周的工作流是什么样的？从接到需求到交付。」

他想了想：「看需求文档，设计方案，写代码，联调，测试，上线。」

我说：「这个流程里，AI 在哪个环节？」

他愣了一下：「……写代码的时候用 Copilot。」

技术没问题。但他自己的工作流和五年前一模一样。

那一刻我就知道，他做不出好的 Agent 系统。 一个自己都不是 AI 驱动工作方式的人，设计不出 AI 驱动的产品。