idea-evaluator

创意评估器

概述

此技能从顶级会议审稿人和资深导师的综合视角评估初步研究创意。它根据创意生成指南中的五个改进维度（更高、更快、更强、更便宜、更广泛）为创意评分，将创意的生命周期与用户的实际能力和每周可投入的时间相匹配，探查创意是否具有范式转变潜力，指出致命缺陷，并给出以下三种结论之一：强烈接收、修改后接收，或拒绝并转向其他方向。

目标是在学生投入数月时间之前淘汰薄弱创意，并在开始写作之前，将有潜力但尚不成熟的创意打磨得更完善。

何时使用此技能

• 用户有一个创意草案，并询问是否值得推进。
• 用户要求检查新颖性、评估可行性或进行评分。
• 用户确定论文范围或开始实现之前。
• 用户正在比较两个或三个候选创意，需要有结构的权衡分析。
• 用户怀疑范围不断扩大，希望获得外部评估。
• 用户提到“评估这个创意”“给这个创意评分”“评估可行性”或“这是不是一个好的研究方向”。

何时不要使用此技能

• 用户已经实现了创意，正在撰写论文。请改用 intro-drafter、tech-paper-template 或 benchmark-paper-template（单独的插件）。
• 用户明确要求从零开始头脑风暴新创意。请直接对话；有关颠覆式创新的操作指南，请参阅手册第 2.3 节。
• 用户要求评审现有稿件。请使用 pre-submission-reviewer。
• 用户专门要求评估基准方面的贡献。请在定向模式下使用 benchmark-paper-template（单独的插件）。

核心流程

步骤 1：第一印象与论文类型定位

阅读用户对创意的描述。用一段话说明该创意属于新颖问题、新颖方法还是新场景。能否用一句话讲清楚这个故事？如果无法写出这句话，说明创意本身可能还不够清晰，暂时无法评估；请用户重新表述。

在转述时，按研究方法而非院系名称对研究范式分类：实验、基准测试、消融实验或模型架构属于 STEM（继续使用以下五个维度和致命缺陷进行评估）；文本分析、档案研究或概念论证属于人文学科；调查、访谈、统计或实地研究属于实证社会科学；回归、IV、DID、RDD 或面板数据属于金融或经济学；成文法、判例或法理属于法律。

参见：references/domain-evaluation-frameworks.md，其中列出了非 STEM 范式所使用的替代五维框架和致命缺陷替代项。如果范式不明确，只问一个问题：“核心方法是实验、调查、文本分析还是理论推导？”

步骤 2：致命缺陷审查（前置关卡）

参见：references/fatal-flaws.md，了解十项标准致命缺陷，每项都附有检测规则和防御策略。

在评分步骤之前运行致命缺陷审查，而不是之后。最多识别两项致命缺陷。对于每项缺陷，说明缺陷内容、引用检测规则，并建议具体的防御措施。

只要环境具备文献检索能力，就必须通过实际检索来评估新颖性缺陷（F1）（学术搜索工具、针对学术索引的网络搜索，或访问公共 API 的 shell）。从构想中提取两到三个关键词组（核心方法加领域；机制加任务；技术加基准），进行搜索，并列出最接近的三到五篇已发表作品，包括标题、作者和年份。对于每篇作品，说明实际不同之处所在的维度：作用对象、机制、输入粒度或问题设定。标题相似本身不能证明重复；只有找不到任何一个不同维度，才能认定为重复。检索结果只支持元数据层面的判断（谁做了什么、在哪里做）；绝不要引用搜索摘要中的数字或方法细节。“未找到”不能证明新颖性：应报告“使用这些关键词未检索到直接重叠的作品”。如果没有检索能力，则将新颖性判断标记为“未经核实；需要进行文献检查”。

被数据否定的核心机制自动判为 CRITICAL。 如果用户自己提供的数据或附件已经表明，基线或简单对照与核心机制表现持平或超过它，则将结论锁定为 Reject and Pivot；不要写防御措施，也不要编造乐观的阈值。有关“被数据否定”与“尚未测试”的确切界定，请参见 references/fatal-flaws.md 的“被数据否定”部分。

短路规则。 如果任何致命缺陷在严重性分类中被标记为 CRITICAL（单独即可导致拒绝，且无法在生命周期内修复），则在此处停止并直接给出结论：

• Verdict：Reject and Pivot。
• 仅输出第 1（第一印象）、第 2（致命缺陷及 CRITICAL 缺陷）和第 7 节（基于缺陷的理由给出结论）。
• 不要进行五维评分、范式转变探查、可行性检查或诚信审查。这些内容对于已被拒绝的构想只会是装饰。

如果没有发现 CRITICAL 缺陷，则继续执行步骤 3。

步骤 3：生命周期与能力匹配

参见：references/lifecycle-capability-matching.md，了解六类生命周期矩阵、能力自评标准和不匹配的补救策略。

将构想归入以下六类之一：应用、基础理论、跨学科、前沿探索、数据密集型、创新技术。根据用户声明的能力进行匹配（每周有效工作时长、技能深度、理论与应用方面的优势）。如果生命周期短于用户实际可投入的执行周期，则输出不匹配标记。

第 4 步：五维评分

各维度的切入策略、评分标准和实例请参阅：references/five-dimensions.md。

从以下各维度为想法评分：

• 更高效：提升效果和准确性。
• 更快：提高效率并降低成本。
• 更强健：增强稳健性、抗噪能力和泛化能力。
• 更便宜：降低数据、标注或解决方案成本。
• 更广泛：实现跨领域迁移或统一。

每项按 1–10 分评分，并依据用户陈述的贡献给出明确证据。指出该想法潜力最高的两到三个维度，并建议在论文中重点强调这些维度。

评分原则：每个维度都从 5 分起步，并说明分数变动的依据。有两类理由可以提高分数，且两者都算数：用户报告的实测结果（引用原话），或站得住脚的机制论证（将评分标注为“基于机制，尚未由数据验证”）。扎实但未经测试的机制，可以在加上该标注和明确的验证实验后获得 8 分或 9 分；不要系统性地限制未经测试的想法的评分。若某个维度既没有数据，也没有机制，则维持 5 分，并注明“未提供依据”。注意归因：如果显著增益可能来自外围因素（路由、后处理、更强的基础模型、有利的样本），则在消融实验隔离出核心机制前，应限制该维度的评分。评分参考文档的最后两节对这两条规则均有详细说明。

对于非 STEM 范式，请改用 references/domain-evaluation-frameworks.md 中的替代维度，并遵循相同的评分原则。

第 5 步：范式转变探查

四项探查原则（第一性原理、房间里的大象、技术周期、海明规则）以及需要深入探索颠覆式创新时对手册第 2.3 节的交叉引用，请参阅：references/paradigm-shift-probe.md。

用以下四个问题检验该想法：

1. 它是否挑战了该领域视为理所当然的隐含假设？
2. 它是否解决了一个人人都看得到、却没人愿意触及的棘手问题？
3. 它是否顺应了技术周期的转变（例如，LLM 让此前不切实际的方法变得可行）？
4. 如果这个问题自行得到解决，该领域是否会发生实质性变化？（海明规则）

如果有两项或更多回答为“是”，说明该想法具有颠覆潜力。请注明这一点，并建议阅读手册第 2.3 节，以深入思考颠覆式创新的各个维度。

第 6 步：可行性检查

根据用户陈述的资源（硬件、数据访问权限、团队规模、工程技能、时间安排）评估：

• 计算资源风险：实验能否在所述硬件上运行？
• 数据风险：所需数据是否可获取，还是需要昂贵的标注或私有来源？
• 工程风险：实现是否符合用户的技能栈？
• 时间风险：端到端预计耗时（编码、实验、写作、修订）是否符合该想法的生命周期？

如果任何风险较高，请明确指出并提出缓解建议。

第 7 步：完整性门槛

在给出结论前，执行下方“完整性门槛”部分中的检查。

第 8 步：最终结论

给出以下三种结论之一：

• 强烈接收：立即执行。两个或更多维度达到 8 分以上，没有致命缺陷，能力匹配为绿色，且符合生命周期要求。
• 修改后接收：开始前根据建议调整范围。部分维度较弱、存在可修复的缺陷，或生命周期不匹配但可以缩短。
• 拒绝并转向：不要推进此版本。已有基准或方法占据明显优势、能力不匹配且无法弥补，或存在两个以上致命缺陷。

如果高分基于机制而非数据，请将结论限定为“值得推进，但有待验证实验”，并在前三项行动中注明该实验。

按下方“输出格式”给出评估结果。

完整性关卡

每条要点都标注了可执行性类别。[inspection] 表示 LLM 可以仅根据生成的输出核验该要点。 [attestation] 表示 LLM 声明已完成检查，但 用户仍有责任进行核验。[user-attest] 表示 这是技能无法确认的用户侧规则。

返回评审结论之前：

1. [inspection] 每个维度的评分都引用用户所述贡献中的具体证据；不得凭“感觉”打分。
2. [inspection] 可行性判断须依据用户所述资源，而非泛泛的假设。
3. [inspection] 新颖性判断须引用具体的既有研究，否则标注为“未经核实；需进行文献检索”。
4. [inspection] 致命缺陷须具体且可采取行动；“这可能行不通”不能算作缺陷说明。
5. [inspection] 评审结论须与评分一致：Strong Accept 至少需要两个维度得分达到 8 分及以上，且没有 CRITICAL 缺陷。
6. [inspection] 范式转变的主张须指出哪个探查问题得到了肯定回答。
7. [attestation] 生命周期预测须基于该领域近期的发展速度进行推理；用户在据此采取行动前，应结合自己对该子领域的了解进行合理性检查。

若任何 [inspection] 检查未通过，须降低评审结论等级，并将对应的输出章节标记为“需要用户关注”。对于 [attestation] 要点，技能须说明已执行检查，并由用户确认结果。

静默执行此关卡。不要输出逐项关卡通过或未通过的报告；未通过的情况须作为具体发现出现在受影响的输出章节中，最终评估不得包含内部检查流程。

输出格式

1. 初步印象

• 论文类型：<新问题、新方法或新场景>
• 一句话概述：<...>

2. 致命缺陷审查（前置关卡）

#	缺陷	严重程度	应对方案
1	...	CRITICAL 或 MAJOR	...

如果存在任何 CRITICAL 缺陷，跳过第 3 至 6 节，转到第 7 节，给出 Reject and Pivot 结论。

3. 生命周期与能力匹配

方面	用户输入	评估
想法类别	...	...
生命周期	... 个月	...
每周有效工时	...	...
匹配度	...	Green、Yellow 或 Red

4. 五维雷达

维度	得分（1-10）	依据	提升建议
更高	...	...	...
更快	...	...	...
更强	...	...	...
更便宜	...	...	...
更广	...	...	...

5. 范式转变探查

探查问题	是或否	理由
第一性原理	...	...
房间里的大象	...	...
技术周期	...	...
汉明法则	...	...

颠覆潜力：<无、可能、强>。

6. 可行性

风险	等级	缓解措施
算力	...	...
数据	...	...
工程	...	...
时间线	...	...

7. 评审结论

<Strong Accept、Accept with Revisions 或 Reject and Pivot> （若高分基于机制，请附加“值得推进，但须先完成验证实验”）

首先采取的三项行动：

1. ...
2. ...
3. ...