企业官网建设流程全解析

2011 年 10 月，一位 Google 工程师在内部社交平台 Google+ 上写了一篇吐槽长文。因为隐私设置没搞明白，这篇本来只给同事看的内容被公开了，随后被科技媒体大量转载，成了当年技术圈讨论度最高的一篇“内部檄文”。作者叫 Steve Yegge，文章后来被统称为 “Google Platform rant”。

十多年过去了，文章里的具体案例和技术细节早就过时。但你会发现，它讨论的问题——平台思维、API 优先、服务化架构、组织激励、开发者生态——到现在依然是云原生和平台工程领域的核心议题。这篇文章不只是一个技术圈八卦。它其实是一个从业二十多年的资深工程师，拿 Amazon 和 Google 两家公司做对照，讲清楚“平台是怎么设计出来的”。

如果你想搞清楚下面几个问题，这篇值得往下看：为什么 AWS 能长成巨头生态，而 Google 早期很多优秀产品却很难被第三方深加工？为什么有些公司内部工具总在重复造轮子？平台工程到底在解决什么问题？

今天这篇就来复盘这次事件，并且把它映射到当前做 API 设计、服务治理和内部开发者平台的具体实践上。

1. 事件回放：那篇被公开的帖子到底说了什么

1.1 作者是谁：程序员、博主、Amazon 前员工

Steve Yegge 在技术圈不是无名之辈。去 Google 之前，他在 Amazon 工作多年，参与过与电子书、搜索推荐相关的业务开发。他是个很能写的人，在博客时代就输出过大量关于编程语言、软件工程和职业发展的长文，风格犀利，喜欢把一个观点讲到极致。

2011 年，他加入 Google。站在这个位置回看 Amazon，他对两家公司的“平台观”差异体会很深。于是，在 Google+ 讨论 Google 社交产品时，他顺势把积攒下来的想法写成了一篇长文。从流传版本来看，这篇内容与其说是“吐槽”，不如说是一篇夹杂着大量真实工作体验的平台战略分析。

1.2 帖子是怎么被公开的

当年的具体情况大致是：Steve 把长文发在 Google+，本想设定为内部可见，最终却被公开。文章很快就被技术社区和科技媒体保存、转载。

这里要提醒一句，当时转载流出的版本并不是一次有组织的官方发布，属于个人言论的意外公开。我们今天能看到的翻译版本、摘录版本很多，但最准确的说法，仍要以当时的原始文本为准。很多程序员后来把这篇长文称作“谷歌平台失败史”，其实有点标题党，它更像一份亲历者视角的观察报告。

1.3 核心论点拆解

用现在的语言来概括，文章的核心论点可以拆成下面几层：

这五层内容放到今天看，依然能对得上现代公司在做“内部平台”时的痛点。产品是直接满足用户需求，平台是让更多人能基于你的能力做事，这中间的实施逻辑差别很大。

2. 平台思维与产品思维：一条容易混淆的界线

2.1 什么是平台思维

Steve 在文章里强调的“平台思维”，核心是把能力抽象成可复用、可编程、可被他人扩展的基础服务。

搜索引擎对普通用户来说是一个产品；但如果把搜索能力开放成 API，让企业可以构建垂直搜索工具，那它就变成平台。数据库引擎对开发人员来说是产品；但把它托管成云数据库，按需调用、弹性扩展，它就成了平台。平台思维不关心“最终用户点击了什么”，更关心“开发者能不能利用这套能力做出自己的东西”。

一个最直接的判断标准是：如果团队把某个能力封装成服务，并且允许团队之外的调用方通过网络接口使用它，这个能力就是在向平台演进。反之，如果所有能力都只能在自家产品页面里操作，那无论公司多大，都只是产品公司。

2.2 产品思维为什么不是平台思维

很多团队把“提供 API”误认为“做平台”。实际上，平台涉及的东西更多，至少包括稳定的契约、版本治理、鉴权体系、配额管理、错误码、文档、SDK、计费或者成本分摊。产品思维关注体验和转化率，平台思维关注接入效率和扩展边界。

这里放一张对比表，方便理解：

不是说产品思维不对。优秀的终端产品非常难得，但平台思维能带来更大的杠杆效应。同一份基础能力，通过 API 开放给一万个开发者，可以衍生出比原团队自研更多的使用场景。

2.3 平台化的三个层次

在实际落地过程中，平台化通常分三层：

第一层是可复用服务。把公共能力从业务代码中抽出来，变成独立服务。比如做统一登录、统一配置、统一文件存储。这阶段还没有对外部开发者开放，但内部已经建立起服务边界。

第二层是面向开发者开放。服务不只内部使用，还能通过 API 被外部应用调用。此时需要完整的接入文档、测试环境、配额策略和版本管理。

第三层是形成生态。开发者不只是调用几个 API，而是能在平台上面创建、分发、交易自己的应用。典型的例子包括云市场上的第三方镜像、插件系统、低代码平台上的组件市场。

Steve 的 rant 之所以犀利，是因为他认为 Google 当时的问题恰恰停留在第一层和第二层之间。内部产品已经很多，但没有把这些能力统一抽象成对开发者友好的服务生态。

3. Amazon 的 API 优先模式，为什么让他印象深刻

3.1 从 Amazon 内部“服务化”到 AWS 平台化

Steve 在 Amazon 的工作经历让他直观感受到了 API 优先带来的工程纪律。Amazon 很早就强调：团队之间不能直接读其他人的数据库，不能直接共享代码仓库来实现业务调用，必须通过服务接口完成。这套规则后来在公开报道中被反复提到，和 Steve 文章里的描述一致。

表面上看，这是为了技术解耦。更深层的意义在于：它强制每个团队把能力看作可独立交付的服务。你必须在接口稳定性、数据模型、权限控制方面达到能被外部调用方依赖的程度。这种严谨度很容易迁移到公有云上。当 AWS 对外提供计算、存储、数据库等服务时，底层逻辑与内部服务化是一致的。

3.2 强制 API 带来的工程纪律

强制 API 的效果之一，是避免了“改别人的表结构”这类混乱。服务之间的访问变成请求和响应，而不是直接操作内部实现。接口的稳定性和可测试性往前迈了一大步。

另一个效果是：服务拥有者必须回答“我这个能力谁能用、怎么用、用了出问题找谁”。这个要求在开发阶段看起来很麻烦，但它逼着团队提前考虑文档、鉴权、限流、错误码。这些围绕 API 的能力，反而是平台成长的基础。

今天做微服务、做中台，遇到的大量问题，都可以追溯到服务边界没定义清楚。如果内部团队之间可以随意读写数据库，表面上是效率高，实际上是把耦合成本推迟到未来。

3.3 开发者生态的飞轮

当 AWS 把这些服务对外开放，飞轮就转起来了：API 数量越多，开发者越容易组合出复杂应用；开发者使用越多，平台方越清楚应该补齐哪些服务；新服务上线，又有更多使用场景被创造出来。

这是 Steve 文章里对 Amazon 模式最羡慕的一部分。Google 不缺技术，缺的是把技术变成可编程生态的系统性投入。对今天做平台工程的人来说，这个飞轮依然成立：生态不是靠一个“开放平台”口号形成的，而是靠一个个稳定、易用、能解决真实问题的 API 逐渐积累起来的。

4. Google 被批评的四个问题

4.1 产品之间不打通：内部 API 薄弱

文章中一个很著名的观察，是 Google 内部有很多产品线，但产品之间的能力复用并不顺畅。不同团队会遇到相似的问题，却往往各自重复解决。本质上，是因为缺少一个以 API 为中心的协作机制。

这种不打通带来两个代价：一是内部开发效率下降，二是对外的整体性变差。用户会觉得你家的服务各自为战，开发者更觉得很难把 Google 能力整合进自己的产品。当年那个环境下，这类批评并不是孤例。

4.2 面向开发者的 API 开放缓慢

Steve 的观点里，Google 一些产品在推出时并没有把 API 当作一等公民。即使后来开放了 API，往往也是以产品页面的方式去推广，而不是以开发者平台的方式运营。

对比 AWS 的流程：先有 API，再有控制台界面，界面只是 API 的调用工具。而很多互联网产品通常是先有产品界面，API 变成某个后续补充的功能。这导致开发者接入的优先级很低，文档质量、版本管理、兼容性保障也很难达到平台级标准。

4.3 组织与激励不支撑平台化

平台化投入周期长，短期指标难看，收益归属也很模糊。如果绩效评估只关注产品增长和用户量，团队理性选择就是把精力放在短期功能建设上。

Steve 的文章抓住了组织激励和平台发展之间的关系。平台建设需要跨团队协作，如果缺少对共享基础设施贡献的认可机制，潜在贡献者就不会参与。这个观察在今天依然非常准确——做平台工程，首先要设计合理的激励机制，否则口号再多也没用。

4.4 搜索业务的平台化机会

在 Steve 看来，搜索是 Google 最重要的资产，但一直被当成产品，没有被打造成可以被第三方深度调用的平台能力。他甚至认为，竞争对手如果做类似搜索平台的事情，会构成威胁。

这个判断当时引发了很多讨论。客观来看，搜索能力开放给第三方存在商业模型、数据安全、查询质量等多方面难题，不是简单开放 API 就能成立。但其中的核心思路值得保留：核心资产如果只能通过自己的页面提供给用户，那么扩展性就会受到很大限制。

5. 现在回看：这篇 rant 是预言还是偏见

5.1 后来发生了什么

从大趋势来看，AWS 在云基础设施上形成了强大的生态，云计算本身的赛道选择和平台策略被证明是成功的。

Google 这边也在后续多年里做了不少平台化演进：开源 Kubernetes、推出 Firebase、把更多云服务放到 Google Cloud 上。尤其是 Kubernetes 能够从一个内部容器编排系统成长为今天云原生领域的基石，本身就是“把内部工具平台化并开放出去”的典型样本。从这个角度来说，Steve 批评的方向有一定道理，平台化的确值得做。

5.2 Google 的平台化演进

十多年过去，Google Cloud 已经是公有云市场的重要参与者，API 网关、云函数、托管数据库等基础设施完备程度比 2011 年高出很多。与此同时，Google 在 Android、Chrome 等生态上一直坚持平台化路线。

但在当年语境下，Google 的核心收入来自搜索广告，公司更愿意把资源投入到能直接贡献营收的产品上，对长期生态的投入谨慎。这种业务结构决定了它的平台节奏和 Amazon 不一样。Steve 的 rant 更多是在表达工程师视角的遗憾，而不是完整商业判断。

5.3 客观看待：平台不是万能药

也有人批评 Steve 把 Amazon 模式过于理想化。AWS 的 API 优先模式也有问题，比如服务复杂度高、成本估算难、供应商锁定风险。做平台，不等于每个业务都要做成平台。小团队在资源不足时，先做产品验证市场，再慢慢平台化，反而更稳妥。

所以，这篇文章最大价值不是“Google 不如 Amazon”的结论，而是提供了一组判断工具：平台化需要什么条件、会碰到什么组织阻力、短期利益和长期杠杆之间怎么权衡。这套思考框架，比事件本身的八卦属性更有用。

6. 平台工程：从 rant 到现代工程实践

现实中的平台工程，不像 Steve 文章里那样只谈战略，它已经变成一套可执行的工程体系。下面用几个例子说明，当年 rant 里提到的问题，在今天的工程实践中如何落地。

6.1 API 优先设计

平台化的出发点，是服务对外能力时先定义 API 契约。这里的常见做法是使用 OpenAPI 来描述接口，让文档、代码生成、测试工具都围绕契约展开。

下面是一个示意用的 OpenAPI 片段，说明一个内部订单服务如何暴露接口：

openapi: 3.0.0 info: title: Internal Order API version: 1.0.0 paths: /orders/{id}: get: summary: 获取订单详情 parameters: - name: id in: path required: true schema: type: string example: "20240611001" responses: "200": description: 返回订单详情 content: application/json: schema: type: object properties: orderId: type: string status: type: string amount: type: number

这只是一个示意文件，实际项目里还需要补充鉴权、分页、错误码等字段。重点是：API 先行，页面和调用方实现跟在契约后面。契约稳定，平台才能稳定。

6.2 内部服务目录与 API 治理

平台化之后，服务数量会快速增加。这时候，需要有一个内部服务目录，把服务负责人、API 文档地址、环境入口、版本策略集中管理起来。

示例配置如下：

services: - name: user-service owner: team-account apiSchema: ./openapi/user.yaml versioning: semver environments: dev: "https://api.dev.internal/user" staging: "https://api.staging.internal/user" prod: "https://api.internal/user" observability: metrics: "prometheus/user-service" traces: "jaeger/user-service"

这个目录可以被内部开发者门户加载，让其他团队像逛应用商店一样发现服务。很多公司做的内部开发者平台，本质上就是在做一个更智能的服务目录，把 API 发现、权限申请、配额审批、监控告警串成一条线。

6.3 开发者体验（DX）度量

平台使用者是开发者，平台好不好用要看开发者体验。可以先把最基础的健康检查和接口可用性指标采集起来。示例（同样为示意命令）：

# 检查服务健康状态 curl -s https://api.example.internal/health | jq .status # 查看最近 5 分钟调用成功率 curl -s "https://metrics.example.internal/api/v1/query?query=sum(rate(http_requests_total{job=\"order-api\"}[5m]))"

这类命令可以进入平台的自动化巡检脚本，也可以用来做开发者接入前的自检。当平台团队能看到每个服务的调用量、错误率、P99 延迟时，平台的改进方向就变得更清晰了。

7. 平台化落地清单：如果你来搭建一个内部平台

7.1 从第一天就暴露 API

做内部工具时，不要只做一个 Web 页面，要同时提供 API。哪怕页面只是 API 的调用演示，也比“页面先行、接口后补”好。这样其他团队可以更早做集成测试，平台能力也能更快被验证。

反过来说，如果一开始只知道做页面，后续补 API 时会发现很多页面逻辑已经和服务状态耦合在一起，接口设计空间被大大压缩。

7.2 文档、版本、兼容性管理

平台的生命力来自契约稳定性。给每个接口定义好文档，并用语义化版本管理升级。破坏性变更要让调用方有足够时间迁移。千万不要用“反正内部使用，随便改”的心态对待 API 契约。

实际项目中可以借助工具自动生成文档，并在 CI/CD 里检查 OpenAPI 变更，拦截不规范的破坏性升级。

7.3 可观测性

平台服务必须有日志、指标、链路追踪。调用方出了问题，第一件事是查平台侧日志；平台侧如果查不到调用轨迹，问题就会变成两边互相踢球。至少在服务入口打上请求 ID，并在响应头返回给调用方。

7.4 吃自己的狗粮

平台团队应该用自己搭建的平台去开发真实业务功能。如果你连自己的平台都用不下去，那么外部团队更不可能愿意用。吃自己的狗粮，能最快发现 API 设计问题、文档缺失和配额策略不合理。

7.5 建立平台保障机制

平台的运行要有保障机制，比如 SLO、降级方案、成本分摊规则。内部团队使用平台产品，也需要一个快速的反馈闭环。平台团队最好有固定的 oncall 机制，问题响应要像对外产品一样严格。

8. 给个人开发者的建议

8.1 把你的项目也当成平台

你现在做一个开源项目或者一个工具，可以多想一层：别人能不能通过编程方式使用它？提供一个 CLI 或 REST API，比只提供 GUI 更容易被集成到别人的流水线里。这会让你的项目拥有更大的影响半径。

在个人项目里实践 API 优先并不难，先定义好输入输出格式，再写业务逻辑，最后再加 UI。这样做出的项目天然具备被脚本调用的能力。

8.2 写博客、开源代码，就是在构建个人平台

Steve Yegge 之所以能在技术圈留下一笔，不只是因为他在 Google 和 Amazon 工作过，更因为他持续公开输出观点。对一个技术人来说，持续输出高质量文章和开源代码，本质上就是把自己大脑里的思路做成可被外部调用的 API。

你的文章可以被网络搜索引用，你的代码可以被其他项目依赖。这就是个人影响力层面的“平台化”。哪怕没有公司级资源，这套逻辑也成立。

8.3 学会从历史教训里抽象框架

不要把这篇 rant 当成简单的“某公司好、某公司坏”。它的价值在于抽象出了一个框架：平台需要明确的契约、合理的组织激励、稳定的服务基础设施，以及愿意长期投入的团队。

你在设计接口、划分服务边界、做技术方案评审时，都可以试着问一句：这是不是在为一个可扩展的平台做铺垫？答案不一定要“是”，但想清楚，比不明不白地做要强得多。

这里要特别提醒一点：无论做内部平台还是外部开放能力，都要注意数据和内容合规。接口开放意味着数据可能被更广泛地流转，至少要提前确认授权边界、隐私保护和测试环境隔离。特别是在涉及用户画像、人脸、声音、版权素材等敏感能力时，合法授权是平台化的前提，不是可选项。