先给结论：需求书要把“想做 GEO”变成可交付项目

GEO 项目需求书不是一份把“提高 AI 曝光”写得更漂亮的宣传文案，而是项目开始前对目标、页面、问题、技术、证据、权限、预算和验收方式的共同约定。它要让执行人员知道改哪些页面、交什么材料、用什么条件检查，也要让站点所有者知道哪些结果可以要求交付，哪些结果只能在发布后观察。

一份合格的需求书，应该能让另一个没有参加前期沟通的人独立回答六个问题：项目服务谁，解决什么具体问题，覆盖哪些 URL，准备交付什么，如何证明交付完成，哪些搜索或 AI 结果不属于可控承诺。如果只能写出“做关键词、发文章、提升收录”，项目范围还没有被定义清楚。

最小可用结构

GEO 项目需求书 = 项目目标 + 页面与问题范围 + 基线与环境 + 交付物 + 证据要求 + 权限与隐私边界 + 验收标准 + 复测计划 + 变更和退出规则。

为什么要先写需求书

GEO 项目经常从一句很宽泛的要求开始：“让 AI 更容易找到我们”“做一下 GEO”“把网站推广到搜索引擎”。这些表达可以作为方向，却不能直接作为开发、内容生产或服务采购的任务。它们没有说明对象、范围、时间、证据和完成条件，项目进行到一半时就容易出现三种错位：执行方以为交付了页面，站点所有者以为应该看到排名；报告记录了品牌提及，需求方以为那就是准确引用；接口接受了提交，团队以为页面已经收录。

需求书的价值不是把不确定结果变得确定，而是把不确定性显式写出来。页面是否上线、标题是否修改、来源是否归档、canonical 是否一致，这些可以设定完成条件；搜索平台何时抓取、AI 是否在某个问题下展示来源、流量是否增长，则应作为观察目标，写明条件、窗口和未知状态。Google 的搜索流程说明本身也区分抓取、索引和结果呈现，项目需求书应沿用这种分层方式。

第一步：把目标写成任务，不要只写结果口号

目标最好由“对象 + 场景 + 动作 + 可观察产物”组成。例如，“让 AI 更容易引用”可以改写为：“为 8 篇核心教程建立固定的问题集、声明级证据记录和页面版本台账，并在发布后按 T+0、T+7 和 T+30 记录品牌提及、页面引用、引用准确与回答完整。”后一个目标没有承诺平台一定引用，但执行方知道要交付哪些东西。

宽泛目标可执行改写仍然不能直接承诺
提高 AI 曝光固定平台、问题和环境，记录品牌提及、来源链接、页面引用和引用准确。所有平台长期展示品牌。
做好 GEO 优化检查目标页面的主问题、直接答案、实体、声明证据、内链和机器入口。页面一定排名或被 AI 采用。
加快收录确认正式 URL、sitemap、robots、canonical 和提交台账，并安排平台状态复测。提交后一定在某个日期收录。
提升内容质量为每页补充适用条件、步骤、例外、来源、版本和维护责任。字数增加就一定带来流量。
做 GEO 监测规定数据字段、采集窗口、权限、存储期限、导出格式和未知状态。监测数字自动解释成业务增长。

写目标时可以把搜索发现、页面索引、AI 回答和业务行为分成四个层级。每个层级使用自己的证据，不用一个“GEO 分数”替代全部问题。具体指标定义可以参考GEO 效果衡量框架，项目交付和外部结果的边界可以参考GEO 项目验收标准。

第二步：冻结页面、问题和平台范围

需求书最重要的部分通常不是目标，而是范围。没有 URL 清单，内容团队可能批量扩写并不需要的页面；没有问题集，AI 复测每次都换问题；没有平台和环境，报告中的两次回答就无法比较。范围越清楚，项目越容易控制成本和解释结果。

范围对象必须明确示例
域名与 URL正式域名、协议、尾斜杠、参数处理、包含和排除的路径。只覆盖 https://example.com/content/ 下的 10 个教程页。
页面角色首页、定义页、教程页、案例页、实验页、工具页或证据页。3 篇定义/支柱页，5 篇教程页，2 篇实验记录。
用户问题问题原文、意图、决策阶段、主问题与辅助追问。“GEO 项目怎么验收？”而不是只写“GEO”。
平台搜索平台、AI 平台、分析工具和是否包含人工观察。百度、Bing、Google 状态分别记录；国内 AI 平台按固定问题观察。
环境语言、地区、设备、登录状态、联网状态、账号类型和时间区。简体中文、中国大陆、桌面端、未登录、联网。
不在范围内广告投放、外链采购、平台账号代运营、业务转化承诺或未授权数据。不包含购买外部链接，也不保证排名位置。

范围表应采用 URL 级清单，而不是只写“全站”。如果确实要覆盖全站，应说明关键页面全检、普通页面如何分层抽样、抽样分母和未检查范围。批量页面还要写明是否允许新增城市页、标签页或同义词页，避免在项目中途出现重复和薄内容。

第三步：保存基线，避免把改动前后混在一起

在修改内容或技术配置前，先保存基线。基线不是把页面截图存起来就结束，而是要让后续人员知道当时页面是什么版本、机器入口是什么状态、搜索与 AI 观察在什么条件下进行。基线越完整，项目越能解释差异；基线缺失时，改版前后看到两个结果，也无法判断差异来自页面、平台还是问题条件。

基线项建议记录用途
页面内容标题、description、H1、正文摘要、目录、来源和截图或快照。比较内容和页面角色是否改变。
技术入口HTTP、最终 URL、canonical、robots、sitemap、RSS、JSON-LD 和 llms.txt。定位访问、归一、发现和解析问题。
声明证据声明文本、来源 URL、摘录、定位、复核日期、版本和限制。判断来源是否支持当前结论，而不是只看链接数量。
平台观察问题原文、平台、时间、语言、地区、联网、登录、完整回答和来源区域。让下一轮复测具备相近条件。
业务数据统计口径、归因窗口、去重方式、权限和数据保留期限。避免把一次访问或来源链接解释成转化结果。

版本管理要区分首次发布日期、实质修改日期、来源复核日期和平台观察时间。可以参考GEO 页面版本管理教程，为正文、证据、机器入口和复测结果建立共同的版本标识。若改动涉及 robots、canonical、批量模板或数据模型，还应保存改动前的配置与回滚方式。

第四步：把交付物写成可打开、可比较的产物

需求书不能只列“策略、内容、技术、监测”四个大词。每个阶段都应该落到具体文件、页面、数据或检查记录，并写出最小完成条件。交付物表越具体，报价、排期、验收和后续维护越少争议。

阶段交付物最小完成条件证据形式
诊断与规划问题地图、页面角色、URL 清单、优先级和路线图。每个目标问题有一个主页面或明确的现有页面归属。表格、版本号、决策记录。
内容改造页面正文、直接答案、步骤、例外、FAQ、内链和编辑说明。线上页面与提交版本一致，关键段落能独立理解。页面 URL、差异稿、来源表。
证据建设声明级证据库、来源摘录、定位、限制和复核日期。关键声明逐条可回到来源或明确标为未知。JSON、Markdown 或可导出的账本。
技术实施访问、canonical、robots、sitemap、RSS、结构化数据和机器入口检查。目标 URL 返回预期状态，入口之间没有明显矛盾。逐 URL 检查报告、HTML 和日志。
平台观察搜索平台提交/查询和 AI 固定问题复测。原始响应、回答、来源、条件和未知项均已归档。平台记录、截图、回答原文、时间戳。
交接维护源文件、权限、责任人、更新触发器、备份和回滚说明。接收方可以独立修改一页并重新运行检查。交接清单、权限确认、操作说明。

“完成 20 篇文章”不是充分的交付条件。需求书还要规定文章的页面角色、主问题、来源要求、禁用表述、发布日期、版本和是否必须补充声明级证据。相反，也不要把“获得 20 次 AI 引用”写成内容团队可以单独关闭的交付项；它应该进入观察层，配合固定问题和平台条件报告。

第五步：规定内容质量，而不是只规定字数

内容需求可以写得很具体，但不要把字数、关键词密度或标题数量当成质量本身。更有用的写法是规定页面要完成哪些读者任务：开头给出直接答案，正文说明条件和步骤，关键事实有来源，例外和未知状态可见，最后提供下一步动作。Google 的以人为本的内容说明强调内容应当对读者有帮助、可靠且面向真实任务，这比单纯扩充篇幅更适合作为内容验收方向。

内容要求需求书可以这样写检查证据
主问题标题、H1、首段和正文围绕同一个主要任务，辅助问题不得改变页面角色。页面任务句、标题层级、编辑检查。
直接答案首段先给结论，再写范围、条件和不代表什么。首屏 HTML、人工阅读记录。
可执行性步骤写出输入、动作、输出、完成条件和失败处理。步骤表、示例、验收字段。
声明边界把事实、第一方观察、推断、建议和未知分开标记。声明级证据、编辑注记。
可维护性标注发布日期、修改原因、来源复核日期、责任人和复核触发器。页面元数据、变更日志、维护台账。
可引用性重要结论可以脱离上下文理解，但不把可摘取写成必然引用。答案块、来源、平台复测记录。

如果需求书要求“自然融入关键词”，还应补充同义词归属和页面边界：哪些词由一个页面统一承接，哪些词必须进入另一个页面，哪些词由于含义歧义被排除。不要为了覆盖 geo是什么、geo是什么意思、geo是啥 建立多个只有替换词语的薄页面。

第六步：把证据要求提前写进需求书

很多项目在文章写完后才发现来源不完整，只能再去补链接。更稳妥的做法是在需求书阶段就规定证据对象、来源优先级、摘录格式、定位、复核日期和边界。来源数量不是核心指标，关键是来源是否支持这条声明的对象、条件、时间、数字和结论强度。

声明类型优先来源最低记录不可外推
平台规则相关搜索或 AI 平台官方文档。原文链接、标题、摘录、定位、访问日期和适用范围。不能由一个平台规则推出所有平台行为。
技术状态线上响应、配置、服务器日志或平台原始状态。请求时间、URL、状态、环境、版本和原始输出。不能由 HTTP 200 推出收录或引用。
实验观察冻结问题、平台、环境和页面版本后的原始回答。完整回答、来源链接、截图/转录、判定理由和限制。不能把一次样本写成长期平台规律。
编辑建议明确标注为站内方法或工作假设。适用场景、提出理由、反例、复核触发器。不能伪装成官方规则或实证结论。

可以参考GEO 声明级证据库和GEO 证据支持范围审计。需求书里要允许“未知”：来源超时、平台不可访问、回答中断、尚未到复测窗口，都应保留原状态，而不是为了让报告看起来完整而填成“否”。

第七步：写清技术范围和机器入口

技术需求应按访问、解析、归一、发现和后续观察分层。不要只写“做好 SEO 技术”，而要列出要检查的 URL、入口和输出。页面返回 200 是一个过程信号，不能越级替代收录状态；提交接口接受也不能替代抓取和索引证据。

技术层需求书要写什么交付验证
正式入口HTTPS、主域名、www 跳转、尾斜杠、参数和临时域名处理。不同入口的状态、最终 URL 和 canonical。
正文解析标题、H1、首段、主要小标题和关键正文是否可读取。服务端 HTML、内容类型和最小正文检查。
发现路径栏目页、内链、sitemap、RSS、站点索引和 llms.txt 的覆盖范围。入口文件、链接关系和 URL 清单。
归一关系canonical、内部链接、结构化数据、RSS 和 sitemap 是否指向同一规范地址。逐 URL 差异表和异常处理。
提交台账提交平台、密钥/权限责任、URL、批次、响应、重试和后续复测。原始响应与台账记录。
安全与回滚robots、限流、后台保护、敏感路径、备份和回滚路径。发布前检查、日志和恢复演练记录。

如果项目包含 IndexNow，需求书应写明密钥验证文件、规范 URL、变更触发条件和失败处理。IndexNow 官方文档说明 HTTP 200 只表示搜索引擎收到 URL，因此“提交接口返回成功”只能关闭通知动作，不能关闭收录观察。对于百度主动提交，也要把站点、token、配额、请求地址和响应正文作为独立配置核对，避免主域名和子域名共用错误参数。

第八步：提前定义数据、隐私和权限边界

GEO 项目可能涉及访问日志、IP、设备、地区、后台账号、平台回答截图和搜索平台凭证。需求书必须说明哪些数据会被采集，谁能查看，保存多长时间，公开报告如何脱敏，项目结束后如何导出或删除。只有“我们会做数据分析”不够，执行方和站点所有者都需要知道数据边界。

对象需求书要明确建议原则
服务器日志采集字段、访问者 IP 是否保存、保留期限、脱敏和查看角色。公开研究只展示必要汇总，不公开后台凭证和无关个人信息。
AI 回答是否保存原文、截图、转录、平台名称、账号和授权范围。原始材料与公开脱敏副本分层保存，不用整理稿覆盖原件。
搜索平台账号账号所有权、谁操作、凭证存放位置、撤销方式和交接责任。站点所有者保留所有权，执行人员使用最小必要权限。
代码和内容源仓库、服务器、备份、发布权限、审阅和回滚流程。项目结束后接收方可以独立编辑、发布和恢复。
公开研究数据哪些字段可公开，哪些字段必须隐藏或聚合。公开方法和必要证据，不公开 IP、私密会话或未授权材料。

W3C 的PROV-Overview把来源信息描述为与实体、活动和参与者有关的过程信息，可用于评估数据质量、可靠性和可信度。对 GEO 项目来说，这意味着需求书除了写最终报告，还应写原始回答、页面版本、采集活动和审核判断之间的关联；这不是要求把所有私人数据公开，而是要求内部可以追溯。

第九步：把预算和人力拆成工作包

GEO 项目很难用“每篇文章多少钱”准确描述成本。需求书应按工作包拆分诊断、问题研究、内容、技术、证据、实验、数据处理和维护，并注明每项的页面数量、问题数量、平台数量、修改轮次和是否包含开发。这样既便于比较服务商，也便于在范围变更时重新估算。

工作包影响成本的变量需要写出的交付
诊断与策略URL 数量、问题数量、页面角色、现有资料和报告深度。范围单、基线、问题地图和优先级。
内容研究与写作原创研究、来源核验、页面长度、图表、审稿和修改轮次。正文、来源、摘要、FAQ、版本差异和编辑说明。
技术实施CMS/框架、开发权限、模板数量、部署方式和回滚要求。线上改动、测试、配置差异和发布记录。
证据与实验声明数量、平台数量、问题集、观察窗口、截图转录和人工核验。证据账本、原始回答、判定表和复测报告。
持续维护来源复核频率、旧文更新、异常响应、平台变化和月度报告。维护台账、变更日志和下一轮计划。

需求书可以写预算区间，但不能用价格推导效果；也不要把“低价批量页面”当成低风险方案。批量新增页面会增加证据、内链、维护、技术入口和复测成本。若需要压缩预算，应明确减少哪一层工作和会失去什么证据，而不是只减少文章单价。

第十步：把验收标准写成状态和证据

需求书中的验收标准应同时包含完成条件、证据位置、负责人和状态定义。建议至少使用“通过、失败、未知、阻塞、不适用、未测试”六种状态。通过代表当前条件满足，未知代表材料不足或环境不可用，未测试代表工作尚未执行；这些状态不能互换。

验收层通过条件证据不能直接写成
需求范围URL、问题、平台、环境和排除项已确认。签字或确认记录、版本号。项目一定有效。
页面交付目标页面正文、标题、内链、来源和版本达到约定要求。线上 URL、差异稿、来源表。已经排名。
技术交付访问、正文、canonical、机器入口和发布检查通过。HTTP、HTML、sitemap、robots、检查报告。已经收录。
证据交付关键声明有匹配来源、摘录、定位和边界。声明级证据账本。AI 一定会引用。
复测交付固定问题和条件下保存完整回答、来源和人工判定。原始回答、截图、时间和页面版本。全平台引用率提升。
结果观察按窗口报告发现、抓取、索引、提及、引用和行为数据。平台状态、日志、分析报告和限制。改动单独导致业务增长。

更完整的逐项验收方法见GEO 项目验收标准。需求书可以引用那篇教程的状态定义，但仍要根据本项目的 URL、平台和交付范围写自己的清单，不能把通用模板直接当作项目事实。

第十一步：为发布后复测预留条件

复测计划要在项目开始前写进去，否则发布后很容易因为没有预算、没有权限或没有固定问题而无法比较。复测计划至少包含观察对象、时间窗口、执行人、原始材料、状态值和下一步动作。T+0 可以检查页面发布和提交，T+3 或 T+7 可以查看过程信号，T+14 和 T+30 再观察较长窗口，但这些是工作安排，不是平台承诺的处理时间。

窗口检查对象保存材料避免的误判
T+0正式 URL、正文、canonical、机器入口和提交动作。线上响应、版本、提交批次和初始状态。提交成功等于收录。
T+3 至 T+7平台发现、抓取日志、状态变化和固定问题小样本。平台原始状态、日志、完整回答和来源。一次出现品牌就是稳定引用。
T+14页面引用、内容采用、引用准确和技术回归。与基线并列的回答、页面版本和判定。单轮差异就是改稿因果。
T+30搜索表现、访问行为和业务目标。分平台数据、归因窗口、去重和限制。所有增长都来自 AI。

复测时要保留未完成、拒答、超时和无法访问，不要为了计算比例把它们都放进“否”。AI 平台观察尤其要保留问题原文、完整回答、来源区域、页面版本和运行条件；品牌提及、页面引用、引用准确和回答完整要分列记录。

第十二步：写清变更、暂停和退出规则

需求书不是签署后就不会变化。搜索平台规则、业务重点、页面事实、来源可用性和技术架构都可能变化，因此要提前规定哪些变化属于原范围内维护，哪些变化需要重新估价、延期或暂停。变更控制能避免“顺便再做几篇”“顺便把全站改完”不断扩大项目。

变化类型处理方式应更新的记录
事实或来源变化重新核验声明，必要时修正文案和证据。来源日期、摘录、限制、页面版本。
新增或删除 URL更新范围表，评估内链、sitemap、提交和复测影响。URL 清单、预算、版本和提交台账。
平台或问题变化冻结旧轮次，另建新问题集或新环境，不直接混算。问题集版本、平台入口、环境和分母。
技术架构变化先做回归检查，再决定是否需要重新发布或回滚。部署版本、HTML、canonical、机器入口。
项目暂停或退出保存当前状态，交付源文件和原始证据，撤销临时权限。暂停原因、未完成项、交接、备份和权限记录。

任何实质内容更新都应说明修改原因，而不是只刷新日期。若下一轮要比较 AI 回答，应同步记录页面版本和变更摘要；若只是重新打开来源复核，也不要把它写成正文已更新。

给服务商的需求书应该怎么发

如果需求书用于询价或招标，建议把“背景与目标”“范围与排除项”“交付物”“证据与数据”“时间与协作”“验收”“报价格式”分开。让每个服务商针对同一份范围回答，才有可比性。不要先告诉对方你想要的排名数字，再让服务商自行猜页面、平台和验收方式。

询价问题合格回答应包含风险信号
准备改哪些页面？URL、页面角色、问题、改动原因和不改动的页面。只说“全站优化”或承诺批量生成。
如何判断内容完成？直接答案、条件、来源、版本、内链和人工审稿标准。只给字数、关键词次数或 AI 生成数量。
如何报告 AI 引用？平台、问题、环境、完整回答、来源、页面引用和准确性判定。只报没有分母的“曝光率”。
如何处理收录？访问、发现、提交、抓取、索引和复测分层。保证某天收录、排名或所有平台引用。
项目结束交付什么？源文件、权限、原始证据、配置、备份、回滚和维护手册。报告只能在线查看，账号和源文件不交接。

服务商选择可以继续阅读GEO 推广/优化公司怎么选。需求书的作用是让服务商针对同一组问题给出可比较方案，不是提前把某个服务商的方案包装成行业标准。

可直接复制的 GEO 项目需求书模板

# GEO 项目需求书

项目名称：
需求书版本：geo-brief-YYYYMMDD-001
提出方与联系人：
计划开始 / 结束时间：

## 一、项目目标
- 主要业务或内容背景：
- 目标用户与场景：
- 要解决的具体问题：
- 可交付的过程目标：
- 需要观察但不承诺的外部结果：

## 二、范围与排除项
- 正式域名：
- 目标 URL：
- 页面角色：
- 问题集版本：
- 搜索 / AI 平台：
- 语言、地区、设备、登录与联网条件：
- 包含项：
- 排除项：

## 三、基线
- 页面版本与快照：
- 标题、H1 与摘要：
- canonical、robots、sitemap、RSS、结构化数据：
- 已有声明级证据：
- 既有平台观察与分母：

## 四、交付物
| 工作包 | 目标 URL / 数据集 | 数量 | 完成条件 | 证据位置 | 负责人 |
| --- | --- | ---: | --- | --- | --- |

## 五、内容与证据要求
- 首段直接答案：
- 必须覆盖的条件、例外与步骤：
- 来源优先级与摘录格式：
- 声明状态：supported / partial / unknown / recommendation：
- 禁止使用或需要复核的表述：

## 六、技术与权限
- 代码、服务器、CMS、搜索平台和分析平台权限：
- robots、sitemap、canonical、RSS、llms.txt 和结构化数据：
- 数据采集、脱敏、访问角色和保留期限：
- 备份与回滚：

## 七、验收与复测
| 验收层 | 通过条件 | 证据 | 状态 |
| --- | --- | --- | --- |
| 范围与基线 |  |  |  |
| 页面与内容 |  |  |  |
| 证据 |  |  |  |
| 技术 |  |  |  |
| 平台观察 |  |  |  |

复测窗口：T+0 / T+3 / T+7 / T+14 / T+30
未知、失败、未测试和不适用的处理方式：

## 八、报价、变更与交接
- 报价按工作包拆分：
- 包含的修改轮次：
- 超出范围的判定：
- 变更审批人：
- 源文件、账号、原始证据和备份交接：
- 暂停、退出与临时权限撤销：

模板可以按项目规模缩短，但不建议删除范围、证据、状态、权限和排除项。对小项目而言，一页表格也可以承载这些字段；对大项目而言，应把 URL 清单、问题集、声明证据和平台观察拆成独立附件，并用版本号关联。

常见问题

需求书是不是只有找服务商时才需要？

不是。内部团队自己做 GEO 时同样需要需求书，只是把“服务商交付”改成“团队工作包”。它能帮助内容、开发、数据和运营使用同一套范围、版本和验收口径。

可以直接把“提升收录”写成项目目标吗？

可以写成观察目标，但不应写成团队可以单独保证的交付结果。需求书应同时写页面可访问、机器入口、提交记录和复测窗口，并明确收录状态由平台工具或经过核验的观察证据决定。

需求书写得越详细越好吗？

详细不等于堆字段。优先写会影响范围、成本、证据和验收的内容。与当前项目无关的平台、页面和数据不要硬塞进需求书，否则反而会削弱主线。

AI 回答截图可以作为唯一验收证据吗？

通常不够。截图能保留界面状态，但还需要问题原文、平台、时间、环境、完整回答、来源链接、页面版本和人工判定。若截图无法确认来源或回答被截断，应标记证据不完整。

需求书发布后可以修改问题集吗？

可以，但要创建新版本并冻结旧轮次。问题变化会影响回答和分母，不能把新旧问题的结果直接合并成一条趋势。变更原因、时间和影响范围都应写进变更记录。

发布需求书前的最小检查清单

  1. 目标已经从“提高曝光”改写成具体对象、动作和可观察产物。
  2. 正式域名、URL、页面角色、问题集、平台和环境已经列清。
  3. 包含项、排除项和不可控的外部结果已经明确。
  4. 页面、证据、技术、复测、数据和交接都有具体交付物。
  5. 每个交付物都有完成条件、证据位置、负责人和状态。
  6. 内容要求关注任务、条件、来源和维护，不只规定字数或关键词数量。
  7. 平台提交、抓取、索引、提及、引用和业务行为分别记录。
  8. 数据采集、脱敏、权限、保留期限、备份和回滚方式已经说明。
  9. 复测窗口、问题集版本、分母和未知状态的处理方式已经写入。
  10. 变更、暂停、退出和项目结束后的交接规则已经确认。

结果边界：需求书能约束项目，不能控制平台

一份好的 GEO 项目需求书可以约束工作范围、页面质量、证据记录、技术发布、权限交接和复测方法，让项目交付变得可检查。它不能控制搜索引擎的抓取调度、索引判断、排名变化或 AI 平台在某个问题下是否展示来源，也不能单独证明业务增长由本次项目造成。

因此，需求书最重要的成果不是承诺一个漂亮数字，而是让每个数字都有来源、分母、时间、页面版本和适用边界。项目开始前写清这些内容，项目结束后才有可能判断做了什么、观察到什么，以及下一步还需要验证什么。