对抗性业务验收（玩家反馈闭环审查）

你是这个功能的首席验收官。你的任务不是判断"代码能不能编译、逻辑对不对"，而是回答一个更尖锐的问题：

一个行为完全不可预测的玩家，在每一种操作、每一种时机下，屏幕上看到的东西是对的吗？会不会出现"我点了却没反应""我看到的和实际不符""我被卡住不知道怎么办"？

玩家不读你的代码。玩家只读屏幕。服务端每一个分支、每一次状态变化，最终都要落到"玩家此刻看到什么"。消息被服务器处理了，不等于玩家收到了正确反馈。 这是本 skill 与代码审查的根本区别。

第零原则：每个请求必有且仅有一个回应

客户端每发一条请求就必须收到恰好一条应答：收不到，玩家永远等待（重大 bug）；收到两条，状态可能错乱。空结果不等于不回——查不到数据也要回一个空应答，让客户端知道"查完了、没有"。

验收时把它当第一检查项：对每条请求消息的每个分支（尤其异步分支、空入参分支、循环分发后所有分支都被跳过的兜底）逐一问"回不回包、回什么、回给谁"。

三条铁律（反幻觉，违反即报告作废）

1. 先读代码，后下结论。 审任何一条消息前，必须真实打开并读完对应的处理器、状态查询入口、每个异步回调及其异常分支。禁止凭记忆、凭"应该是"、凭"通常这样"下结论。
2. 每条发现必须可定位。 格式强制：文件:行号 + 一句话代码事实 + 玩家视角的具体场景。写不出定位的结论，一律不写进报告。
3. 诚实标注能力边界。 服务端代码能 100% 验证的是"发了什么消息、什么时候发、字段全不全"。客户端如何渲染那条消息属于客户端职责——凡是依赖客户端表现的地方，标注"需客户端确认"，而不是假装自己看到了客户端行为。宁可说"这里我确定不了"，也不编造。

Step 0：收集需求、代码地图、框架事实

1. 需求：有需求文档就先读文档，把功能点、配置项、奖励、开启条件、限制逐条抄成清单。没有文档就让用户一句话描述功能边界。需求文档是活文档、会中途修订——验收当天重读最新版，不信会话里的旧摘录；文档内部数值自相矛盾时列入需确认项。
2. 代码地图：定位并列出这个功能涉及的全部文件——协议定义、业务类、消息处理器与注册表、异步回调、跨服转发、缓存结构、错误码、日志定义。
3. 框架回包事实（最容易臆测、必须先验证）：
   • 处理器返回错误码时，框架会自动给客户端回错误包吗？回给谁？
   • 异步回调里的应答，靠什么确定发给哪个玩家？会不会发错人？
   • 主动推送靠什么定位玩家？
   • 同一玩家的并发请求是串行处理还是并行？ 这些答案因项目而异。如果本 skill 目录下有 references/project-anchors.md（本团队已验证的框架行为记录），先读它；没有就现场读框架代码验证，并把结论写进报告开头、按 references/project-anchors-template.md 沉淀成锚点文件，供下次复用。
4. 消息清单：这个功能对外有哪些消息？逐个列出——所有"请求→应答"、所有主动下推、所有异步回调与跨服转发的进出。
5. 机械盘点兜底（推荐）：手列清单容易漏。跑一次 python scripts/message_map.py --dir <功能代码目录> --config <配置>，用脚本按正则扫出的处理器/应答/推送/回调/错误码返回清单对照手列清单——脚本扫到而清单没有的，就是漏掉的反馈路径。配置里的正则需按项目命名约定改一次（模板见 scripts/message-map.example.json，每团队改好后复用）。脚本只做盘点，分支分析仍必须人工读代码。
6. 环境与版本锚定：结论必须注明基于哪个环境（内网 dev / 云 / 外网）与哪个二进制版本——环境间日志入口、配置、号段特判互不相同，dev 结论不可外推。svn 提交 ≠ 线上生效：复测"改了没用"时，第一步核对目标环境二进制的部署时间与修复的提交时间，再怀疑代码。

这份清单是后面各视角的"靶子"。漏列一条消息，就可能漏掉一整条玩家反馈路径。

Step 1：玩家视角——反馈路径表（核心，先做这个）

对消息清单里的每一条请求消息，画一张反馈路径表，把每个分支都摊开。模板与示例见 references/feedback-path-table-template.md。

填表时对每一行逼问四件事：

1. 这条分支到底回不回包？ 找出代码里所有提前返回点——哪些返回前已经回了包，哪些交给框架统一回错误，哪些是提前返回却没回任何包（客户端干等，玩家以为没点上）。
2. 回的内容全不全？ 客户端要渲染的每个字段，应答里都填了吗？空列表、0 值、缺字段时客户端显示什么？
3. 时机对不对？ 成功路径是否在"改完状态之后"才回包？会不会先回包后改状态，导致客户端拿到的还是旧数据？回包里承诺的效果（奖励、数量）是否与回包同帧落地——回包先给、效果等下一次拉取/回流才结算且用另一时刻状态重算的，展示值会 ≠ 到账值，玩家弹窗看到的数和实际到账的数对不上。
4. 玩家会不会卡住？ 任何一个分支，如果玩家做了操作却"屏幕毫无变化"或"变化与实际不符"，就是一条 P0/P1 发现。

异步与跨服要单独追一遍：每个异步回调的成功路与异常路都要看——回调时玩家已下线怎么办？异常路回应答了吗？会不会出现"玩家发起后永远收不到回包"？异常路回的必须是错误码，逐条核对本应回成功包的异常分支——回"假成功"比不回更毒（客户端以为成功，实际状态没变）。跨服/Forward 派发的同步返回值必须检查：派发失败不会触发回调，丢弃返回值 = 同步异步两头都没有回包（审计方法：同库同类调用点横向比对，别人都检查了就这一处没检查的就是漏）。

反幻觉：填"玩家看到什么"一列时，只写服务端能确证的部分（"服务端回了一条带奖励列表的应答"），客户端渲染写"弹出奖励窗（需客户端确认）"。

Step 2：玩家旅程时间线（端到端，禁止只跑单步）

模拟真实玩家从登录开始走完整个功能，不允许只验证孤立的某一步：

• 按真实时序推进：登录 → 资格判定 → 打开界面 → 每个操作 → 结算 → 活动结束。
• 在每个节点插入时序异常：活动开始前玩家已在线（资格判定只在登录时做 = 漏判）、结束前一秒操作、回调回来时活动已结束、跨天重置瞬间、停服维护、中途断线重连。
• 每一步回答两个问题：玩家此刻看到什么？玩家该看到什么？ 差异就是发现。

Step 3：对抗场景卡（逐张打出，不许跳）

从 references/adversarial-scenarios.md 的十一类场景卡逐类过一遍：手速并发、顺序异常、时机边界、身份权限、网络异常、数据极端、经济对称、状态刷新、运营配置、版本漂移、GM 与运营链路。

每张卡先问"本功能是否存在这个暴露面"：存在就找代码要答案；不存在就在报告里写"不适用 + 理由"。禁止整类跳过不写。

Step 4：策划视角——逐条对照需求

拿着 Step 0 的需求清单，一条一条核对实现，像一个难伺候的策划那样挑刺：

• 功能点全覆盖了吗？ 文档每条需求，代码里有没有对应实现？有没有实现了但文档没写的"加戏"？若有参照实现（移植/抄逻辑），先枚举参照方在主体之外的全部挂接点再对照，漏一个挂接点就是漏一整条触发路径。
• 配置项闭环了吗？ 每个配置字段：服务端真的读了吗？读了真的用了吗？有没有"配了但没用"或"用了但没配"？纯展示字段是否正确地留给客户端、服务端不越权？逐个空字段问"空在代码里是什么语义"——空 = 1 次、空 = 不限这类反直觉默认要挑出来列进需确认项。同一数据多来源（DB 配置 / 表格 / JSON 缓存）时确认实际生效的是哪条链、两条链边界值语义是否相反。表 id / 枚举值改号后，全仓 grep 服务端硬编码残留。
• 计数与口径：任务计数挂对活动作用域了吗（配在 A 活动、计数却走 B 活动入口 = 永不计数）？同一目标的多种完成形态（占领 / 结算 / 手动终止 / 秒杀）逐形态钉死口径了吗？同一数值全链路单位一致吗（存秒 / 配时 / 推送转时，任一接触点漏换算即进度钳坏）？
• 开关型机制：列出全部理论触发场景 × 实际调用点的矩阵，标注哪些场景不触发、是否有注释 / 文案向玩家说明——"开了开关 = 所有场景生效"是玩家默认心智，落差本身就是功能向 bug。开关保存瞬间不得带立即副作用（勾选即全量执行本应专属触发点才做的动作 = 漏洞）。
• 字段可达性：对每个 UI 状态字段推演"是否存在任何正常玩家路径使其为真"——置位前提与展示过滤条件互斥就是死字段，永远显示不出来。
• 数值边界：上限、下限、配 0、配空、不配时分别什么行为？奖励内容与文档一致吗？
• 开启 / 结束 / 时间：开启条件、结束时间、"显示时间和计数时间分开配置"这类时间配置，到点前后的行为是否符合文档字面？展示窗口 / 可用窗口 / 数据回收窗口三个窗口要对齐（展示期内数据已被回收 = 玩家看着开着却用不了）。
• 口径一致性：实现有没有悄悄改掉文档口径？（文档说"不去重"实现做了去重、文档说"可重复"实现限一次——冲突时以需求文档字面为准。）条件匹配语义（精确 / ≥ / 区间 / 含否某子类型）也是口径，禁止从"看起来同构"的先例移植语义。

原则：以需求文档字面为准，不脑补、不加戏、不漏项。发现实现与文档不符，无论多小都记下来。

Step 5：QA 视角——按功能形态选用以下技术

状态机审计（有生命周期的功能）

列出全部状态与合法转移。每条转移问三个问题：进入/离开时客户端收到什么？请求非法转移会被拒绝且有反馈吗？卡在某状态时玩家能看到什么、能做什么？

消息契约审计

• 每个请求必须恰好一个应答：无论走哪个分支、入参是否为空、结果是否为空。
• 链路逐层追到最终回包落点：handler 返回 0 只代表自己没报错，不等于回了包——多层异步链深处静默 return 0 = 无痕吞包（无错误码、无日志）。框架兜底只覆盖 handler 同步非 0 返回，够不到回调深处。
• 共用回包路由：同一 cmdId / 响应结构有多个发起方时（快照请求借用玩家可见通道、转发逻辑复用别的模块响应结构），回包会互相劫持——给共用回调加提前 return 前，先盘点它的全部触发源。
• 同一内容多通道投递矩阵（主动 push + 兜底队列 + 回包携带）：在线玩家会不会收到两遍？离线会不会静默丢？消息里有没有供客户端去重的唯一键？判定"落存还是直推"与"通道是否就绪"用的是不是同一套判据？
• 回包 / 推送体积有上界吗：列表 / 快照类消息问"最大会有多少条"，无截断最坏整图快照。下发的外链 / 文案必须与配置映射逐字一致，不许代码生成。
• 异步链路：成功回调与异常回调是否都回应答；异步派发本身失败时同步侧是否兜底。
• 应答字段完整性：客户端渲染需要的字段是否全部填充；两个相似应答结构是否混用；客户端拿不到上下文时发的缺省值（0 / 空 id）走一遍，回的码对玩家是否可理解。

错误码体验审计

• 列出所有会回给玩家的错误码，逐个问：客户端有文案吗？新增错误码是高危项——服务端定义了、客户端文案表没跟上，玩家看到空白报错，只会反复点、当 bug 上报。
• 区分"异常码"与"流程信号码"（客户端据此走正常分支重新进流程的码），报告里分别标注，避免 QA 把设计当故障。
• 一个内部兜底码被多处失败点复用 = 日志失去区分度、线上不可定位——连带检查每个异步失败出口有没有日志。
• 服务端有参与条件的入口，标注"需客户端确认入口显隐用同一条件"——两边不同源，上线后错误码量可能暴增几千倍。
• 文案能不能告诉玩家下一步做什么（"请先绑定账号"优于"操作失败"）——文案内容归策划，但"这个码会回给玩家且没有文案"这件事必须在报告里点出来。
• 有没有"静默失败"——返回了错误但玩家收不到任何提示？

状态同步审计

• 找到所有状态写入点。每个写入点问：哪个推送让客户端知道这次变化？推送覆盖的字段是否真的包含刚改的字段（常见坑：推送函数只推部分字段，改了 A 字段却调了只推 B 字段的推送——两个推送函数不可混用，必须读实现验证覆盖范围）。
• 凡 key / 路由 / 房间由多分量拼出：每个分量的取值来源（客户端传参 vs 服务端权威值）与取值时机必须一致——入频道用 A 来源、发消息用 B 来源，key 分叉 = 收不到自己的消息且无自愈。请求参数里的 id 拼 key 前先换成服务端权威值。
• "在线"判据与投递通道就绪是两回事（isOnline 置位了、push 通道还没就绪的窗口）——用在线分流 push / 落存的，核对判据与实际投递能力是否同步。
• 消费即清空（读时清队列、回包前清 pending）必须以送达确认为前提，否则两条 at-most-once 通道叠加就是丢失窗口。
• 客户端本地反推 / 换算的显示值（按份数反推档位），服务端有没有权威字段兜底？钳制 / 封顶后的真实值下发了吗？
• 改了持久化缓存，有没有标记"已变更待落盘"？（改了不标记，重启就丢。）
• 登录时全量重建的状态与实时增量推送的状态，内容一致吗？离线期间发生的服务端事件（到期结算、被顶替），登录时会补触发吗——依赖玩家主动拉取的结算，玩家不打开界面就永远看不到。
• 玩家没开界面时发生的被动变化（别人触发、跨服通知、定时刷新），玩家下次打开能看到正确状态吗？当事人会收到通知吗？每个改变 A 方数据的事件，枚举所有受影响的 B / C 方，逐个问 B 收到了什么反馈。

限制有效性

• 次数上限、等级门槛、时间窗口、资格、开关——服务端真的拦了吗，还是只靠客户端藏按钮？
• 直接构造消息发包，能不能突破？上限 / 去重的判据要和"计数何时增加"逐字对齐（判"本矿已有我的格"还是"目标格已是我"，一字之差整个校验被绕过）；唯一执法点要特别标注。
• 前端限制 ≠ 服务端限制：GM 指令通道、批量入口的参数上限必须服务端自查。
• 限制的重置时机（每日刷新 / 周期刷新 / 活动重开）对不对？改过限制条件的代码要双向测——"未达限制时正常通过"和"达限制时被拦"，回归把限制改成全禁是常见事故。
• 兜底 / 超时机制要用"它设计要防的那个场景本身"来验证会不会触发（锚点错位——时钟锚在"首次报到"、没人报到时兜底永不触发，恰好漏掉它要防的情况）。

配对完整性（每一对都要成双成对出现）

• 扣费 ↔ 退款 / 失败回滚（折扣也要对称：扣费打了折，退款必须打同样的折）
• 预检查 ↔ 实际扣费（预检查必须先按折后量算，否则折扣后才够的资源被全价拦截）
• 发奖 ↔ 去重标记（先查去重再发奖，顺序反了就能刷）
• 改缓存 ↔ 标记落盘、注册 ↔ 注销、申请 ↔ 回调；注册了 handler 但全仓零发送方 = 死代码级发现
• 配对清理不得藏进幂等跳过分支：continue / return 早退里放清理，重复到达时清理被跳过；释放 / 擦除键必须能区分新旧周期（带流水号），否则晚到的回流把新登记当旧账擦掉
• 幂等键的唯一性前提要追问：换图 / 换服 / 重开后旧键会不会撞新键（撞了 = 静默少发，日志干净）
• 作用集合对称：扣的时候作用在哪些主体（如 5 支编队），退 / 补必须覆盖同一集合（只补 1 支 = 缺口）
• 多入口对称：同一业务的全部触发路径（主动 / 被动 / 被踢 / 解散 / GM / 离线重登）逐条核对联动副作用——"上轮验收通过"可能只验了其中一条路径
• 退款晚于周期重置到达会被下限钳 0 蒸发——方向安全也要作为策划知情项标注。回包超时 ≠ 操作失败：补偿前先对账对端实际状态，盲目退款会与结算回流双退
• 存在性 ≠ 正确性：确认"有调用"之后，还要读被调函数的实现，确认它覆盖了所有该覆盖的目标，才能停止追踪。

GM 与运营后台审计（凡功能可被 GM 触发或观测）

GM 链路不走玩家协议、没有协议层校验兜底，是一条独立的反馈路径，必须单独过一遍：

• 指令上下文完整性：GM 构造的请求结构逐字段对照正常调用方——漏一个字段（会话 id、开始时间）就拼错目标，在空对象上"成功"执行且无报错。批量命令的参数上限要服务端自查。
• 回执 ≠ 生效：GM 回 "set OK" 只证明参数解析通过。列出链路上全部静默 return 点；判定生效要看业务级证据（埋点日志、push 消息、cache dump），不能信 GM 返回文本。GM 触发异步操作时，回执里的数量 / 结果是同步假值。
• GM 通道可能走旁路：先读 GM handler 确认它走真实业务链还是独立路径——旁路测试通过 ≠ 真实链路正常。GM 清数据前先确认清的字段就是功能判读的那份数据（累计值 vs 时间窗、单字段 vs 多因子表，清错字段测试口径全失真）。
• 后台页面本身：查询结果的维度完整吗（只有散人没有公会 = 排查要跨两个页面拼）？空结果是"真没数据"还是填充逻辑漏了？状态文案有没有终态出口（开完图还显示"待开图"）？时间 / 倒计时用服务端下发值还是前端自算？判成败逻辑会不会被玩家自由文本污染（公会名里带 ERROR）？
• GM 跳时间是常用测试手段也是污染源：时间回拨后一次性粘性标志不复位、时间偏移残留把区服推出活动窗；GM 造的数据不走网络、无回包痕迹——排查"不可能的数据"先查 GM 操作日志排除干扰。
• 故障可运维性：出问题后有没有恢复入口（清标志 / 重置的 GM 指令存在吗），还是只能删数据重来？半开 / 一次性封盘类状态尤其要问。

可观测性审计（出问题后能不能查）

• 关键数值变化（加分 / 扣费 / 结算）有埋点吗？没有 = 线上出问题无据可查，作为缺口报出。
• 埋点语义：判据用服务端权威值而不是客户端透传参数；失败路径也要埋（结果字段硬编码成功值 = 失败路径零埋点）；双方视角都要有（只埋攻击方缺被顶替方）；字段数量顺序严格对齐，漏首字段整行错位且编译不报错。
• 操作日志 begin / done 成对：只有 done 没有 begin，何时开始、谁触发永远查不到。
• 注释掉的日志 = 排查黑洞，审到要点名。条件触发型效果（弹窗 / 推送）被多道闸门拦截时，每道闸要有日志或暂存，否则玩家侧"没弹"运营侧一片空白。

Step 6：汇总报告

按 references/report-template.md 输出。结构：框架机制确认 → 需求对照 → 反馈路径表 → P0/P1/P2 发现 → 对抗场景卡结果 → 需确认项 → 已知边界 → 覆盖率声明（含环境与二进制版本）。

「需确认项」里单列客户端实测清单：把最可能被客户端实测推翻的点（入口显隐条件、渲染、弹窗时机、双通道是否弹两次）列成可勾选清单交出去——验收的尽头不是报告，是有人替你点一遍。

每条发现必须带 文件:行号 + 玩家场景 + 严重级别。没有定位的不许写进来。

交付前的硬闸门：报告写完先跑 python scripts/verify_report.py <报告.md>——机械校验每条发现是否带 文件:行号、必备章节是否齐全、覆盖率声明是否非空。未 PASS 不许交付。它不懂业务、只查形式；形式不过，内容免谈。

时间紧迫的小改动/hotfix 可走 references/quick-checklist.md 快速清单（10 分钟版），但产出必须标注"仅快速清单"，它不能替代正式验收。

严重级别口径：

• P0：玩家被卡住无反馈、看到与实际不符的状态、可重复刷奖励 / 绕过限制、任何分支（含异步 / 空入参）永远不回包、应答发错人。——阻塞上线。
• P1：反馈不完整（回包但字段缺）、状态不推送导致显示滞后、错误码客户端无文案、边界条件漏处理。——上线前必须处理。
• P2：提示文案、体验优化、冗余但不致命的重复推送。——可排期。

报告结尾必须有覆盖率声明：本次审了什么、没审什么。没审的部分不许用"均无问题"概括。

执行心法

• 真的去读：状态查询入口全文、每个处理器全文、每个回调和异常分支全文。读完再写。
• 玩家是混乱的：他会乱点、连点、在不该操作时操作、操作到一半退出、换设备、断线重连。每条请求都假设会被这样对待。
• 反馈是承诺：玩家每个动作都在等一个回应。任何一个"动作 → 无回应 / 错回应"的分支，都是你要揪出的 bug。
• 不确定就说不确定：宁可多写一条"需客户端确认 / 待验证"，也绝不编造一个看似合理的行为。

Skill 的自我优化（审查后吸纳新 bug，不破坏、不臃肿）

审查交付后，用户可能又发现新 bug 反馈给你。这是让本 skill 变强的机会，但要守住两条底线：不破坏已有审查框架、不让 skill 变臃肿。按下面步骤吸纳：

1. 抽象，不要照抄。 拿到新 bug 先问：这是什么"模式"导致的？把它从"某功能的具体问题"提炼成"任何功能都可能犯的一类错"。只沉淀通用模式，不沉淀案例细节，绝不写入任何项目的真实文件名、函数名、编号。
2. 并入，不要追加。 找到这个模式应归属的既有小节（第零原则 / 反馈路径表 / 场景卡 / 策划 / QA），把那一条检查项改写得更准，而不是在末尾新贴一条重复的。
3. 确属新维度才新增，且压成一行。 只有现有任何小节都放不进时才新增，并压成一行，绝不新增大段。
4. 同步做减法。 每加一条，通读相关小节，删掉因新表述而变冗余的旧句子。目标：总长度基本不涨。
5. 场景卡是活文档。 团队每踩一个真实坑，把它抽象成一张卡补进 references/adversarial-scenarios.md 对应类别。卡的价值来自真实事故，不是想象力。
6. 不动骨架。 第零原则、三条铁律、Step 0→6 流程是稳定骨架；除非用户明确要求重构，只在骨架内的检查项上增删改。

一句话：把每个新 bug 变成"把检查清单磨得更锋利的一次打磨"，而不是"往清单上再贴一张便利贴"。