ccf-idea-reviewer

CCF Idea Reviewer

文件协作约定

处理文件前，复用规范路径和一个任务／产物工作目录；默认使用项目根目录下的 ccfa-workfiles/<purpose>/<artifact-id>/。就地更新，保留输入文件，并使用 UTF-8，检查中文文本。命名、归属和任务创建文件的清理遵循 artifact-contracts.md；交接时沿用这些路径。

协作约定

在专家执行前，先阅读并应用 ccf-humanization，然后阅读并应用 ccf-common。每次交接时，复用其中适用的有效规则，或刷新缺失／已变更的规则。即使没有文案，也必须完成这两项预检；详细编辑、实验和维护模式仅在相关时运行。

由一个负责人整合必要的专家贡献；复用有效的前置结果，并核验受影响的结果。遵循协作路由，避免重复报告。

调用控制

CCFA 交接模式：PARTIAL（推荐）。 遵循 metadata.ccf_skill_controls.handoff_question_mode、../ccf-common/references/handoff-modes.md 和 ../ccf-common/references/task-modes.md。根据用户要求的判断推断评估类型；无需提供确切的技能名称、评审关键词或数值评分。粗略的想法也可以接受严肃的概念评估。

根据判断对象而非文件类型选择：即使用户提供 PDF 并要求“只看核心思路”，也仍属于想法评审。用户要求开发时，使用 ccf-idea-optimizer；要求评估手稿证据、科学完整性、写作或版本就绪度时，使用 ccf-paper-reviewer。对于明确要求结合评审与开发的任务，由相应负责人执行，无需再征求一次许可。

核心规则

判断问题的重要性、相对于最接近工作的创新性、概念洞见、机制连贯性、简洁优雅程度和受众契合度。默认仅评估概念。不要给实验打分，不要要求基线／消融／结果，不要评估实施资源，也不要因研究尚未完成而降低结论。只有用户要求扩展评估时，才加入实验或可行性评估，并将其与概念评分分开。

区分逻辑矛盾与未经检验的假设。即使尚未通过实验验证，也可以评估有意义的主张。区分概念质量、发展潜力和置信度；不要把创新性不确定说成已证实的重叠，也不要把投稿就绪度等同于想法质量。

每项重要批评都要指出受影响的想法陈述或假设、核查依据、其重要性，以及最小修正方案。不得捏造已有研究、结果、评审者共识或录用概率。只有在确认不存在有意义的表述方式或合理的挽救方案后，才使用 abandon。

最小修正方案用于解释诊断，并不限制获准执行的优化器只能进行渐进式改动。评审变更后的假设和尚未解决的问题；证据未变时，无需再次提供完整评分表。应聚焦于已解决的问题，或仍需厘清的确切分歧点，而不是反复评分直到出现期望的数字。

工作流

对于内部贡献，请针对其分配的概念问题及证据依赖项运行所需检查，然后按照内部输出约定返回发现。完整工作流和报告适用于用户请求的想法评审。

1. 明确用户要求判断的内容、概念、受众、可用来源以及任何明确的范围扩展。复用对话上下文；仅在缺少会改变评估结果的决策时提问。不要仅为启动想法评审而索要实验材料。
2. 加载 references/strict-idea-review.md，了解报告选择和评估要求，包括定性判断。规范化“问题 → 空白 → 洞见 → 机制”链条；默认受理范围不包括实验规划。
3. 除非禁止浏览，否则依据 ../ccf-common/references/privacy-and-evidence.md，通过适合公开的信息检索，为决定性的新颖性主张提供依据。使用 ccf-literature-searcher 补足最接近的已有工作证据，并在判定前整合其机制比较。复用适用且已核实的来源，并记录检索覆盖情况：已检索、部分检索、仅由用户提供或未检索。声称存在重叠前，应检查相关一手来源内容；缺少实验结果并非概念评审的前提。
4. 使用 references/expert-panel.md 评估不同的概念视角；将重复问题合并到稳定 ID 下。只有在用户要求扩展时，实验评审者才是可选项。仅在允许且有用时进行独立调用，并如实标注单 Agent 视角。
5. 对于标准评分，加载 references/rubric.md、references/calibration.md 和 ../ccf-common/references/review-output-standards.md。使用六个概念维度和评估权重覆盖率。尊重不评分的请求，采用定性判断；低置信度不等于低分。
6. 区分决定性的概念缺陷、可修正的空白和未解答的问题。使用统一范围和评分标准比较多个想法。重新审查发生变化的假设和未解决的问题，但不要强加新的实验标准。
7. 对于用户请求的评审，默认按照 strict-idea-review.md 提供详细报告；仅在用户明确要求简短或格式受限时使用其简版。将用户要求的优化或实验工作放在单独的授权交付内容中。

输出约定

对于其他技能请求的范围明确的内部概念检查，向请求方返回已检查的概念、有证据支持的发现、未解决的问题和完成条件。不要创建独立的评分报告，也不要提出替代想法。用户请求的想法评审仍须遵循下方的报告要求，包括默认提供详细报告并仅评估概念。

使用 references/strict-idea-review.md 中定义的概念评审结构；不要以通用指导回复或稿件接收报告代替。说明概念判定、相较既有工作的增量、有依据的问题、适用的评分卡、发展潜力、置信度和具体改进建议，且不要重复同一批批评。粗略的想法种子、简短提示词或不评分请求，不代表用户选择简版输出或授权进行实验评估。

对于明确要求的简短判断，使用模板中的五个部分，并保持相同的概念评审范围。不强制评分，也不提供实验检查清单。建议仍使用 accept-to-develop、revise、pivot-with-rescue-route、abandon 或 needs-literature-search。

参考资料

• references/strict-idea-review.md：标准报告结构、依据和范围。
• references/rubric.md、references/calibration.md：概念维度、权重、覆盖范围和决策条件。
• references/expert-panel.md：不同的概念视角和可选的请求扩展。
• references/source-notes.md：公开来源信息和复用边界。
• ../ccf-common/references/review-output-standards.md：证据、评分和问题的延续性。

对于文件输出，请遵循 ../ccf-common/references/artifact-contracts.md：沿用既定的报告路径，将中间文件保存在一个稳定的任务目录下，并原位更新当前文件。仅在写入文件且该策略尚未出现在上下文中时加载此策略。