通化网络服务甲乙双方指标不同如何建立可对照的交付表
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c9cda4a49cfd.html
📄
通化网络服务甲乙双方指标不同如何建立可对照的交付表
结论是有条件的：先把双方各自的指标拆成“同一批可核对对象”，再为每个对象指定一个主口径和一个辅助口径，交付表才可能对照；如果双方连对象范围都不一致，例如甲方按整站页面数、乙方按已发布文章数，那么任何换算都只是把分歧藏进表格，对照关系并不成立。
先确认双方说的是不是同一批对象
指标不同往往不是口径之争，而是对象之争。甲方说“页面”，可能指模板页、栏目页和详情页的合集；乙方说“页面”，可能只指有正文内容的详情页。此时先做一次对象清点，把双方各自认可的条目列出来，再取交集和差集。交集部分可以直接进入交付表，差集部分单独标注归属，不混入同一行。
一个假设例子：甲方统计出 120 个页面，乙方统计出 90 个页面。核对后发现差的 30 个是列表页和标签聚合页。若甲方坚持这些也算交付，交付表就应把它们列为独立行，而不是用 120 与 90 相除去算完成率。动作是把差集逐条命名，结果是后续验收不再围绕一个总数争论，而是围绕“哪些行存在争议”推进。
给每个对象设一个主口径和一个辅助口径
可对照不等于两个数字相等。更实用的做法是让每一行只有一个主口径，辅助口径只用于解释差异。例如主口径是“已上线且可访问”，辅助口径是“已提交内容源”。当两者数量不一致时，先看辅助口径是否包含尚未发布的内容，再决定这一行算未完成还是算待确认。
- 主口径决定这一行是否通过，辅助口径只解释为什么两个数不同。
- 主口径必须能用一次独立检查复现，例如按同一份清单逐条打开。
- 辅助口径不要写成“进度良好”这类无法复核的描述。
- 同一行不允许同时挂两个都算通过的主口径。
这样做的实际影响是：当甲方报 100、乙方报 80 时，不必先判断谁对谁错，而是先问 20 的差额落在哪个辅助口径里。差额能逐条指认，下一步就是补做或改判；差额指认不出来，说明对象清单本身需要重做。
什么情况下这套对照表会失效
反例是：双方指标差异来自时间窗口不同，而不是对象或口径不同。甲方按下单日统计，乙方按实际发布日统计，同一批任务在月中会天然出现数量差。此时建立再细的交付表也无法消除差异，因为两个数描述的是不同区间。正确动作是先统一统计区间，再谈口径；区间不统一，对照表只会把时间差误判成执行差。
另一个会让对照失效的条件是：一方指标包含返工和替换，另一方只统计首次提交。若返工量较大，两个数会持续背离，且这种背离不是质量问题，而是统计规则不同。遇到这种情况，应在交付表中增加“首次提交”和“最终保留”两列，让返工可见，而不是把它藏进一个完成率里。
把交付表写成可核对的行动清单
表头建议只保留必要字段：对象名称、归属方、主口径、辅助口径、核对方式、差异原因、下一步动作。核对方式要具体到可执行，例如“按清单逐条访问并记录状态”，而不是“双方确认”。差异原因只能填可指认的事实，例如“未发布”“已发布但未在清单内”“统计区间不同”。
每次核对后只做一件事：把差异原因归入“需补做”“需改判”“需重设口径”三类之一。归入需补做的，进入下一轮执行；归入需改判的，修改主口径判定；归入需重设口径的，暂停对照，先改表头。这个动作的价值在于，它让下一步由差异类型决定，而不是由哪一方声音更大决定。
下一步动作与判断依据
先选一批数量最小、最容易逐条核对的对象做试点，例如十个页面或十条内容。用同一份清单分别按甲方口径和乙方口径各核一遍，记录差额能否逐条指认。若差额能全部指认，说明对象和口径基本对齐，可以扩大范围；若差额无法指认，先不要扩大，回到对象清点这一步重做。这个判断只依赖可复现的核对记录，不依赖任何一方对整体进度的描述。
