题目质量要求

本文是 Neuro OJ 的建议规范（SHOULD）：不阻止导入，但推荐出题人遵循，以提升题目的可读性、可做性、可评性与可维护性。

与题目包格式规范（强制 MUST）不同，本页规则不会被导入校验拦截。但其中「来源署名」与「模板不得含完整实现」等属于硬性质量要求，违反会影响题目可用性与公平性。

题目命名规范

• 标题简洁、准确、无歧义；中文建议 5–30 字，英文 3–20 词。
• 来源署名（必须）：
  • 官方/样例题在标题中标注来源，格式为 [来源] 题目名，例如：
    • [LMCC-T 2025 交流活动] 古诗词题目格式标准化
    • [LMCC-T 2026 第一轮] 大模型基础概念
    • [LMCC-T 2026 第二轮] 数学作业批改助手
  • 客观题是第一轮认证中使用的，同样标注 [LMCC-T 2026 第一轮]。
  • 第三方出题组举办的比赛，在进入主题库前也必须在标题上署名（如 [XX杯 2026] 题目名）。
• 避免：测试题、未命名、A+B 这类无信息量命名；避免把题号/难度/类型写进标题（display_id 由系统生成）。
• 语言：与题面语言一致，项目以中文为主，可中英双语。
• 可搜索性：包含核心知识点/能力关键词，便于搜索。
• 风格：不用 emoji、特殊符号、过长副标题。

tag 适用规范

Neuro OJ 有双类标签：

• problem 标签：人人可见，用于来源、知识领域、题型/能力。
• algorithm 标签：通过后可见，仅用于真正的算法/数据结构（如 DP、图论、滑动窗口）。

LMCC 知识领域标签（建议用 problem kind）

基于 CCF 大纲 12 模块：

人工智能基础概念、大模型基础概念、模型架构、预训练技术、指令微调、人类对齐、解码与部署、提示学习、复杂推理、智能体、模型评测、模型伦理与安全。

来源标签（problem kind）

LMCC 样例题、LMCC-T 2025 交流活动、LMCC-T 2026 第一轮、LMCC-T 2026 第二轮、第三方比赛 等。

能力/题型标签（problem kind，可选）

客观题、编程题、材料题、代码实现、API 调用、RAG/检索增强、文本解析、信息提取、结构化输出、知识应用 等。

数量与命名

• 数量：建议 2–5 个，最多不超过 8 个；避免堆砌。
• 命名：使用社区/大纲通用术语，避免自造词、过细标签；同义标签应合并。
• 避免：与标题重复、过于宽泛（难题）、过于具体（2026-08-25 测试）、误导性标签。
• 客观题套卷：不得关联算法标签（系统强制）。

题面与数据质量

• 题面结构：题目描述、输入格式、输出格式、样例、数据范围/限制、说明/提示。
• 清晰性：无歧义；输入输出格式明确；样例覆盖典型与边界。
• 数据范围：明确给出；覆盖最小值、最大值、空输入等边界。
• 测试数据：建议全部不可见；可见用例仅用于题面示例/调试；隐藏用例覆盖边界、极端、随机/压力。
• 数据强度：至少包含样例 + 边界 + 随机/压力；LLM 题考虑多样性与评分稳定性。
• 样例即测试：题面中的样例应同时作为 evaluator 的可见自测用例，建议只用于调试与友好提示、不计入正式评分（需在 evaluate.py 内自行实现；平台骨架 data/problems-src/1001/evaluate.py 默认把可见与隐藏用例等权计分，见 test-data.md）。

模板要求

• 每道编程题 SHOULD 提供 template.py，作为选手作答的起点。
• template.py MUST NOT 包含可通过全部测试的完整正确实现。
• 模板应包含：函数签名、参数/返回值说明、必要的 TODO 或骨架逻辑；LLM 题可给出消息结构示例，但不得直接给出可满分的 Prompt。
• 模板应与题面中的“你需要实现”一致，且能在不修改评测脚本的情况下直接作为提交入口。

模板文件名可在 manifest 中更改

模板默认取 template.py，也可用 manifest.template 指定其他纯文件名（禁止 /、\、..）。它是代码编辑器的初始代码（starter code），由 GET /api/v1/problems/:id/template 拉取，与支持包无关。

评测脚本质量

• 健壮性：处理异常、超时、非法输入，不崩溃。
• 不泄露隐藏数据：不可见用例的输入/期望/细节不写入面向用户的 details。
• 标准测试点明细：新评测器应在 details.cases 中输出 case_id、status、hidden、time_ms 等字段；hidden 必须为布尔值（true 隐藏 / false 可见），可见用例可附输入/期望/实际输出，隐藏用例不得包含敏感输出。
• 可重复性：无随机/时间依赖（或固定种子），结果确定。
• 资源使用：合理设置 time/memory，避免死循环/无限等待。
• 安全：不注册通用转发 capability；密钥不入包/题面；LLM 题走 noj-llm-gateway。
• 样例自测：evaluator 应运行题面给出的样例（建议不计分，需自行实现），并输出对选手友好的调试信息。
• 调试信息应明确易读：结构化、标注输入/期望/实际、错误原因，方便选手定位问题。

评测脚本自身的异常要上抛，不要吞掉

evaluate.py 的运行期异常（如 Solution 调用抛出未捕获的错误）应直接向上抛出、不输出 ---RESULT---，由 judge 统一收尾为 error。若自行捕获后仍输出结果，会把真实故障掩盖成 finished + 0 分。样例题骨架即遵循此约定。

难度与发布流程

• 难度：easy/medium/hard 与题面/数据强度匹配；新题建议从 easy/medium 开始。
• 发布前自测清单：
  • 用一版参考答案提交，确认状态与得分符合预期。
  • 检查隐藏用例的可见性（由 evaluator 控制）。
  • 检查 details.cases 是否按标准输出，且隐藏用例不含输入/期望/实际输出。
  • 检查资源限制是否合理。
  • 修改后重新上传，或对旧提交触发 rejudge。
• 审核：P 型题仅管理员可创建；U 型题由创建者自行管理（owner 可将其转为公开），批量转公开/转 P 型由管理员在评定队列处理。建议 U 型也遵循本规范。

产物提交（artifact）不支持 rejudge

自测清单中的"触发 rejudge"不适用于 submission_mode: artifact：产物提交评测完成后存储对象会被立即删除，无法重测，只能让做题人重新提交。详见Web 题目编辑器 § 产物提交题。

测试数据可见性策略

• LMCC 官方标准：测试数据分为可见与不可见。
• Neuro OJ 建议：全部正式评分数据使用不可见测试数据；可见数据仅用于题面示例/调试。
• 样例：可见、建议不计分（骨架默认计分，见 test-data.md）、可展示调试信息。
• 隐藏用例：不可见、正式计分、不展示输入/期望/细节。
• 测试点明细：可见用例可在 details.cases 中展示输入/期望/实际输出；隐藏用例只展示 ID、状态、耗时与内存等非敏感元数据，不展示输入/期望/实际输出（见测试数据与样例规范的「测试点结果详情」）。
• evaluator 必须保证不泄露不可见测试数据：不可见用例的输入、期望答案、评分细节不得出现在用户可见结果中。