进阶第 2 章：怎样做一轮
以后还能比较的 GEO 基线

一张截图，为什么算出了百分之百

麦序科技刚整理完第一版客户问题，林岚就迫不及待地做了一次观察。

她在自己常用的 AI 产品里输入：

麦序科技适合连锁烘焙企业吗？

回答不仅提到了麦序科技，还准确说出了中央厨房和生产协同。林岚截下品牌出现的两行，发到工作群里：

第一轮结果很好，品牌覆盖率百分之百。

周舟只问了六个问题：

1. 一共问了多少道题？
2. 使用的是哪个入口？
3. 账号里有没有保存过麦序资料？
4. 是新会话还是原来的对话？
5. 完整回答和来源在哪里？
6. 下个月准备怎样重复这次观察？

林岚发现自己一个也回答不完整。

她只问了一题；使用的是自己的长期账号；提问前刚上传过产品资料；同一会话已经讨论过三次麦序；截图只留下品牌附近两行。即使这段回答完全正确，也无法说明陌生客户在普通入口会看到什么。

下午，销售用手机问了同一句话，没有看到麦序；许程在新会话里得到一段很短的回答；另一位同事打开带网页来源的入口，又看到了不同内容。

四个人看到的结果可能都是真的。问题不在于谁撒了谎，而在于他们观察的不是同一个条件。

基线要解决的正是这件事：先留下一个边界清楚、以后能够回来的起点。

基线不是成绩，而是一张带日期的起点照片

很多新手听到“基线”，会以为要给品牌算一个标准分。

麦序科技真正需要的不是一张 82 分的成绩单，而是能够回答：在什么问题、什么入口、什么时间和什么可见条件下，团队当时实际看到了什么？

以后官网、产品说明或外部来源发生真实变化，团队再尽量沿用同一组条件复测。这样才能判断哪些现象发生了变化，哪些仍然存在。

基线更像一张带日期和拍摄位置的照片。它能说明当时镜头里有什么，不能证明所有时间、所有用户和所有平台都会看到相同画面。

它也不能告诉企业平台内部为什么生成某句话。模型版本、检索策略、服务负载和平台更新通常不在企业控制之内。团队只能固定自己能控制的部分，记录界面能看见的部分，对后台不可见的部分承认未知。

因此，麦序没有再写“测一下 AI 里的品牌表现”，而是把本轮任务改成：

使用第 1 章冻结的四十二个客户问题，在三个目标客户真实使用的入口中，各完成三次可见新会话观察，保存完整回答、可见来源和运行状态，作为后续修复与复测的起点。

这句话已经决定了问题版本、入口范围、重复方式、证据内容和未来用途。

第一天上午：先锁住四十二个问题

第 1 章交出了四十二个核心问题：三十二个长期核心问题，加十个本阶段重点问题。问题版本冻结于 7 月 14 日。

冻结不是说这些问题永远不能改，而是本轮执行期间不能因为结果不好就临时换题。

例如，非品牌问题 Q-018 是：

已有收银系统的三十家烘焙门店，什么情况下还需要单独的中央厨房排产系统？

如果连续几次回答没有出现麦序，林岚不能把它改成“麦序科技为什么适合三十家门店”，然后继续使用原编号。新问法直接提示了品牌，客户任务也从选择方法变成了品牌验证，前后不再可比。

执行期间，团队只修正了一个不影响意图的标点错误，并保留变更记录。销售后来新增的“跨城市中央厨房权限怎样分开”进入下一版候选，没有替换表现不好的问题。

每道正式问题都带着编号、完整文本、品牌类型、客户角色、购买阶段、意图和风险说明。执行人员复制冻结文本，不在现场把问句润色成自己喜欢的样子。

这样做不是追求字面僵硬，而是防止团队在看到结果以后悄悄移动观察对象。

第一天下午：三个入口为什么不能只写成三个平台

麦序没有按员工个人喜好挑产品，而是回到销售沟通和客户访谈。

老板经常用普通网页聊天快速了解解决方法；运营负责人会使用带网页来源的 AI 搜索核对厂商资料；信息技术负责人还会在普通登录的聊天助手中询问接口与部署。

团队因此建立三个教学代号入口：

入口	用户实际在做什么	本轮记录重点
入口甲：普通网页聊天	快速理解问题和可能方案	初始解释、候选和限制条件
入口乙：带可见网页来源的 AI 搜索	查找厂商与公开依据	完整回答、来源标题和落地网址
入口丙：普通登录聊天助手	在工作场景中核验能力	产品事实、风险边界和下一步动作

这里故意使用代号，因为本书中的回答与数据都是教学合成内容，不代表任何真实产品的当前表现。

“某平台”还不够具体。同一产品可能同时有网页聊天、移动应用、搜索模式、办公入口和企业版本。入口不同，账号状态、来源展示、对话上下文和可见功能都可能不同。

平台很热门，不等于目标客户一定使用；某个入口第一次结果难看，也不能因此被删除。只要它对应真实客户情境，结果不理想本身就是需要保存的观察。

第二天：十道试运行题先救了正式基线

团队没有直接启动 378 项任务，而是先选十道题试运行。

试运行很快暴露了三个问题。

第一，入口乙的来源默认折叠。执行人员只复制正文时，会把来源全部漏掉。

第二，一名同事使用个人账号，回答里出现了本轮问题没有提供的麦序资料。团队无法证明这些内容一定来自账号记忆，但已经足以说明该账号不适合核心基线。

第三，一道问题同时询问“能否连接收银系统”和“上线后能否减少损耗”。回答只完成前半部分，两名分析人员对它算完整还是不完整意见不同。

这些问题若在正式执行后才发现，团队可能得到几百条无法统一解释的记录。

麦序因此调整了执行方式：入口乙每次展开可见来源；核心观察使用经过清理、没有保存麦序资料的普通账号；含两个独立任务的问题回到问题系统拆分，不带进正式基线。

试运行的成功标准不是提前看到好答案，而是让不同同事按照同一说明执行时，能够保存相近类型的证据。

能固定的固定，能看见的记录，看不见的别猜

正式执行前，小陈把影响解释的条件分成三层。

第一层是团队能够固定的条件：问题文本、入口、账号类型、新会话方式、人工选择的模式、语言与地区设置、重复次数和执行窗口。

第二层是每次运行能看见但可能变化的状态：精确时间、设备、登录状态、界面显示的模式名称、回答是否完整、是否展示来源、是否发生跳转或报错。

第三层是团队看不见的后台条件：具体模型更新、内部检索策略、服务负载和平台没有公开的排序机制。

第三层不能靠经验补全。界面没有显示模型版本，就写“未显示”；产品没有搜索开关，只能记录“本次回答展示三个网页来源”，不能反推后台一定执行了某种固定流程。

团队最终确定：核心基线使用普通登录账号，每次从界面可见的新会话开始，不使用上传过企业资料的个人账号。入口甲和丙没有手动搜索开关；入口乙使用当时默认的搜索回答。

“新会话”也只描述界面能确认的状态。它不等于团队已经证明平台没有任何账户级历史影响。

为什么每道题要问三次

试运行中，同一个问题在同一入口出现了三种正常回答：第一次列出四个候选，第二次只给选择方法，第三次列出三个候选并提醒先核验收银接口。

一次观察可能只是一次波动。重复观察能让团队看到：某个现象只出现一次，还是在当前有限样本中多次出现。

麦序选择每道题、每个入口做三次独立新会话观察。三次不是行业标准，也不是统计学保证，只是团队在五个工作日内能够完整保存和复核的工作量。

重复时，问题文本和入口保持一致。第一次回答后追问“为什么没有提麦序”，不能算第二次独立观察，因为追问已经加入品牌提示和上下文。

高风险错误可以触发追加观察，但追加样本必须单独标记。如果结果不好就继续问到出现满意答案，结果好就立即停止，团队最终只是在挑选自己喜欢的回答。

三次中两次出现品牌，可以写“本轮三个有效样本中出现两次”。不能写成“该平台有 66.7% 的固定推荐概率”。样本太小，外部环境也会继续变化。

重复观察的价值是看见波动，不是制造看似精确的预测。

378 是怎样算出来的，又意味着多少工作

正式计划非常直接：

42 道问题 × 3 个入口 × 每项 3 次独立观察 = 378 个计划样本

378 不是一个越大越专业的数字。它意味着团队必须完成 378 次提问，检查 378 次回答是否结束，展开并保存可见来源，把每条记录连接到正确问题和入口，还要处理失败、重试和人工复核。

如果每项从执行到保存平均需要四分钟，仅原始采集就超过二十五小时，还没有计算复核和分析。

这也是为什么小团队不应该一开始覆盖十几个入口、几百道问题。执行能力只能可靠保存一百项，就先缩小问题或入口；不要计划一千项，最后只留下两百张来历不清的截图。

麦序将四十二题分成三个批次，在五个工作日内交替执行三个入口。这样不会第一天只测入口甲、最后一天才测入口丙，尽量减少行业新闻、平台更新或企业自身发布集中落在某一个入口上的时间偏差。

团队在窗口内暂停计划中的官网重大改版和集中外部发布，但没有声称外部环境完全静止。执行开始和结束时间都进入本轮说明。

一条原始记录必须让陌生同事找回现场

每次观察完成后，执行人员不先判断品牌好坏，而是先保存现场。

一条正式记录至少包含：问题编号和完整问法、入口、执行时间、账号状态、会话状态、可见模式、完整回答、可见来源标题与网址、全页截图和运行状态。

例如第 3 章将继续分析的记录编号是 乙-Q033-02：入口乙，问题 Q-033，该入口的第二次独立观察。

回答很长时，团队同时保存全文和全页截图。全文便于检索与逐句分析，截图则保留候选顺序、来源角标、折叠区域和警告提示。

复制回答时不修正错别字，不删除重复句，也不为了报告整洁重排段落。错误、重复和含糊本身可能就是后续证据。

来源不能只保存显示标题。能够打开时，还要保存实际落地网址和检查时间；发生跳转时，记录最终页面。界面只显示来源名称而没有链接，就照实写“无可复制链接”，不要自行搜索一个相似页面替代。

随机找一位没有参与执行的同事，只给他观察编号。如果他能找回问题、完整回答、来源、条件和截图，这条记录才真正具备复查基础。

第二批出现服务繁忙，为什么不能记成品牌未出现

执行第二批时，入口乙出现多次“服务繁忙，请稍后重试”，另有一次回答到半句中断。

页面里确实没有麦序科技，但这不是“品牌未出现”。系统没有形成可分析的正常回答，团队观察到的是运行失败。

麦序为每项任务使用五种状态：

运行状态	现场是什么情况	后续怎样使用
有效完整	回答实质完成，需要的可见区域正常保存	可进入回答与来源分析
有效但存在可见缺失	主体完整，但来源区等可见部分未正常加载	可分析正文，来源相关结论单独受限
明确拒绝	回答明确拒绝某种要求，并可能提供替代方法	分析拒绝内容，不冒充普通推荐回答
技术失败	空白、服务错误、登录失效、网络中断或严重截断	只进入运行质量，不进入品牌表现
执行错误	问错题、用了错误会话、误传附件或保存错位	从核心分析排除，但保留原记录和原因

“无法评选全国最好软件，因为缺少公开标准”属于有意义的拒绝，不是服务失败。它可能没有推荐品牌，却正确拒绝了无依据排名。

主体已经完成、只有来源区域没有加载，也不应与整段空白混为一谈。正文仍可分析，来源数量和支持关系则必须注明证据缺失。

技术失败按照基线前确定的规则重试。原失败记录不会删除，成功重试也不会被改写成第一次就成功。

分类的目的不是让报表复杂，而是避免把“没有形成回答”“回答拒绝排名”和“正常回答没有品牌”压成同一个结果。

异常样本不要急着扔掉

除了服务故障，团队还看到了几类奇怪结果：回答把中央厨房排产理解成影视排期；来源标题可见，点击后却是不存在的页面；可见新会话里出现了本轮没有提供的企业资料；几次回答几乎逐字相同。

这些记录不一定是垃圾。

名称误解可能暴露企业类别表达问题，失效来源可能进入来源治理，新会话中的历史信息可能提示账号条件需要复核。它们都是第 3、4 章的重要线索。

异常记录先写现场事实，不抢先猜平台内部原因。例如：

回答将“中央厨房排产”解释为影视制作排期，全文没有讨论门店订货或食品生产。

这句话可被另一位同事复核。相比之下，“平台不懂麦序”既没有明确对象，也无法说明什么证据会推翻它。

只有能够确认是团队自己的执行错误，才从核心分析中排除。即使排除，也保留原记录、错误原因和重新执行编号，防止同类问题重复发生。

第五天晚上，378 项任务得到了什么结果

五个工作日结束后，周舟先汇报运行状态，而不是品牌成绩。

本轮状态	数量	解释边界
计划样本	378	四十二题、三个入口、每项三次
有效完整	349	能进入完整回答分析
有效但来源区缺失	7	正文可用，来源分析受限
明确拒绝	6	单独分析拒绝理由与替代帮助
技术失败	12	只反映本轮运行质量
执行错误排除	4	不进入核心结论，保留审计记录

后五类正好合计 378。这个核对看起来基础，却能快速发现记录丢失、状态重复或失败被悄悄删除。

任何比例都必须先说明分母。

如果分析“完整回答中的接口事实错误”，分母可能只使用符合条件的有效完整回答；如果分析“本轮来源是否可见”，七条来源区缺失就必须单独出现；如果分析任务完成质量，技术失败与执行错误都不能消失。

团队没有用 378 直接计算一个品牌提及率，也没有把技术失败算成品牌未出现。先说明哪些记录有资格回答哪个问题，数字才有意义。

三个入口为什么没有合成一个总分

入口乙展示的网页来源较多，入口甲的回答通常较长，入口丙在本轮接口问题中出现了更多旧事实。

这些差异没有被压成“麦序科技 GEO 总分”。

三个入口对应不同客户任务，来源展示方式也不同。给入口乙的来源数量更高权重，可能只是奖励它的产品形态；把入口甲的长回答视为质量更高，也可能忽略长回答中的事实错误。

团队分别描述每个入口：在什么问题类型中出现了哪些候选、事实、来源和风险。跨入口汇总时，只汇总定义真正一致的运行数量，并保留入口维度。

同样，品牌问题、半品牌问题和非品牌问题也不应直接平均。问题已经写出公司名称时，品牌出现并不令人意外；非品牌问题是否形成合理候选，则是另一种观察。

不做总分不等于拒绝量化。团队仍然可以统计当前样本里的品牌位置、事实错误、可见来源和不确定表达，只是每个数字都带着入口、问题类型、时间和有效样本范围。

这轮基线能告诉你什么，不能告诉你什么

这轮基线能够告诉麦序科技：在约定的五个工作日、四十二道题、三个入口和可见条件下，团队保存了哪些回答；哪些问题反复出现接口绝对化、类别混淆或自动执行错误；哪些来源在本次界面中可见；哪些任务因技术或执行原因无法分析。

它也为以后留下了比较起点。团队知道要回到哪个问题版本、入口、账号条件、新会话规则、重复次数和证据口径。

但它不能证明某个平台长期固定推荐谁，不能代表国内所有 AI 产品，不能推断平台内部采用了哪种模型或检索流程，也不能保证企业修改内容后回答一定变化。

基线还不是原因诊断。发现旧产品名多次出现，只能先保存现象；究竟是官网关系混乱、旧来源仍公开、页面入口薄弱，还是其他因素，需要后续证据支持。

好的基线不是看起来确定，而是让不确定性有清楚边界。

把哪一条回答交给第 3 章

运行状态确认以后，团队才开始选择分析样本。

他们没有只挑没有品牌的回答，也没有只挑最有利的截图。第一条深度分析选择 乙-Q033-02，因为它同时包含几种典型情况：品牌位于主结论，回答给出了有帮助的采购建议，也出现了接口范围过度概括和自动执行错误，并展示三个看似丰富的来源。

它能够回到完整问题、入口、时间、账号条件、新会话状态、全文、来源和截图，因此具备逐句分析基础。

接下来第 3 章会问：客户读完会相信什么？哪些说法得到当前事实支持？“直接安排生产”为什么是高风险错误？三个来源是否真的支撑最强说法？

如果第 2 章只留下品牌附近两行，第 3 章就无法完成这些判断。

这就是两章之间真正的交接：不是把一个提及数字交给分析人员，而是把一条能够回到现场的完整证据交给他。

用三十六次观察完成自己的第一次练习

第一次练习不需要照搬麦序的 378 项规模。

从第 1 章选择六道问题：两道非品牌选择问题、两道品牌事实问题、两道高风险或采购问题。选择两个目标客户确实使用的明确入口，每道题各做三次独立新会话观察：

6 道问题 × 2 个入口 × 3 次 = 36 项计划任务

开始前先写清问题版本、入口、账号条件、新会话方式、可见模式、执行窗口、失败重试和保存位置。用其中两道题试运行，确认来源能够展开、记录编号不会覆盖、另一位同事能找到完整回答。

正式执行时，不根据答案临时换题，不追问品牌后冒充独立观察，也不删除失败。每项先保存完整证据，再选择运行状态。

完成后先做一个最基础的核对：所有状态数量相加，是否等于三十六。随后随机抽取三个编号，请没有参与执行的同事找回问题、回答、来源、条件和截图。

最后只回答三个问题：这批记录能分析什么，哪些结论因来源或失败受到限制，下一章最值得逐句审查的是哪一条回答。

能做到这里，你已经拥有一条真正可复查的 GEO 起点，而不再只是几张让人兴奋或沮丧的截图。

延伸阅读与资料来源

• Aggarwal 等人的论文 GEO: Generative Engine Optimization 提供了按查询、生成式引擎和观察结果开展实验的研究背景。本章借用明确查询与条件的思路，不把论文实验设置当作企业统一标准。
• 美国国家标准与技术研究院发布的 生成式人工智能风险管理框架简介 强调测量应结合具体情境，并记录限制、变化和人工判断。本章将这些通用原则用于运行状态、变量、异常和复核，不代表该框架评价任何具体平台。