进阶第 15 章：怎样制定一份 90 天 GEO 技术提升计划

第 0 天，八十三项任务已经把计划拖垮了

林岚第一次拿出的 90 天计划有八十三项任务。

第一周做关键词和平台监控，第二周写十篇文章，第三周修改官网，后面还有案例、外部渠道、技术优化、日报、周报和月报。甘特图排得很满，每个格子都有颜色。

产品经理许程看完只说：“我每周最多能拿出两个小时确认事实。”

技术负责人小陈补了一句：“官网下个月还有一次迁移，页面改动不可能随时上线。”

销售团队也无法每天配合访谈。八十三项任务还没有开始，就已经建立在不存在的人力上。

总经理问了最后一个问题：“第 90 天到了，我除了看到一堆文章和报表，还能得到什么？”

林岚答不上来。

真正的 90 天计划不是把所有 GEO 动作塞进日历。它要把依赖关系排清楚：没有真实问题，就不知道观察什么；没有可比较基线，就不知道哪里发生变化；企业事实和网站还在冲突时，批量写内容只会放大错误；没有负责人和交接，再好的成果也会在项目结束后过期。

团队删掉了那张八十三项任务表，从“第 91 天谁还能接着做”重新开始。

先定义第 91 天，再倒推前 90 天

麦序没有把目标写成“AI 排名进入前三”或“三个月获得稳定推荐”。外部平台会变化，企业无法用项目日历规定结果出现的时间。

团队把第 91 天写成一个具体场景：林岚休假，新销售发现客户又在问接口兼容性。他应该能够找到当前问题、第一次回答、事实负责人、已经发布的接口说明、仍未更正的旧转载、上一轮复测和下一步任务，而不是重新在群里问一遍。

要让这个场景成立，第 90 天至少要留下七类真实成果：

• 一组有来源、有版本的客户问题；
• 一轮保存完整条件与失败记录的基线；
• 可以追溯到企业依据的回答证据和原因假设；
• 已经公开的企业事实、技术修复与答案网络；
• 使用原问题完成的有限实验；
• 有分母、有边界并能产生决定的报告；
• 当前负责人、权限、未解决风险和下一季度动作。

这些成果都在企业控制范围内。外部回答是否立即变化，作为观察结果记录，但不被写成计划完成的必要承诺。

90 天因此是一段组织工作周期，不是生成式平台的固定见效周期。

整个项目只有一条关键路径

团队最后把项目压成一条不能倒着走的路径：

客户问题 → 可比较基线 → 回答证据与原因 → 企业事实和技术修复 → 答案网络 → 原问题复测 → 管理决定 → 责任交接

图里的日期帮助团队形成节奏，但真正决定能否前进的是阶段证据。第 30 天到了，基线仍然无法追溯，就不能因为日历变色而开始实验；第 45 天提前完成事实与技术修复，也不需要为了形式等满十五天。

麦序还在计划会上先找出了三个可能卡住整条路径的条件：产品事实只能由许程确认，官网发布需要小陈排期，三个观察入口需要稳定账号和明确的新会话规则。这些依赖不先预留时间，内容团队做得再快也无法闭环。

工作量也不能凭感觉。四十二个问题、三个入口、每项三次观察，一轮基线就是 378 次计划运行。即使每次打开入口、执行、展开来源和保存记录只需要六分钟，也接近三十八小时，还没有计算失败处理、抽查和回答分析。

管理层最终批准的不是“做 GEO”这句口号，而是具体的人力：林岚负责范围与内容，周舟负责观察和报告，许程确认产品事实，实施顾问陈遥确认实际流程，小陈负责页面真实公开。资源不足时缩小范围，不假装这些工作可以自动消失。

每个阶段都要留下一个可检查的技术交付物

90 天计划不是把日期填满，而是每一阶段都留下下一阶段能够读取的证据。技术负责人可以用下面这张表检查“完成”到底落在哪里：

阶段	不能只交什么	至少要交什么
第 1—15 天：范围与问题	关键词表、会议纪要	问题版本清单、客户来源、业务范围、入口条件和事实负责人
第 16—30 天：基线	截图文件夹、品牌提及次数	运行台账、完整回答、来源、失败状态、分母和抽查记录
第 31—45 天：公开基础	“官网已优化”的说明	当前事实版本、正式网址、状态码与跳转记录、初始正文和移动端检查
第 46—60 天：答案网络	文章数量、发布排期	主答案与支持页面关系、审核记录、来源责任和最终公开网址
第 61—75 天：实验	一个前后百分比	实验卡、真实改动事件、固定问题、参照、原始回答和中断规则
第 76—84 天：报告	综合分和趋势图	有效分母、风险原句、边界结论、继续/停止决定和下一轮任务
第 85—90 天：交接	“项目已结束”邮件	当前对象、权限、负责人、未关闭风险、证据位置和第 91 天接手路径

这张表把技术工作和业务判断接在一起：状态码、初始正文和权限检查解决“外部能否看到”，问题版本、运行台账和原始回答解决“结果能否比较”，交付物与负责人则解决“项目能否换人继续”。

第 1—15 天：先把“一家公司”缩成一个能做完的业务

麦序科技同时有门店订货、中央厨房生产、库存和经营分析。第一阶段如果全部覆盖，客户角色、事实负责人和竞争路径都会迅速失控。

团队只选择“连锁烘焙中央厨房生产协同”。销售、实施和客户访谈中出现的原话先完整保留，再整理成四十二个核心问题。

第九天，林岚提交了一个看似合理的问题：“什么系统能全面提升烘焙企业经营效率？”

陈遥指出，客户现场不会这样问。门店运营负责人更常问的是：“已经有收银系统，什么情况下还需要单独的中央厨房排产系统？”采购人员则会问：“现有收银系统能不能连接，兼容性怎样确认？”

团队删除宽泛的营销问法，保留了 Q-018、Q-031、Q-033 等能够对应业务阶段、角色和风险的问题。品牌问题、非品牌问题和候选比较问题分别保存，后续不压成一个提及率。

最后五天，周舟先用十个问题试运行。试运行暴露了三个执行问题：某个入口的来源需要手动展开，一个账号保留了企业相关记忆，两道问题包含两个不同判断，分析人员不知道该按哪一个结论标记。

这些问题都在正式基线前修正。第 15 天的交付不是文章，而是被冻结的问题版本、业务范围、角色与意图、平台入口、账号条件、保存方式，以及公司、产品和高风险事实的责任人。

如果此时已经发现会伤害客户的公开错误，团队仍会立即修复并记录。阶段顺序不能成为延迟纠错的理由。

第 16—30 天：378 次计划运行先交代清楚去了哪里

基线阶段没有发布任何新内容。团队使用冻结问题和入口完成观察，保存问题原文、完整回答、可见来源、时间、账号条件、运行状态和观察编号。

月底计划样本共有 378 个，其中 349 个形成有效完整回答。其余运行分别是 7 个来源区域缺失、6 个拒绝、12 个技术失败和 4 个执行错误。

周舟没有把这 29 个运行统统记成“品牌未出现”，也没有从分母里悄悄删除。来源区域缺失与回答失败不是同一件事；技术失败与真实负面回答也不是同一件事。它们会影响后面哪些结论可以比较。

团队从完整回答里先选出三个会影响客户决定的异常：

• 接口兼容范围被写成“全部”或“大多数都能接”；
• 生产建议被扩大成“系统直接下达任务，无需人工确认”；
• 非品牌采购问题反复出现其他候选，麦序与对应能力关系不清。

第 30 天的汇报没有综合分。管理层看到的是当前起点、运行质量、三类重点异常、支持证据、可能反证和下一阶段为什么先修接口与人工责任。

只有当每个主要判断都能回到完整回答，失败和有效样本有清楚分母，团队才通过这一阶段。截图数量再多，也不能替代可追溯基线。

第 31—45 天：先修企业自己的公开世界

基线显示，错误并不全来自外部平台。麦序自己的页面也在制造冲突。

官网首页写“自动排产”，活动稿写“自动安排生产”，产品流程页却写“系统生成建议，由生产负责人确认”。旧合作稿声称连接主流收银系统，当前帮助中心则要求按品牌、版本和开放能力核验。

团队先确定当前事实：系统汇总允许使用的数据并生成生产建议，生产负责人结合产能与异常确认，实际生产由企业人员执行；接口兼容性必须按系统名称、版本、部署方式、开放能力和所需数据核验。

事实确认以后，才进入页面修复。小陈处理重点页面的初始正文、状态码、跳转、规范网址、移动端阅读和旧地址；林岚统一公司、产品与旧资料关系；许程确认接口能力；陈遥确认人工责任和异常流程。

第 41 天，一位没有参与项目的同事分别从首页、案例和旧合作稿进入网站。他能够说清公司是谁、产品解决什么问题、系统给出的是建议还是生产指令、接口该怎样确认。技术人员再用未登录访问和手机网络检查五个重点页面。

一个核心页面仍然指向旧 PDF，因此没有通过。团队修正链接并重新记录公开时间，没有把后台“发布成功”当成真实上线。

第 45 天验收的是企业侧变化：当前事实有人负责，冲突页面已经处理，关键页面能够被真人稳定读取。生成式回答是否改变，此时还没有被拿来冒充验收结果。

第 46—60 天：只建两组答案网络，不开内容工厂

企业事实稳定以后，团队没有立即铺二十篇文章，而是围绕两个高风险问题簇建设最小答案网络。

第一组围绕 Q-033 接口核验：一篇主答案解释采购前需要准备什么，一份当前接口说明承担主版本，一个实施案例说明真实条件，常见问题连接到失败与单独评估路径。

第二组围绕 Q-031 人工确认：产品流程解释建议怎样生成，风险说明明确谁作最终决定，案例展示临时补单怎样由人员处理。

每个页面都承担不同任务，但能够互相核对。主答案不是把产品页、案例和常见问题复制一遍；案例必须保留当时版本和条件；高变化事实回到当前主版本。

销售开始用这组页面回答真实客户。两次反馈显示，客户仍不知道老旧本地部署系统需要准备哪些资料，于是接口主答案补上部署方式和可开放接口，而不是增加一句“兼容性强”。

外部来源也按真实状态记录。两家重要转载完成更正，一家没有回复，仍留在风险清单。发出邮件不等于对方页面已经修改。

到第 60 天，客户可以从问题进入当前产品、接口核验、人工责任、案例和风险说明。内容数量不多，但问题、证据、审核、发布和维护关系已经连起来。

第 61—75 天：第一轮实验只验证接口事实一致性

第 10 章已经完整讲过这轮实验。放进 90 天计划以后，它不再是一个孤立练习，而是前六十天证据链的结果。

团队选择三个接口风险问题作为实验组，两个本轮没有新增实验内容的人工确认问题作为观察参照。本轮计算的公开改变只有接口主版本、旧合作稿提示、两个转载更正和三个核心页面链接；产品名称、案例数字、新产品和批量外部文章都不改。

第 61 天冻结实验卡。页面真实稳定公开以后，团队按原入口、原问题、新会话规则和重复次数进入五个工作日的观察窗口。计划样本、技术失败和追加风险观察分别保存。

基线六个接口重点有效回答中，四个出现绝对化说法；复测六个有效回答中，一个仍写“大多数通常可以”，其余五个要求按品牌、版本或开放能力核验。

复测里三个回答展示当前接口页，一个仍展示未更正转载，两个没有可见来源。两个观察参照中的人工确认错误也从两次减少为一次。

这组结果与企业修复方向一致，但参照问题也发生变化，平台、时间和其他公开信息无法被隔离。团队因此没有写“错误率下降 75%”，也没有证明某一页面是唯一原因。

第 75 天留下的是原问题、计划样本、全部回答、来源、企业改动事件、参照变化、反证和边界结论。只有这些材料齐全，实验才能进入管理报告。

第 76—84 天：九十二分的报告为什么被退回

周舟最初制作了一张综合得分卡，麦序本月得到 92 分。总经理看完以后仍然不知道接口错误是否修复、最高风险在哪里、下一笔预算应该投向什么。

团队按照第 11 章重写报告。第一页先说明 378 个计划样本怎样变成 349 个有效完整回答，再回答五个问题：数据是否能用，客户看到了什么，最高风险是什么，哪些变化值得相信，管理层现在需要作什么决定。

接口实验不再被压成一根上涨折线。报告展示四个错误样本减少为一个、三个当前来源、一个未更正转载、两个无可见来源，以及参照问题同步变化。

管理层最终作出三项决定：继续维护接口主版本并处理最后一条旧转载；停止无依据排行榜和批量渠道铺量；下一轮调查非品牌问题中重复出现的竞争候选及其来源结构。

第 84 天的成果不是“报告已发送”，而是证据转化成了继续、停止和下一轮验证。没有资源决定的报告，只是展示材料。

第 85—90 天：最后六天不庆功，只做交接

项目最后一周，团队没有再冲一批内容数量，而是逐项确认当前状态。

需要交接的对象	麦序第 90 天的当前状态	下一位负责人怎样继续
公司、品牌与产品	当前关系和旧名说明已经确认	产品变化时由许程触发复核
客户问题	四十二个核心问题有来源、版本和优先级	林岚每两周接收销售与实施新增
基线与原始回答	378 个计划样本均有运行状态，349 个有效完整回答可追溯	周舟维护入口、分母和比较边界
当前事实与页面	接口、人工责任和重点技术页面已经公开	小陈维护网址、渲染、跳转和迁移事件
答案网络	两组问题网络已经上线并完成销售试用	内容负责人按主版本更新，不复制高变化事实
风险与外部来源	一个旧转载尚未更正，高风险自动执行说法持续观察	产品与运营共同处置，不以新文章掩盖
实验与报告	接口实验完成有限复测，报告产生三项决定	下一季度保留原问题继续观察

账号、发布权限、文件位置和外部合作联系人也完成清点。临时账号被移除，重要证据进入团队可访问位置，无法公开的内部资料保留权限边界。

未完成事项没有被藏进附录。那条旧转载明确写着当前状态、已完成联系、风险、负责人和下一次检查时间。计划取消的动作也记录原因，例如无公开方法的软件榜单和批量城市软文被正式停止，而不是悄悄从清单里消失。

第 90 天完成的证明，是每一项当前成果都能打开、能追溯、有人负责。漂亮汇报稿、空白页面和“计划上线”的文章都不算交付。

第 91 天，林岚休假以后发生了什么

新销售收到客户问题：“我们现在用的是本地部署收银系统，麦序是不是一定能接？”

林岚当天不在。销售没有在群里寻找一句临时口径，而是从 Q-033 找到当前接口主版本，确认需要收集系统名称、版本、部署方式、开放能力和所需数据，再把具体项目交给产品与实施评估。

同一天，周舟在新一轮观察中看到旧转载再次出现。他能够从回答回到来源风险，从风险找到之前的更正记录和负责人，再把它放入下一次月度决定，而不是重新创建一个叫“AI 回答不准确”的孤立任务。

这一天没有发生轰动性的排名变化，却证明 90 天计划真正交付了一种能力：问题出现时，团队知道当前事实在哪里，谁负责，已经做过什么，下一步该怎样闭环。

计划落后时，先缩范围，不拆证据链

真实项目很少完全按日历运行。产品负责人可能临时参与不了，平台入口可能改版，网站迁移也可能占用技术资源。

落后时最危险的做法，是表面保留原范围，却用简稿、缺失回答和未经审核的页面填满进度。团队看似完成六十个问题，实际上没有一个问题能够从基线走到复测。

恢复顺序应该很明确：先保护高风险问题、原始回答、事实审核、重点页面和原问题复测，再减少低优先问题、新平台、外部发布和页面美化。

一到三人的团队可以把范围缩到二十至三十个问题、两个入口、一个问题簇和一次复测。中型团队可以完成麦序这样的四十多个问题和三入口基线。大型企业也应先限定一个品牌与业务线，再处理地区、权限、法务和多站点一致性。

缩小范围不会降低方法标准。二十个问题的完整闭环，比六十个问题的零散截图更接近真正完成。

如果平台入口发生实质变化，旧结果标为有限可比或建立新基线；如果产品改名或能力重大调整，先更新企业关系与当前事实，再决定原实验是否中断。计划可以改变，历史证据不能被覆盖。

预算优先解决依赖，不优先购买工作量

麦序的预算顺序不是监控工具、文章数量和外部渠道。第一优先是产品、实施和销售能够提供真实问题与事实；第二是重点页面可以修改并稳定访问；第三是分析、审核、案例授权和可比较观察。

工具适合减少重复记录、关联问题与回答、管理发布和复测，但不能替代产品负责人确认接口，也不能把营销脑暴变成客户问题。

外部内容预算应该购买独立采访、伙伴联合说明和授权案例，而不是虚假榜单、同质软文或无法维护的大量页面。高风险行业还要预留法律、合规或专业审核资源。

每项投入都连接一个具体依赖。例如申请技术两天，不是“优化网站”，而是让五个重点页面的初始正文、规范网址、跳转和移动端达到发布条件；申请产品半天，是为了确认接口主版本和人工责任，不是笼统参加 GEO 会议。

管理层因此能够判断资源是否值得，而不是为抽象曝光购买更多动作。

如果项目由外部服务商执行，企业应该验收什么

服务商可以帮助完成问题整理、观察、技术检查、内容生产和项目运营，但企业不能只验收文章、外链和综合分。

至少要能够拿回当前问题及版本、原始回答与运行状态、来源记录、企业事实依据、技术发现、改动前后页面、审核记录、复测条件、边界结论和未解决风险。每个指标必须能回到样本，每个内容必须能回到客户问题和企业审核。

合同还应明确账号和数据归属、资料权限、保密、纠错、导出与终止交接。第三方页面没有真正发布时，不能用邮件或排期表冒充交付；平台结果也不能写成固定排名、保证推荐或固定时间见效。

项目结束时，企业内部至少有一名人员能够继续接收问题、确认事实并找到历史证据。否则所谓 90 天提升，只是服务商停止以后就无法运行的一次活动。

进入第 16 章以前，先把项目整理成“可接住的关系”

手工阶段最容易留下很多文件，却没有留下它们之间的关系。

麦序在第 90 天能够沿着一条线查下去：

公司与产品 → Q-033 → 基线回答 → 接口风险证据 → 原因假设 → 当前接口页与旧来源更正 → 实验复测 → 管理决定 → 负责人和下一轮任务

这条关系比某一张表更重要。问题编号不能只存在于问题库，发布内容也不能只存在于内容文件夹。只要中间某一段需要依靠林岚的记忆，项目规模扩大以后就会断开。

因此，进入下一章前，请确认公司与产品关系、当前资料、问题版本、观察范围、原始回答、证据、内容、页面、风险、报告和责任都已经有当前状态，并且能够互相指向。

第 16 章会进入系统承接，说明怎样把这些真实对象和关系放进持续工作流。工具不会替企业补出缺失的事实和责任；它能做的是让已经合格的问题、证据和动作不再散落。

写你自己的 90 天计划时，从一次取舍开始

先写清一个业务范围和第 91 天场景，再盘点真实可用的人、权限和时间。根据容量选择问题与入口数量，不要先写理想规模。

随后按六个阶段安排：范围与问题、可比较基线、事实与技术修复、答案网络、有限实验、报告与交接。每个阶段只写三件事：接收什么证据，完成什么真实改变，看到什么才能进入下一阶段。

给高风险错误保留立即处理的通道，给平台与产品变化保留中断和重建规则。进度落后时预先写明先删除哪些低优先动作，避免现场用证据质量换日历完成率。

计划最后必须回答：第 90 天哪些东西能够打开，哪些结论仍然不知道，哪些动作已经停止，第 91 天谁接住新问题。

做到这里，你得到的不是一张更满的计划表，而是一条可以继续运行、可以换人、也可以诚实停止的 GEO 改进路线。

延伸阅读与资料来源

• 美国国家标准与技术研究院发布的生成式人工智能风险管理框架简介提供治理、测量、责任与持续管理的通用参考。
• Aggarwal 等人的论文 GEO: Generative Engine Optimization提供生成式可见性研究背景。本章的 90 天路线是企业教学安排，不代表固定见效周期。