Research Plan

核心功能

本 Skill 通过系统化调研顶尖期刊/会议论文，为用户制定个性化、可落地的科研分析策略。

核心价值

• 证据驱动：基于顶级期刊论文的方法学，而非凭空设计
• 系统性调研：自动化的文献检索、筛选、下载流程
• 深度学习：从 PDF 中提取分析方法和技术细节
• 可落地性：输出清晰的目标/步骤，可直接执行

使用场景

• 制定实验设计方案
• 规划数据分析流程
• 设计技术路线图
• 确定统计方法选择
• 制定可视化策略

输入规范

必需输入

• 需求描述：清晰描述要解决的问题和目标

可选输入

• 工作目录：默认当前目录
• 文献年份范围：默认近 5 年
• 目标期刊/会议：指定特定来源
• 语言偏好：默认英文
• 最大文献数：默认 30 篇

流程

输入

按用户请求和配置文件提供必要输入；缺失信息应明确列出并停止依赖该输入的步骤。

执行步骤

• 因本 skill 设计缺陷导致的 bug，先用 bensz-collect-bugs 规范记录到 ~/.bensz-skills/bugs/，不要直接修改用户本地已安装的 skill 源码；若有 workaround，先记 bug，再继续完成任务。
• 只有用户明确要求“report bensz skills bugs”等公开上报时，才用本地 gh 上传新增 bug 到 huangwb8/bensz-bugs；不要 pull / clone 整个仓库。

基于文献调研的科研分析策略规划助手

旧名 make-research-plan 仅作为 prompt 兼容别名保留；历史 .make-research-plan/ 仅作显式兼容读取、迁移或清理，新运行统一使用任务级工作区。

阶段 0：初始化

输入：

• 用户需求描述
• 工作目录路径（可选，默认当前目录）

操作：

1. 验证工作目录存在且可写
2. 创建任务级隐藏工作目录 .bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/research-plan/
3. 明确告知用户创建的目录位置和用途

输出：

• .bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/research-plan/ 目录结构

目录结构：

.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/research-plan/
├── input/papers/        # 下载的 PDF 文献
├── input/metadata/      # 调研元数据
│   ├── theme.json      # 主题和关键词
│   └── search_history.json # 检索历史
├── output/extracted/    # 提取的文献信息
│   └── papers_info.json # 论文结构化信息
├── output/analysis-framework.md # 分析框架总结
├── output/plan.md             # 任务内草稿
└── log/                       # 命令、验证与错误日志

阶段 1：主题提取与文献调研

步骤 1.1：主题提取

目标： 从用户需求中结构化提取研究主题和关键词

方法：

• 分析用户需求文本
• 识别核心研究领域
• 提取关键概念术语
• 生成多个相关主题（如适用）
• 为每个主题生成 3-5 个关键词

输出： metadata/theme.json

{
  "primary_topic": {
    "name": "主题名称",
    "description": "主题描述",
    "keywords": ["关键词1", "关键词2", "关键词3"]
  },
  "secondary_topics": [
    {
      "name": "相关主题1",
      "keywords": ["关键词1", "关键词2"]
    }
  ],
  "extracted_at": "2026-01-19T09:30:00Z"
}

步骤 1.2：文献检索

检索策略：

1. 多源检索：

   • PubMed（生物医学）
   • Google Scholar（综合）
   • IEEE Xplore（工程技术）
   • arXiv（预印本）
   • Semantic Scholar（AI 驱动）

2. 检索式构建：

   • 主主题关键词 AND 分析方法相关词
   • 优先检索近 5 年文献
   • 限定高影响因子期刊/顶级会议

3. 质量过滤：

   • 优先 peer-reviewed 文章
   • 排除非英文文献（除非用户指定）
   • 优先高引用论文

输出： metadata/search_history.json

{
  "searches": [
    {
      "topic": "主题名称",
      "query": "检索式",
      "source": "数据源",
      "results_count": 150,
      "timestamp": "2026-01-19T09:35:00Z"
    }
  ]
}

步骤 1.3：文献筛选与评分

AI 逐篇评估：

1. 语义相关性评分（1-10 分）

   • 标题匹配度
   • 摘要相关性
   • 关键词重叠

2. 子主题分组：

   • 方法学论文
   • 应用案例
   • 综述文章
   • 工具/软件

3. 高分优先选取：

   • 保留评分 ≥ 7 分的论文
   • 确保各子主题都有代表性
   • 控制总数在 15-30 篇

输出： metadata/papers_scored.json

{
  "papers": [
    {
      "title": "论文标题",
      "authors": ["作者1", "作者2"],
      "year": 2024,
      "journal": "期刊名",
      "relevance_score": 9,
      "subtopic": "方法学",
      "doi": "10.xxxx/xxxxx",
      "url": "https://doi.org/..."
    }
  ]
}

步骤 1.4：生成参考文献清单

输出： references.bib

格式：标准 BibTeX，包含所有必要字段

步骤 1.5：下载 PDF

方法：

• 优先通过开放获取链接下载
• 使用 Unpaywall API 查找合法免费版本
• 保存到 papers/ 目录，命名格式：{第一作者姓氏}_{年份}_{期刊简写}.pdf

输出： papers/*.pdf

错误处理：

• 记录下载失败的 DOI
• 不阻塞后续流程
• 在最终报告中说明哪些论文未能获取

阶段 2：深度学习分析策略

步骤 2.1：PDF 信息提取

目标： 从每篇 PDF 中提取分析方法和技术细节

提取内容：

• 研究设计：实验类型、对照设置、样本量
• 数据预处理：清洗步骤、归一化方法、质量控制
• 统计方法：检验方法、多重比较校正、效应量
• 可视化策略：图表类型、配色方案、工具
• 软件工具：R/Python 包、版本、参数设置
• 验证方法：交叉验证、bootstrap、灵敏度分析

方法：

• 使用 PDF 读取工具提取文本和表格
• AI 语义分析识别 Methods 章节内容
• 结构化存储提取的信息

输出： extracted/papers_info.json

{
  "papers": [
    {
      "id": "paper_001",
      "title": "论文标题",
      "methods": {
        "study_design": "队列研究",
        "preprocessing": ["质量控制", "归一化"],
        "statistical_tests": ["t检验", "ANOVA"],
        "correction": "FDR",
        "visualization": ["箱线图", "热图"],
        "software": {
          "R": ["limma", "ggplot2"],
          "parameters": {"adjust.method": "BH"}
        }
      },
      "strengths": ["大样本量", "预注册"],
      "limitations": ["单中心研究"]
    }
  ]
}

步骤 2.2：综合分析框架

目标： 综合所有论文，提炼最佳实践

分析维度：

1. 方法学共识：

   • 多篇论文共用的方法
   • 领域内标准流程
   • 推荐的最佳实践

2. 方法学差异：

   • 不同场景的适用方法
   • 新兴方法 vs 传统方法
   • 争议点

3. 工具生态：

   • 最常用的软件包
   • 工具的优缺点比较
   • 版本兼容性

4. 质量控制：

   • 数据验证标准
   • 结果稳健性检验
   • 可复现性实践

输出： analysis-framework.md

模板见：research-plan/references/output-templates.md

阶段 3：制定个性化计划

步骤 3.1：需求对齐

分析用户需求：

• 研究问题是什么？
• 有什么特殊约束？
• 期望的输出是什么？
• 技能水平如何？

映射到分析框架：

• 匹配相关方法学章节
• 识别适用的工具
• 确定质量控制点

步骤 3.2：计划生成

输出： plan.md

模板见：research-plan/references/output-templates.md

步骤 3.3：计划审查

向用户呈现：

1. 计划概要
2. 关键决策点说明
3. 可选方案对比
4. 修改建议邀请

审查问题：

• 计划是否覆盖了你的需求？
• 步骤是否清晰可行？
• 有没有遗漏的分析？
• 有没有需要调整的部分？

对于用户

1. 需求描述要具体：避免模糊表述
2. 明确约束条件：数据类型、样本量、技能水平等
3. 审查计划时认真：这是你的研究，你有最终决定权
4. 保留工作目录：便于后续调整和复现

对于 AI 执行

1. 透明性：明确告知每一步在做什么
2. 可追溯性：所有推荐都有文献依据
3. 保守性：不确定时承认而非编造
4. 用户中心：计划要符合用户实际约束

实现/脚本状态与职责边界见：research-plan/references/implementation-notes.md

变更记录见：research-plan/CHANGELOG.md（版本号以 research-plan/config.yaml:skill_info.version 为准）

输出

核心输出

1. plan.md：最终分析策略计划（用户友好格式）
2. analysis-framework.md：分析框架总结（详细技术文档）
3. references.bib：参考文献清单（可引用）

辅助输出

4. metadata/：调研元数据（可复现）
5. extracted/papers_info.json：论文信息结构化数据（可再利用）

输出管理

本 Skill 的新任务中间文件统一写入 ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/{skill名}/input|output|log/。同一任务复用一个任务根目录；多 Skill 协作才创建 shared/。正式交付物不写入该目录，历史隐藏目录只允许显式兼容读取、迁移或清理。

校验

完成后执行 Skill 已有的静态检查、脚本验证或人工复核，并记录通过标准。

失败与恢复

常见问题

Q: 无法下载某些 PDF A: 记录失败的 DOI，可以在最终报告中说明，或尝试手动获取

Q: 提取的方法信息不完整 A: 使用补充材料（supplementary materials）或联系作者

Q: 文献数量太少 A: 放宽检索条件（年份、关键词范围）

Q: 不同论文方法冲突 A: 在分析框架中标注争议点，提供多方案选择

约束

功能边界

• ✅ 可以做的：

  • 调研文献并总结方法学
  • 制定分析策略和步骤
  • 推荐工具和最佳实践
  • 生成可执行的计划文档

• ❌ 严禁做的：

  • 执行实际的数据分析
  • 修改用户原始数据
  • 撰写正式科研论文
  • 做出科学结论

使用限制

1. 仅提供策略建议，具体实施需要用户验证
2. 方法学推荐基于文献，不能保证适用于所有场景
3. PDF 依赖可获取性，部分文献可能无法获取
4. AI 提取可能有误差，关键信息建议人工复核

质量保证

• 所有推荐都来自同行评议论文
• 明确标注证据强度（多论文共识 vs 单篇论文）
• 提供参考文献追溯
• 标注不确定性或争议点

公共硬约束

• 任务需要落盘时，使用唯一的 ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/ 根目录；共享材料放入 shared/，Skill 专属材料放入该 Skill 的 input/、output/、log/。
• 正式交付物、源代码和正式计划按项目约定保存，不写入任务工作区；未经授权不覆盖、删除、迁移或远程写入。
• 项目维护变更检查 BAC 可用性并记录需求、AI 产出、工具结果、文件改动和验证摘要；BAC 只做过程审计，不替代署名、责任或合规判断。
• 不记录 API Key、访问令牌、密码、Cookie、环境/凭据文件、私有 Prompt、身份信息、本地用户名、主机名或不必要的大体积原始数据。
• 文件路径必须规范化并限制在授权项目范围内；外部 URL、子进程和网络访问遵循最小权限，防止路径遍历、SSRF 和命令注入。
• Skill 版本唯一记录在自身 config.yaml:skill_info.version；公开 API、协议、目录或配置变更同步文档与 CHANGELOG.md。
• 仅将 Skill 或 Bensz 基础设施本身的设计缺陷交给 bensz-collect-bugs；先脱敏写入 ~/.bensz-skills/bugs/，当前任务不中断，只有用户明确要求才公开上报，禁止直接修改用户已安装的 Skill 源码。

Skill 专属约束

不得超出本 Skill description 和上方流程所声明的范围；不将未验证的信息伪装成确定结论。