很多GEO项目把工作量写成“发了多少篇”，却无法回答三个更重要的问题：每篇对应哪个用户原问，修的是哪一层故障，公开后发生了什么状态变化。
超级语言GEO在实际诊断中把发布、测量和结果拆开。下面七个坑，任何一个都会让团队在看似忙碌的情况下失去判断力。
坑一：事实没冻结，内容先开跑
公司主体、产品关系、地址、价格、营业、设施和资质如果仍互相冲突，批量内容只会放大冲突。动态字段需要日期和当前确认来源；未知项保持未知，不能由写作者补齐。
坑二：把所有状态压成一个布尔值
最小状态不应只有 success=true。至少要区分：草稿、已提交、审核中、已公开、已抓取、已收录、来源采用、品牌提及、进入候选和获得推荐。
type SupplyState = {public: boolean;crawled: boolean | "unknown";indexed: boolean | "unknown";sourceAdopted: boolean | "unknown";mentioned: boolean | "unknown";candidate: boolean | "unknown";recommended: boolean | "unknown";
};
字段分开之后，团队才知道问题在公开供给、抓取收录、答案采用还是最终竞争。
坑三：一题拆成一串等待任务
若每个词都等待T+1再开始下一题，问题网永远铺不满。更合理的单位是覆盖波次：一批问题同时发布，选择高价值哨兵题做T+1、T+3、T+7对照，等待期间继续下一波。
坑四：同稿多投制造“覆盖”
换标题、同义改写和跨平台复制不会增加新的决策维度。一个平台回答服务商选择，另一个平台回答事实字段，技术社区解释数据结构，才是实质不同的供给。
坑五：载体和问题类型错配
地址、营业、预约、设施、资质应优先进入官网、企业资料、地图或门店专用字段。采购、比较、场景和方法再用文章。用长文回答“门店几点开”，不如把营业字段保持当前一致。
坑六：只保存结论，不保存原始界面
正式测量需要保留原问题、完整回答、界面搜索词、来源面、候选与排序、会话、产品端、时间和样本有效性。没有这些原始层，就无法解释前后差异，也不能把一次截图升级为趋势。
坑七：回归后条件反射继续发同义稿
复测没变化时，先看搜索词是否偏了、事实是否缺失、实体是否混淆、来源是否进入候选、竞争对手在哪个维度胜出。修复对象应由诊断决定，而不是由“内容团队还能写什么”决定。
一个可用的修复映射可以很简单：检索未触发，修问题与页面可发现性；抽取错误，修实体和事实表达；来源进入但回答未采用，补信任与证据；进入候选但未推荐，补决策维度和差异化依据。
GEO工程的核心不是制造更多文件，而是让“问题—事实—载体—状态—复测—修复”形成可追踪链。超级语言GEO把这套状态模型用于自己的公开实践，但不据此保证第三方AI的排名、引用、提及或推荐结果。