月赛审核要求（细则）【存档】

链接需修正

此文章内的链接需要修正为完整链接。

如果认为本文有需要修改之处，请私信联系小粉兔，欢迎提出修改意见。（2023-6-30 前有效）

---

本文中的『月赛』均指大月赛或小月赛，而不指普及组月赛和语言月赛。

在联系 kkksc03 并与对接的月赛审核员$^{\textsf{[2]}}$联系后，您需要准备：

1. 首先明确是大月赛还是小月赛，或其他类别。大月赛分 Div.2 和 Div.1，每个 Div 都是 $4$ 题，两个 Div 之间共享 $2$ 题，也就是有 ABCDEF 难度递增的共 $6$ 题，Div.2 含有 ABCD，Div.1 含有 CDEF。小月赛相当于只有大月赛的 Div.2。其他类别指的是题目编排上非传统，例如相同模型的题目分两个题或是两个 Div 均有的彩蛋题等等，但仍然需要与小月赛或大月赛中的其中一者类似，这是为了方便出题费用发放（大月赛 ￥4300 元，小月赛 ￥2200 元）。$^{\textsf{[5]}}$
2. 原则上洛谷不接受多个组织或个人在无交流的情况下共同组题，即我们推荐在同一个组织内准备好所有题目后提交月赛申请，或至少有合作关系并且出题相关人员之间可以正常沟通。
   需要特别注意的是：为了保证各题出题人间对各个题目进行充分交流，直接参与比赛工作的人员（包括验题人、造数据人等等，不含审核员和仅知道题目 idea 不参与比赛工作的人（但需做好保密工作））数量不得超过题目数的 $1.5$ 倍。$^{\textsf{[4]}}$
3. 联系月赛审核员后，就可以向审核员发送准备好的题目 idea 了，具体方式可以是洛谷个人私题或团队私题，或存储在其他任何地方均可（比如文本文件或是 PDF 格式，甚至其他 OJ 的私题，只要能让审核员看到就行，当然首选推荐是洛谷团队私题，原因见下）。在这个阶段并不需要有成文的题解或测试数据，但是当审核员要求提供题解时请配合。
4. 审核员开始审核题目 idea 后，可能会提出修改意见甚至认为题目质量不够而拒绝该题，如果审核员认为目前准备的题目不足以组成一套质量合格的月赛题，可以提供新题进行替换。允许提交 idea 审核的时候在同一个难度位置安排多个题目，审核员可能会选取其中一个题目作为最终题目，其他没有过审的题目可以回收自用。审核员应当自觉保证不泄露没有过审的题目，当它们在其他地方被使用时也不应做出可能影响公平性的举动，出题组也应当避免让这些题目出现在可能与审核员利益相关的赛事中。
5. 当通过了 idea 审核后，审核员将会参与部分分的设计、时间限制和内存限制的确定以及数据强度的监督，有必要时会参与验题（在 idea 审核的阶段，审核员也可能有提交代码的需求，如果此时还没有数据的话可能会延缓 idea 审核的进度）甚至造数据。如果在这个阶段发现某一题的部分分难以设计或数据强度难以保证可能会打回上一阶段重新选题。
6. 当审核员认为有信心在某一时间内完成月赛题目的所有工作，将会讨论月赛举办时间，一般是某一天的 14:00 ~ 18:00，根据难度可以调整时长，但具体时间原则上不应该变化太大。为了防止意料之外的问题或是单纯地对出题组效率预判错误，选取时间应当要谨慎。为了比赛宣传需要，原则上必须提前至少一个星期通知 kkksc03 制作宣传海报，以预留充分的宣传时间。
7. 还需要准备的是月赛直播讲评，需要做一个讲评 PPT/Beamer 或是类似的东西。讲评一般在比赛当晚 19:00 开始，具体持续时长可以由讲评者自己把控，讲评者在当晚有没有时间也需要纳入比赛日期确定时的考量内。直播相关事宜请联系 kkksc03，并提前确认相关设备是否正常工作。
8. 为了防止洛谷比赛题目顺序的一些可能出现的 bug，建议所有题目都放置在同一个团队下，并且按顺序（即你希望它们在主题库中的排列顺序）编号，即在同一个团队下的 Txxxxx 编号是递增的（不一定要连续）。这个工作可以在所有题目审核完毕，数据也都造好后，在比赛开始前做，如果顺序是乱的可以请一位用户把所有题目迁移到个人题库再按顺序迁移回去。

需要特别注意的事项

• 特别注意题目安全性问题，每个交予审核的题目，出题组必须告知审核员已知的所有可能知道该题目 idea 的人，即使他们可能与比赛无关。
  在准备比赛（特别是验题）的过程中，需要确保无关人员无法通过任何渠道获取到题目。一个有风险的途径是把私题的可见性设置为公众可见，我们不推荐在验题时这样做，正确的做法是将私题迁移至团队内，并设置为仅团队可见，让验题人加入团队进行验题。
• 关于同步赛：近期有发现出题组在与洛谷方面无任何沟通的情况下私自联系其他 OJ 举办同步赛的情况。这是非常不适当的。
  再次强调：出题组应当积极配合工作，尽量多与审核员交换信息，如果隐瞒重要信息，审核员有权拒绝进行到任何进度的月赛申请。

题面和评测方式的额外要求

月赛题目的题面需要严格遵守洛谷主题库题目规范。

由于是 IOI 赛制，在无特殊情况下时，必须使用子任务，所以必须说明『本题采用捆绑测试』。
（这是对于传统题和交互题而言的，提交答案题不适用此规定）

对于有多种可能的正确输出的传统题，即需要用到 Special Judge 的题目，包括输出小数的题目（可能有浮点误差的情况），必须在【输出格式】中注明。

一些容易引起歧义的内容必须写清楚，例如：

• 子串、子序列、连续子序列：强烈不推荐使用『连续子序列』，对于『子串』和『子序列』，至少在题面中的一处注明子串是连续的，子序列是不一定连续的。
  还需要注意的是，『所有子串』或『所有子序列』是否包含长度为 $0$ 的空串或空子序列，这是需要说明的。
• 本质不同：必须说明本质不同的精确定义。

关于一些错别字和推荐用法的例子：

• 连通：不应写成『联通』，是错别字。
• 结点：推荐使用『结点』而非『节点』或『顶点』，非强制。

一些杂项

• 赛时答疑帖应发在洛谷讨论区中的学术版，应在比赛当天发布，不可提早发布。需要加粗注明『如果发现比赛有原题或其他影响公平性的因素，请私聊管理员和出题人，而不要以任何方式公开，违者视影响可能会得到禁言的惩罚。』。
• 月赛结束后需要提供评价渠道，以让参赛选手评价比赛质量，可以选择知乎评价问题或在洛谷评价。
  • 如果选择发布知乎评价问题，不应擅自发布，必须在比赛宣传开始后、比赛开始前的时间段中发布。
  • 如果选择在洛谷评价，可以与赛后总结帖写在一起。
• 在月赛过审后，出题组不应擅自创建比赛，创建比赛和迁移题目的工作应该由 kkksc03 和审核员负责，出题组不需要参与（必要时可以催一下）。
• 没有出锅的话题目都会在赛后立刻加进主题库（有必要时，请催促审核员）。
• 赛后总结可以写一下每道题的一血之类的，以及一些奖品发放的结果（洛谷官方奖品或出题组自费的奖品）。
• 现强制出题组提供『官方题解』用于在洛谷题解区展示，出题组需要在比赛前准备好官方题解作为隐藏博客。审核员需要负责确保提供的题解符合基本规范并且具有较高质量以帮助用户理解。审核员需要在官方讲评结束后立即将题解取消隐藏并（通过后台）提交至对应题目的题解区。
• 对于 Div.1 BCD 而言，讲评的三天保护期已废除，讲评结束后审核员应该立即打开题解通道。
• 比赛结束后，题目加入主题库时，审核员需要添加对应题目的算法标签，以供用户筛选。所有题目都需要有至少一个算法标签。

一些细节

• 月赛题都应该要加『洛谷月赛』和『洛谷原创』标签，请出题组和审核员复核。
• 月赛题一般情况下都应该要加『O2 优化』标签，请出题组和审核员复核。如果确实有禁止 O2 优化的需求，请和审核员讨论。
• 月赛题在无特殊情况下时，任何测试点的时间限制不应少于 500 ms，这是为了评测机可能存在的波动考虑。
• 月赛题在无特殊情况下时，每题所有测试点的时间限制之和不应超过 360 s。特殊地，在无特殊情况下时：
  • 如果月赛类型类似于小月赛，则各个题所有测试点的时间限制之和分别不应超过 30 s、30 s、120 s、360 s（分别对应难度定位在 ABCD 的题）。
  • 如果月赛类型类似于大月赛，则各个题所有测试点的时间限制之和分别不应超过 30 s、30 s、120 s、120 s、360 s、360 s（分别对应难度定位在 ABCDEF 的题）。
  • 小月赛的 AB 两题和大月赛 Div.2 的 AB 两题的测试点数量不应超过 $30$ 个。
  • 如果有超出上述限制的需求，请出题人和审核员考虑此需求是否确实合理。如果确实有需求，请提前与审题员和 kkksc03 联系，这是为了评测机总承载能力考虑。
• 月赛题在无特殊情况下时，任何测试点的内存限制不应超过 2 GiB 且不应少于 8 MiB。

组题或比赛时的失误判定标准与出题费用标准

见洛谷月赛工资发放细则。

一般传统题数据格式要求

在传统题（即可以一次性从标准输入中读入、一次性输出到标准输出，不存在交互过程）中，每个测试点的数据包含恰好一个输入文件，并且洛谷还要求恰好一个输出文件（即使可以为空）。

除开个别可能的特殊题目外，对一般的传统题的输入输出数据格式有要求，此要求与 NOIP、NOI、IOI、ICPC 等主流赛事应当保持大致同步：

• 未在题面中特殊说明并强调时，输入文件必须仅包含 ASCII 中的可见字符、空格、以及换行符，具体地：

  可见字符包含：

  • 数字，即 0123456789，对应 ASCII 编码中的 $48 \sim 57$。
  • 大写英文字母，即 ABCDEFGHIJKLMNOPQRSTUVWXYZ，对应 ASCII 编码中的 $65 \sim 90$。
  • 小写英文字母，即 abcdefghijklmnopqrstuvwxyz，对应 ASCII 编码中的 $97 \sim 122$。
  • 字符 !"#￥%&'()*+,-./（其中 ￥ 应为美元符），对应 ASCII 编码中的 $33 \sim 47$。
  • 字符 :;<=>?@，对应 ASCII 编码中的 $58 \sim 64$。
  • 字符 [\]^_`，对应 ASCII 编码中的 $91 \sim 96$。
  • 字符 {|}~，对应 ASCII 编码中的 $123 \sim 126$。
  • 其他字符均不为可见字符。
  • 所有可见字符占据 ASCII 编码中的 $33 \sim 126$。
    可以使用 C++ 中的标准库函数 int std::isgraph(int) 判断是否为可见字符。

  空格和换行符的 ASCII 编码分别为 $32$ 和 $10$。
  换行符在 C++、Python 等常见语言中的字符或字符串中可以使用 \n 进行转义。

  换句话说，如果输入文件中需要出现这些字符以外的 ASCII 字符、甚至非 ASCII 字符，应询问审核员意见并在最终题面中特殊说明并强调。

  一般来说，传统题的输入文件只会出现数字、大写英文字母、小写英文字母、输入负数或浮点数时需要的符号（+-.）、以及空格和换行符。
  存在一些题目的输入文件中需要出现不在此列的标点符号或数学符号等特殊字符，也应在题面中显眼位置指出，以免选手遗漏。

  即使文件中仅存在满足上述要求的字符，也需保证字符编码与 ASCII 兼容。例如，不能使用 UTF-32 或 UTF-16 进行编码。

• 未在题面中特殊说明时，需要确保输入文件中不存在以下情况（假设文件中仅包含上文允许的字符）：

  • 空文件，或仅包含空格或换行符。
  • 空行。形式化地说：文件以换行符开始或存在连续两个换行符。
  • 存在行首空格或行末空格。形式化地说：
    文件以空格开始或存在空格与换行符相邻（连续的两个字符按顺序分别为空格和换行符，或换行符和空格）的情况。
  • 连续的多个空格。
  • 文件不以换行符作为最后一个字符。
    注意这一条的意思是输入文件需要以换行符结束。

  事实上，存在一些常见的输入格式违背上述要求的可能性，例如常有输入文件以空行分隔的情况。但除非为了特殊的显示效果，不应该违背上述要求。
  不影响显示效果的前提下应尽可能遵守上述要求。换句话说，以下要求一般比其他要求更应该遵守，除非是为了特殊的字符串处理需要：

  • 不存在行末空格，空白行内不应有空格。
  • 不存在文末超过两个换行符。
  • 以换行符作为最后一个字符。

  而这些要求也是造数据时的常见问题。例如，造数据中向输入文件输出时，应当避免：

  • 输出数组或矩阵时在最后一个元素后仍输出空格。
  • 漏掉文末的换行符。
  • 重复输出文末的换行符。

  如果确实有违背上述要求的需求，也应询问审核员意见并在最终题面中特殊说明。
  例如：如果输入文件中会出现空行，或会出现连续的多个空格，或行首空格，应在题面中特殊说明。

• 类似洛谷在 Special Judge 中提供了 Testlib 的使用，在此也指出在造数据时可以使用 Testlib 中的 Validator 功能对输入文件进行格式上的检查。

• 对于题目要求的选手的输出格式，无特殊情况时也应遵守类似规定。

• 洛谷要求数据中对于每个输入文件提供对应的输出文件，当没有设置 Special Judge 时将会使用忽略行末空格和文末换行的全文比较，此时输出文件也应遵守类似规定。如果使用了 Special Judge，可以根据需要自行设置输出文件的内容，只要不影响给出正确的评测结果即可。

对于提交答案题、交互题等题目类型，上述要求可能不适用，但相通之处的标准应统一，例如在题面中对非常见字符进行说明等。

特别地，在 Windows 或其他非 Unix 系统下造数据后，把文件传输到 Linux 下后，可能出现换行符编码不正确的情况。具体地：

• 造数据的时候请注意换行符使用 Unix 格式（即 \n）而不是 Windows 格式（即 \r\n），如果是在 Windows 系统下造的数据就有可能出现这个问题，如果使用的是 Windows 系统，可以使用系统自带的记事本（Notepad）打开文件然后看一下右下角显示的是 CRLF 还是 LF，如果是后者就没问题（当然，旧版 Mac 格式（即 \r）也是不行的）。
  在 Windows 下造数据时避免造出 \r\n 格式换行符的方法可以查看附录。

附录

Windows 环境下造数据注意事项

洛谷评测机是 Linux 环境，在一些特定题目中，特别是字符串题，如果换行符格式不正确，而用户使用了 getline（C++ 中）等函数进行读入，就会出现输入错误的情况。这些情况在历次月赛中造成了一定的影响，所以还是需要注意一下。

如果你的数据生成器是使用 C++ 写的，并且在代码中显式对输入输出进行重定向（例如使用 fopen、freopen、ofstream 等等），只需要使用二进制文件格式输出到文件即可。举个例子：

• 如果使用 C 风格输入输出，只需要在打开输出文件的时候在 const char* mode 参数中传入 "wb" 即可，其后的 b 字符即代表了二进制格式。
• 如果使用 C++ 风格输入输出，只需要在定义 std::ofstream 对象时在构造函数的第二个参数 std::ios_base::openmode mode 中传入 std::ios::binary 即可。

如果你的数据生成器不是使用 C++ 写的，并且也在代码中显式对输入输出进行重定向，而且你清楚地知道如何在该语言中使用二进制文件输出，那么使用和上述类似的方法即可。

如果你是使用命令行对标准输出进行重定向的，则比较麻烦，如果你的数据生成器是使用 C++ 写的，可以考虑这样的方法：

• 我们假设运行命令行时的命令是“[generator] < [parameter_file] > [input_file]”，其中 [parameter_file] 表示该数据点的一些参数，[input_file] 表示该数据点的输入文件。
• 那么我们把命令行命令改成“[generator] [parameter_file] [input_file]”，即取消重定向。
• 为了能继续正常接收参数和输出到输入文件，其实 C++ 是可以通过 main 函数的参数接收命令行参数的，格式为：int main(int argc, char *argv[]);。
• 其中 argc 为命令行参数个数，argv[0] 到 argv[argc - 1] 就依次存储了这些参数，例如上面的例子“[generator] [parameter_file] [input_file]”中，有：
  • argc = 3；
  • argv[0] = [generator]；
  • argv[1] = [parameter_file]；
  • argv[2] = [input_file]。
• 所以把 main 的参数写上，然后在 main 的开头加上 freopen(argv[1], "r", stdin); 和 freopen(argv[2], "wb", stdout); 即可，这是对于 C 风格 I/O 的处理方法，C++ 风格的处理方法也是类似的。

上面是对输入文件的 \r\n 的处理方式，推荐输出文件的 \r\n 问题也用类似方式处理。

还有最后一个通用的解决方法：按正常方法造好所有数据后，写一个 dos2unix.cpp：

#include <cstdio>

const int SIZE = 100000000;
char buf[SIZE];

int main(int, char *argv[]) {
	std::FILE *fin = std::fopen(argv[1], "r");
	std::size_t cnt = std::fread(buf, sizeof(char), SIZE, fin);
	std::fclose(fin);
	std::FILE *fout = std::fopen(argv[1], "wb");
	std::fwrite(buf, sizeof(char), cnt, fout);
	std::fclose(fout);
	return 0;
}

在命令行运行命令 dos2unix.exe [filename] 即可把 \r\n 变成 \n。

那么也就是造好所有数据后，记下输入输出文件名，批量使用 dos2unix 把它们改好即可。

参考资料 / 外部链接

1. 【有偿】洛谷月赛征题令，https://www.luogu.com.cn/blog/kkksc03/luogu-call-for-contest-2。
2. 题目管理志愿者轮换制度，https://www.luogu.com.cn/discuss/186291。
3. 洛谷主题库题目规范。
4. 洛谷公开比赛规范及要求。
5. 洛谷月赛工资发放细则。
6. MikeMirzayanov/testlib，https://github.com/MikeMirzayanov/testlib。
7. Testlib 简介，https://oi-wiki.org/tools/testlib/。

更新日志

• 2021-08-05：初版。
• 2021-08-20：添加 Windows 环境下造数据避免换行符 \r\n 的具体方法。添加对时间限制的下限为 500 ms 的限制。
• 2021-08-27：添加了题目需要添加『洛谷月赛』标签的注意事项。
• 2021-10-01：添加了【题面和评测方式的额外要求】：指出了非特殊情况必须使用子任务，以及添加了关于『子串』和『子序列』消歧义，『本质不同』消歧义的说明，指出了『联通』的误用（应该写成『连通』）。
• 2021-10-16：添加了每题的所有测试点的时间限制之和的上限的一般要求。添加了每题的所有测试点中的内存限制的上下限的一般要求。添加了关于不积极与审核员交换包括举办同步赛在内的重要信息或隐瞒其他重要信息的警告。
• 2021-10-17：添加了对赛时答疑帖和知乎评价问题的进一步要求。
• 2021-10-18：添加了【参考资料 / 外部链接】。
• 2021-12-19：添加了出题组不应擅自创建比赛的注意事项，要求一般情况下需要添加『O2 优化』标签。
• 2022-01-26：添加了关于题目安全性的注意事项。
• 2022-02-27：添加了对比赛工作人员的数量限制，添加了《公开比赛要求》作为参考资料 / 外部链接。
• 2022-04-10：添加了题目需要添加『洛谷原创』标签的注意事项。
• 2022-05-01：修改了关于比赛评价渠道的规定，不强制要求在知乎提出评价问题。
• 2022-06-19：添加了【一般传统题数据格式要求】，规定了输入输出文件的一些技术标准。
• 2022-08-09：添加了强制提供官方题解和算法标签的规定，取消了官方讲评的保护期。
• 2022-09-05：明确了取消保护期只针对 Div.1 BCD 三个试题。
• 2022-12-06：将公开传播可能影响比赛公平性的因素的惩罚中的警告性棕名一项去掉，仅保留禁言的惩罚。
• 2022-12-12：添加了【组题或比赛时的失误判定标准与出题费用标准】。添加了《洛谷月赛工资发放细则》作为参考资料 / 外部链接。