AI 时代的产品经理，该如何布局企业的内容门户矩阵
浏览：0
巴克励步
产品经理画用户旅程时，习惯从注册、激活、付费讲到留存。但有一个维度常被折叠进「市场去管」或「研发去挂」——用户在成为客户之前、成为开发者之时、成为采购评审对象之际，各自需要不同的内容与入口。 二级域名前缀是这些决策的公开痕迹。本研究对多家 SaaS/AI 公司二级域名样本聚合后发现：成熟样本常见 10～20 个二级前缀；MVP 阶段约 4 类骨干（www + docs + help + status）。对产品经理而言，规划的不是「…
产品经理画用户旅程时，习惯从注册、激活、付费讲到留存。但有一个维度常被折叠进「市场去管」或「研发去挂」——用户在成为客户之前、成为开发者之时、成为采购评审对象之际，各自需要不同的内容与入口。
二级域名前缀是这些决策的公开痕迹。本研究对多家 SaaS/AI 公司二级域名样本聚合后发现：成熟样本常见 10～20 个二级前缀；MVP 阶段约 4 类骨干（www + docs + help + status）。对产品经理而言，规划的不是「买几个域名」，而是受众 × 场景 × 权限矩阵，以及与之匹配的 MVP→成熟路线图。
一、先画矩阵，再批入口清单
| 受众 | 核心场景 | 建议前缀（行业惯例） | 权限 |
|---|---|---|---|
| 潜在客户 | 了解产品与价格 | www, products | 公开 |
| 已购用户 | 完成任务、排障 | help, app | 登录 / 租户 |
| 开发者 | 集成与调试 | docs, api, developers | 公开 + API Key |
| 采购 / 安全 | 合规与 SLA | trust, legal, status | 公开 |
| 员工 | 制度与知识 | intranet | 内网 / SSO |
help vs docs 必须在 PRD 阶段写清：help = 任务步骤；docs = 概念与接口参考。样本中二者均为高频前缀（各计 4 次），许多公司分设——若产品定义模糊，两站内容必然打架。
二、六层架构：排期用的「体验楼层」
把门户当成一栋楼，便于与研发、内容、运营对齐排期：
第1层 门脸层 www / brand
第2层 自助与认知层 help / blog / community
第3层 产品与应用层 app / chat / platform
第4层 开发者与集成层 api / docs / developers
第5层 信任与韧性层 status / trust / privacy
第6层 身份与商业化层 auth / admin / pay
AI 时代新增一层思考：chat 既是产品应用层入口，也是内容体验（提示词、拒答策略、会话升级规则）——
chat 在样本中计次 5，与 platform 并列中腰。三、三阶段路线图（产品视角）
| 阶段 | 骨干内容组合 | 常见技术表现 | 产品要交付的能力 |
|---|---|---|---|
| MVP（约 1 个月） | 门脸 + 文档 + 自助 + 可用性 | www + docs + help + status | 潜客看懂、用户能查、事故可通报 |
| 成长期 | + 获客、开放集成、合规、对话产品 | 约 8～12 前缀 | 开发者路径、AI 检索、采购应答 |
| 成熟期 | + 社区、伙伴、学院、内网、活动 | 约 15～20+ 前缀 | 生态、组织知识、雇主品牌 |
子域数量是果不是因：Mintlify 平台方自身仅 4 个主机却服务海量客户文档；Intercom 20+ 主机呈现 B2B 全景。同一规律，不同剖面。
四、MVP 阶段产品 Checklist
-
绘制受众-场景矩阵（至少四格：潜客 / 用户 / 开发者 / 运维）
-
确认 api 与 docs 发布解耦——网关变更不应拖垮文档站可用性
-
定义 status 服务组件清单，与监控告警源一致
-
明确「无登录即可完成的集成最小路径」需要哪些 docs/api 页面
五、成长期产品 Checklist
-
platform / app / chat 的登录态与租户模型写进架构文档
-
开放平台（developers + api）配额、计费、SLA 对外陈述一致
-
采购常见问题（trust）与产品路线图可见性策略——哪些对外、哪些 NDA
-
评估对话产品（chat）与 help 的升级路径（拒答 → 工单 → 人工）
OpenAI 案例：双根域（
openai.com + chatgpt.com）体现受众分裂——终端用户链路与企业/开发者叙事不宜硬塞同一 IA。产品经理宜先问「谁的主旅程」，再定根域与子域。六、成熟期产品 Checklist
-
intranet / jobs / legal 权限模型与 HR、法务流程对齐
-
labs / 实验性子域与生产隔离策略（避免未发布能力泄露）
-
评估是否需要第二品牌根域（产品子品牌 vs 公司品牌）
-
多区域：app/docs 镜像策略（参考 Intercom 、）
七、信息架构上的四个决策点
1. 子域 vs 路径
docs.company.com 与 company.com/docs 均可；子域利于权限隔离与 CDN 策略，路径利于初期简化。惯例命名影响用户与 Agent 预期。2. 内容源是否 Headless
每个场景独立 CMS → 改一处改三处。产品应推动单一事实源 + 多通道渲染，尤其价格、SLA、数据驻留。
每个场景独立 CMS → 改一处改三处。产品应推动单一事实源 + 多通道渲染，尤其价格、SLA、数据驻留。
3. 公开文档与产品行为版本绑定
AI 会引用你的 docs。公开 API 文档与线上行为不一致，比没人看文档更伤品牌。
AI 会引用你的 docs。公开 API 文档与线上行为不一致，比没人看文档更伤品牌。
4. 空站风险
盲目铺 20 个前缀而无运营能力 → 入口越多、过时信息越多。矩阵规划应与团队产能匹配。
盲目铺 20 个前缀而无运营能力 → 入口越多、过时信息越多。矩阵规划应与团队产能匹配。
八、产品经理的「30 分钟立项法」
- 列出所有对外 URL，标受众与权限。
- 圈出矩阵中的空白格——即下一季度产品内容债。
- 与法务确认 trust/status 是否可进售前包——这往往比新功能更能缩短 enterprise 销售周期。
AI 时代的产品经理，布局内容门户矩阵，本质是把信息架构上升为产品架构的一部分。功能可以迭代，错误的路径预期很难挽回。
与研发对齐的两张「最小架构图」
发布解耦图：api 网关、docs 站点、status 服务分属不同部署单元，避免「发版顺带搞挂文档站」。
权限边界图：auth/admin/pay 与公开 docs 的 Cookie 域、CORS 策略——防止控制台会话泄露到公开爬虫路径。
权限边界图：auth/admin/pay 与公开 docs 的 Cookie 域、CORS 策略——防止控制台会话泄露到公开爬虫路径。
产品评审新功能时，除 PRD 外增加一问：本条能力变更，影响哪几个对外门户的哪几段事实？ 养成习惯后，门户矩阵会从「市场清单」变成「产品交付物」。
关于 Baklib
内容门户矩阵要落地，离不开「受众-场景-权限」与「单一内容源、多站点分发」的基建。Baklib 定位下一代企业数字内容基础设施，提供与行业 18 类体验场景对齐的门户模板，并支持 Headless 架构——产品团队可定义 docs、help、trust、developers 等场景的 IA 与权限，内容团队在同一中台维护事实源，研发通过 API 或标准前端消费内容。
对产品经理的价值在于：MVP 四件套可快速上线，成长期按矩阵扩展场景而不推倒重来；版本化内容与发版流程可挂钩，降低「文档落后于产品」的结构性风险。布局矩阵时，可把 Baklib 当作「门户矩阵的默认骨架」做 POC 对照。了解更多见 www.baklib.com。
数据说明：阶段规模、Top4 集中度来自本研究对多家 SaaS/AI 公司二级域名样本聚合。
