site查询优化：工具支持的对象格式变化时怎样改输入规范
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4779f8401b60.html
📄
site查询优化：工具支持的对象格式变化时怎样改输入规范
结论先说：对象格式变化时，不要只改字段名，而要把输入规范拆成“对象标识、对象边界、对象状态”三层，并规定每层由谁确认、用什么证据核对。只有当新旧格式能映射到同一对象语义，且至少两种独立证据指向同一对象时，旧输入规范才可以平移；否则应新建规范并把旧规范标记为待废弃。
先判断格式变化属于哪一层
对象格式变化通常不是单一事件。第一层是对象标识变化，例如原先用站点根域，现在要求用带协议和路径前缀的完整地址。第二层是对象边界变化，例如原先一个输入代表整个站点，现在一个输入只代表某个目录或某种资源类型。第三层是对象状态变化，例如原先默认包含已删除对象，现在只返回当前可访问对象。
三层变化对输入规范的影响不同。标识变化通常只需补全字段；边界变化会改变结果可比性；状态变化会让历史对比失去意义。判断时可以让两个角色分别按旧规范和新规范各生成一份输入清单，再逐条标注差异属于哪一层。如果分歧集中在“这条记录到底代表哪个对象”，就是标识问题；如果分歧集中在“这条记录是否应被计入总数”，就是边界或状态问题。
把分歧转成可核对的项目
多个角色对同一事实有不同理解时，不要先争论谁对。先建立一张核对表，每行至少包含：原始输入、解析后的对象、对象边界说明、状态说明、证据来源、确认人。证据来源可以是工具返回的原始字段、服务端日志、页面自身的规范化声明，或第三方对照清单。确认人必须能对某一层负责，不能所有层都写“团队”。
假设某团队原先用不带路径的域名作为查询输入，工具改版后要求输入完整地址。角色A认为旧输入仍能覆盖全站，角色B认为旧输入只覆盖首页。此时把两种理解都写成核对项：旧输入解析出的对象是什么、新输入解析出的对象是什么、两者是否指向同一组页面。若证据只能证明旧输入返回过首页相关结果，不能证明它覆盖全站，那么旧输入规范就不能继续用于全站统计。
这里要说明一个会使上述结论失效的反例：如果工具明确提供了对象继承或别名机制，并且该机制有可核对的映射记录，那么旧输入仍可能覆盖新格式下的多个对象。此时不能仅凭“格式不同”就判定旧规范失效，而要先验证映射记录是否完整、是否稳定、是否对所有角色可见。缺少映射记录时，按不继承处理更安全。
改输入规范时先改校验规则
输入规范不只是给操作者看的说明，还应包含校验规则。格式变化后，至少增加三类校验：第一，对象标识是否可解析为唯一对象；第二，对象边界是否与统计口径一致；第三，对象状态是否与本次查询目的匹配。校验不通过时，不应静默替换或自动补全，而应返回明确原因，让操作者决定是修正输入还是调整口径。
一个实际动作是：把旧输入批量跑一遍新校验，记录失败类型和数量。若失败集中在缺少路径前缀，说明只需补全字段；若失败集中在同一输入解析出多个对象，说明边界定义需要重写；若失败集中在已删除对象被排除，说明历史对比需要重新设置基线。这个动作的结果直接决定下一步是平移旧规范、修订旧规范，还是新建规范。
新旧规范并行期的取舍
格式变化后通常需要一段并行期。并行期不是简单地把两套规范都保留，而是明确哪套用于对外报告、哪套用于内部排查。对外报告应使用新规范，因为对象边界和状态更明确；内部排查可以暂时保留旧规范，但必须标注它不能用于跨期比较。并行期结束时，旧规范应转为只读或归档，避免不同角色继续引用不同版本。
如果两个角色对同一事实仍有不同理解，下一步不是继续开会，而是各自提交一份按新校验规则生成的输入清单，并附上对象解析证据。清单一致的部分直接合并；不一致的部分逐条标注属于标识、边界还是状态问题，再指定唯一确认人。只有确认人能提供可复核证据时，该条才进入正式规范。
