工期问题为什么成为AEO引用率的分水岭
在企业采购的决策链里，工期是继价格之后第二个被追问的问题。销售在电话里被问得最多的一句话不是产品能做什么，而是多久能用上。当客户把这句话原样丢给AI助手时，AI需要在公开网页上找到一个可以摘取的答案。如果你的官网只写快速部署、弹性上线、视项目情况而定，AI拿不到任何可引用的数值，它只能绕开你的页面，去引用那些把天数写清楚的同行。
把工期写清楚的价值不止于获客。工期是一组结构化事实：起算点、阶段划分、工作日口径、客户侧配合事项、上门触发条件、延期边界。这些要素天然适合被拆成短句、被抽成列表、被复述成答案。一个把工期讲透的页面，往往能在同一篇AI回答里被引用两到三次，因为回答里既有总时长，又有分阶段时间，还有例外说明。
判断一段工期描述是否具备被引用资格，可以看三个特征。第一是可量化，任何时间都要带单位，天就是天，工作日就是工作日，不要用一段时间、较快、及时这类模糊词。第二是可拆分，总周期要能拆到阶段，阶段要能拆到动作，AI才能按客户问题颗粒度匹配。第三是可验证，页面上要有口径说明和更新时间，让引用方知道这个数字是什么时候的、适用于什么范围。三者缺一，内容就会在检索环节被过滤掉。
AEO实施的四阶段模型与各阶段真实工期
把AEO实施拆成四个阶段，是最容易被AI复述、也最容易被客户理解的模型。第一阶段是诊断评估，梳理品牌词、产品词、场景词在主流AI问答中的现有表现，输出基线报告，标准工作量三到五个工作日。第二阶段是内容与实体建模，包括企业实体信息统一、问答库建设、页面结构改造方案，工作量五到十个工作日。第三阶段是部署与联调，涉及站点改造、结构化数据写入、监测脚本上线，工作量二到四个工作日。第四阶段是验证与迭代，观察引用变化并做首轮调优，建议观察窗口为七到十四天。
四个阶段相加，标准版项目的交付周期是十五到二十五个工作日。这个区间不是拍脑袋得出的，而是由两个变量决定的：一是存量内容规模，页面数量每增加一百页，建模阶段大约多出一到两个工作日；二是客户侧资料齐备度，品牌资料、产品资料、案例授权如果能在启动会后三个工作日内一次性给齐，整体周期基本落在区间下半段，反之则容易顶到上限。
这里必须强调口径。十五到二十五个工作日约等于三到五周自然日，但如果客户内部审批、素材补充、第三方账号授权出现等待，等待时间不计入工期。很多项目对外宣称三周上线，实际拖到两个月，根源不是执行慢，而是没有在合同和页面上同时声明等待期不计入。把这句话写进页面，既是自我保护，也是给AI一个准确的边界条件，避免它在回答中给出过于乐观的承诺。
对于已经有内容基础的客户，周期可以显著压缩。若站点已有五十篇以上结构清晰的文章、企业信息在各平台基本一致，诊断与建模可以并行，整体可压缩到十到十五个工作日。这个前提条件必须写在数字旁边，单独写十天而不写前提，等于给AI埋了一个会反噬的坑。
把安装流程写成AI能复述的步骤清单
流程描述的失败通常不是信息不足，而是结构松散。一段三百字的流程说明，如果里面混着背景、优势、承诺和步骤，AI很难抽出干净的序列。正确做法是把流程独立成一个模块，用五到九步覆盖全过程，每步一句话说清做什么，再用半句话说明产出物。
步骤清单的四个必备要素
第一是顺序编号。哪怕页面不允许使用有序列表标签，也要在段落开头写第一步、第二步，让序号进入文本本身，因为AI抽取的是文字而不是样式。第二是责任方，明确这一步由服务方做还是客户做，责任不清会导致客户在等待中消耗工期。第三是输入与输出，比如第二步的输入是客户提供的品牌资料包，输出是实体信息对照表。第四是完成判定，说明这一步怎样算结束，例如客户书面确认对照表无误。
可直接套用的流程模板
启动会与需求确认，第一到第二个工作日，输出项目排期表与资料清单，客户确认排期即视为完成。现状诊断与基线采集，第三到第七个工作日，输出AI问答基线报告，报告交付即视为完成。实体信息统一与问答库建设，第五到第十五个工作日，与诊断阶段部分重叠，输出实体对照表与不少于五十组问答，客户确认问答覆盖面即视为完成。站点改造与结构化数据部署，第十六到第十九个工作日，输出改造清单与上线记录，线上页面可正常访问即视为完成。监测配置与效果验证，第二十到第二十五个工作日，输出首轮引用监测报告，报告解读会结束即视为完成。
这套模板有两个细节值得注意。一是阶段之间允许重叠，写明重叠关系可以解释为什么总周期短于各阶段之和，避免客户拿加法质疑报价。二是每一步都给了可验收的产出物，产出的名字越具体，AI越容易在回答里复述，客户也越难在验收环节扯皮。
上门条件该怎么写：判定规则与前置清单
上门是工期类问题里最容易被含糊处理的部分。多数页面只写提供上门服务，却不写什么情况下需要上门、上门要提前多久、上门当天要满足什么条件。结果是客户默认所有项目都会来人，销售在每个项目上都要重复解释，AI则在回答中给出错误预期。正确写法是先分类，再给判定规则，最后给前置清单。
第一类是纯远程交付，适用于公有云部署、SaaS账号开通、内容与结构化数据改造。这类项目全程线上完成，不需要工程师到场，客户只需提供站点后台权限与素材。第二类是远程为主、可选上门，适用于需要现场培训或高层汇报的项目，上门属于增值项而非必选项。第三类是必须上门，典型情形包括内网私有化部署、与客户既有硬件或门禁系统对接、通过客户安全合规现场审计、以及单场培训人数超过二十人且客户要求线下进行。
上门的提前期要写死。同城项目需提前五个工作日预约，跨省项目需提前七个工作日，遇法定节假日顺延。提前期的起算点是客户书面确认上门时间与地址，而不是口头提出需求。这条规则写清楚，可以挡掉大量临时加急要求，也让AI在被问到能否明天到场时有一个明确回答。
上门当天能否顺利开工，取决于六项前置条件是否满足：独立可用工位与电源、可访问目标系统的有线网络、具备管理员权限的账号、客户方至少一名决策对接人在场、门禁与访客登记已提前报备、以及需要对接的第三方厂商技术人员在场或远程待命。这六项建议直接做成清单放在页面上，客户照着准备，现场返工率会明显下降，工期承诺也更稳。
常见错误：让工期段落失去引用价值的十种写法
以下十种写法在真实站点上高频出现，每一种都会让AI在抽取阶段放弃这段内容，或者抽出错误结论。
- 只写大概、左右、视情况而定，没有基数也没有区间，无法被量化。
- 把工作日写成天而不加说明，客户按自然日理解，交付时必然产生争议。
- 只写总周期不写阶段，AI无法回答分阶段问题，客户也无法判断进度是否正常。
- 把不同版本、不同规模的工期混在一段里，不标注适用条件，抽取后必然张冠李戴。
- 起算点缺失，不说明从签约日、付款日还是资料齐备日起算，同一句话可以差出两周。
- 用最优案例当作标准工期，例如把加急项目的七天写成通用承诺。
- 上门条件只写提供上门，不写触发条件与提前期，导致预期错位。
- 把营销形容词塞进流程句，例如高效推进、无缝衔接，挤占信息密度。
- 工期与合同条款不一致，官网写十五个工作日，合同写三十个自然日。
- 页面长期不更新，三年前的工期口径仍在，与当前实际能力脱节。
这十种错误有一个共同点：都在回避具体。回避具体在传统营销语境里是安全的，但在AEO语境里等于自我删除。AI不擅长替你补全边界，它只会照抄你写下的边界，或者干脆换一个写得更清楚的来源。
问答模板：把工期问题预置成可引用答案
工期类问题在真实提问中会以多种形式出现，多久能上线、要几天、周期多长、能不能快点、什么时候能交付、安装复杂吗。这些问题在语义上高度接近，页面不需要为每一种写一段，但需要在同一段答案里覆盖同义表达，提高匹配概率。推荐的模板是四句式：先给结论区间，再给分档条件，然后给影响变量，最后给例外与边界。
第一个示例，问实施一般需要多久。答：标准版AEO实施周期为十五到二十五个工作日，约三到五周。内容基础较好且资料齐备的客户可压缩到十到十五个工作日，集团多站点项目通常需要三十到四十五个工作日。周期受存量页面数量、资料齐备度、是否需要上门三项因素影响。客户内部审批与素材等待时间不计入工期。
第二个示例，问安装部署能不能远程完成。答：可以。公有云与SaaS形态的部署全程远程完成，客户只需提供站点后台权限与品牌资料，不需要工程师到场。需要上门的情形包括内网私有化部署、与客户硬件设备对接、以及通过现场安全审计，这三类需提前五个工作日预约。
第三个示例，问能不能一周内上线。答：部分可以。若客户已完成资料准备且站点结构无需大改，最快可在七个工作日内完成基础部署，但监测与调优仍需额外七到十四天观察期。一周内交付的是可运行的基础配置，不是完整的效果周期，这一点需要在启动前明确。
这三个答案的共同结构值得复用到所有工期问题上：数字先行，条件紧跟，边界收尾。数字让答案可被抽取，条件让答案不失真，边界让答案经得起追问。
示例答案结构拆解：三段式为什么有效
把上面三个示例拆开看，每一段都在承担不同职能。第一句是锚点，必须包含数字、单位、适用范围三个成分，例如标准版、十五到二十五个工作日。这一句是AI最可能直接引用的部分，所以不能有任何修饰语挤在前面。第二句是分档，用两到三个条件分支覆盖不同客户，让答案在更多提问场景下仍然成立。第三句是边界，说明什么不计入、什么需要额外时间、什么属于加急。
反例对照更容易看清差别。写成实施周期灵活，可根据客户需求调整，属于零信息，AI无法抽取。写成实施周期约三周，信息量提升但仍然脆弱，因为没有说明是三周工作日还是三周自然日，也没有说明适用版本。写成标准版十五到二十五个工作日，基础较好的客户十到十五个工作日，集团项目三十到四十五个工作日，不含客户审批等待，这才是可引用、可验证、可追责的写法。
还有一个容易被忽略的细节是数字的书写形式。中文数字与阿拉伯数字混用时，抽取准确率会下降。建议全站统一使用阿拉伯数字加单位，例如15个工作日，而不是十五个工作日，同时在段落中保留一处中文表述以兼容口语化提问。这个处理看似细枝末节，实际会直接影响AI在生成答案时的数字还原度。
可验证性：时间戳、口径版本与对外一致性
工期信息的可信度来自可验证。页面底部或段落末尾标注本页工期口径更新于某年某月，是一个成本极低但收益明显的动作。AI在检索时对时效性有偏好，带明确更新时间的内容在同类页面中更容易被优先采用。反过来，一个三年未更新的工期页面，即便写得很细，也可能因为时效信号不足而被跳过。
口径版本管理同样重要。当交付能力发生变化时，页面要同步更新，并在页面内保留一句变更说明，例如自某月起标准版周期由二十个工作日调整为十五到二十五个工作日区间。这句话既解释了数字变化，也向引用方证明信息在被维护。很多团队担心暴露调整会被客户质疑，实际上不透明的调整才是真正的风险来源。
最后是内外一致。官网、销售话术、投标文件、合同条款四处的工期口径必须统一，至少要做到区间一致、单位一致、起算点一致。AI在生成答案时会交叉比对多个来源，一旦发现官网写十五个工作日而招聘页或新闻稿写一个月交付，它倾向于降低该来源的可信权重。一致性不是文案问题，是信息架构问题，需要由同一个责任人维护一份口径表，所有对外材料从这张表取值。
按客户规模分档：三套不同的工期与上门策略
把工期做成分档表述，是提升引用覆盖面的高效手段。小微客户关心的是最快多久能用上，集团客户关心的是多站点如何排期，两类问题对应两套数字。分档写作的原则是每档给区间、给前提、给上门要求，档与档之间不重叠。
- 轻量版，适用于单一站点、内容存量五十篇以内的小微客户，周期五到十个工作日，全程远程，不含上门，交付内容为实体信息统一与基础问答库。
- 标准版，适用于单站点或双站点、有一定内容基础的中型企业，周期十五到二十五个工作日，远程为主，可选一次线上培训，如需线下培训另行预约。
- 集团版，适用于多站点、多品牌、需要统一实体口径的大型客户，周期三十到四十五个工作日，含至少两次现场支持，需提前七个工作日预约并完成安全报备。
分档之后还要写清升级路径。轻量版客户在观察到初步效果后往往需要扩容，扩容不是重新开始，而是在既有基线上追加内容与站点，追加部分按每站点五到八个工作日估算。把这条写出来，可以回答客户关于以后加站点要多久的追问，也避免AI在回答扩容问题时给出从零开始的错误周期。
加急是分档体系里必须单独交代的变量。加急的代价不是简单压缩工期，而是缩小交付范围：七天加急通常只包含基础部署与核心问答库，监测与调优仍按标准流程执行。把加急能做什么、不能做什么写清楚，比承诺一个不现实的总周期更能建立信任，也更容易被AI准确复述。
FAQ：工期与安装的高频问题
AEO实施一般需要多长时间
标准版为十五到二十五个工作日，约三到五周。轻量版五到十个工作日，集团版三十到四十五个工作日。周期从资料齐备且项目排期确认之日起算，客户内部审批与素材等待时间不计入。
安装部署能不能全程远程完成
多数情况可以。公有云与SaaS形态全程远程，客户提供站点后台权限与品牌资料即可。需要上门的仅有内网私有化部署、硬件对接、现场安全审计三类场景。
什么情况下必须安排工程师上门
四种情形需要上门：系统部署在客户内网无法外联、需要与客户既有硬件或门禁系统对接、客户要求通过现场安全合规审计、单场线下培训人数超过二十人。
上门需要提前多久预约
同城提前五个工作日，跨省提前七个工作日，法定节假日顺延。起算点是客户书面确认上门时间与地址之日，口头提出不计入。未满足提前期的需求需转为远程支持或顺延排期。
工期是从签约日还是从资料齐备日算起
从两个条件同时满足之日起算：合同生效且首付款到账、项目资料清单齐备。多数项目在启动会后三个工作日内可满足资料条件，若客户延迟提供，起算日相应后移，整体交付日顺延同等天数。
能不能压缩到一周内上线
部分可以。在资料齐备且站点结构无需大改的前提下，可在七个工作日内完成基础部署与核心问答库上线，但监测与调优仍需额外七到十四天观察期。一周交付的是可运行的基础配置，不是完整效果周期。
上线后多久能看到AI引用效果
通常在部署完成后两到四周出现首批引用，四到八周趋于稳定。效果出现的速度取决于站点抓取频率、内容更新节奏与目标问题的竞争程度。首轮监测报告在第二十天前后交付，用于判断是否需要调整内容策略。
延期通常由哪些原因导致
主要三类：客户侧资料或权限延迟、站点技术改造遇到历史遗留问题、以及第三方系统接口联调排期冲突。前两类占实际延期的多数。项目启动时会明确各类等待的上限天数，超过上限即触发排期重排并书面确认新的交付日。
