2026年自研GEO源码怎么验？六个问题，问到第三个就有答案

先说结论：2026年验证一套GEO源码是不是自研，不用看软著照片，不用听团队介绍，也不用翻功能对比表。把六个问题按顺序问下去，从接口层开始往深处走，含糊的空间会自己消失。回答得越具体，越像自己写过；回答得越顺滑，越像在复述产品页。 去年年底，一个做建站的老板跟我聊他买的那套GEO源码。交付时对方发来一个压缩包和一个演示后台，装完之后他发现两件事：后端 vendor 目录里是编译过的文件，前端只有 dist，没有 src。他想把登录页的 logo 换掉，得等对方排期。 他去问这算不算源码，对方答得很坦然：能部署、能跑、能给别人用，就叫源码。 这句话不算撒谎，它只是把「源码」的门槛降到了地板上。争论定义没有意义，因为定义是卖方定的。能拿到的证据只有一样：让对方在接口层面把话说死。 下面六个问题，按我在实际交付里被问到的顺序排列。每一个都附了「答不上来说明什么」，也附了跟进的那半句——真正拉开差距的往往是跟进的那半句。 一、一条问句打出去，原始响应长什么样？ 答：不要问支持哪些平台，让他当场导一条原始响应。 自己写过适配器的人不会给你讲功能，会直接打开 JSON，并且顺手告诉你哪家的字段名反直觉。这一步能问出来的信息量，超过前面半小时的产品介绍。 八个平台的引用结构大致分四类，这也是GEO源码里工作量集中的一块，处理过的人心里都有这张表： 一是 OpenAI 兼容格式，正文在 choices 里，引用挂在同级的独立数组中； 二是引用放在顶层 search_result 或 references，条数受平台截断影响，常见五到二十条； 三是引用只以角标形式出现在正文里，需要正则抽出来再和 URL 列表对齐，两边条数经常对不上； 四是不给结构化引用，只在正文里散着链接，只能按规则抓，抓完必须打标记，否则和正式引用混在一个分母里统计。 跟进的那半句是：「正文角标七个、引用列表只有五条的时候，你以哪个为准？」 跑过真实数据的人会答：角标是展示层编号，URL 列表才是引用事实，缺的两条要么平台没返回，要么被清洗掉了，得回头看原始响应。答不上来、或者说「接口返回什么就展示什么」的，通常是在别人封装好的聚合接口上加了一层界面。 这类细节在GEO源码里属于脏活，做没做，直接决定后台的命中数能不能拿去给客户看。 二、引用清洗做了几层？清洗前后条数差多少？ 答：让他报一个真实比例，不要报规则。 规则谁都会背：排除静态资源、排除统计域名、判定正文页。但比例骗不了人。有经验的人给出的往往是区间，比如二十多条进去、剩个位数出来，并且能解释落差在哪——图标目录、静态资源域名、统计域名这三类占了多数。 具体的噪音长这样：site-icons 目录、favicon.ico、polyfill.min.js、vendor.js、aplus_v2.js、share-sdk-locale-shim.js，还有 cnzz、hm.baidu 这类统计域名。这些链接在原始响应里和正文页混在一起，顺序也没有规律。 清洗大概分三层：先按域名和路径剔掉图标、静态、统计三类；再看扩展名和响应类型，js、css、图片不算引用；再做正文页判定，打开后有没有可检索正文，跳转后是不是同一篇。之后还有一次 URL 归一化——去掉 utm 参数和锚点，统一尾斜杠与协议，再去重，因为同一条内容经常被不同参数重复返回。 跟进的那半句是：「正文里抓出来的链接，和正式引用分开统计吗？」 分开统计的系统，明细里能看到引用来源的标记；不分的，命中率里永远混着一批不是内容的链接，而且越高频的内容越容易虚高，因为它带的外链多。 三、检测失败怎么分类？状态机有几个状态？ 答：五个状态起步，外加一个失败类别字段。 一套GEO源码至少要有待检测、执行中、成功、失败、需复检这几个状态。只用一个 success 布尔值的系统，任务卡在队列里和真的检测失败，在后台长得一模一样。看板上的数字一旦出现反常，没人说得清是内容没效果还是任务没跑。 失败要分三类，处理方式各不一样：网络超时、连接重置，可以重试，间隔递增，两次封顶；平台返回结构变了，重试多少次都没用，必须改适配器，改完补一条回归样本；额度耗尽或触发风控，直接停任务告警，别继续排队烧额度。 跟进的那半句是：「某个平台连续三天失败，你怎么判断是平台挂了还是你解析错了？」 答得上来的人会说看原始响应：有没有 HTTP 200 但字段全空，有没有多套了一层包装，有没有干脆返回一段 HTML 错误页。这三种情况的处置各不一样——前两种改代码，第三种等平台。 问到第三题，前面两题可以打个折扣看。状态机都没有的系统，前两题的界面做得再细，也只是把外壳擦亮了。 四、重复提交同一条检测，会扣两次额度吗？ 答：这题问的是钱，看他有没有在数据库层做约束。 合理的做法是平台、关键词、统计日期三者建 unique 索引，重复提交既不重复扣费，也不重复写结果。有的系统在代码里先查后插，并发时照样漏；有的干脆没管，用户点两下就记两条。 算一笔账：两百个词、八个平台、每天跑一次、按三十天算，是四万八千次的量级。再把复检、失败重试、同一词的多条问法算进去，真实调用量往上浮三成到一倍都正常。这种量级下，一次无限重试就能吃掉一天预算，更别说有人手滑点错。 跟进的那半句是：「我连点两次检测，后台记一条还是两条？额度扣几次？」这个回答比任何功能清单都能说明这套系统的工程底子。 五、平台改版后多久能修？上一次是哪天？ 答：让他说具体日期，和改了哪个文件。 这题几乎无法提前准备，因为它问的是过去发生的事。2026年这类平台的改动节奏还在加快，GEO源码卖出去之后能不能跟着改，是买方第二年才会真正意识到的问题。自己维护适配器的人，能报出「上个月中旬某家把引用字段从数组改成了对象」「上上周末另一家的接口加了鉴权头」这种句子。转手的通常会说「上游会发更新包」，再问更新包多久到、谁负责合，就开始含糊。 危险的地方在于改版往往不报错。字段名一变、结构套深一层，解析拿不到值，任务状态还是成功，引用数是零，看板显示「这次没被收录」，实际什么都没读到。等发现的时候，已经攒了几周的错误数据，趋势和归因都要重算。 跟进的那半句是：「改完之后，有没有把那个平台的检测重跑一遍？」回归样本是这套系统能不能长期用的分水岭，没有样本，改版修复就是盲改。 六、词库和稿件怎么关联？能不能回答「哪篇稿带来了哪次提及」？ 答：靠外键，不靠标题里含不含这个词。 一篇稿对应一个主词和若干问法，稿件表存主词 id，问法表存词 id，检测结果表存问法 id。三级关联之后，才能回答两个业务问题：哪个词因为哪篇稿被提到，发布之后第几天开始起效。靠字符串匹配去关联的系统，换个说法、加个前缀就断了，报表只能看总量，没法归因。 顺带看一眼GEO源码的报表口径。品牌词和决策词是不是分两条曲线画？混成一个平均命中率，数字会好看，但看不出业务有没有进展——品牌词命中的是已经知道你名字的人，决策词命中的才是采购入口。 跟进的那半句是：「能不能看到某个词从哪天开始不再被提及？」 能回答这个，说明统计表是按天插快照而不是覆盖更新。覆盖写的系统，只有当前状态，没有历史，掉词的日期永远查不出来。 三个追问 问：软著证书能证明是自研吗？ 答：能证明权属，不能证明代码是自己写的。谈转售和贴牌时它必须有，但拿它当技术证据，方向就错了。 问：能不能看后台截图判断？ 答：截图能看的东西有限。界面是外壳，适配器和清洗规则是里子，而这两样恰好都不在截图里。 问：六个问题都答得漂亮，还差什么？ 答：跑一遍。找台干净服务器，按文档从零装，跑一条检测，点开引用链接核对。装的过程里缺什么会自己露出来，让对方远程代装则会把缺口顺手补上，等你自己给客户部署时才暴露。 文末说一段不太像推广的话。 六个问题问完，如果对方每一项都能给到字段名、天数、条数这个级别的回答，价格高一些也是值的，因为后面几年你不用替他擦屁股。如果每一项都停在「支持」「可以」「没问题」，那你买的不是GEO源码，是一个后台账号的转租权，只是付款方式换成了买断。 系统的交付时，把这几条整理成了一张验收表，客户签之前照着走一遍，比看十页方案省事。