一位曾经的 Google 铁杆用户最近写了篇刺痛人心的文章——Google 正在走 IBM 的老路。不是技术不行，而是拥有最完整技术栈的公司，偏偏在产品策略、用户信任和自动化服务的冷漠中，一步步把优势挥霍干净。
这个判断值得每一位做平台和基础设施的工程师认真对待，因为它揭示了一个反复上演的失败模式：垂直整合越深，离用户越远，组织越容易"IBM 化"。
IBM 的教训：技术最强，市场最冷
上世纪七八十年代的 IBM，拥有从芯片到操作系统到整机到企业服务的全栈能力。没有任何一家公司能在垂直整合上比它更完整。但 IBM 做了什么？——用这种优势锁住客户，用复杂的服务合同制造切换成本，用官僚流程替代产品创新，最终把 PC 时代的主导权拱手让给了微软和 Intel。
关键不是 IBM 技术落后，而是它把技术优势转化成了对用户的控制而非服务。客户感受到的不是"这家公司帮我解决问题"，而是"这家公司让我离不开它"。
Google 的全栈优势正在变成全栈傲慢
今天的 Google 拥有堪称完美的垂直整合：TSMC 代工的 TPU 裸芯片、自建全球数据中心网络、自研 Gemini 等大模型、Chrome/Android 两大终端操作系统、全球最大搜索引擎——从硅片到搜索结果页，每一层都是自己的。
这种端到端控制在效率上无可匹敌：TPU 和模型的协同设计让推理成本低于竞争对手，自建网络让延迟可控，自有终端让分发零摩擦。但问题也恰恰出在这里——当你每一层都自己做了，你就不再需要听任何一层的外部反馈。
具体表现：
- 产品策略失误：Google+、Allo、Hangouts、Stadia 一连串产品仓促上线又草草收场，用户投入的时间和数据被随意丢弃。这不是创新试错，是对用户时间的不尊重。
- 用户信任崩塌：搜索结果页被 AI 概览塞满，广告与内容的边界越来越模糊，用户要找的信息被层层包装。你不再觉得 Google 在帮你找答案，而是在帮你消费它想让你看的东西。
- 自动化服务的冷漠：YouTube 创作者被算法误判封号后找不到人工申诉通道，Google Cloud 客户遇到计费异常只能和 AI 客服对话，AdSense 账户被封时收到的是一封没有具体原因的模板邮件。每一条自动回复都在告诉用户：你的问题不值得一个真人来看。
垂直整合的悖论：控制力越强，反馈越弱
垂直整合的初衷是效率——减少跨组织协调，降低接口摩擦。但它有一个隐性代价：组织内部的反馈回路被截断了。
在开放生态中，你的芯片不好，下游厂商会骂你；你的 API 不好，开发者会弃你；你的产品不好，用户会走。这些外部反馈虽然刺耳，却是纠正方向的唯一可靠信号。
当你把上下游都变成内部团队，这些信号就变成了内部汇报——经过层层过滤、KPI 包装和政治考量，到达决策层时已经面目全非。IBM 当年看不到 PC 的威胁，不是因为信息不存在，而是因为信息在内部流转中被稀释了。Google 今天看不到用户对搜索质量下降的愤怒，同样不是因为反馈不存在，而是因为反馈在内部指标（广告收入、点击率、AI 概览覆盖率）的掩盖下变得不可见。
实践：用"平台衰退检测器"审视自己的组织
这个模式不是只有巨头才会掉进去。任何拥有端到端控制力的平台型团队——无论你做的是内部基础设施、SaaS 产品还是开源项目——都可能重复同样的路径。下面是一个可以用来自检的 Python 脚本，它从五个维度评估你的平台是否出现了"IBM 化"信号：
"""
platform_decay_detector.py
评估你的平台/组织是否出现"IBM化"衰退信号。
运行方式: python platform_decay_detector.py
修改 scores 字典中的分数(1-10)来反映你的实际情况。
"""
import json
# 每个维度 1-10 分，1 = 完全没有问题，10 = 严重问题
# 请根据你所在组织的实际情况调整分数
scores = {
# 维度1: 用户反馈是否被内部指标遮蔽
# 高分信号: 你更关注 DAU/收入/点击率而非用户投诉和弃用原因
"feedback_masked_by_metrics": 7,
# 维度2: 自动化服务是否替代了人工触点
# 高分信号: 用户遇到问题时只能和 AI/模板邮件/自动流程交互
"automation_over_human_touch": 8,
# 维度3: 产品策略是否依赖锁定而非价值
# 高分信号: 用户留在你的平台是因为切换成本高，而非因为体验好
"lock_in_over_value": 6,
# 维度4: 被弃用的产品/功能是否留下用户债务
# 高分信号: 你频繁关停功能但未提供迁移路径，用户数据被随意丢弃
"abandoned_user_debt": 5,
# 维度5: 内部团队是否对外部变化反应迟钝
# 高分信号: 竞品发布新功能或市场出现新需求时，你的团队需要数月才响应
"internal_response_lag": 7,
}
def detect_decay(scores: dict) -> dict:
total = sum(scores.values())
max_possible = len(scores) * 10
# 加权: 维度1和2权重更高，因为它们是早期预警信号
weights = {
"feedback_masked_by_metrics": 1.5,
"automation_over_human_touch": 1.5,
"lock_in_over_value": 1.0,
"abandoned_user_debt": 1.2,
"internal_response_lag": 1.0,
}
weighted_total = sum(scores[k] * weights[k] for k in scores)
weighted_max = sum(10 * weights[k] for k in scores)
ratio = weighted_total / weighted_max
if ratio < 0.3:
level = "健康"
advice = "平台状态良好，继续保持对用户反馈的敏感度。"
elif ratio < 0.5:
level = "早期预警"
advice = "开始出现衰退信号，重点检查反馈遮蔽和自动化冷漠两个维度。"
elif ratio < 0.7:
level = "中期衰退"
advice = "用户信任正在流失，需要立即恢复人工触点并清理用户债务。"
else:
level = "严重衰退"
advice = "平台已进入IBM化晚期，用户正在寻找替代方案。需要从组织架构层面改革。"
# 找出最严重的维度
worst_dim = max(scores, key=lambda k: scores[k] * weights[k])
return {
"total_score": total,
"max_score": max_possible,
"weighted_ratio": round(ratio, 2),
"decay_level": level,
"worst_dimension": worst_dim,
"advice": advice,
"dimension_details": {
k: {
"score": scores[k],
"weight": weights[k],
"weighted": round(scores[k] * weights[k], 1),
"interpretation": interpret_dimension(k, scores[k]),
}
for k in scores
},
}
def interpret_dimension(dim: str, score: int) -> str:
interpretations = {
"feedback_masked_by_metrics": {
range(1, 4): "用户反馈仍能直达决策层",
range(4, 7): "内部指标开始主导决策，用户声音被稀释",
range(7, 11): "决策几乎完全依赖内部指标，用户投诉被视为噪音",
},
"automation_over_human_touch": {
range(1, 4): "关键环节保留人工服务",
range(4, 7): "自动化覆盖大部分场景，但关键问题仍有人工兜底",
range(7, 11): "用户只能与AI/模板交互，申诉通道已关闭",
},
"lock_in_over_value": {
range(1, 4): "用户选择你是因为产品体验好",
range(4, 7): "部分用户留下是因为切换成本，但仍有核心价值",
range(7, 11): "用户留下纯粹因为迁移太痛苦，而非产品有价值",
},
"abandoned_user_debt": {
range(1, 4): "关停功能时提供清晰迁移路径",
range(4, 7): "偶尔弃用功能，用户需要自行寻找替代方案",
range(7, 11): "频繁弃用功能，用户数据/工作流被反复打断",
},
"internal_response_lag": {
range(1, 4): "对外部变化响应迅速(1-2周)",
range(4, 7): "响应需要1-2个月，但最终会跟进",
range(7, 11): "响应需要季度级别，经常错过市场窗口",
},
}
for score_range, text in interpretations[dim].items():
if score in score_range:
return text
return "未知"
if __name__ == "__main__":
result = detect_decay(scores)
print(json.dumps(result, indent=2, ensure_ascii=False))
print(f"\n衰退等级: {result['decay_level']}")
print(f"最严重维度: {result['worst_dimension']}")
print(f"建议: {result['advice']}")
运行前修改 scores 字典中的分数来匹配你的实际情况。输出会给出衰退等级、最严重维度和具体建议。这个脚本不是精确测量工具，而是强迫你正视那些被内部指标掩盖的信号的框架。
给平台建设者的三条自检规则
从 IBM 到 Google 的教训中，可以提炼出三条适用于任何规模组织的规则：
1. 每一层都必须有外部反馈通道，且该通道不能被内部指标过滤。 Google 搜索质量下降的真实信号不在内部 CTR 数据里——CTR 上升可能只是因为用户被迫多翻页。真实信号在用户主动发表的抱怨、第三方评测、竞品迁移率里。如果你只看内部仪表盘，你永远看不到问题。
2. 任何面向用户的自动化流程，都必须保留一条人工申诉的"裂缝"。 这不是技术问题，是信任问题。当用户发现他们的问题永远只能被模板邮件回应时，他们不是更依赖你的平台，而是更想离开。IBM 的客户最终离开不是因为技术差，是因为没有人听他们说话。
3. 关停产品/功能时，必须同步提供迁移方案和用户数据导出。 Stadia 用户投入的游戏进度、Google+ 用户的社交关系、Hangouts 用户的聊天记录——这些不是"产品实验的副产品"，是用户的生活数据。随意丢弃它们不是"快速迭代"，是对用户契约的违反。
Google 的技术栈仍然是业界最强的。TPU 的推理成本优势、自建网络的延迟控制、从芯片到模型到终端的协同设计——这些硬实力没有任何公司能复制。但 IBM 当年的硬实力也没有任何公司能复制。技术优势从来不是护城河，用户信任才是。而信任的建立方式，不是让用户更离不开你，而是让用户觉得你值得依赖。