当我研究了一些市场上知名的互联网/软件/AI 公司的二级域名后，发现了一个惊人的规律

# 当我研究了一些市场上知名的互联网/软件/AI 公司的二级域名后，发现了一个惊人的规律  当我研究了一些市场上知名的互联网/软件/AI 公司的二级域名后，发现了一个惊人的规律。 基于我们讨论的这些公司（Perplexity、Anthropic、OpenAI、Cursor、Framer、Intercom、Mintlify）的二级域名模式，也能看到一些共性。 ## 最惊人的规律 **现代 AI 公司域名策略：主域名 + 2～3 个品牌域名 + 10～20 个核心子域名** ``` 主品牌域名（官网） ├── api.（API 网关） ├── www./chat.（用户界面） ├── trust/legal/privacy（信任页面） ├── dashboard/admin（管理） ├── cdn-/static-（资源） └── status（监控） + 品牌 CDN 域名（*.static.com 格式） ```  这个**标准化子域名架构**确实是现代 SaaS/AI 公司的通用模式，概括了前面分析的公司里反复出现的组合。 **[Perplexity.ai](https://www.perplexity.ai)** 实际存在： - [www.perplexity.ai](https://www.perplexity.ai)（官网） - [docs.perplexity.ai](https://docs.perplexity.ai)（文档） - [api.perplexity.ai](https://api.perplexity.ai)（API） - [labs.perplexity.ai](https://labs.perplexity.ai)（实验） - [blog.perplexity.ai](https://blog.perplexity.ai)（博客） - [podcast.perplexity.ai](https://podcast.perplexity.ai)（播客） **[Anthropic.com](https://www.anthropic.com)** 实际存在： - [www.anthropic.com](https://www.anthropic.com)（官网） - [docs.anthropic.com](https://docs.anthropic.com)（文档） - [api.anthropic.com](https://api.anthropic.com)（API） - [console.anthropic.com](https://console.anthropic.com)（类似 dashboard） - [legal.anthropic.com](https://legal.anthropic.com)（法律） **[OpenAI.com](https://www.openai.com)** 实际存在： - [www.openai.com](https://www.openai.com)（官网） - [chat.openai.com](https://chat.openai.com)（AI 聊天） - [platform.openai.com](https://platform.openai.com)（类似 dashboard） - [admin.openai.com](https://admin.openai.com)（管理） **[Cursor.com](https://www.cursor.com)** 实际存在： - [www.cursor.com](https://www.cursor.com)（官网） - [api.cursor.sh](https://api.cursor.sh)（API） - [trust.cursor.com](https://trust.cursor.com)（信任） **[Framer.com](https://www.framer.com)** 实际存在： - [www.framer.com](https://www.framer.com)（官网） - [api.framer.com](https://api.framer.com)（API） - [docs.framer.com](https://docs.framer.com)（文档） - [gallery.framer.com](https://gallery.framer.com)（类似 resources） ## 这个规律背后的商业逻辑 ``` 核心目的：模块化 + SEO + 信任 ├── SEO：每个子域名独立权重 ├── 用户体验：功能直达（chat.openai.com 一秒进聊天） ├── 信任：trust/legal/docs 强化专业感 ├── 技术隔离：api / 不同 CDN 独立部署 └── 品牌扩展：labs/podcast 展示创新 ``` ## 惊人之处：高覆盖率 清单里这类子域模板在 **SaaS 公司** 中覆盖率极高。这说明： 1. **产品思维趋同**——最佳实践被反复复制 2. **用户心智稳定**——大家都知道 docs/api/trust 去哪找 3. **运维架构标准化**——云厂商与 CDN 进一步固化模式 **引用：** 这套归纳可以直接写成「SaaS 域名与子域设计」的参考框架。 但问题是：要把完整闭环跑起来，往往要采购多家供应商再拼在一起，数据就容易变成孤岛。这时，**统一内容层**的价值会非常明显。 ## 问题本质：供应商碎片化 → 数据孤岛 成功企业常见的闭环需求： - **www.** → 官网（CMS + CDN） - **docs.** → 文档站 - **api.** → API 文档 / 开发者门户 - **blog.** → 内容营销 - **labs.** → 实验与创新展示 - **trust.** → 合规与信任页 - **jobs.** → 招聘与雇主品牌 多家系统叠加，容易出现 **数据不通、体验割裂、运营成本高**。  ## Baklib 的对应思路 用**统一平台**承载多站点、多形态内容，减少「一功能一系统」带来的断裂： - 统一数据与权限，降低孤岛 - 一致的品牌与导航体验 - 更可控的 SEO 与发布流程 - 团队只维护一套后台与规范 ## 商业说服逻辑（示例） **Perplexity** 一类公司需要同时维护：官网 CMS、文档站、博客、播客等——往往是多套系统、多套数据。 **Baklib** 的方向是：把数字体验相关的内容与站点尽量收敛到同一套体系里管理、发布与度量，降低拼接成本。  **对比表（示意）** | 维度 | 传统多供应商 | 统一平台思路 | |------|----------------|----------------| | 系统数量 | 多系统并行 | 尽量合一或强集成 | | 数据 | 易孤岛 | 易拉通与复用 | | 体验 | 易割裂 | 易一致化 | | 成本 | 授权与对接叠加 | 总体拥有成本更可控 | --- *本文由工作区 Markdown 整理发布；配图已上传至 Baklib DAM。*