计算两个非负整数字符串的乘积，不能直接用大整数类型

什么是 CAP 定理？在分布式系统中，面对网络分区（Network Partition）时，我们应该优先保证一致性（Consistency）还是可用性（Availability）？请结合实际业务场景举例说明。

GPU 显存约束调度：算法与实现代码仓库：github代码入口：src/Solution.cpp前言看到有人想要题解，心血来潮写了一下。这份算法分数大约能到385分，因为之后我的提分基本就是堆叠了，甚至可能有过拟合可能，所以定了这一版。第38期前几周基本霸榜，最后一周被几个大佬轮着炒，而且因为刚好在保研夏令营，没什么时间搞，真给大佬们跪了。因为太多了，让AI整理出来的可能没那么准确，欢迎大家提意见。1. 问题模型共有 N 个推理请求和 K 张 GPU。请求 i 包含：到达时刻 A[i]；输入长度 Lin[i]；输出长度 Lout[i]。调度器需要给出开始时刻 S[i] 和 GPU 编号 k[i]。题面要求：S[i] > A[i]请求在 [S[i], S[i] + Lout[i] - 1] 内活跃。活跃时刻 t 的显存占用为：mi(t)=Lini+(t−Si+1)m_i(t)=Lin_i+(t-S_i+1) mi​(t)=Lini​+(t−Si​+1)每张 GPU 还要同时满足两条约束：活跃请求数不超过并发上限 B；活跃请求的显存之和不超过该卡容量 M[k]。目标函数由总等待、最大完成时刻和最大等待组成：V=∑i(Si−Ai)+max⁡i(Si+Louti)+max⁡i(Si−Ai)V=\sum_i(S_i-A_i)+\max_i(S_i+Lout_i)+\max_i(S_i-A_i) V=i∑​(Si​−Ai​)+imax​(Si​+Louti​)+imax​(Si​−Ai​)常规离线搜索中的网格、regret 和局部搜索都按 sumD = Σ(S[i] - A[i]) 选优。完整 V 会在求解器返回时计算；源码只在小规模精确解与启发式解比较、最终残余解与继续贪心比较时，用它直接决定取舍。图示说明：文中曲线、网格和区域图由题面公式与源码中的固定候选、阈值生成，仅用于解释算法结构，不代表运行性能。2. 显存检查只看关键点这是实现里最重要的化简。对于已经放在某张 GPU 上的请求 j，记：C[j] = S[j] + Lout[j] - 1 v[j] = Lin[j] - S[j] + 1那么请求 j 在活跃时刻 t 的显存可以写成：mj(t)=vj+tm_j(t)=v_j+t mj​(t)=vj​+t在一段没有请求完成的时间里，活跃集合不变。若当前活跃请求数为 cnt，所有已有请求的显存之和为：Mem(t)=∑jvj+t⋅cntMem(t)=\sum_j v_j+t\cdot cnt Mem(t)=j∑​vj​+t⋅cnt它随 t 单调增加。把新请求 i 放到 [s,e] 后，新请求本身也以斜率 1 增长。因此，两次完成事件之间的总显存峰值只会出现在区间右端。完整逐时刻扫描可以缩成三类检查：放置时刻 s 的并发数；落在 [s,e) 内的已有请求完成时刻；新请求自己的结束时刻 e = s + Lout[i] - 1。图 1　固定开始时刻后，显存只会在相邻完成事件之间上升。s 负责并发边界检查，已有请求完成点和新请求结束点覆盖显存峰值。伪代码如下：canPlace(i, k, s): e = s + Lout[i] - 1 if Lin[i] + Lout[i] > M[k]: return false if activeCount(k, s) + 1 > B: return false for C in completionTimes(k), where s <= C < e: if Mem(k, C) + Lin[i] + C - s + 1 > M[k]: return false if Mem(k, e) + Lin[i] + Lout[i] > M[k]: return false return true每张 GPU 保存两组按完成时刻排列的数组：end[]：完成时刻；v[]：上式中的常数项。head 指向第一个仍活跃的请求，sumV 和 count 维护活动窗口的聚合值。时间前进时只移动 head，不反复擦除数组头部。图 2　逐时刻扫描的检查次数随 Lout 增长；源码逐项检查活动请求的完成时刻，再检查新请求结束点，最坏次数由并发上限 B 约束。对应源码：Sched：src/Solution.cpp:21-170快速模拟器中的完整检查：src/Solution.cpp:257-6243. 事件驱动构造有了快速可行性检查，下一步是把一个优先级顺序变成完整调度。构造器只在两类事件上工作：新请求到达；某个请求完成。主循环如下：while 仍有请求未调度: t = min(下一次到达, 下一次完成) 把新到达请求加入 pending 从每张 GPU 的活动窗口移除已完成请求 按优先级整理 pending for i in pending: s = t + 1 k = 在 s 时刻最合适的可行 GPU if k 存在: 放置请求 i else: 保留到后续事件再试默认策略是在所有可行卡中选择新请求活跃区间内已有显存峰值较低的一张。这样不容易把某张卡过早堆出高峰，也给其他请求留下更多装箱空间。3.1 earlyStoppending 已经按优先级排序。如果连续多个高优先级请求都放不下，继续扫描很深往往只会让低优先级请求占掉零碎空间。earlyStop 记录连续失败次数，达到阈值后结束本轮扫描，等待下一次完成事件释放资源。它只影响本轮继续扫描多深，不会绕过合法性检查：真正放置的请求仍走完整显存和并发检查；没有尝试的请求只是延后，不会被强行放置。图 3　构造器在到达或完成事件上重整 pending，本轮放不下的请求会留到后续事件继续尝试。对应源码：src/Solution.cpp:257-624。4. 优先级量化网格单一排序很难覆盖全部输入。短请求适合尽快释放并发名额，大输入请求又会长期抬高显存基线。实现先用请求生命周期的显存—时间面积建立主优先级：Areai=Lini⋅Louti+Louti(Louti+1)2Area_i=Lin_i\cdot Lout_i+\frac{Lout_i(Lout_i+1)}{2} Areai​=Lini​⋅Louti​+2Louti​(Louti​+1)​排序键省去一次项，只保留乘积项和平方项：Pi=a⋅Lini⋅Louti+b⋅Louti2P_i=a\cdot Lin_i\cdot Lout_i+b\cdot Lout_i^2 Pi​=a⋅Lini​⋅Louti​+b⋅Louti2​代码使用少量离散权重，而不是连续调参。下表把源码中的两个系数同时除以 125，只保留等价整数比；共同缩放不会改变排序结果。组(a, b) 整数权重a = 8(8,0), (8,2), (8,4), (8,5), (8,6), (8,7), (8,8), (8,10), (8,12), (8,16), (8,24)a = 4(4,4), (4,8), (4,16), (4,32)a = 2(2,2), (2,8), (2,24), (2,48)边界(0,8), (16,4)图 4　图中权重已约去源码系数的共同因子 125，点的位置完整对应固定的离散候选表。图 5　不同权重会改变优先级对 Lin 与 Lout 的敏感方向，少量代表性组合覆盖几种主要取舍。每个面板分别归一化，只比较形状，不比较绝对数值。主网格把每组权重与若干 earlyStop 组合，GPU 方式固定为 0。网格结束后，只拿当时最好的优先级和 earlyStop 再尝试 GPU 方式 1、2。搜索先估计一次完整构造的耗时，再根据剩余墙钟决定跑完整网格、缩减网格还是最小网格。无论预算多少，都会保留已经找到的最好可行解。图 6　每次构造的耗时估计决定墙钟内可承担的网格规模；初始批和最终残余分别搭配 8 组与 6 组 earlyStop。曲线直接按源码阈值计算。代码还补充了线性键，用来表达接近 SPT、同时给输入长度加权的顺序。候选公式和执行顺序固定写在源码中；实际运行到哪个子集，只由算法阶段和剩余墙钟决定，不根据输入统计做分类切换。对应源码：src/Solution.cpp:634-731。5. regret 与局部搜索优先级网格给出几个稳定起点，剩余时间用来调整请求顺序。图 7　常规离线候选统一按 sumD 选优；只有小规模分支定界和最终残余保底比较直接使用完整 V。5.1 regret bootstrap先运行当前最好顺序，得到每个请求的实际等待：D[i] = S[i] - A[i]等待越久的请求，下一轮越向前提升：Pi←Pi−η⋅Dimax⁡jDj⋅scaleP_i\leftarrow P_i-\eta\cdot\frac{D_i}{\max_j D_j}\cdot scale Pi​←Pi​−η⋅maxj​Dj​Di​​⋅scale图 8　等待占当前最大等待的比例越高，优先级下降越多；构造器按升序取请求，因此它会在下一轮被适当前移。每一轮都会重新构造完整方案。只有代理目标更好时才更新全局最优，但本轮更新后的优先级仍可作为下一轮起点。它把搜索从单纯的面积排序推向更照顾长等待请求的顺序。5.2 严格改进局部搜索局部搜索混合四类邻域：交换相邻或相近位置的两个请求；把一个请求向前插入；把当前等待较久的请求前移；把前部占用面积较大的请求适当后移。接受规则保持简单：候选的 sumD 必须严格下降。网格、regret 和局部搜索都不使用完整 V 选优，因此这里的“严格改进”只针对代理目标，不代表目标函数的三项都逐步单调。5.3 后缀检查点一次交换通常只影响调度顺序的后半段。全量首帧路径会周期性保存检查点，包括：当前事件位置；每张 GPU 的活动窗口；pending 队列；已累计的 sumD；已启动请求数。候选变化后，从变化位置之前最近的检查点恢复，只重放受影响的后缀。candidate order changes near position p checkpoint = latest saved state before p restore(checkpoint) replay only the affected suffix accept iff candidate sumD < incumbent sumD对应源码：regret：src/Solution.cpp:728-747局部搜索：src/Solution.cpp:754-947检查点恢复与保存：src/Solution.cpp:422-469、497-5066. 无损 int16 量化预筛一次完整构造会反复判断某个请求是否能放到任一 GPU。逐个调用完整检查仍然偏贵，所以代码先计算一个便宜的必要条件，批量排除已经能证明不可行的请求。图 9　只有所有非满 GPU 均被必要条件排除时才令 mask=0 并跳过；mask=1 仍需 64 位整数精确检查。设尝试开始时刻为 s，某张 GPU 上最早完成的活动请求在 C0 结束：cm = C0 - s + 1若 Lout[i] > cm，新请求会跨过 C0。在 C0 必须满足：Lini≤Mk−sumVk−C0⋅cntk−cmLin_i\le M_k-sumV_k-C_0\cdot cnt_k-cm Lini​≤Mk​−sumVk​−C0​⋅cntk​−cm记右侧为 threshold[k]。再结合单个请求自身峰值约束：Lin[i] + Lout[i] <= M[k]可得到便宜的掩码判断：candidate_on_gpu = (Lin + Lout <= capacity) and ((Lin <= threshold) or (Lout <= cm)) candidate[i] = OR over all non-full GPUs图 10　蓝色区域只是单张非满 GPU 的必要条件所保留的候选集合，灰色区域才表示可在该卡排除；多张 GPU 的结果按位取 OR。掩码为 0：所有 GPU 都已被必要条件排除，可以跳过完整检查；掩码为 1：只表示“尚未证明不可行”，仍必须调用完整检查。这条预筛只产生假阳性，不产生假阴性。6.1 为什么可以用 int16题面范围给出：Lin <= 2048 Lout <= 2048 Lin + Lout <= 4096它们都能精确存入有符号 16 位整数。容量和阈值写入 int16 前向“保留候选”的方向夹紧：夹紧只会多保留请求，不会把可行请求误删。掩码为 1 后，最终放置仍使用 64 位整数做精确检查。pending 的 Lin、Lout 使用 SoA 连续数组保存，候选掩码按块惰性计算。x86 且支持 AVX2 时走向量内核，否则使用同逻辑的标量版本。两条路径只影响吞吐，不改变调度规则。对应源码：标量与 int16 内核：src/Solution.cpp:190-255SoA、阈值夹紧与分块掩码：src/Solution.cpp:348-420、508-6207. 全量到达与流式到达交互题最容易出错的地方，是把离线算法直接套到尚未到达的请求上。实现明确分成两条路径：全量首帧使用 solv::Sim，流式在线使用独立的 Sched；两者遵循同一套关键点可行性原理，最终残余求解再回到 solv::Sim。图 11　全量首帧直接进入离线搜索；流式路径先由 Sched 提交可见请求，全部请求到齐后才建立残余问题，运行中请求作为固定 seed，只优化尚未启动的尾部。7.1 全量首帧若第一帧已经给出全部请求，直接构造离线实例并运行 solveOffline，最后一次输出全部 (S,id,k)。搜索分为网格、bootstrap 和局部搜索三个阶段。每个阶段都保留当前最好可行解，预算不足时可以提前收尾。K = 1 且 N <= 16 时另跑 350ms 的分支定界：搜索树完整跑完时可以证明最优；若墙钟先到，则返回以启发式解为初值的最好可行解。对应源码：离线求解器：src/Solution.cpp:634-952小规模精确分支：src/Solution.cpp:954-1123全量首帧入口：src/Solution.cpp:1203-12407.2 流式在线与最终残余流式阶段由轻量 Sched 维护环形时间表、完成事件和 pending，只使用已经到达的请求做在线决策。全部请求到齐后，代码收集尚未启动的请求，并把已经提交且仍在运行的请求转换为每张 GPU 的 seedE/seedV。残余问题的到达时刻统一设为当前时刻 t，因此离线构造器给出的开始时刻自然满足 S > t。残余解不会直接覆盖原计划。实现还会模拟一份“继续原贪心”的保底方案，用完整实例的 V 比较，只有严格更优的残余安排才会采用。对应源码：在线调度器：src/Solution.cpp:21-170残余建模、求解和比较：src/Solution.cpp:1268-13628. 正确性边界实现依靠以下不变量维持合法性：活跃请求按完成时刻有序，head 之前的请求全部过期；sumV 等于活动窗口中所有 v 的和，count 等于活跃请求数；任何真正放置都经过完整并发与显存检查；候选掩码为 0 才允许跳过，掩码为 1 必须精确复核；当前最优解建立后，bestS/bestK 对应一份已经完整构造的可行方案；在线输出只包含已经到达的请求，开始时刻严格晚于当前时刻。不同机器的运行速度会影响墙钟内能尝试多少候选，因此得到的目标值不一定完全一致；合法性不依赖搜索是否收敛。9. 复杂度操作上界实际减负手段单 GPU 可行性O(B)完成点扫描，head 单向移动选择 GPUO(KB)int16 掩码先跳过明显不可行请求一次完整构造宽松上界 O(N²KB)事件驱动、earlyStop、SoA 分块局搜候选一次构造或一个后缀检查点恢复，受硬墙钟截止离线空间O(K(N+B)+N)每张 GPU 保存活动 end/v 数组理论最坏复杂度仍然较高。实际能在固定时间内运行多个候选，依靠的是预筛、活动头指针、事件化推进和后缀恢复共同降低常数与平均扫描深度。10. 编译与运行推荐 Linux 和支持 C++17 的 GCC：g++ -std=c++17 -O2 -pipe src/Solution.cpp -o solution程序使用 bits/stdc++.h、unistd.h 和 GCC 函数属性。x86 平台会在运行时检查 AVX2；不支持时使用标量内核。这是交互式程序。每个时间步读取 t、到达请求数及请求信息，随后输出本轮决策数量和若干行 (S,id,k)，并立即刷新输出。直接把完整数据一次重定向到标准输入，不一定等价于正式交互环境。独立校验器至少应检查：每个请求只调度一次，且 S[i] > A[i]、1 <= k[i] <= K；按开始和结束事件重放每张 GPU，任意时刻并发数不超过 B；重放显存曲线，任意时刻总显存不超过 M[k]；独立计算 sumD、maxC、maxD 和完整 V；覆盖全量首帧、稀疏到达、K = 1、小容量、高并发上限和最大 N。11. 已知局限构造器只在到达或完成事件后启动请求，没有枚举事件之间更细的可行时刻；常规候选搜索只按 sumD 选优，没有把 maxC 和 maxD 直接纳入比较；候选数量由剩余墙钟决定，不同机器上的实际搜索深度可能不同；单文件程序便于编译复现，但不等同于生产级调度库接口。如果继续改进，优先考虑更精细的最早可行时刻搜索，以及完整 V 的增量维护。核心框架不需要改变：精确关键点检查、快速完整构造、用保底解约束搜索风险。

请问部署失败怎么看原因？

能不能在原基础上增加五次，有些数据也需要测量，每天10次提交机会有点跟不上进度了

38期用例时限说明一下？

请问每月新一期赛题何时发布？

请问或将证书何时发放？

看前面帖子说运行时间总共为 100s，包含编译时间，那么请问一下交互器的运行时间是否被计算在内。如果包含在内能不能提供一下正常评测中交互器运行的时长。

这俩减号是不是应该是加号？这么久了好像没人提出来。

请问35期结果什么时候出啊，36期都公布了

我是一名平凡的草根，白天在一家汽车工厂为生活奔波，夜晚则因热爱而潜心学习。只有1台普通的笔记本，也从未接受过系统或专业的训练，全凭一腔热情，独自搭建起了一个向量检索的原型。今天，鼓起勇气将测评数据贴在这里，希望能遇到专业老师带带自己。 一、背景与挑战在向量检索领域，传统方案常面临“精度-成本”两难：近似最近邻（ANN）算法为追求速度会损失召回率（通常85-99%），且内存占用高（数GB），依赖GPU或集群，难以在边缘设备部署。本文介绍一套纯本地、高精度、低资源的混合检索架构，在普通笔记本上实现了100%无损召回、百万级QPS、亚毫秒标量过滤，并在公开长文本记忆基准上取得99.20%召回率二、核心技术创新2.1 两阶段渐进检索：实现无损召回第一阶段：使用轻量级量化编码对向量进行压缩存储，快速筛选出候选集，候选规模仅扩大至最终结果数的2倍。第二阶段：从共享内存中读取原始高精度向量，对候选集进行精确距离计算。以极小延迟增量（3-5%）换取100%召回，打破了ANN固有的精度损失。2.2 共享内存多线程并行检索采用预创建的线程池，并通过共享内存零拷贝技术让所有线程直接访问同一份索引数据。在8核笔记本上实现40倍以上加速，P99延迟从近200ms降至5ms以内。2.3 紧凑型标量过滤引擎针对等值、集合、范围、数组包含及逻辑组合等查询条件，使用位图索引结构。1M文档等值查询P99延迟低于0.01ms，QPS达数十万，每文档内存仅1.5KB。2.4 轻量级特征权重学习模块自研极简网络结构（8输入→4隐层→1输出），算子硬编码，无框架依赖。在CPU单线程上预测吞吐超过百万QPS，单次预测延迟低于1微秒。三、性能测试结果3.1 向量检索（40万向量，100维）  指标实测值召回率 (Recall@10)100%P99 延迟13.4 ms内存占用（量化存储）38 MB加速比（多线程 vs 朴素并行）45倍3.2 标量过滤（100万文档）  查询类型P99延迟QPS等值匹配0.006 ms224,215集合包含（5值）0.164 ms26,323数组包含0.217 ms78,023多条件与（3条件）0.429 ms4,744所有查询召回率、精度均为100%。3.3 长文本记忆基准（LongMemEval）  指标成绩Recall@599.20% (496/500正确)知识更新类100%时间推理类99.25%多会话类98.50%该成绩为公开纯检索系统中的最高分，超越多个已知方案。3.4 特征权重学习模块  指标实测值预测吞吐1,199,041 QPS预测 P50 延迟0.0005 ms内存增量（1000次更新）1.52 MB四、与主流方案对比  能力本方案主流方案（云原生/集群）向量检索召回率100%85-99%向量内存（40万）38 MB>2 GB标量过滤 P99<0.3 ms10-100 ms标量过滤 QPS224k数百长文本记忆纯检索99.20%81.6-93.4%边缘部署嵌入式CPU需集群/云混合检索能力向量+图+关键词多路融合向量+标量过滤五、适用场景边缘AI / 端侧大模型：本地推理+本地检索，数据不出设备。企业私有知识库：100%召回，满足金融、医疗等“零容忍”场景。RAG系统：毫秒级检索+高召回，提升生成质量。嵌入式数据库：替代传统搜索引擎+向量插件组合，显著降低硬件成本。六、总结本文展示了一套完全运行在普通笔记本电脑上的高性能混合检索引擎。通过两阶段渐进检索、共享内存并行、紧凑索引等技术创新，在不依赖GPU和集群的前提下，实现了100%无损召回、亚毫秒标量过滤、世界领先的长文本记忆检索。该方案为边缘计算、私有化部署、高精度检索等场景提供了可落地的技术路径，证明高性能与低成本可以兼得。

已经过去这么久了，怎么没动静了

尊敬的华为软件精英挑战赛组委会、上合赛区评审专家：您好！我们是同济大学“恭喜以下队伍打铁”队。在2026年华为软件精英挑战赛上合赛区初赛中，我们取得了86万分的成绩。近日收到组委会关于我们代码查重异常的通知，团队对此高度重视并第一时间进行了全面复盘与自查。我们完全理解并坚决拥护组委会对学术诚信和比赛公平性的严格把控，但我们郑重声明：本团队绝对没有任何违规抄袭行为。 在此，我们诚恳地向组委会提出申诉，希望评审专家能结合我们的真实开发过程和核心策略，对我们的代码进行人工复核，以恢复我们的成绩及晋级资格。对于查重系统出现的异常，我们分析主要由以下两个客观原因叠加导致：一、 赛题底层算法的强收敛性与AI辅助开发的固有特性本道赛题属于二维不规则多边形排样的经典问题。在基础算法层面，业内公认的最优解即为闵可夫斯基和（NFP卷积）。在追求高分的前提下，底层算法选型具有高度的一致性。同时，在比赛规则允许的范围内，我们使用了大模型（ChatGPT 5.4、Claude Code）作为底层标准算法的辅助编写工具。虽然我们在提示词中严格限制了“禁止引入Clipper、Boost、CGAL等开源库或其他公开代码”，但由于大模型本身是通过学习海量公开学术论文与技术博客训练而成，其生成的标准NFP卷积、凸分解等底层算法实现，天然会与部分开源思路或标准范式产生结构性相似。这种底层算法的相似性是大模型辅助开发的正常现象，是对公开学术成果的合理参考，而非直接复制他人代码。二、 我们的核心高分壁垒：完全原创的多路线分支策略与参数调优我们能取得这样的分数，并非依赖某段标准底层算法的实现，而是基于我们完全原创的四层动态分支求解策略以及上百次的本地参数调优。这是其他队伍无法复制的核心工程量，主要体现在以下几个方面：独创的多路线分支系统： 我们摒弃了单一路线，设计了四条求解路径：路线A：精简NFP卷积（AI辅助实现）路线B：凸分解+队列式合并（AI辅助实现）路线C：最小凸包覆盖 Fallback（团队完全手写实现）路线D：完全NFP卷积（实验后已弃用）精细的动态切换逻辑： 我们通过多边形顶点数(n, m)和凹点(reflex)比例进行动态路由。例如：当 n+m <= t1 时，进入凸分解路线；否则扫描reflex点数量。若双方均为凸多边形，或 reflex比例 > w1 且 n+m >= t2，亦或 n+m >= t3，程序会直接进入我们手写的 Fallback 路线，通过牺牲极小的精度来换取极大的时间效益。大量的工程优化与实验： * 查询与I/O优化： 使用了基于 y-bucket 和矩阵哈希优化的 BVH 查表输出，并手写了基于 getchar_unlocked/fread 与 _write 的 I/O 加速。参数炼丹： 为了确定很多组黄金参数，我们进行了超过200组本地对比实验。正是这套独一无二的工程化架构和参数组合，让我们在排行榜上脱颖而出。如果是恶意抄袭，绝无可能在没有经过大量试错的情况下拼凑出这样一套严密的动态分支系统。三、 详实的开发过程证据为了证明团队工作的原创性，我们已将整个赛程的开发记录整理成附件，随时接受组委会的严格审查：提交记录： 完整展示了从基础框架搭建、多分支逻辑合并、底层优化到最终调参的演进过程。200+组本地实验记录： 包含完整的测试数据、参数调整对比及分数变化日志。团队协作证明： 包括部分每日技术讨论记录、代码评审截图。我们三名队员在过去的三周里倾注了所有的课余时间，熬过了无数个日夜才换来今天的成绩。我们非常珍惜华为软件精英挑战赛这个极具含金量的平台。恳请各位评审专家在人工复核时，重点审阅我们代码中的动态分支控制流（Fallback机制）以及相关的BVH查询优化部分。我们坚信组委会一定会秉持公平、公正、客观的原则，查明事实真相。期待您的回复！感谢各位老师在百忙之中的辛勤付出！此致敬礼！同济大学“恭喜以下队伍打铁”队队长：彭怡焱联系电话：13500754388邮箱：2451299@tongji.edu.cn2026年4月13日附件：代码查重报告截图及分析说明完整提交记录及分支演进截图200余组本地参数对比实验数据汇总表团队协作沟通记录及代码Review截图

请问何时有新一期的赛题？