方向 1：开源鸿蒙 PC 专项积分赛实战复盘。记录与审核状态截至 2026-10-21。

我最初筛选积分赛任务时，优先寻找同名软件已有完成记录的项目。Clp、DyLP、dbg-macro 等任务都有历史配方可参考，至少可以减少从零探索目录、依赖和构建方式的时间。早期清单甚至写过“接近照抄”。后续经历让我重新评估了这句话：历史成果是调查入口，不能直接作为当前任务低风险的证明。

本文记录我在开源鸿蒙 PC 专项积分赛中的任务选择和版本交付经验。案例状态截至 2026 年 10 月 21 日，不把已提审、构建通过或本地测试通过写成积分已到账。

对刚开始参赛的同学，认领任务很容易被理解成一道选择题：软件是否熟悉、历史配方是否存在、预计几天能编过。我后来发现，还要问另一个问题：最终要向平台交付什么证据，哪些动作需要维护者参与。只估计写代码的时间，会把依赖发布、任务关联和人工审核都当成收尾小事；这些前置条件却可能决定一个技术上已经修好的任务能否继续推进。

这篇文章围绕一次选择标准的调整展开。Clp 和 Allegro 用来说明已有成果为什么仍需重新验证；五组任务映射用来说明修订身份为什么必须核对；OdinFmt 用来说明任务登记与接收范围可能产生冲突。具体算法和代码缺陷留给各自的技术文章，这里重点解释认领时怎样看待这些成本，交付时怎样把状态讲清楚。

先把任务版本与源码版本对起来

任务列表中的名称、上游标签和仓库适配目录未必采用同一套版本写法。认领之前，我会沿着历史合并申请查到实际源码声明，再核对下载地址、固定校验值和测试文件。只有名称相同，仍不足以证明可以直接复用。

Odin 与格式化工具的任务登记，就涉及月份名称与实际源码快照的对应。后续 OLS 修订还处理了六月版本登记和实际源码快照不一致的问题。对这些任务，真正需要回答的是“准备交付哪份源码”，而不只是“有没有一个同名目录”。

可复用内容也需要拆开看：构建方式可以参考，依赖可用性需要重新确认，测试是否真的执行需要看原始日志。历史配方中的测试数量、通过率和平台假设，不能未经核对直接复制到新申请。

图 1 依据本项目经历整理的认领前检查顺序。示意图，不代表赛事通用规则。

把历史配方当成调查线索 逐项判断可以复用什么

配方是描述软件下载、依赖、构建和打包方式的文件。拿到一个已有配方，我首先关注的不是它有多少行，而是它把哪些条件写死了：源码对应哪个标签，目标系统是否走专门分支，是否默认静态库或动态库，消费者程序是否真正使用产物。能够解释这些输入，才有条件判断当前任务与旧任务的差异。

例如，Clp 的常规求解路径已有检查，但后续才通过负数标记发现另一条接口路径存在问题。Allegro 的旧消费者可以输出通过，动态库内部标识检查却失败。这两个案例都说明，找到同名配方和看到一条成功日志，只能减少调查起点的不确定性，不能直接缩小当前需要验证的功能范围。

我因此把复用拆为三种判断。源码声明和构建目录可以作为起步参考；依赖是否可获取，要在本次环境中确认；测试结论必须回到对应提交的原始输出。三种判断可以得出不同答案。例如目录结构可复用，生产参数需要修正，旧测试还需要补充。这样描述任务，比简单标记为“可照抄”更接近真实投入。

固定校验值用于确认下载到的源码内容，不能替代运行验证；历史测试报告说明当时验证过什么，也不能证明当前分支仍然相同。我会把任务登记版本、上游源码版本和适配修订版本分别记录。它们可能看起来相似，却承担不同职责：一个对应赛事任务，一个对应实际输入，一个对应这次交付身份。

已有发布版本出现缺陷 应当怎样交付

项目中，部分版本已经发布，生产配方受到不可原版本覆盖的约束。对于这类任务，如果只是补充消费者测试，可以在允许范围内推进；如果发现问题实际位于生产构建，则要按项目流程提供新的适配修订版。

例如，Clp 后续用 1.17.10.1 修复了普通 char 对负数保留标记的解释问题；Allegro 用 4.4.3.1.2 接续动态库标识修复；DyLP、Osi 和 OLS 也分别产生了对应修订。这些修订保留了原任务和旧版本的历史，不能通过改正文把旧缺陷描述成从未存在。

这里的返工不全是重新写代码。已经发布的版本出现生产构建缺陷后，修复参数落在新修订中，消费者、版本说明和任务关联也必须指向同一个修订。如果代码测试的是新包，申请正文还写旧版本，审查者无法仅凭“测试通过”判断成果属于哪一项任务。输入身份没有对齐，后续再完整的日志也很难被准确使用。

我在整理材料时，会把同一次交付的源码提交、适配版本、依赖来源和测试入口放在一起核对。如果使用旧缓存中的二进制，必须说明那份包与当前提交的关系；如果仅重新编译消费者，也要与从源码完整重建区分。认领阶段先想清楚这些材料如何对应，后面就不必靠回忆拼接多个轮次的结果。

这里容易漏掉一个交付动作：新申请与原任务的实际关联。技术修复完成后，任务系统仍可能挂在旧申请上。新申请正文写上任务编号，只是说明意图；反馈表提交成功，也只是反馈送达。维护方是否已经完成关联，需要查看实际任务列表。

五组映射教会我的状态管理方法

10 月 21 日核查时，任务 971、6549、6543、6518、7289 分别需要由旧申请接续到修订申请 16533、16540、16560、16632、17152。留档中这五个修订的 linked_tasks 仍为空。前四个显示共享构建通过，OLS 的共享状态仍未知。它们不能因为真机测试通过，就被统一标成“比赛完成”。

图 2 五组任务与修订申请的历史映射。状态取自 2026 年 10 月 21 日核查，不是实时查询。

我后来把状态拆成独立字段：源码提交、目标设备验证、共享构建、实际任务关联、人工审核、正式发布。某一字段变绿，只更新这一字段。这样可以避免“一个截图里有绿色，就把整项任务勾完”的误判，也方便向维护者说明究竟缺哪个动作。

以 Clp 为例，任务 6518 原来对应旧申请 #14879，修复后的新申请是 #16632。共享构建通过，回答的是对应源码在共享流程中的执行结果；linked_tasks 为空，回答的是平台是否把实际任务关联到这个申请。两个字段描述不同对象，它们可以同时成立，不能用其中一个覆盖另一个。

五组映射的价值也不在数量本身，而在于把后续请求变得明确。维护方需要知道原任务是谁、旧申请是谁、新申请是谁、要接续哪个版本和分支。仅说“我的任务又没了”，会混入技术失败、作者取消提审、范围拒收和关联未更新等不同原因。保留映射后，至少可以对着具体记录讨论，而不必先争论是哪一层状态发生了变化。

这些经历让我把任务进度写成几个并列结论。例如“真机验证完成，共享构建通过，原任务仍关联旧申请，人工审核等待处理”。它读起来比“完成百分之九十”稍长，却能直接指导下一步：当前需要处理的是任务关联和审核，而不是再重复运行一遍已经通过的消费者。

任务可认领 仍需要确认审核范围

另一个案例是 OdinFmt。该任务已经认领并关联，也有实际消费者和快照测试结果，但 10 月 21 日出现了针对非 C/C++ 范围的拒审意见。这时问题已经不只是能不能编译，而是该任务应采用什么接收口径。

这件事不能简单概括为平台状态丢失。至少 Allegro 的取消提审有审查人明确留言，OdinFmt 也有新的拒审记录。把所有变化都归咎于系统，会让后续沟通偏离事实。对范围问题，应保留任务、源码和审核证据，请维护方确认规则适用；反复点击提审不会替代这一步。

遇到范围冲突 先保留登记与源码两侧的事实

OdinFmt 的案例里，平台任务语言标签与上游主体实现语言需要分开看。任务登记为 C++，不能改变实际源码以 Odin 实现的事实；源码使用 Odin，也不能由参赛者自行推出赛事应该如何接收。技术事实可以查源码，比赛范围需要维护方给出口径。把这两个问题混在一起，既不能解决编译，也不能解决审核。

因此，整理范围争议时，我会保留任务页面、版本和语言字段、固定配方实际调用的编译器，以及审查人原话。这样做是为了让同一项任务可以被准确讨论，不是为了把个别任务的意见扩大成赛事对某种语言的永久规则。原有消费者通过情况继续记录，但它不能自动推翻当前拒审意见。

认领之前如果就能看出范围存在冲突，应尽早确认。已经投入实现之后，也应停止把重新提审当作解决办法。真正待解决的是这份成果能否按现有任务接续、是否需要调整接收方式。技术验证可以继续补充，但不能代替平台对此作决定。

我现在认领前会留下哪些材料

我会先保存任务编号、登记版本、历史申请和源码校验值，然后确认目标设备上需要哪些依赖、测试是否依赖图形界面或额外数据、已发布版本允许修改什么。如果接收范围存在疑问，应在大规模投入之前厘清。

开始实现后，保留一个失败基线、一份准确修复提交和一轮与该提交绑定的验证。交付时再核对任务关联、共享构建和审核发布。这里没有关于“保证拿分”或成功率的统计，只有本项目实际遇到的返工点。

对刚参赛的同学，我建议先选自己能够验证的任务，再谈看起来容易的任务。历史成果可以缩短调查过程，但真正减少返工的是提前明确输入、验收范围和交付身份。

把交付材料整理成别人能够复核的记录

我现在会围绕四个问题整理一项任务：实际输入是什么，原来怎样失败，改动了什么，结果覆盖哪里。输入包括固定源码和依赖；失败包括原始日志与最小复现；改动绑定准确提交；结果同时保留已执行、未执行和等待外部办理的部分。读者不用从几十张截图中猜测哪张属于最终版本，审查时也更容易指出缺口。

如果另一位同学要接手，我希望他能直接找到一个失败基线、一份修复和一轮对应验证，而不是重新经历全部探索过程。中间候选和失败轮次可以归档，但不能将不同轮次的最佳结果拼成一轮不存在的“全部通过”。这也是我愿意保留旧申请和旧缺陷记录的原因：它们解释了新修订为什么有必要。

这些做法不能保证每项任务都顺利，也没有形成可宣称的成功率。它们解决的是本项目已经遇到的返工原因：认领时低估验证成本、交付时混淆版本身份，以及用技术通过替代平台状态。对于参赛同学，先确认自己能独立验证哪条路径、能留下哪些材料，比只比较软件名称是否熟悉更有实际价值。

公开参考与结果边界

相关修订申请：https://atomgit.com/OpenHarmonyPCDeveloper/build_in_harmonyos/merge_requests/16632 ；https://atomgit.com/OpenHarmonyPCDeveloper/build_in_harmonyos/merge_requests/16533 ；https://atomgit.com/OpenHarmonyPCDeveloper/build_in_harmonyos/merge_requests/17152 。这些链接用于核对源码与公开讨论，不表示申请已全部获得批准。本文没有给方向 2 的应用开发与上架经历补写不存在的成果。

说明：本文基于本人参赛项目材料整理，使用 AI 辅助文字组织与示意图排版；测试结果来自实际留档。图中日志节选并非新增测试或终端截图。