SEO Page Builder

创建 SEO 页面

把已验证的搜索需求和 SERP 证据转化成产品现有技术栈与设计系统中的完整页面。

开始前完整读取 内容质量与投入度。

输入门槛

必须取得：

• 目标用户、搜索情境和任务；
• 主关键词家族、意图、季节性和需求证据；
• 每个候选词前三到五个相关头部页面；
• 每个头部页面自上而下的区块描述；
• 搜索引擎层、用户层和质量层拆解；
• 跨页面的信息增益缺口；
• 产品能力、期望用户动作和转化路径；
• 品牌、法律、技术和来源约束。

缺少这些证据时，向调用 Model 报告并返回 $research-seo-demand，不得从关键词量、摘要或 URL 列表直接设计页面。

用 SERP 决定页面形态

• 工具意图：提供可运行工具或直接产品动作。
• 模板/资源意图：提供可以浏览、筛选和有效预览的集合。
• 怎么做意图：提供完整教程、具体步骤、示例和判断标准。
• 比较意图：给出明确标准、证据、差异和选择结论。
• 解决方案意图：围绕一个具体问题组织页面，并提供可信证据和真实行动路径。
• 社区内容占据头部：考虑在对应平台提供原生内容，或让页面吸收该形态的真实问题与经验密度。

产品能直接完成任务时使用混合形态：先完整满足信息意图，再在最有用的节点提供产品动作。

先写页面设计文档

代码之前先写叙述性设计文档：

# <URL 路径> 页面设计文档

title: <最终 title>
description: <最终 description>
keywords: <必要时填写>
canonical: <最终 canonical>

## 页面结构（自上而下）

1. 首屏：<一句话描述这一块展示什么>
2. <区块名>：<一句话描述这一块展示什么>

## 数据与引用清单

- <正文中的数字或事实主张>：<内部数据口径或外部一手来源 URL>

页面结构必须来自 winner 页的逐块描述和产品真正有用的差异。每个区块恰好一句话，只写内容与形式：

• 不解释这一块吃什么词；
• 不写排期和上线计划；
• 不论证为什么需要这一块；
• metadata 写最终上线文案，不写备选方案；
• 数据与引用清单必填；无法给出来源的数字和主张从正文删除。

创造信息增益

至少加入能支持用户行动或判断的材料：

• 具体流程、示例和反例；
• 质量标准、rubric 和阈值；
• 真实产品行为或一手证据；
• 对相关数据的原创分析；
• 可复制表格、清单或交付物；
• 权威一手来源；
• 适用条件、边界和失败模式。

资源发现是任务时，提供分类、点评和原始链接，不重新托管无权分发的文件。

撰写页面

• 用答案、工具动作或用户需要做出的选择开头。
• 使用短句和稳定术语。
• 每一节能够独立理解和抽取。
• 在要求转化前先交付有用内容。
• 常识保持简短，把篇幅留给独有方法、标准和证据。
• 显示真实作者、团队或内容责任主体及更新时间。
• 转化动作必须延续用户进入页面时要完成的任务。

Meta description 只选择一个信息量高的判断、方法、限制或结果，用自然完整的句子讲清楚；不要写成页面目录，也不要为了接近固定字数堆砌区块和功能。

添加图片

先写清每张图片必须解释的任务、对象或结果。产品行为优先使用真实浏览器截图；需要生成或编辑的概念图、封面和辅助素材调用 $generate-image。生成时把参考图和真实截图直接作为 reference image 传入模型，不使用 SVG/HTML 模板或“占位符后填充”流程。

逐张检查文字、对象、顺序、场景、裁剪和移动端可读性。使用稳定文件名、明确尺寸、适当压缩和描述性 alt。

实现与验证

遵循产品仓库现有框架、组件、视觉系统、路由和发布流程。按页面需要加入：

• title 与 meta description；
• canonical；
• Open Graph 和社交 metadata；
• 对应 schema.org 结构化数据；
• 单一、清楚的标题层级；
• 上下文内链；
• sitemap；
• 来源链接、作者和更新时间；
• 响应式和无障碍内容。

运行产品已有的格式化、类型、构建、路由、SEO 和无障碍检查，并用 Runtime 的真实浏览器检查最终渲染页面。把实现后的页面交给 $review-seo-page 对抗审阅。