一步步设计
先确认目标值得预测
虚构任务是预测问题单是否需要本周维护者关注。标签来自独立的维护记录，输入只允许创建时可见的描述；关闭后的处理结果不能进入特征。若规则能直接确定优先级，先使用规则，不为“用 AI”制造预测任务。
把语义问题变成可解释特征
例如 Noul 问是否存在可复现步骤，Score 按档位描述影响范围。保存 feature_id、问题、档位、模型版与每行结果；Noul 数值不是“信息充分度分数”的通用替代。缺失调用保留 missing 标志，不默认作0。
按实体或时间切分，避免近重复泄漏
同一问题单的更新、复制标题和重复报告应放同一分组。按任务选择时间切分或组切分；用训练集拟合，用验证集选问题与参数，最终测试集保留到结尾。问题提议者也不能查看测试标签或测试错误来改特征。
建立简单基线再迭代
比较固定多数类、关键词规则或基础文本方法，再比较新增语义特征。每轮固定预算、数据和测量指标；由训练或验证错误生成下一轮候选问题，并记录删留原因。新增十个相似问题不一定增加信息，还可能重复编码同一偏差。
做消融并报告费用与适用范围
删除某特征后复测其贡献，看改善是否来自数据泄漏或特定项目。标签不平衡时除总体准确率外记录各类表现、漏掉重要单的比例和人工负担。最终只在保留测试集测一次报告，明确样本来源、时间、问题版本与每条特征成本。
完整走查 · 本站虚构样本
| 观察到什么 | 如何判断 | 代码怎么处理 |
|---|---|---|
| 特征使用“已被维护者标为重要” | 可能包含目标或后验信息 | 从创建时输入中删除 |
| 同一问题单不同更新进入不同集合 | 近重复泄漏 | 按问题单分组切分 |
| 新增问题改善验证结果 | 尚未证明测试泛化 | 冻结方案后测保留集 |
可复制的设计草案
以下为本站原创示例。JSON 展示请求或输入形状；Python 仅计算虚构分数，不调用 API。真实接入仍需核对官方接口及任务策略。
# Feature schema for an invented issue dataset.
{
"group_key": "issue_id",
"prediction_time": "issue_created_at",
"features": ["has_reproduction_steps", "impact_level"],
"missing_policy": "keep_missing_indicator",
"forbidden_inputs": ["future_maintainer_label", "closed_at"],
"split_roles": ["train", "validation", "untouched_test"]
}容易踩的坑
- 用测试集错误指导下一轮特征。
- 把 missing 当不存在。
- 只展示提升，省略基线与费用。
TRY / THINK / COMPARE
先想一想，再看解析
最终测试表现不佳，能看错例重写特征再继续用同一测试集宣布提升吗？
展开解析
可以诊断，但该集合不再是未使用的最终测试。后续实验需明确它已参与开发，并准备新的独立测试或预先定义验证流程。
交付前检查
- 特征只读取预测时可用信息。
- 实体近重复和时间泄漏已处理。
- 有基线、版本、预算和消融。
- 最终测试未指导问题设计。
常见问题
自动提问就算自动研究完成了吗？
不是。数据、监督训练、验证与预算控制组成整个实验；本页不执行训练循环。
数值特征能迁移到所有项目吗？
未证明。跨项目或语言使用前重新验证标签与分布。
资料与延伸阅读
参考官方架构模式与 Datawhale 实战主题，本站独立编写讲解、案例与练习。示例为教学设计，未调用 API，不代表性能测试。