灯光模拟HarmonyOS应用实战-88-科二有9颗种子，变体却每8题换一次：用VariantAxisPlan拆掉硬编码步长

灯光模拟HarmonyOS应用实战-88-科二有9颗种子变体却每8题换一次用VariantAxisPlan拆掉硬编码步长题库生成器最难发现的问题往往不是循环越界而是两个看似无关的下标被同一个常量绑在一起。The_kemusan当前有 9 颗科二生成种子、8 颗科四生成种子却统一按“每 8 个索引切换一次地点与条件”。这个写法对科四看起来顺滑一轮场景刚好走完 8 颗种子到了科二同一场景只走 8 颗第 9 颗会落到下一轮后续配对持续平移。本文只处理生成游标与维度步长的契约不判断哪一条驾驶规则是否应该覆盖某个地点也不把题量当作业务覆盖率。第 59 篇已经讨论RuleId、批准组合和覆盖账本这里关注更靠前的一层给定同一份种子和维度计划生成器能否用可解释、可复现、与种子数量无关的坐标推进。一、源码事实8 同时扮演了数据长度和变体步长当前QuestionBank.ets:408-490定义了 9 个SUBJECT_TWO_SEEDSQuestionBank.ets:492-565定义了 8 个SUBJECT_FOUR_SEEDS。两个数组最终都进入appendGeneratedSubjectQuestions()但buildVariantText()不接收种子数量而是直接用字面量8计算轮次functionbuildVariantText(index:number):string{constroundMath.floor(index/8);constplaceVARIANT_PLACES[round%VARIANT_PLACES.length];constconditionVARIANT_CONDITIONS[Math.floor(round/VARIANT_PLACES.length)%VARIANT_CONDITIONS.length];return${place}、${condition};}functionappendGeneratedSubjectQuestions(target:QuestionItem[],subject:string,prefix:string,seeds:GeneratedQuestionSeed[],count:number):void{for(letindex0;indexcount;index){constseedseeds[index%seeds.length];// buildGeneratedTitle() 内部再次用同一个 index 计算变体}}还可以确认地点数组在QuestionBank.ets:304-308有 20 项条件数组在QuestionBank.ets:310-313有 10 项科二、科四各请求生成 1000 题调用点位于QuestionBank.ets:703-704。这些是静态源码事实。当前源码没有VariantAxisPlan、没有计划版本也没有输出游标回执。不能由此直接写成“现有 1000 题一定缺失某条规则”。题目是否业务有效需要规则目录和产品审核本文能明确指出的是8没有名称、没有来源并且它只与当前科四种子长度偶然相等。二、9 颗种子经过 8 步窗口时会发生什么把生成索引记为i。当前种子坐标是i mod seedCount场景轮次是floor(i / 8)。科四的seedCount为 8所以每一个轮次都会看到种子0...7。科二的seedCount为 9同一轮只有连续 8 个索引漏掉哪颗种子会随轮次移动。轮次索引范围科二种子下标当轮未出现的种子0070,1,2,3,4,5,6,7818158,0,1,2,3,4,5,67216237,8,0,1,2,3,4,56324316,7,8,0,1,2,3,45这个现象不等于数组访问错误所有下标仍在合法范围内。真正的问题是“同一地点与条件应该陪伴多少颗种子”没有成为显式决策。维护者新增、删除或排序种子时场景配对会静默改变代码审查只看到数据数组变化难以意识到字面量8仍在控制另一段逻辑。可用一个只读探针把耦合打印成坐标先观察再改造interfaceLegacyCoordinate{index:number;seedIndex:number;round:number;}functioninspectLegacyCoordinates(seedCount:number,sampleCount:number):LegacyCoordinate[]{constresult:LegacyCoordinate[][];for(letindex0;indexsampleCount;index){result.push({index,seedIndex:index%seedCount,round:Math.floor(index/8)});}returnresult;}这里的探针是建议代码尚未加入项目。它的价值是把“感觉不对”转成一张可审查的坐标表不承担题目业务正确性的判断。三、这不是第59篇覆盖账本的重复问题第 59 篇解决的是“应该覆盖哪些规则与场景”种子要有RuleId业务先批准适用维度最终结果再生成覆盖账本。本文解决的是“计划如何被稳定枚举”同一计划中种子轴、地点轴和条件轴怎样前进哪个字段决定完整周期。两者可以按层次拆开层次回答的问题本文是否处理规则目录哪条灯光规则存在否适用矩阵某规则能否搭配某地点、条件否轴计划种子、地点、条件以什么顺序前进是题面构造坐标如何变成标题与选项只保留适配边界覆盖报告最终是否满足批准集合否交给覆盖账本因此不能用本文的笛卡尔式枚举替代业务适用性审核。若某颗图标认知种子不应拼接任意道路地点应该由上游计划过滤掉对应坐标游标只负责忠实、确定地走完已经批准的坐标。四、先把隐含规则写成 VariantAxisPlan最小改造不是把8替换成seeds.length后结束而是定义一份可序列化、可核对的计划。计划至少要声明种子数量、地点键、条件键、计划版本和请求数量。展示文本与稳定键分开避免润色中文时被误判为一套新计划。interfaceAxisValue{key:string;label:string;}interfaceVariantAxisPlan{planId:string;seedCount:number;places:AxisValue[];conditions:AxisValue[];requestedCount:number;}interfaceVariantCoordinate{absoluteIndex:number;seedIndex:number;placeIndex:number;conditionIndex:number;cycleIndex:number;}seedCount由调用方从实际seeds.length写入不能另抄一个常量。places与conditions不能为空requestedCount可以小于、等于或大于完整周期但必须在生成前被校验。planId是计划身份不是题目 ID也不应由数组对象地址或当前时间临时推导。计划对象让代码评审看到真实意图科二用 9科四用 8两个科目可以共用同一套地点和条件却不再共用一个未经说明的步长。五、用混合进位坐标让三个轴独立推进若产品决定“同一地点与条件下先遍历全部种子再进入下一个地点”可以使用混合进位坐标。第一轴长度来自seedCount第二轴来自地点数第三轴来自条件数任何一个数组扩缩都能自动改变周期。functionresolveCoordinate(index:number,plan:VariantAxisPlan):VariantCoordinate{constvariantsPerConditionplan.seedCount*plan.places.length;constcycleLengthvariantsPerCondition*plan.conditions.length;constpositionindex%cycleLength;constvariantIndexMath.floor(position/plan.seedCount);return{absoluteIndex:index,seedIndex:position%plan.seedCount,placeIndex:variantIndex%plan.places.length,conditionIndex:Math.floor(position/variantsPerCondition),cycleIndex:Math.floor(index/cycleLength)};}对科二而言一个地点与条件会连续分配 9 个坐标对科四而言则是 8 个。这里没有“所有种子都适用于所有场景”的断言。传入函数的plan应先由规则计划层过滤如果计划采用稀疏单元格而不是完整三轴组合也可以让VariantAxisPlan直接携带批准坐标列表再按列表下标前进。混合进位的好处是每个除数都有来源维护者能从类型和值推导周期。若未来加第四个维度也应显式增加轴而不是再叠一层难以命名的除法。六、生成器只消费坐标回执负责解释过程题面构造函数不应再自行重算round。生成入口先解析坐标再从计划和种子目录取值最后将坐标写入伴随回执。这样失败时可以区分“计划无效”“坐标越界”“题面被去重”与“实际生成数量不足”。interfaceGeneratedCoordinateReceipt{planId:string;requestedCount:number;emittedCount:number;cycleLength:number;firstCoordinate?:VariantCoordinate;lastCoordinate?:VariantCoordinate;}functionbuildPlannedQuestion(index:number,prefix:string,subject:string,seeds:GeneratedQuestionSeed[],plan:VariantAxisPlan):QuestionItem{constcoordinateresolveCoordinate(index,plan);constseedseeds[coordinate.seedIndex];constplaceplan.places[coordinate.placeIndex].label;constconditionplan.conditions[coordinate.conditionIndex].label;constoptionResultbuildGeneratedOptions(seed);return{id:${prefix}_${index1},subject,type:TYPE_CHOICE,title:${seed.scenario}场景为${place}、${condition}应如何处理,options:optionResult.options,answer:optionResult.answer,explanation:seed.explanation,category:seed.category};}buildGeneratedOptions()是现有函数建议方案只调整坐标来源。回执不应存储完整题干保存稳定计划键和计数即可减少日志体积。若appendUniqueQuestion()丢弃了同标题题目回执要同时记录尝试数和发出数但具体业务覆盖仍由第 59 篇的覆盖账本判断。七、改算法时必须处理旧题 ID 的语义漂移当前生成 ID 使用${prefix}_${index 1}。如果只改变索引到场景的映射s2_auto_9这个 ID 仍存在但它对应的地点和条件可能已经改变。历史错题、收藏或外部报告若只保存 ID会把旧语义解释成新题面。可以选择两种迁移策略新算法使用新前缀例如s2_v2_旧 ID 继续由旧目录解释ID 基于稳定规则键和批准坐标构造并给计划单独加版本。不要把生成时间拼入 ID那会让同一计划每次启动得到不同身份。也不要在没有旧数据调查时直接覆盖旧 ID。本文没有读取设备上的历史分布无法判断现有用户是否已经保存生成题 ID所以这里只给迁移约束不声称某种策略已可直接发布。项目旧生成器新生成器科二种子步长固定 8来自计划的 9科四种子步长固定 8来自计划的 8地点数当前 20计划显式声明条件数当前 10计划显式声明题目 ID仅前缀加序号保留旧版或启用新版本过程说明无计划、周期、首尾坐标八、测试要同时固定顺序、周期和变更响应只断言“生成了 1000 条”无法约束坐标。建议用小计划做纯函数用例2 颗种子、2 个地点、2 个条件完整周期应为 8再分别用 9 颗和 8 颗种子确认一个变体单元会走完对应数量。functionassertCoordinate(actual:VariantCoordinate,seed:number,place:number,condition:number):void{if(actual.seedIndex!seed||actual.placeIndex!place||actual.conditionIndex!condition){thrownewError(unexpected coordinate);}}constplan:VariantAxisPlan{planId:subject2-plan-v2,seedCount:9,places:[{key:city,label:城市主干道},{key:rural,label:乡村道路}],conditions:[{key:normal,label:视线正常}],requestedCount:18};assertCoordinate(resolveCoordinate(0,plan),0,0,0);assertCoordinate(resolveCoordinate(8,plan),8,0,0);assertCoordinate(resolveCoordinate(9,plan),0,1,0);assertCoordinate(resolveCoordinate(17,plan),8,1,0);还要补一条变化响应把seedCount从 9 改为 10 后第 9 个索引仍在第一个地点只有第 10 个索引才进入第二地点。这个用例专门防止字面量8回流。另需验证空种子、空地点、空条件、负请求数和超大请求数的拒绝路径不能等到% 0产生不可解释坐标。九、排障时先看坐标不要先改题目文案症状优先查看常见根因修复方向科二同一地点少一颗种子前 18 个坐标仍按 8 分轮步长取自计划的seedCount新增种子后大量题面换场景计划版本与坐标快照ID 未版本化保留旧计划或启用新前缀科四正常、科二异常两科种子数常量偶然等于科四长度分科构造计划周期末多出重复坐标cycleLength与请求数取模位置计算错误统一在resolveCoordinate()计算生成数量小于请求数去重前后计数标题去重丢弃题目回执区分 attempted 与 emitted修改中文标签后计划身份变化planId来源用展示文本拼计划键稳定键和标签分离坐标正确但题意不合适批准单元格上游未做适用性过滤回到规则计划不在游标层猜测排障日志不需要打印完整 1000 道题。记录计划 ID、索引、三个轴下标和问题码已经足以复现游标行为。完整题干可能很长只有在受控调试环境中才应按需抽样。十、验证清单、总结与未验证边界合入前可以逐项核对科二计划的seedCount来自实际 9 颗种子科四来自实际 8 颗种子。生成路径中不再出现没有名称的Math.floor(index / 8)。空种子、空地点、空条件在生成前返回明确问题码。坐标函数为纯函数相同计划与索引始终返回相同结果。一个地点与条件单元按计划遍历完整种子轴。请求数超过完整周期时cycleIndex可解释重复轮次。题目 ID 迁移策略经过历史引用调查不静默复用变义 ID。回执区分请求数、尝试数、发出数和去重数。业务适用性仍由RuleId与批准计划判断。页面随机抽题只消费最终题库不重新解释生成坐标。当前源码足以确认 9、8、20、10 四个数组规模确认变体轮次写死为 8确认两个科目都调用同一生成入口并各请求 1000 条。由这些事实可以推出维护风险和配对平移但不能推出某条交通规则已经遗漏也不能证明用户当前一定看到了错误题面。VariantAxisPlan、混合进位坐标、生成回执和 ID 迁移表都是建议实现尚未写入The_kemusan。本次只核对源码并撰写文章没有修改 ArkTS 工程没有运行hvigorw assembleHap --no-daemon没有生成新的 HAP也没有在模拟器或真机上执行题库、搜索、作答与历史回放。正式实施后仍需经过目标 SDK 编译、纯函数用例、题库业务审核和设备端抽样四层证据不能互相替代。