上个月有个做家居品类的投放团队交接AB页跳转配置，接手的人拿着上一任留下的文档配了两天，灰度比例、参数映射、日志字段全都照着文档填的。上线第三天出事了——部分渠道的跳转分支跟预期完全对不上。回头翻文档，就一句话"按渠道配置对应目标页"，哪个渠道对应哪个目标页、依据什么条件判断、条件冲突了谁优先，一个字没写。这种事儿真不是个例。AB页跳转的配置从来就不是单一文件，规则条件、参数映射表、灰度比例、日志字段、回退开关，这几组东西是绑在一起的一个集合，交接的时候任何一组缺了上下文，接手方就只能靠猜。
配置文档交付清单的价值就在这儿：它不追求写一本完整手册，而是保证接手方拿到清单后，能在有限时间内把链路配起来、验证通过、并且知道出问题时从哪查。下面按准备、执行、复盘三个阶段拆开讲，每个阶段写清输入是什么、要产出什么、验收标准怎么定。
为什么AB页跳转的交接比普通配置交接更难
普通配置交接，交的是一份参数表；AB页跳转交接，交的是一条决策链路。链路上至少有三层东西：判定层，什么条件下走哪个分支；映射层，分支对应哪个目标页、参数怎么带过去；观测层，跳转发生后怎么确认走对了。三层之间是耦合的，判定条件改了，映射表可能要跟着改，日志字段也要跟着调，否则事后根本还原不出当时为什么走了那个分支。
交接期最容易断裂的恰恰是耦合关系。上一任脑子里装着"这个条件是给那个渠道兜底的"这类隐性知识，文档里只写了条件表达式本身。接手方看到条件能读懂语法，读不懂意图，于是要么照抄不敢动，要么觉得多余给删了，两种都会出问题。交付清单的第一个设计目标，就是把隐性意图显性化：每个条件旁边要能回答"为什么是这个值""什么情况下可以改""改了会影响谁"。
第二个难点是验证成本。AB页跳转的配置对不对，光看文档看不出来，得跑流量验证。但交接期往往没有独立的测试流量预算，接手方只能拿线上真实流量边跑边看，出错就是真实损失。所以交付清单里必须包含"可离线验证的部分"和"必须线上灰度验证的部分"的切分，让接手方知道哪些能提前自查、哪些必须走灰度。
准备阶段：先盘链路，再定交付边界
盘清链路上的配置承载点
准备阶段的第一件事不是写文档，是把配置到底散在哪些地方盘清楚。AB页跳转的配置通常分布在四类承载点上：规则引擎里的条件配置、跳转插件或中间件里的映射表、灰度控制台的流量比例设置、日志采集侧的字段定义。每一类承载点的负责人、变更流程、回滚方式都可能不同。
盘点时按承载点列一张表，每行记录：承载点名称、当前配置版本或快照时间、变更入口（谁有权限改）、回滚手段、最近一次变更时间和原因。这张表本身就是交付清单的骨架，后面所有交付物都挂在它下面。限制条件在于，盘点要覆盖交接范围内全部承载点，漏一个就意味着接手方将来在某处改配置时不知道还有另一处联动。
验证盘点是否完整的方法：拿一条真实的历史跳转请求，从入口到目标页走一遍，看这条请求经过了哪些配置读取点，能对上盘点表就基本完整。
定义交付边界：交什么、不交什么
交接最容易扯皮的是边界不清。交付方觉得"我文档都给了"，接手方觉得"关键的没给"。准备阶段要把边界写死：本次交接覆盖哪些渠道、哪些页面组、哪些规则集，不覆盖的部分明确标注"仍由原团队维护"或"已下线"。
边界定义要落到可核对的程度。比如"覆盖A、B两个渠道的跳转规则"，要能对应到具体的规则集ID或配置快照，而不是一句范围描述。不覆盖的部分同样要给出去向，接手方至少知道遇到边界外的问题该找谁。
- 输入：交接范围说明、现有配置的承载点盘点表、各承载点最近变更记录
- 产出： 交付边界声明（含覆盖清单与排除清单）、承载点责任对照表
- 验收标准： 接手方随机抽三条线上跳转请求，能独立定位到每条请求涉及的配置承载点，且与盘点表一致
执行阶段：交付物清单怎么列才经得起核对
执行阶段的交付清单按四类组织，每类都要有明确的验收动作，不能只写"已提供"。 第一类是规则条件说明。每个跳转分支的触发条件要写清三样：条件表达式本身、这个条件服务的业务意图、相邻条件之间的优先级关系。优先级尤其容易被漏——两个条件同时命中时谁生效，文档不写，接手方只能按配置文件的书写顺序猜，而书写顺序往往和实际生效顺序不是一回事。验收动作：接手方挑两个可能同时命中的条件，能说出冲突时的实际走向，并与线上行为对得上。
第二类是参数映射表。跳转时带过去哪些参数、参数名在源页和目标页之间是否改名、空值或缺值时怎么处理，逐条列出。参数透传断链是交接后的高频问题，根源大多是映射表只写了"正常情况"，没写缺值兜底。验收动作：给一个缺参数的样本请求，接手方能按映射表说出目标页最终收到的参数集。
第三类是灰度与回退配置。当前灰度比例是多少、按什么维度切分（渠道、地域、设备还是随机）、回退开关在哪、回退后流量落到哪个兜底页。这几项必须写具体数值和具体入口，不能写"按需调整"。验收动作：接手方能在不询问交付方的情况下，独立完成一次灰度比例调整和一次回退演练。
第四类是观测字段说明。决策日志里记了哪些字段、每个字段的含义、哪些字段用于事后还原跳转分支。这一类的验收动作是：拿一条历史日志，接手方能仅凭字段说明还原出这条请求走了哪个分支、命中了哪个条件。
验收证据要留痕，不能只写"已确认"
交接文档最常见的失效方式是：清单上每项都打了勾，但打勾依据是口头确认。三个月后接手方配错了，回头查交付记录，只看到一行"规则条件说明已提供"，没法判断当时提供的版本对不对、内容全不全。
可行的做法是每个交付物挂三样留痕：交付版本标识（快照时间或文件版本号）、验收动作的执行记录（谁在什么时间做了什么核对）、遗留问题清单（当时已知但未解决的点）。遗留问题清单尤其重要，它把"已知的坑"显性化，避免接手方把已知问题当成新故障去排查。限制条件是留痕本身有维护成本，所以只对核心交付物强制留痕，辅助材料可以简化。
文档写得再细，也不如让接手方在交付方在场的情况下完整配一遍。执行阶段末尾安排一次双人演练：接手方按清单独立完成一个渠道的配置变更，交付方只观察不干预，记录接手方卡住的每一个点。这些卡点直接反写回清单，作为下一版的补充项。
演练的验收标准不是"配完了"，而是"接手方能在不提问的情况下配完，且变更后观测字段的读数符合预期"。如果接手方中途提问超过预设次数，说明清单对应部分还需要补。
复盘阶段：把交接期的偏差反写回清单
偏差分类：缺项、错项、歧义项
交接完成后一到两周，做一次偏差复盘。把这段时间接手方遇到的配置问题分三类：清单里完全没写的（缺项）、写了但内容不对的（错项）、写了但两种理解都说得通的（歧义项）。三类问题的修法不同：缺项补内容，错项改内容并追溯为什么错，歧义项改表述方式。 歧义项最值得花时间。比如"灰度比例按渠道切分"这句话，可以理解成每个渠道内部按比例随机，也可以理解成不同渠道分配不同比例。两种理解配出来的结果完全不同，但句子本身没毛病。复盘时把这类句子挑出来，改成带例子的表述，比抽象描述管用得多。
清单迭代的节奏与版本管理
交付清单本身也要版本化。每次交接复盘后产出一版更新，记录改了什么、为什么改。版本号不必复杂，按交接批次编号即可。这样做的好处是，下一次交接时可以直接拿上一版的清单当起点，而不是从零起草。
迭代节奏上，建议交接完成后一个月内完成首轮复盘更新，之后按需维护。太频繁的迭代会让清单变得臃肿，太久不更新则失去时效性。
- 输入：交接期问题记录、双人演练卡点记录、线上观测异常记录
- 产出： 偏差分类表、清单更新版本、遗留问题跟踪清单
- 验收标准： 更新版清单能让未参与本次交接的第三人读懂核心配置逻辑，且能独立完成一次小范围配置变更
实战复盘：一个流量团队的交接踩坑记录
某做家居流量站的团队，日均跳转请求量在几千次量级，服务器是两台中等配置的云主机加一个跳转中间件。原负责人离职前留了一份交接文档，按"规则、参数、灰度"三节写的，看起来齐全。接手的是一个刚转岗过来的运营，配了三天上线，第一周就出了状况：某渠道的跳转目标页和预期不一致，部分请求落到了默认页。
排查下来是两层问题叠在一起。第一层，文档里参数映射表只写了参数名对应关系，没写缺值兜底，该渠道有个参数在部分请求里为空，中间件按空值处理，映射失败后走了默认分支。第二层，规则条件里的优先级只在配置文件注释里提了一句，运营按文档顺序理解，实际生效顺序是另一套，两个条件同时命中时走向和文档描述相反。
调整过程分三步走。先把承载点重新盘了一遍，发现除了文档写的三节，日志字段定义和回退开关入口完全没交，补进清单。然后针对参数映射补了缺值兜底规则，并在映射表里加了"缺值时目标页收到什么"的样例行。最后把优先级关系从注释里提出来，单独成节，用"条件A命中且条件B命中时走A"这种直白句式写，不再依赖配置文件顺序。
调整后做了一次双人演练，运营独立配了一个小渠道，中途卡了两次，都记进了清单更新。最终状态是：交接后第二个月，该团队处理了两次小范围配置变更，没有再出现落错页的情况，观测字段也能支撑事后还原。遗留问题还剩一个——跨渠道共用的规则集边界仍然有点模糊，标注为待下一轮梳理。
交付清单的常见设计误区
第一个误区是把清单写成配置的逐行翻译。清单的作用是保证关键信息不遗漏，不是把配置文件抄一遍。抄一遍的后果是清单和配置同步维护成本翻倍，最后两边都不准。正确做法是清单只记"接手方必须知道才能正确操作"的内容，配置本身以快照形式引用。 第二个误区是只写正常路径。交接文档里正常路径写得再细，缺了异常分支的说明，接手方遇到第一个边界情况就得回来问人。缺值、超时、条件冲突、回退后流量去向，这几类异常分支至少要各写一条。
第三个误区是验收标准写成"已阅读确认"。阅读确认只能证明接手方看过，证明不了能用。验收标准要落到可执行的动作上，比如"能独立完成一次回退演练""能凭日志字段还原一条历史请求的分支走向"。
收束：一份可复用的检查项清单
把上面的内容收成一组检查项，交接时逐项过一遍，比临时起草文档可靠。
- 承载点盘点表是否覆盖规则配置、映射表、灰度控制台、日志字段四类，且每条能用真实请求对上
- 交付边界是否写明覆盖清单与排除清单，排除部分是否有明确去向
- 每个跳转分支的条件是否附带业务意图与优先级关系说明
- 参数映射表是否包含缺值与异常值的兜底行
- 灰度比例、切分维度、回退入口、兜底页是否写到可直接操作的粒度
- 观测字段说明是否支持仅凭字段还原分支走向
- 核心交付物是否挂版本标识、验收执行记录、遗留问题清单三样留痕
- 是否完成一次接手方独立操作、交付方只观察的双人演练
- 交接后两周内是否完成偏差分类复盘并产出清单更新版本
- 更新版清单是否经过未参与交接的第三人可读性验证
这十项不必每次都全做，但缺哪项要心里有数——缺的那项就是下次交接最可能出问题的地方。清单本身不是目的，让接手方在没有人可问的情况下也能把链路配对、验证对、出问题时查得动，才是交付清单真正要守住的东西。
