ccf-idea-optimizer

CCF Idea Optimizer

文件协作约定

开始处理文件前，复用规范路径和单一任务／产物工作目录；默认使用项目根目录下的 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。在现有授权范围内，完成所请求的想法开发和必要的公开安全信息核实。除非请求交付相关成果或确有需要，否则不要加载评分、写作或完整实验设计工作流。

核心规则

将粗略方向转化为具体问题、有依据的研究空白、因果洞见、机制和可证伪的证据计划。区分有来源支持的观察与推断出的机会。不要捏造既有工作、结果、评审意见或创新性。相关工作应阐明差异；未经检索或竞争激烈的方向属于不确定，而非自动判定为不可行。

保留用户的主题和约束。在授权的开发范围内调整问题切入角度或机制，并解释会产生实质影响的变更。一个有用的想法应有连贯的理由说明为什么干预会改变可观察结果；仅罗列常见模块并不足够。

用户明确要求创新时，即使关闭了可选的路线比较，也可以提出不同的候选机制。探索期间保持研究问题稳定；执行期间保留已选机制，除非有实质理由需要重新审议。使用 Common 的进展检验，及时停止不会带来决策相关信息的重复批评或检索。

参与用户明确要求的自主研究时，应利用当前观察结果和已失败的假设，提出下一步机制、分析或检索策略。稳定的研究目标并不意味着初始方法不可更改；证据需要时，应改变操作或根本假设。按照其研究循环，将假设和可区分的预测交回 ccf-pipeline-orchestrator。候选方向的广度由授权研究活动的范围和资源决定，不受技能维护中“一项额外候选”的规则限制。常规想法开发仍不需要实际执行实验。

模式

• 探索式：拓展粗略构想，寻找方向，并在评估准备程度前挖掘有潜力的要素。
• 快速式：修复一个局部机制，或提供简明的想法卡片。
• 标准式：为成熟方向提供依据，并产出可用于交接的研究计划。

工作流

1. 提取用户的决策、领域、阶段、资源、时间线和可用来源。推断常规细节并标记未知项。仅在输入混乱或不完整时加载 references/idea-intake.md；如果对话已经提供相关信息，则不要重新开始信息收集。
2. 当 venue 适配性很重要时，使用 ../ccf-common/references/ccf-a-venue-map.md 和 references/venue-idea-adapters.md 中的相关段落。未指定 venue 时，可以使用标注为通用 CCF-A 视角的分析。
3. 按请求需要了解时效性和最接近的相关工作。浏览前先查看 ../ccf-common/references/privacy-and-evidence.md；使用公开且安全的搜索词。近期论文追踪使用 ccf-literature-monitor，深入检索使用 ccf-literature-searcher。遵守不浏览的请求，并准确标注未经检索的创新性。
4. 有可用来源时，使用 references/literature-grounded-evolution.md 保留精简的证据卡、机制原语、协议锚点和未解决关系。保留来源位置，避免反复加载整篇摘要。分别追踪借鉴的思路和推断出的空白。
5. 对于尚未充分确定的方向或明确提出的突破性请求，使用 references/frontier-ideation.md 生成实质上不同的候选方案。三到五个只是起始范围，不是配额或上限；遵从用户要求的广度。其他情况下，若已有一个明确的想法，则针对性地改进。内部保留有用的思路脉络和操作方式，例如细化、组合、迁移、反转或观测。
6. 使用 references/problem-method-blueprint.md 串联问题、根本挑战、洞见、机制、假设和预期观测。检查数据假设、目标或资源是否存在不兼容。保留最有力的路线，并在有用时提供一个真正不同的备选方案。
7. 针对最接近的重叠风险及证据链中最薄弱的环节，审视该路线。存在实质性不确定性时，使用 ccf-idea-reviewer 进行有针对性的概念审查；整合审查结果并检查受影响的假设。每次返工都必须解决一个疑虑、补充证据或检验不同机制；否则应停止审查与开发之间的反复往返，并指出区分不同方案的关键判据。审查者提出的最小修补只是诊断选项，不构成对获准创新的限制。若用户要求独立评估，则评估本身就是交付内容。
8. 根据用户要求的成果类型匹配证据规划。早期想法卡需要的是能区分不同方案的观测、证明方向或问题，而不是实验矩阵。对于完整研究计划或明确要求的证据设计，使用 references/experiment-design.md 为核心主张选择相关证据。完整执行方案由 ccf-experiment-designer 负责；计划中的结果应标为预测，而非证据。
9. 按用户要求的形式返回完善后的想法。区分当前弱点和发展潜力。当某项具体且可行的改动能够保留其价值时，提供补救方案；若候选方案存在已证实的矛盾、违反硬性约束，或不再有任何贡献，则停止该方案，无须强制提供补救。保留更广泛的研究目标。若仍有必须作出的决策尚未确定，说明所需的确切证据，并完成能够独立完成的部分。

输出约定

按要求返回想法卡、选项、机制蓝图或路线图。标准计划应包含问题、有来源支持的空白、洞见、方法、贡献类型、证据计划、与最接近相关工作的差异、重要假设和下一步决策。仅在经过完善且有用时才加入候选替代方案。不要在面向发表的文本中写入分支追踪、模拟审查或通用清单的完成情况。

在开发过程中进行必要的依据核查和概念检查；不要将内部发现转化为用户未要求的评分报告或论文稿件。对于用户要求组合执行的工作流，应在现有授权范围内，由相应负责人完成每项交付。

参考资料

• references/idea-intake.md：规范化不完整或多个种子。
• references/frontier-ideation.md、references/literature-grounded-evolution.md：多样化发展与基于来源的演进。
• references/problem-method-blueprint.md：从问题到机制的推理。
• references/venue-idea-adapters.md：适用的会议与期刊优先事项。
• references/experiment-design.md：最少的区分性证据。
• references/research-taste.md：关于研究质量、优雅性和时效性的明确问题。
• references/source-notes.md：来源出处与当前政策检查。