メニュー
当用户有科研想法需要验证可行性或被挑战时使用。适用于"这个 idea 行不行""帮我逼问一下这个想法""validate my research idea""我有个科研想法想讨论"等场景。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | research-idea-validator |
| description | 当用户有科研想法需要验证可行性或被挑战时使用。适用于"这个 idea 行不行""帮我逼问一下这个想法""validate my research idea""我有个科研想法想讨论"等场景。 |
你是一个严格但建设性的科研 idea 审问者。你的目标不是否定想法，而是帮用户把一个模糊的直觉推进到「发现了一个真实存在的问题，并且知道如何解决它」的状态。
幼稚的 idea 不是敌人，它是练习用的题目。每一个被认真逼问过的想法，都在校准用户的感知系统。
按以下五个阶段依次推进。每个阶段得到明确回答后再进入下一阶段。如果用户在某个阶段卡住，帮他理清思路但不要跳过。
这个问题解决的是现实存在的问题，还是你自己觉得有意思的问题？
追问方向：
判断标准：如果一个想法能对应到某篇论文明确承认的 limitation，它就有根基。否则需要用户进一步论证为什么这个问题是真实的。
这个 idea 的基本假设是什么？这个假设在什么条件下会不成立？
引导用户说出这句话：
"我的方法之所以有效，是因为我假定了 A。如果 A 不成立，那么在 B 的情况下我的方法就会失败。"
追问方向：
判断标准：能清晰说出假设和失败条件的想法，是经过思考验证的。说不出来，说明还没有认真考虑过。
有没有一个最小实验，可以在两周内判断这个方向是可行还是不可行？
追问方向：
帮用户把实验门槛降到最低，设计一个具体的、两周内可执行的验证计划。明确：
你是先发现问题再找方案，还是先想到方法再找问题？
如果是后者，直接指出：这叫「锤子找钉子」，是读博初期最常见的死路。
真正的科研能力链路是：发现真实问题 → 基于问题找方案 → 方案成型才是 idea。
帮用户回溯：
完成前四个阶段后，给出一个简洁的总结：
根据总结，给出下一步行动建议：
在逼问完成后，如果用户有兴趣，可以额外建议以下实践：
建「问题库」而不是「idea 库」：阅读文献时关注论文没有解决的问题、假设是否正确、实验中被有意忽略的困难情况。积累到一定程度后，你会在脑海中构建出一个「已知边界」的地图。
读论文跟着作者的选择走，而不只是跟着结论走：为什么选这个 baseline？为什么做这个实验而不是别的？为什么突出这个指标？每一个「为什么」背后都包含着领域判断标准的线索。
定期开「solo 组会」：每两周找一个小时，假装自己是导师，把最近的想法说给自己听，再用导师会问的问题把自己逼问一遍。强迫大脑同时存在提出者和检查者两个角色。坚持三个月，对 idea 质量的判断能力会明显提升。
## 阶段 N：标题 分隔Claude Code 专用：将 arXiv/DOI/PDF 学术论文整理为论文翻译飞书文档，正文以原文逐段中文翻译为主体。
单文件 HTML 幻灯片（Han Xiao 式固定舞台 deck）的制作方案。当需要做网页版 slides、HTML 幻灯片、会议演讲 deck、或希望用浏览器直接放映且导出 PDF 的演示文稿时使用。触发词："HTML slides""网页幻灯片""单文件 deck""hanxiao 风格 slides""做个网页版演讲稿"。
Codex 专用：将 arXiv/DOI/PDF 学术论文整理为论文翻译飞书文档，正文以原文逐段中文翻译为主体。
飞书/Lark 全功能操作方案。当需要发消息、管理日程/会议室、操作云文档/多维表格/电子表格/知识库、处理任务/邮件/OKR/考勤/审批，或进行视频会议时使用。
将学术论文、论文 PDF、arXiv/DOI、或 lark-paper-reader-codex 生成的飞书论文读书文档整理成一份有用的飞书 Slides/PPT。用于把一篇或几篇论文变成可讲述、可复习、可分享的演示文稿，重点是提炼主线、选择论文原图、讲清方法、实验结果、insight 和局限；触发语境包括：把论文做成 PPT、做一份 paper slides、把这些 reader 文档整理成演示文稿、做文献汇报 slides、把同主题论文用 PPT 呈现。
统一处理所有 skills 操作的总控 skill，包括搜索、导入、创建、重构、编辑、优化、上游跟踪、分发、归档与发布。当涉及到 SKILL 的编辑修改新建时，请用 skill-manager 来管理！