关于 idea-quality
idea-quality 是评估研究构想的技能,适用于需要在实验前审视研究想法的研究者。它从构想文本出发,按问题价值、方法质量和问题契合度评分,并要求以具体文本证据说明判断。
主要功能
- 01从构想文本评估研究想法
- 02按三个维度分别评分
- 03引用原文证据支撑评分
- 04支持两项构想的比较
- 05区分绝对评分与相对判断
适用场景
- 01在实验前审视研究构想
- 02识别问题与方法之间的错位
- 03比较两项研究构想的优劣
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ microsoft/ researchstudio --skill idea-quality安装后在 Claude Code 中输入/idea-quality确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
evals/evals.jsonevals/sample_ideas/mismatch_gate.mdstrong_grpo.mdweak_temperature.md详细介绍
创意质量
在构想阶段评判一项研究创意的强弱——此时还没有任何实验——并给出质量评分及评审者认可的理由。此技能独立运作:根据下方三个维度的第一性原理进行评判。它不查阅任何外部语料库、数据集或其他技能,因此其判断仅凭创意文本即可复现。
输入:一个创意 Markdown 文件
创意是一份包含三个部分的 .md 文件。阅读文件,然后将每个部分对应到其作用:
# Title
<≤ ~15 words: the idea's handle>
## Motivation
<the bottleneck / gap the idea attacks, why it matters, and why it is still open>
## Method
<the proposed contribution as concrete numbered steps>
- 标题 → 标识名称。
- 动机 → 对应维度 A(这个问题是否值得研究),并为维度 C提供“问题”部分。
- 方法 → 对应维度 B(方法是否出色),并为维度 C提供“方法”部分。
如果某个部分缺失或内容单薄,请根据其余内容推断最合理的解读,并在报告中说明所作的假设——不要停下来要求澄清。如果用户传入两个文件(或一个包含两个创意的文件)并要求比较,请采用成对比较流程。
评判范围:评判什么,以及刻意不评判什么
- 不存在实验。 每个维度都是基于推理的判断——类似评审者在看到结果之前,仅根据摘要作出的判断。绝不要捏造或假设实验结果来评分。 如果某项主张的真实性需要实验才能验证,就评判其论证的可信度,而不是想象中的结果。
- 不检查已有研究。 “是否有人已经做过这件事?”属于独立的文献重复性核查任务。要评判的是创意本身是否出色(确有研究空白、方法有深度、合理且切题),而不是是否存在近似重复的研究。评判贡献本身的抱负程度,而非其相对于文献检索结果的新颖性。
高分意味着创意本身出色;这并不代表它一定会被录用,因为录用还取决于此技能无法评估的执行情况。
三个维度
只评这三个维度。每个维度都满足以下条件:(a)仅凭想法本身即可评估,无需实验;(b)能够区分强弱;(c)不是文笔润色程度的替代指标。
A — 问题定位质量。 动机部分指出的缺口是否真实、重要、不显而易见且确实尚未解决,还是肤浅、已有解决方案,或是为了方便而挑选的简单目标?
- 强:这个缺口很重要,而且该领域尚未弥补;指出这一点本身就有洞见。
- 弱:问题显而易见/已有解决方案,或是为了能够廉价地“解决”而挑选的容易目标。
- *存在这一维度的原因:*作者自行选择瓶颈时,显得成功的最廉价方式就是挑选一个容易目标。这个维度可以防止“容易的瓶颈加微不足道的修复”获得高分。
B — 方法质量。 提出的方法本身是否出色?将其评为一个数字,但在理由中必须分解为三个有明确名称的子项,因为单一分数会掩盖其中哪一项较弱:
- 深度 — 是否提出了真正的新机制/构造/重新界定问题的方式,而非渐进式改动(新调度策略、多一个损失项或一个超参数)。
- 可靠性 — “为什么它应该有效”的论证在内部逻辑上是否站得住脚?假设是否有依据,还是存在含糊其辞/未明说的条件/逻辑漏洞?评估方法自身的逻辑,无论它针对什么问题——契合度属于维度 C。
- 可行性 — 原则上是否能够实现,还是需要现实中不太可能存在的资源/预言机/数据?*这里的意思是“能够实现”,而不是“能取得好结果”——不要臆造结果。*这是权重最轻的子项;让深度主导维度 B,并将可行性视为打破平局的因素,而不是同等重要的第三项。
- *注意:*维度 B 关注的是方法本身的影响幅度与严谨性,并从内在价值出发进行评判——不考虑文献中是否已有重复工作(这是单独的先前技术检索任务)。
C — 问题契合度。 方法是否真正针对动机中指出的具体缺口,并有望解决它,而非瞄准相邻、更容易或不同的问题?
- 强:方法的机制明显针对所指出的缺口;如果方法奏效,该缺口就能得到弥补。
- 弱:方法针对的问题与所声称的问题不同,或只是声称方法与该缺口相关,却未加以说明。
- *与维度 B 中的可靠性的界限:*维度 B 的可靠性问的是“方法自身的逻辑是否连贯?”,维度 C 问的是“这种逻辑与这个问题是否相关?”方法可能内部逻辑严谨(维度 B 高),却解决了错误的问题(维度 C 低);也可能切中目标(维度 C 高),但论证含糊(维度 B 低)。两者务必分开评判。
评分:双轨制
始终进行绝对评分。比较两个想法时,还要进行成对评分——并将成对评分视为可信信号,因为相对判断的噪声远低于绝对分数(绝对分数往往集中在 3/5 左右)。绝对评分的 0–100 分只是易读的辅助参考,不是经过校准的真值。
每个维度均按1–5 分评分(整数)。评分等级没有固定描述——相反,每个分数都必须引用想法中的具体措辞/要素作为依据。没有引用证据的分数不允许;让评分保持诚实的不是评分标准表,而是证据要求。评判实质内容,而非长度或表达流畅度——简短精炼的想法可以得 5 分;篇幅很长、润色精良的想法也可能只得 2 分。
赛道 1——绝对评分(针对单个想法)
总分(各维度权重相同,每项从 1→0、5→满分):
overall = round(100 * (A + B + C - 3) / 12)
结论档位:strong ≥ 67 · borderline 34–66 · weak < 34。
A/C 门槛(优先于档位)。 A 和 C 几乎是必要条件,B 则不是——因此:
- 如果 A ≤ 2 或 C ≤ 2,无论总分多少,结论都不能是
strong(最多为borderline)。原因:在琐碎问题上采用出色的方法(A 低),或面对重大问题却采用无法解决它的方法(C 低),都算不上出色的想法——否则等权平均分会造成误导。用一行说明上限及原因。 - 仅 B 较低不会触发封顶:能切实解决重大问题的简单方法(反直觉的极简主义)仍可能很出色。
赛道 2——两两比较(比较两个想法)
对每个维度,用一行说明哪个想法更强(Idea 1 / Idea 2 / 平局)及原因;对于 B 维度,分别注明各子项判断(深度 / 合理性 / 可行性)中哪一方胜出,避免丢失诊断信息。然后综合判断总体胜者——但问题契合度(C)几乎是必要条件:如果某个想法在 C 上明显落后,通常会因此输掉总体比较,即使它在 A 和 B 上胜出也一样,因为不适合其所针对问题的方法并不是更好的想法。独立评判各个维度;不要让一个维度影响其他维度。
盲评,不看来源。 如果将两个想法作为评估的一部分进行比较,切勿考虑哪个系统 / 模型产出了哪个想法——来源不能证明质量。(为了公平,两个输入必须采用相同的 Title/Motivation/Method 格式;如果格式不一致,请指出。)
输出格式
单个想法:
## Idea Review — <title>
**Decomposition**
- Problem / gap (from Motivation): …
- Method (the proposed move): …
- Why it should work: …
(assumptions inferred, if any: …)
**Axis scores**
| Axis | Score (1–5) | Evidence (quoted from the idea) | Reason |
|------|-------------|----------------------------------|--------|
| A — Problem position | | | |
| B — Method quality | | | depth: … · soundness: … · feasibility: … |
| C — Problem-fit | | | |
**Overall: NN / 100 · Verdict: strong | borderline | weak**
<if the A/C gate fired: one line naming the cap and why>
**Strongest point:** <one sentence>
**Most fixable weakness:** <one sentence, phrased as what would raise the score>
比较时,对每个想法分别输出绝对评分区块,然后输出:
## Pairwise verdict (Idea 1 vs Idea 2)
| Axis | Stronger | Why (one line) |
|------|----------|----------------|
| A — Problem position | 1 / 2 / tie | |
| B — Method quality | 1 / 2 / tie | depth / soundness / feasibility: who wins each |
| C — Problem-fit | 1 / 2 / tie | |
**Overall winner: Idea 1 | Idea 2 | tie** — <one–two sentence rationale; if a decisive C loss drove it, say so>
反偏见规则(及其重要性)
- 每项评分都要引用证据。 单独给出数字只是凭感觉,而感觉无法区分好想法与差想法;将每项评分与具体论点挂钩,才能让判断可审计、比较公平。
- 评判实质,而非篇幅 / 流畅度 / 格式。 自信、结构良好的描述可以掩饰想法的单薄——不要因为表达而加分,尤其是在 B 的合理性评估中,因为流畅的文字最容易掩盖不成立的推理步骤。
- 停留在想法阶段。 不要臆想实验结果来为评分辩护。如果核实某项主张需要实验,就评估 论证的可信度,而不是凭空编造结果。
- 比较时盲评,不看来源。 哪个模型或系统产出了某个想法,并不能证明其质量;请忽略这一点。