做题量与比赛成绩#

今年在 Codeforces 和 AtCoder 上合计新增通过 472 道题。这里按每道题在账号记录中的首次 AC 计数，重复提交和往年已经通过的题目不重复计算。

过题数据来自 OJFlare 的 9 月 21 日 12:59（UTC+8）快照；计分赛与 Rating 按 9 月 22 日的 Codeforces 官方记录和 AtCoder 官方记录统计。

这两组数字回答的是不同的问题。过题记录包含练习和补题，不能直接说明能否在比赛中独立完成；Rating 则反映限时比赛的结果，两站分数也不能直接换算。目前 Codeforces 为 Expert，AtCoder 为水色。今年的变化更值得关注：AtCoder 有明显提升，Codeforces 的比赛成绩还没有跟上练习中的积累。

从代码里看训练内容#

今年新增通过的 Codeforces 题目中，142 道有官方难度评分，其中 26 道在 2000 分及以上；其余 104 道没有评分，不把它们当作低分题。结合 CodeFlare 中的具体实现，图论模型的组合是这一阶段比较集中的积累。

这些样本都在今年首次通过。它们说明训练已经涉及“如何把条件转成模型，再把多个算法或数据结构接起来”，也覆盖了 DP、计数和代数化简。不过，完成一份专题练习或补题代码，与在没有标签提示的比赛中及时识别模型，仍然是两件需要分别训练的事。

限时比赛中的表现#

Codeforces 今年的 6 场计分赛都完成了 A、B、C，其中一场进一步通过 D，另一场通过 D1。这个结果说明前半场有一定基础，但中段题的突破还不稳定，前面的题也会因错误提交损失时间。

Round 1111 是一个具体例子：D1 在约 92 分钟时通过，随后 D2 在最后约 17 分钟内连续提交了 10 次，均为 TLE。对于这种情况，复盘需要回到操作次数上界和重复计算上，判断是否应该调整算法或数据结构。比赛最后才反复尝试，很难留出重新建模的时间。相关记录：D1 的 AC、D2 的首次 TLE与最后一次 TLE。

Codeforces 最近一次计分赛停在 7 月 18 日，所以 1617 还不能充分反映 8、9 月练习后的状态。要判断后续训练是否有效，需要再用完整的限时比赛检验。

AtCoder 今年从 1083 升到 1463，最高到过 1475。最近参加的 8 场 ABC 中，6 场完成 5 题，2 场完成 4 题；这 8 场都完成了 A 到 D，其中 ABC467、ABC469 是跳过 E 做出 F。按题目特点调整顺序已经能带来收益，但更高难度题目的持续输出还需要积累。

7 月的 ABC467 取得了 2049 的单场 Performance；最近 6 场计分赛的 Performance 则在 1414–1512 之间。全年有进步，近期也进入了需要继续突破的阶段，不能把最好的一场当作稳定水平。

最近的 ABC476 中，E 在开赛约 46 分钟时通过，F 则在次日补出。这道 F 的坐标变换和距离贡献处理已经进入代码积累，但尚不能计为赛时六题。把赛中提交和赛后补题分开看，更容易找到下一步要改进的环节。

下一阶段的训练方向#

根据今年的代码和比赛记录，接下来我想把重点放在三件事上：

1. 增加不看标签的限时混合训练。 以 Codeforces 1700–2000 分题、ABC E/F 和部分 ARC 题为主要候选，按实际难度选题，练习从条件中识别模型。每次记录建模耗时、首交结果，以及是否借助提示。
2. 把复杂度与实现检查前移。 提交前明确状态数、每次操作的代价和总操作次数；遇到 TLE 时先重新估算上界。多种结构共同维护状态的题，可以写小规模直接模拟来对照；调用模板前检查平行边、边界下标和整数范围。
3. 持续参加完整比赛并复盘下一道题。 用计分赛或完整虚拟赛检验专题训练能否迁移，区分赛时独立完成、赛后独立补出和参考题解后的实现。保留图论专题训练，同时继续覆盖 DP、计数与构造，避免只在熟悉的题型里练习。

DMOJ：从提交代码到维护评测环境#

和算法训练关系最紧密的是 DMOJ。这套部署包含网页、后台任务、通信桥、评测机、数据库和缓存，另有 PDF 服务与 HDU 特殊评测适配服务。

一次代码提交会经过网页接收、任务分发、编译运行和结果回传。平时在 OJ 上看到的提交状态、时间限制和比赛排名，到了自己的环境里，都成了需要配置和维护的具体环节。

我在这套部署中做了比赛计分、排名可见性和提交界面等适配，也接入了 HDU SPJ。题目迁移时，输入输出约定、checker 行为、编译环境和评分规则需要一起考虑。维护评测环境，让平时做题时接触到的规则有了更具体的实现。

邮箱：Stalwart 与 Bulwark#

邮件服务端使用 Stalwart，网页客户端使用 Bulwark Webmail。我的部署包含按域名组织文件夹、JMAP 交互和 Passkey 登录相关的本地适配。

邮件客户端的工作涉及一整套状态：界面上的文件夹如何对应到服务端，登录状态怎样延续到后续请求，操作失败后又该如何提示。这些改动需要把界面、认证和协议放在一起考虑。

数据看板、笔记与信息获取#

FitBaus 提供 Fitbit 数据看板和只读 API；Fast Note Sync 与 Obsidian 插件配合，同步笔记和附件。RSSHub、OpenList、TaoSync 等工具则承担信息获取、文件入口与同步工作。

这些服务处理的数据不同，维护时却经常遇到相似的问题：更新什么时候发生，失败后如何重试，旧数据是否仍然可用，以及怎样知道上一次成功同步的时间。它们也让我把注意力从单个页面，延伸到数据更新和多端状态上。

多人同步与接口适配#

DreamStream99 把 Win98 风格的静态前端与房间同步、媒体处理服务分开。多人一起观看视频时，播放、暂停、跳转和重新加入房间都需要同步，还要处理房主权限和重复操作。

NeXus / Xboard 这一组服务则包含前端、同源中间层和既有后端。中间层把浏览器操作映射到后端接口；前端根据接口实际提供的能力展示功能。这与我在 EZ-Theme 中做的兼容工作有直接联系。

配套服务与日常维护#

其余工具主要负责入口、监控、通知和后台任务：

服务部署之后，维护还会继续：处理异常、跟进上游更新、保存本地修改，以及整理升级和恢复步骤。容器的运行状态只是其中一部分，实际功能仍需要从使用过程去检查。

QQ Chat Exporter#

QQ Chat Exporter #675 处理的是 WebSocket 认证。网页通过 HTTP 完成认证之后，实时进度和流式搜索使用的 WebSocket 也需要携带访问令牌，重新连接时同样如此；HTTPS 入口则需要对应的 wss 连接。

随后提交的 #677 在 2026 年 9 月 6 日 合并，把实验性的私聊漫游查询接入了现有导出流程。

用户可以从已有私聊会话进入，也可以先通过 QQ 号查找对应的 peerUid。选定日期范围后，服务端创建任务、查找消息锚点并查询记录，再复用现有的消息解析、资源处理和格式导出能力。任务页提供进度、取消和下载入口。

这部分工作除了查询本身，还涉及任务排队、并发控制、取消和状态恢复。查询有日期跨度、消息数量和执行预算等限制；结果中保留不完整标记与停止原因，说明这次任务实际完成了什么。它仍是依赖已登录 QQ 和桥接能力的实验性私聊功能，不能保证恢复全部云端历史。

其他贡献#

Daily_CF_Problems 是另一种持续参与开源的方式：把日常做题留下的解法整理好，提交到共同维护的题解仓库。已合并的题解 PR 也记录了这部分积累。

证书#