接入一个系统能力很容易跑出演示调一次接口、弹一个界面、拿到一个结果。但把它变成可预测、可调测、可审核的产品能力是另一回事。入参边界模糊、缺参时直接执行、权限声明与代码行为对不上演示里的顺利在真实使用中会变成误触发、错账和越权风险。这类问题没有一行是出在接口调不通上全部出在工程封装的粗糙上。本文把业务能力接入拆成场景、契约、编排、能力、治理和交付六层贯通开发、调测、审核与上架准备。示例业务设定为支付前的安全确认其余能力账号授权、设备联动、资料变更可以按同一套框架平移。文中代码采用适配层表达正式方法签名以当前官方SDK为准清单、类型与目录结构是应用侧工程示例。一、从单一可验证场景开始第一版只做一个场景用户在高风险交易前完成一次安全确认。把场景写窄有三个好处验收标准可以穷举、失败路径可以枚举、联调对象后台、风控、客服话术都收在一个闭环里。场景定义写成一段可评审的文字——触发条件、用户看到什么、用户做什么、成功与失败怎么判定、每条失败路径的出口是什么。写不清楚的场景后面每一层都会跟着模糊最后变成大家都在猜。// 场景描述的结构化表达 const scenario { id: pay-confirm-v1, trigger: (order) order.amountMinor 5000000 || order.riskLevel high, ui: { title: 安全确认, fields: [merchant, amount, orderId] }, actions: [inputSecret, confirm, cancel], success: (r) r.status SUCCEEDED, failure: [CANCELLED, TIMEOUT, MISMATCH, LOCKED], };1.1 一个写宽了的反例第一版评审时有人提议把订单改址、退款、换绑账号一起塞进同一个确认流程理由是都是确认界面长得差不多。做出来之后问题不断退款要展示退款说明、改址要展示新旧地址对比界面模板被迫做条件分支失败码从四个膨胀到十一个客服话术对不上号。最后还是拆回单场景各自独立演进。场景边界宁可窄窄了可以加宽了拆不动。二、把请求写成机器可检验契约契约是六层里最便宜也最值钱的一层。一份请求契约包含字段、类型、单位、必选性、约束和错误码写完立即变成校验代码所有入口共用。金额用最小货币单位、订单号限定字符集、时间戳统一毫秒——这些约定散落在代码里迟早打架收进契约一处管死。// 请求契约与校验器 const confirmContract { orderId: { type: string, pattern: /^[A-Za-z0-9-]{8,64}$/, required: true }, amountMinor: { type: integer, min: 1, required: true }, currency: { type: enum, values: [CNY, USD], required: true }, merchantId: { type: string, pattern: /^M\d{6,12}$/, required: true }, issuedAt: { type: integer, min: 0, required: true }, }; function validate(contract, input) { const errs []; for (const [k, rule] of Object.entries(contract)) { const v input[k]; if (rule.required (v undefined || v null || v )) { errs.push(MISSING: k); continue; } if (v undefined) continue; if (rule.type integer (!Number.isInteger(v) || (rule.min ! undefined v rule.min))) errs.push(TYPE: k); if (rule.pattern !rule.pattern.test(String(v))) errs.push(FORMAT: k); if (rule.type enum !rule.values.includes(v)) errs.push(ENUM: k); } return errs; }校验失败直接短路返回结构化错误不允许带着脏参数往下走。契约变更走版本号老版本保留一个过渡期两端按版本协商避免服务端升了客户端没跟的窗口期互咬。2.1 契约测试怎么落地契约不是文档是测试。把契约表自动生成一批正负用例缺必选字段、类型错、格式错、枚举越界各来一组断言校验器返回的错误码逐个对得上。契约改了用例没改测试就红——这比任何代码评审都可靠。2.2 契约版本协商的实操约定版本号放进请求头服务端按版本路由校验规则。约定三条同一时间最多存在两个活跃版本新版本上线旧版本至少保留十四天废弃版本的第一天开始打迁移提醒日志按调用方统计谁还没升。这三条让契约演进从赌博变成排期两端团队都能按自己的节奏走。三、入参必须有来源和合法性边界每个入参都要回答三个问题从哪来用户输入、服务端下发、设备采集、能到哪去哪些层可见、不合法时谁兜底。来源标记让排查有据可查可见域限制防止敏感字段被顺手传进日志兜底策略防止缺一个字段就卡死整个流程。字段来源可见域非法兜底orderId服务端下发全部层拒绝进入编排amountMinor服务端计算编排界面拒绝并告警secret用户输入仅能力适配层提示重输deviceFp设备采集治理层降级为匿名风控secret 这类字段永远不进日志、不进状态机、不进任何回调参数只在适配层内存里短暂存在用完即弃。这条红线写进代码评审清单谁碰谁改。3.1 一次字段越权的复盘早期版本为了排查方便把 deviceFp 拼进了确认结果的回调参数里结果日志系统把整个回调对象都打了出来敏感采集字段进了普通业务日志。复盘后的规矩回调参数白名单制新增字段必须先过可见域表日志层加了一道脱敏过滤器命中敏感键名直接打码。越权不是黑客才有的问题工程图省事就是最大的越权来源。3.2 可见域在代码里怎么落地可见域不靠口头约定靠类型收窄编排层拿到的请求对象是 Pick 过的子集敏感字段在类型上就不存在编译器替你把关。适配层内部再建一个独立的小结构体装敏感值出了作用域即销毁日志序列化器对这个类型直接输出掩码。三层防线类型、作用域、序列化任何一层漏了后面两层还能兜住。四、用状态机编排多步流程安全确认至少有探测、就绪、展示、校验、终态五个阶段加上取消、超时、锁定三条中断路径。状态机把现在能发生什么变成显式规则任何时刻只允许一条出口链非法迁移抛错而不是吞掉。const FLOW new Map([ [idle, [probing]], [probing, [ready, unsupported]], [ready, [presenting]], [presenting, [verifying, cancelled, timeout]], [verifying, [succeeded, failed, timeout]], ]); function step(from, event, trace) { const map { probing: probing, confirm: verifying, cancel: cancelled, expire: timeout }; const to map[event]; if (!to || !(FLOW.get(from) || []).includes(to)) { trace.mark(illegal: from event); throw new Error(ILLEGAL from event); } return to; }把超时也当作一次正常迁移处理就不会出现界面在等、会话已死的悬空态。每个迁移都带 trace 打点一次请求从头到尾一条线排查时按 requestId 一查到底。4.1 悬空态的三种成因实测下来悬空态只有三种成因事件重入用户狂点、回调重放、会话失效但界面还活着、超时没有接到状态机上。前两种靠非法迁移防护暴露第三种靠把超时事件化。三样都做齐之后这类的线上工单归零。五、能力适配器隔离平台与业务平台差异版本、机型、服务开通状态只允许出现在适配层。业务层依赖的是四个抽象方法探测、开会话、展示、释放。换机型、升版本、在模拟器跑回归业务层一行不改。export interface SecureConfirmAdapter { probe(): PromiseCapabilityReport; begin(intent: ConfirmIntent): PromiseSession; present(session: Session, payload: Summary): PromiseResult; release(session: Session): Promisevoid; }判断适配层切得好不好有个土办法能不能写一个内存版测试桩替换真适配器把编排层和治理层的单测整体跑通。能说明边界干净不能说明业务层偷摸摸碰了平台细节。5.1 内存测试桩长什么样// 内存桩行为可编排用于编排层与治理层单测 class MemoryAdapter { constructor(script) { this.script script; this.calls []; } async probe() { this.calls.push(probe); return this.script.probe; } async begin(intent) { this.calls.push([begin, intent.orderId]); return { id: s-1 }; } async present(session, payload) { this.calls.push([present, payload.digest]); return this.script.present; } async release(session) { this.calls.push(release); } }桩的关键不是返回值而是 calls 数组单测断言调用顺序、调用次数、传参内容编排层的流程正确性就有了硬校验。桩跑得通的业务层接真适配器只差环境问题。六、分层架构约束副作用六层各管一件事场景层定义验收、契约层管数据、编排层管流程、能力层碰平台、治理层管日志与降级、交付层管产物。副作用网络、存储、弹窗只允许在能力层和治理层出现其余层保持纯函数——同样的输入永远得到同样的输出测试不需要起环境。6.1 一次真实的越层事故编排层有个同事为了快一点直接在流程函数里调了 storage.set 把中间态落盘。单测全绿集成测试时并发两条流程互相覆盖中间态偶现订单错乱。修法是把落盘挪进治理层编排层只发状态已变更事件谁关心谁订阅。副作用越层的代码单测照样绿所以约束不能靠自觉要靠评审清单和分层 lint。七、输出也必须经过契约校验入参有契约回传结果同样要有。平台返回码、摘要哈希、时间戳逐项校验任何一项不过就按失败处理绝不看到成功字样就当成功。function verifyResult(raw, expectedDigest) { if (raw.status ! SUCCEEDED) return FAILED: raw.status; if (raw.digest ! expectedDigest) return MISMATCH; if (Date.now() - raw.finishedAt 300000) return STALE; return OK; }摘要哈希在请求发出前算好存档结果回来比对两边不一致说明中间发生了不该发生的事——展示被替换、参数被篡改、或者拿错了单子。宁可错杀重走流程不放过一次不一致。7.1 结果校验的失败演练校验代码写完要故意喂坏数据改一位摘要、把时间戳拨慢十分钟、把状态换成未知枚举。三种坏数据分别命中 MISMATCH、STALE、FAILED 三条出口一条都不能漏到当成功处理。这组演练进了回归之后校验逻辑再怎么重构都不怕红了就是改坏了。八、重试只处理真正的瞬时失败网络抖动可以重试摘要不匹配不能重试口令错误更不能自动重试。把错误分成三类瞬时网络、超时、确定性参数、格式、安全口令、锁定只给瞬时类发重试名额其余直接走对应出口。重试要带上限、退避和 trace防止把一次失败放大成一场风暴。8.1 重试风暴的教训上线首日出现过一次服务抖动客户端的重试没有退避三秒内把同一个请求打了几百次把本已恢复的服务又压了下去。从此重试统一走一个带指数退避的调度器全局并发上限、单请求上限分开设置并且每次重试都带同一个 requestId服务端能识别并合并重复请求。九、沙箱调测覆盖正负样本调测环境跑两套样本正常请求走通全链路证明能用构造脏参数、过期摘要、非法迁移走失败路径证明坏不了。正负样本都进回归每次契约或流程变更后全量重放。9.1 负样本清单从哪来不是拍脑袋列的三个来源失败路径枚举里每条出口至少一个样本历史工单里每类真实故障一个样本评审会上大家现场想一两个如果这样会怎样。三处合起来覆盖度就够用了。负样本的价值在于它记录的是我们怕什么比正样本更接近系统的真实风险。十、安全与隐私审查前置审查在编码前定规则口令只在适配层内存出现、摘要哈希落日志不落原文、设备指纹最小化采集、权限声明与实际调用一一对应。审查不是上线前补一张表而是评审会上对着代码一条条核对发现偏差当场改。前置的成本是几次评审会议后置的成本是一次安全事件。10.1 审查清单十条口令与等价敏感值是否只在适配层内存出现日志输出是否过敏感键名脱敏过滤器设备标识采集是否声明了用途并最小化权限声明与代码里的实际调用是否一一对应失败路径是否都有出口无静默吞错重试是否只覆盖瞬时错误且带上限回传结果是否逐项过契约校验状态机是否存在可达但未定义的迁移回调参数是否白名单制灰度开关与降级开关是否独立可切。十条对应十类历史事故每一条背后都有一次真实返工。清单会随事故库增长但只做减法不做加法某条连续两年没人命中说明它已内化成习惯可以撤下。十一、交付材料从事实生成交付文档里每一句支持/不支持都要有对应证据用例编号、实测环境、数据来源。手写材料最大的风险是和代码脱节——代码改了文档没跟审核方按旧文档验收到线上问题板子最后打在工程团队身上。从测试报告自动生成验收结论把人从对表里解放出来。// 从回归报告生成验收摘要 function buildAcceptance(report) { return { scenario: report.scenarioId, passed: report.cases.filter(c c.verdict PASS).length, failed: report.cases.filter(c c.verdict ! PASS).map(c c.id), env: report.environment, generatedAt: Date.now(), }; }11.1 材料与代码同源的流水线验收摘要由回归报告自动生成界面截图由自动化脚本在真机上现拍现传接口清单从契约表导出——三样东西都以代码为唯一事实源。审核方提出质疑时回溯链条是结论 → 报告 → 用例 → 提交记录每一环都查得到。手工材料省下的半天往往要用两次返工来还。十二、用失败注入完成验收验收不看功能能跑看失败注入的全矩阵服务不可用、会话超限、摘要篡改、连续输错、中途锁屏每一条都要走到预期出口并留下日志。注入点预期出口必须留痕能力探测失败降级普通确认降级原因码会话创建超时重试1次后降级重试trace摘要比对失败终止告警证据快照连续3次校验失败锁定阻断计数记录中途锁屏再回会话失效重走失效事件十二项全部通过才允许进入灰度。灰度期双写日志两周随时可以回放每一次确认决策灰度转全量后降级矩阵和失败注入用例进入常态回归防止后续迭代把已经堵住的口子又撕开。这套六层框架的成本集中在契约和状态机两处换来的是后面每一层都可以独立替换、独立测试。接入第二个、第三个能力时只有场景层和适配层是新的其余全部复用——工程封装的意义不在第一次接入有多快而在第二次、第三次接入时还敢不敢说这次和上次一样稳。
接入一个系统能力很容易跑出演示调一次接口、弹一个界面、拿到一个结果。但把它变成可预测、可调测、可审核的产品能力是另一回事。入参边界模糊、缺参时直接执行、权限声明与代码行为对不上演示里的顺利在真实使用中会变成误触发、错账和越权风险。这类问题没有一行是出在接口调不通上全部出在工程封装的粗糙上。本文把业务能力接入拆成场景、契约、编排、能力、治理和交付六层贯通开发、调测、审核与上架准备。示例业务设定为支付前的安全确认其余能力账号授权、设备联动、资料变更可以按同一套框架平移。文中代码采用适配层表达正式方法签名以当前官方SDK为准清单、类型与目录结构是应用侧工程示例。一、从单一可验证场景开始第一版只做一个场景用户在高风险交易前完成一次安全确认。把场景写窄有三个好处验收标准可以穷举、失败路径可以枚举、联调对象后台、风控、客服话术都收在一个闭环里。场景定义写成一段可评审的文字——触发条件、用户看到什么、用户做什么、成功与失败怎么判定、每条失败路径的出口是什么。写不清楚的场景后面每一层都会跟着模糊最后变成大家都在猜。// 场景描述的结构化表达 const scenario { id: pay-confirm-v1, trigger: (order) order.amountMinor 5000000 || order.riskLevel high, ui: { title: 安全确认, fields: [merchant, amount, orderId] }, actions: [inputSecret, confirm, cancel], success: (r) r.status SUCCEEDED, failure: [CANCELLED, TIMEOUT, MISMATCH, LOCKED], };1.1 一个写宽了的反例第一版评审时有人提议把订单改址、退款、换绑账号一起塞进同一个确认流程理由是都是确认界面长得差不多。做出来之后问题不断退款要展示退款说明、改址要展示新旧地址对比界面模板被迫做条件分支失败码从四个膨胀到十一个客服话术对不上号。最后还是拆回单场景各自独立演进。场景边界宁可窄窄了可以加宽了拆不动。二、把请求写成机器可检验契约契约是六层里最便宜也最值钱的一层。一份请求契约包含字段、类型、单位、必选性、约束和错误码写完立即变成校验代码所有入口共用。金额用最小货币单位、订单号限定字符集、时间戳统一毫秒——这些约定散落在代码里迟早打架收进契约一处管死。// 请求契约与校验器 const confirmContract { orderId: { type: string, pattern: /^[A-Za-z0-9-]{8,64}$/, required: true }, amountMinor: { type: integer, min: 1, required: true }, currency: { type: enum, values: [CNY, USD], required: true }, merchantId: { type: string, pattern: /^M\d{6,12}$/, required: true }, issuedAt: { type: integer, min: 0, required: true }, }; function validate(contract, input) { const errs []; for (const [k, rule] of Object.entries(contract)) { const v input[k]; if (rule.required (v undefined || v null || v )) { errs.push(MISSING: k); continue; } if (v undefined) continue; if (rule.type integer (!Number.isInteger(v) || (rule.min ! undefined v rule.min))) errs.push(TYPE: k); if (rule.pattern !rule.pattern.test(String(v))) errs.push(FORMAT: k); if (rule.type enum !rule.values.includes(v)) errs.push(ENUM: k); } return errs; }校验失败直接短路返回结构化错误不允许带着脏参数往下走。契约变更走版本号老版本保留一个过渡期两端按版本协商避免服务端升了客户端没跟的窗口期互咬。2.1 契约测试怎么落地契约不是文档是测试。把契约表自动生成一批正负用例缺必选字段、类型错、格式错、枚举越界各来一组断言校验器返回的错误码逐个对得上。契约改了用例没改测试就红——这比任何代码评审都可靠。2.2 契约版本协商的实操约定版本号放进请求头服务端按版本路由校验规则。约定三条同一时间最多存在两个活跃版本新版本上线旧版本至少保留十四天废弃版本的第一天开始打迁移提醒日志按调用方统计谁还没升。这三条让契约演进从赌博变成排期两端团队都能按自己的节奏走。三、入参必须有来源和合法性边界每个入参都要回答三个问题从哪来用户输入、服务端下发、设备采集、能到哪去哪些层可见、不合法时谁兜底。来源标记让排查有据可查可见域限制防止敏感字段被顺手传进日志兜底策略防止缺一个字段就卡死整个流程。字段来源可见域非法兜底orderId服务端下发全部层拒绝进入编排amountMinor服务端计算编排界面拒绝并告警secret用户输入仅能力适配层提示重输deviceFp设备采集治理层降级为匿名风控secret 这类字段永远不进日志、不进状态机、不进任何回调参数只在适配层内存里短暂存在用完即弃。这条红线写进代码评审清单谁碰谁改。3.1 一次字段越权的复盘早期版本为了排查方便把 deviceFp 拼进了确认结果的回调参数里结果日志系统把整个回调对象都打了出来敏感采集字段进了普通业务日志。复盘后的规矩回调参数白名单制新增字段必须先过可见域表日志层加了一道脱敏过滤器命中敏感键名直接打码。越权不是黑客才有的问题工程图省事就是最大的越权来源。3.2 可见域在代码里怎么落地可见域不靠口头约定靠类型收窄编排层拿到的请求对象是 Pick 过的子集敏感字段在类型上就不存在编译器替你把关。适配层内部再建一个独立的小结构体装敏感值出了作用域即销毁日志序列化器对这个类型直接输出掩码。三层防线类型、作用域、序列化任何一层漏了后面两层还能兜住。四、用状态机编排多步流程安全确认至少有探测、就绪、展示、校验、终态五个阶段加上取消、超时、锁定三条中断路径。状态机把现在能发生什么变成显式规则任何时刻只允许一条出口链非法迁移抛错而不是吞掉。const FLOW new Map([ [idle, [probing]], [probing, [ready, unsupported]], [ready, [presenting]], [presenting, [verifying, cancelled, timeout]], [verifying, [succeeded, failed, timeout]], ]); function step(from, event, trace) { const map { probing: probing, confirm: verifying, cancel: cancelled, expire: timeout }; const to map[event]; if (!to || !(FLOW.get(from) || []).includes(to)) { trace.mark(illegal: from event); throw new Error(ILLEGAL from event); } return to; }把超时也当作一次正常迁移处理就不会出现界面在等、会话已死的悬空态。每个迁移都带 trace 打点一次请求从头到尾一条线排查时按 requestId 一查到底。4.1 悬空态的三种成因实测下来悬空态只有三种成因事件重入用户狂点、回调重放、会话失效但界面还活着、超时没有接到状态机上。前两种靠非法迁移防护暴露第三种靠把超时事件化。三样都做齐之后这类的线上工单归零。五、能力适配器隔离平台与业务平台差异版本、机型、服务开通状态只允许出现在适配层。业务层依赖的是四个抽象方法探测、开会话、展示、释放。换机型、升版本、在模拟器跑回归业务层一行不改。export interface SecureConfirmAdapter { probe(): PromiseCapabilityReport; begin(intent: ConfirmIntent): PromiseSession; present(session: Session, payload: Summary): PromiseResult; release(session: Session): Promisevoid; }判断适配层切得好不好有个土办法能不能写一个内存版测试桩替换真适配器把编排层和治理层的单测整体跑通。能说明边界干净不能说明业务层偷摸摸碰了平台细节。5.1 内存测试桩长什么样// 内存桩行为可编排用于编排层与治理层单测 class MemoryAdapter { constructor(script) { this.script script; this.calls []; } async probe() { this.calls.push(probe); return this.script.probe; } async begin(intent) { this.calls.push([begin, intent.orderId]); return { id: s-1 }; } async present(session, payload) { this.calls.push([present, payload.digest]); return this.script.present; } async release(session) { this.calls.push(release); } }桩的关键不是返回值而是 calls 数组单测断言调用顺序、调用次数、传参内容编排层的流程正确性就有了硬校验。桩跑得通的业务层接真适配器只差环境问题。六、分层架构约束副作用六层各管一件事场景层定义验收、契约层管数据、编排层管流程、能力层碰平台、治理层管日志与降级、交付层管产物。副作用网络、存储、弹窗只允许在能力层和治理层出现其余层保持纯函数——同样的输入永远得到同样的输出测试不需要起环境。6.1 一次真实的越层事故编排层有个同事为了快一点直接在流程函数里调了 storage.set 把中间态落盘。单测全绿集成测试时并发两条流程互相覆盖中间态偶现订单错乱。修法是把落盘挪进治理层编排层只发状态已变更事件谁关心谁订阅。副作用越层的代码单测照样绿所以约束不能靠自觉要靠评审清单和分层 lint。七、输出也必须经过契约校验入参有契约回传结果同样要有。平台返回码、摘要哈希、时间戳逐项校验任何一项不过就按失败处理绝不看到成功字样就当成功。function verifyResult(raw, expectedDigest) { if (raw.status ! SUCCEEDED) return FAILED: raw.status; if (raw.digest ! expectedDigest) return MISMATCH; if (Date.now() - raw.finishedAt 300000) return STALE; return OK; }摘要哈希在请求发出前算好存档结果回来比对两边不一致说明中间发生了不该发生的事——展示被替换、参数被篡改、或者拿错了单子。宁可错杀重走流程不放过一次不一致。7.1 结果校验的失败演练校验代码写完要故意喂坏数据改一位摘要、把时间戳拨慢十分钟、把状态换成未知枚举。三种坏数据分别命中 MISMATCH、STALE、FAILED 三条出口一条都不能漏到当成功处理。这组演练进了回归之后校验逻辑再怎么重构都不怕红了就是改坏了。八、重试只处理真正的瞬时失败网络抖动可以重试摘要不匹配不能重试口令错误更不能自动重试。把错误分成三类瞬时网络、超时、确定性参数、格式、安全口令、锁定只给瞬时类发重试名额其余直接走对应出口。重试要带上限、退避和 trace防止把一次失败放大成一场风暴。8.1 重试风暴的教训上线首日出现过一次服务抖动客户端的重试没有退避三秒内把同一个请求打了几百次把本已恢复的服务又压了下去。从此重试统一走一个带指数退避的调度器全局并发上限、单请求上限分开设置并且每次重试都带同一个 requestId服务端能识别并合并重复请求。九、沙箱调测覆盖正负样本调测环境跑两套样本正常请求走通全链路证明能用构造脏参数、过期摘要、非法迁移走失败路径证明坏不了。正负样本都进回归每次契约或流程变更后全量重放。9.1 负样本清单从哪来不是拍脑袋列的三个来源失败路径枚举里每条出口至少一个样本历史工单里每类真实故障一个样本评审会上大家现场想一两个如果这样会怎样。三处合起来覆盖度就够用了。负样本的价值在于它记录的是我们怕什么比正样本更接近系统的真实风险。十、安全与隐私审查前置审查在编码前定规则口令只在适配层内存出现、摘要哈希落日志不落原文、设备指纹最小化采集、权限声明与实际调用一一对应。审查不是上线前补一张表而是评审会上对着代码一条条核对发现偏差当场改。前置的成本是几次评审会议后置的成本是一次安全事件。10.1 审查清单十条口令与等价敏感值是否只在适配层内存出现日志输出是否过敏感键名脱敏过滤器设备标识采集是否声明了用途并最小化权限声明与代码里的实际调用是否一一对应失败路径是否都有出口无静默吞错重试是否只覆盖瞬时错误且带上限回传结果是否逐项过契约校验状态机是否存在可达但未定义的迁移回调参数是否白名单制灰度开关与降级开关是否独立可切。十条对应十类历史事故每一条背后都有一次真实返工。清单会随事故库增长但只做减法不做加法某条连续两年没人命中说明它已内化成习惯可以撤下。十一、交付材料从事实生成交付文档里每一句支持/不支持都要有对应证据用例编号、实测环境、数据来源。手写材料最大的风险是和代码脱节——代码改了文档没跟审核方按旧文档验收到线上问题板子最后打在工程团队身上。从测试报告自动生成验收结论把人从对表里解放出来。// 从回归报告生成验收摘要 function buildAcceptance(report) { return { scenario: report.scenarioId, passed: report.cases.filter(c c.verdict PASS).length, failed: report.cases.filter(c c.verdict ! PASS).map(c c.id), env: report.environment, generatedAt: Date.now(), }; }11.1 材料与代码同源的流水线验收摘要由回归报告自动生成界面截图由自动化脚本在真机上现拍现传接口清单从契约表导出——三样东西都以代码为唯一事实源。审核方提出质疑时回溯链条是结论 → 报告 → 用例 → 提交记录每一环都查得到。手工材料省下的半天往往要用两次返工来还。十二、用失败注入完成验收验收不看功能能跑看失败注入的全矩阵服务不可用、会话超限、摘要篡改、连续输错、中途锁屏每一条都要走到预期出口并留下日志。注入点预期出口必须留痕能力探测失败降级普通确认降级原因码会话创建超时重试1次后降级重试trace摘要比对失败终止告警证据快照连续3次校验失败锁定阻断计数记录中途锁屏再回会话失效重走失效事件十二项全部通过才允许进入灰度。灰度期双写日志两周随时可以回放每一次确认决策灰度转全量后降级矩阵和失败注入用例进入常态回归防止后续迭代把已经堵住的口子又撕开。这套六层框架的成本集中在契约和状态机两处换来的是后面每一层都可以独立替换、独立测试。接入第二个、第三个能力时只有场景层和适配层是新的其余全部复用——工程封装的意义不在第一次接入有多快而在第二次、第三次接入时还敢不敢说这次和上次一样稳。
