4人团队2周交付：从零搭建统一内容模型、前后台一体化SEO输出的品牌官网。博客与案例共用一套CMS，运营人员自主发布零技术介入。
蓝曜炬辉（广州市蓝曜炬辉科技有限公司）在 2026 年初启动品牌官网建设时，面临一个典型的内容工程问题：博客文章、客户案例、服务介绍三套内容体系各自独立，前台展示不一致，SEO 元数据靠手动维护——每次发一篇文章要改四处地方。
团队决定不买现成 CMS，而是自研一套"内容中台"，作为公司后续所有数字化产品的统一内容底座。
核心矛盾在于"快"与"稳"的平衡：团队只有 4 人核心开发力量，要在两周内完成一个可上线验收的版本，同时保证内容模型能支撑后续博客增长到百篇级别、案例库持续扩容、以及前台 SEO 输出的自动化。
另一个隐性挑战是前后台协同——后台 CMS 的结构化字段（标题/摘要/标签/封面图/技术栈/FAQ Schema）必须和前台 Next.js 详情页模板精确对应。字段定义一旦出错，前台渲染就崩。
我们采用"前台品牌站 + 后台 CMS + Go API"三层架构：
| 指标 | 数据 |
|---|---|
| 统一交付 | 3 端（官网 / 后台 CMS / Go API） |
| 首版上线 | 2 周（从开发到可验收） |
| 内容模型 | 1 套（文章 + 案例统一模板） |
| 团队规模 | 4 人核心团队 |
WordPress 的插件生态在内容体量小的时候没问题，但一旦需要结构化 PostDetail（受众/阅读收益/关键点这些字段）、自动化 SEO JSON-LD 输出、以及与 Go API 的深度集成，维护成本会指数级上升。Strapi 等 Headless CMS 更接近我们的需求，但它们的内容模型不够灵活——我们需要的是文章和案例共用同一套字段体系但前台路由不同的能力，这在通用 CMS 里需要大量 hack。自研 4 人团队 2 周完成，后续所有迭代都在自己掌控的代码库内。
确实赶，但这正是"内容中台"思路的价值——我们不追求首版功能完备，而是追求内容模型正确和 API 接口稳定。首版只做了文章和案例两种内容类型的 CRUD + 前台详情页渲染 + SEO 元数据输出。后续的标签体系、PostDetail 结构化字段、FAQ Schema、内链推荐引擎都是在这个稳定的模型上增量叠加的。如果一上来就做大而全，大概率 2 个月也出不来。
PostDetail 是 B2B 技术内容 GEO 的核心信号。Google 和百度对技术内容的"专业性"评估中，作者资质、目标受众清晰度、阅读收益明确性都是加分项。把 audience（目标读者）、readingGain（阅读收益）、keyPoints（核心论点）、stage（决策阶段）、toolStack（工具栈）作为结构化字段存储，前台可以按需渲染为侧边栏信息卡——这对 B2B 决策者的信任度至关重要。
目前我们已经跑通的：写入文章正文后，AI 自动生成 seoTitle / seoDescription / 标签 / PostDetail JSON / FAQ Schema。内链推荐引擎也已上线——根据文章主题和标签，自动从站内已发布内容中推荐 5-10 条相关文章作为内链候选。这些能力全部在现有内容模型和 API 框架内实现，没有引入新的技术栈。
内容中台已支撑官网 v1 上线。下一步规划：接入 AI 自动生成 SEO 元数据、内链推荐引擎、以及多语言（英文/繁体）内容管理能力——全部在现有内容模型和 API 框架内扩展，不需要推翻重建。
]]>
