JunjieCai/scienith-research-booster

Fork 0

[S1W2 交叉评测] AI赋能端到端科研一体化平台-W2 项目反馈 #5

New issue

Open

opened 2026-05-16 23:22:19 +08:00 by jackeyun · 0 comments

jackeyun commented

2026-05-16 23:22:19 +08:00

【S1W2 交叉评测】Scienith Research Booster / AI赋能端到端科研一体化平台项目评测

1. 项目理解

该项目（ResearchFlow AI）旨在构建一个 面向科研工作者的 AI 端到端科研一体化平台，覆盖科研全流程的 10 个关键环节：项目建档 → 文献查询 → 论文解析 → 信息汇总 → 课题选择 → 研究方案设计 → 数据分析 → 结果解读 → 论文写作 → 期刊选择。

项目的核心主张是「端到端」（end-to-end）：当前大多数科研工具只解决单一环节，本项目希望把多个环节串联起来，通过统一的项目上下文（ResearchProjectContext）实现 AI 在各个环节之间的持续协作。这与赛道「跑通核心功能的功能闭环」的要求高度契合。

当前交付物包括：React + TypeScript + Ant Design 前端 prototype（含完整 mock 数据演示 10 个阶段的交互流程）、10 个 SKILL.md 文件（每个科研环节一个）、spec.md（详细的项目提案）、4 份设计文档（技术架构、竞品分析、用户验证计划、上下文流转规范）。

2. 项目优点

2.1 Specs 文档质量极高

spec.md 是三项目中写得最好的项目提案文档。它清晰定义了：项目名称与一句话介绍、9 个核心模块的详细设计、8 个 AI 作用点（语义理解/文献解析/信息综合/课题生成/方案辅助/数据分析/写作辅助/期刊匹配）、5 个评测维度（任务完成率、输出质量、效率提升、用户体验、AI 可靠性）及每个维度的具体可验证指标（如「文献总结时间减少 50% 以上」「关键结论绑定文献来源」）。这完全符合赛事说明中「按照 Specs 中评测标准」的要求。

2.2 10 个 SKILL.md 的质量和一致性

项目定义了 10 个独立的 SKILL.md 文件（research-project-intake、literature-query、paper-reading、literature-synthesis、research-question-generation、research-design、data-analysis-advisor、result-interpretation、paper-writing、journal-selection），每个都遵循统一格式（YAML frontmatter + 目标 + 工作流程 + 输出格式 + 可靠性要求）。这种规范化程度在比赛中非常少见，体现了对「Skills 需完整、有效、可运行」要求的深度理解。

2.3 上下文流转设计非常出色

docs/context-flow.md 是三项目中最体现系统思维的设计文档。它明确定义了 10 个 Skill 之间的输入/输出/下游消费关系，设计了 ResearchProjectContext 对象（包含 project_profile、research_direction、literature_queries、paper_reading_notes 等 20+ 字段），并规定了必须人工确认的关键节点。这种「各 Skill 不是并列存在，而是上下游流转」的设计证明了端到端工作流不只是口号。

2.4 前端 Prototype 交互质量高

App.tsx 虽然使用 mock 数据，但完整展示了 11 个阶段的 UI 界面和交互逻辑。mock 数据质量很高（8 篇肿瘤免疫文献、5 个研究课题、6 个候选期刊 —— 数据内容专业、贴近真实科研场景），不是敷衍的占位符。界面有 Steps 步骤条、文献表格（关键词/优先级/推荐理由）、课题评分卡（创新性/可行性/风险/数据需求）、期刊匹配度评级等专业级交互。

2.5 用户验证计划系统化

docs/user-validation-plan.md 定义了 8 步测试任务、定量+定性指标、对照实验方法（传统方式 vs ResearchFlow AI）、成功标准门槛。这在原型阶段非常少见，体现了产品思维和对「可验证」的重视。

2.6 竞品分析与差异化清晰

docs/competitor-analysis.md 对比了 Elicit、Consensus、SciSpace、Zotero、Paperpal 等工具，明确了 ResearchFlow AI 的定位差异（端到端工作流 vs 单点工具），且没有贬低竞品。

3. 当前问题

3.1 核心问题是：目前仅停留在设计和前端 Mock 阶段，没有可运行的后端

这是最关键的短板。赛事 W2 要求「跑通产品原型 (Prototype)」，当前项目能跑的只是一个展示静态 mock 数据的前端页面。10 个 SKILL.md 定义了「应该做什么」，但没有与之对应的后端代码来实际执行文献检索、论文解析、课题生成等操作。评审者无法通过实际操作验证「文献查询模块能否真的输出相关文献列表」——只能看到硬编码的 mock 数据。

3.2 SKILL.md 是设计规范而非可执行 Skills

项目中的 SKILL.md 文件定义了理想状态下的工作流程和输出格式，但它们不是面向龙虾/Hermes 等 Agent 平台的可执行 Skills。对比医势推演项目的 skills（有路由逻辑、触发词、策略胶囊库、状态机），Scienith 的 SKILL.md 更接近「给人类看的模块需求文档」而非「给 AI Agent 看的执行指令」。这导致 Skills 的「可运行性」存疑。

3.3 缺少真实的 AI 集成证明

spec.md 中描述了 8 个 AI 作用点，但 prototype 中没有接入任何 LLM。没有证据表明这些工作流可以通过 AI 真实执行——例如「论文解析模块」能否真的从一篇 PDF 中提取研究问题/方法/结论/局限性？没有 demo 输出证明。

3.4 10 个 Skills 的粒度差异大

10 个 Skill 虽然格式统一，但内容深度差异明显。paper-reading 和 research-design 的 SKILL.md 有详细的工作流步骤和输出格式；但 data-analysis-advisor 和 result-interpretation 的 SKILL.md 则相对空泛（尤其是对于「数据分析」这种需要具体方法推荐的模块，目前的 SKILL.md 只说「推荐分析方法」而没有给出决策树或分类标准）。

3.5 技术架构仍然比较初步

architecture.md 选型规划多是「候选技术」列表（GPT/Claude/Qwen/GLM 等），缺少具体的技术选型和实现优先级。例如 PDF 解析——是用 PyMuPDF 还是 GROBID？embedding model 用什么？向量数据库选 Milvus 还是 Pinecone？这些选型会影响开发路线图但没有决策。

4. 建议

4.1【最高优先】实现最小可运行后端闭环

不要试图一次实现全部 10 个环节。选择一个高频核心链路（推荐：文献查询 → 论文解析 → 信息汇总 → 课题生成），用 Python/FastAPI 实现：接入 PubMed API 或 Semantic Scholar API → 用 LLM 解析论文摘要 → 存储结果 → 前端展示真实数据。哪怕只实现这 4 个环节，也比 10 个 mock 环节更有说服力。

4.2 将 SKILL.md 升级为 Agent 可执行格式

参照医势推演项目的 SKILL.md 格式，为每个 Skill 添加：触发词（trigger phrases）、路由逻辑（何时激活此 Skill）、输入契约（需要什么参数）、输出契约（返回什么结构）、与其他 Skill 的上下文传递协议。

4.3 为论文解析 Skill 补充 Demo 证明

即使后端未完成，至少手动调用一次 LLM（如 DeepSeek/GPT-4），输入一篇真实论文的摘要，输出符合 SKILL.md 定义的结构化解析结果（研究问题/方法/数据/结论/创新点/局限性），将结果作为 Demo 样例加入项目。这能证明「AI 确实可以完成论文解析任务」。

4.4 收敛 Skills 粒度

10 个 Skills 对 W2 阶段可能过多。建议标注 3-4 个作为「核心 Skills」（如 literature-query、paper-reading、literature-synthesis、research-question-generation），其余标注为「后续扩展」，并为核心 Skills 补充更详细的执行逻辑。

4.5 补充技术选型决策

在 architecture.md 中明确第一阶段的选型（如 PyMuPDF + BGE-small-zh + Milvus Lite + DeepSeek V4），而非罗列候选列表。这体现执行能力。

5. 综合评价

从当前材料来看，该项目：

✅ Specs 文档质量最高，评测标准最完善
✅ 10 个 SKILL.md 格式统一，上下文流转设计出色
✅ 前端 Prototype 交互质量高，mock 数据专业
⚠️ 核心短板：缺少可运行后端，无法验证 AI 的真实能力
⚠️ SKILL.md 更接近设计规范而非 Agent 可执行 Skills

这是一个在「产品设计/Specs/规划」维度上最出色的项目——从 spec 到 context-flow 到 user-validation-plan 形成了一套完整的从设计到验证的文档体系。但当前最大的风险是「只有设计没有实现」——建议集中精力打通最小可运行闭环，哪怕只实现 3-4 个核心模块。

评测人：jackeyun
评测时间：2026年5月
评测依据：赛事说明 S1W2 复赛标准 / SynNovator交叉评测指南

# 【S1W2 交叉评测】Scienith Research Booster / AI赋能端到端科研一体化平台项目评测 ## 1. 项目理解该项目（ResearchFlow AI）旨在构建一个 **面向科研工作者的 AI 端到端科研一体化平台**，覆盖科研全流程的 10 个关键环节：项目建档 → 文献查询 → 论文解析 → 信息汇总 → 课题选择 → 研究方案设计 → 数据分析 → 结果解读 → 论文写作 → 期刊选择。项目的核心主张是「端到端」（end-to-end）：当前大多数科研工具只解决单一环节，本项目希望把多个环节串联起来，通过统一的项目上下文（ResearchProjectContext）实现 AI 在各个环节之间的持续协作。这与赛道「跑通核心功能的功能闭环」的要求高度契合。当前交付物包括：React + TypeScript + Ant Design 前端 prototype（含完整 mock 数据演示 10 个阶段的交互流程）、10 个 SKILL.md 文件（每个科研环节一个）、spec.md（详细的项目提案）、4 份设计文档（技术架构、竞品分析、用户验证计划、上下文流转规范）。 --- ## 2. 项目优点 **2.1 Specs 文档质量极高** `spec.md` 是三项目中写得最好的项目提案文档。它清晰定义了：项目名称与一句话介绍、9 个核心模块的详细设计、8 个 AI 作用点（语义理解/文献解析/信息综合/课题生成/方案辅助/数据分析/写作辅助/期刊匹配）、5 个评测维度（任务完成率、输出质量、效率提升、用户体验、AI 可靠性）及每个维度的具体可验证指标（如「文献总结时间减少 50% 以上」「关键结论绑定文献来源」）。这完全符合赛事说明中「按照 Specs 中评测标准」的要求。 **2.2 10 个 SKILL.md 的质量和一致性** 项目定义了 10 个独立的 SKILL.md 文件（research-project-intake、literature-query、paper-reading、literature-synthesis、research-question-generation、research-design、data-analysis-advisor、result-interpretation、paper-writing、journal-selection），每个都遵循统一格式（YAML frontmatter + 目标 + 工作流程 + 输出格式 + 可靠性要求）。这种规范化程度在比赛中非常少见，体现了对「Skills 需完整、有效、可运行」要求的深度理解。 **2.3 上下文流转设计非常出色** `docs/context-flow.md` 是三项目中最体现系统思维的设计文档。它明确定义了 10 个 Skill 之间的输入/输出/下游消费关系，设计了 ResearchProjectContext 对象（包含 project_profile、research_direction、literature_queries、paper_reading_notes 等 20+ 字段），并规定了必须人工确认的关键节点。这种「各 Skill 不是并列存在，而是上下游流转」的设计证明了端到端工作流不只是口号。 **2.4 前端 Prototype 交互质量高** App.tsx 虽然使用 mock 数据，但完整展示了 11 个阶段的 UI 界面和交互逻辑。mock 数据质量很高（8 篇肿瘤免疫文献、5 个研究课题、6 个候选期刊 —— 数据内容专业、贴近真实科研场景），不是敷衍的占位符。界面有 Steps 步骤条、文献表格（关键词/优先级/推荐理由）、课题评分卡（创新性/可行性/风险/数据需求）、期刊匹配度评级等专业级交互。 **2.5 用户验证计划系统化** `docs/user-validation-plan.md` 定义了 8 步测试任务、定量+定性指标、对照实验方法（传统方式 vs ResearchFlow AI）、成功标准门槛。这在原型阶段非常少见，体现了产品思维和对「可验证」的重视。 **2.6 竞品分析与差异化清晰** `docs/competitor-analysis.md` 对比了 Elicit、Consensus、SciSpace、Zotero、Paperpal 等工具，明确了 ResearchFlow AI 的定位差异（端到端工作流 vs 单点工具），且没有贬低竞品。 --- ## 3. 当前问题 **3.1 核心问题是：目前仅停留在设计和前端 Mock 阶段，没有可运行的后端** 这是最关键的短板。赛事 W2 要求「跑通产品原型 (Prototype)」，当前项目能跑的只是一个展示静态 mock 数据的前端页面。10 个 SKILL.md 定义了「应该做什么」，但没有与之对应的后端代码来实际执行文献检索、论文解析、课题生成等操作。评审者无法通过实际操作验证「文献查询模块能否真的输出相关文献列表」——只能看到硬编码的 mock 数据。 **3.2 SKILL.md 是设计规范而非可执行 Skills** 项目中的 SKILL.md 文件定义了理想状态下的工作流程和输出格式，但它们不是面向龙虾/Hermes 等 Agent 平台的可执行 Skills。对比医势推演项目的 skills（有路由逻辑、触发词、策略胶囊库、状态机），Scienith 的 SKILL.md 更接近「给人类看的模块需求文档」而非「给 AI Agent 看的执行指令」。这导致 Skills 的「可运行性」存疑。 **3.3 缺少真实的 AI 集成证明** spec.md 中描述了 8 个 AI 作用点，但 prototype 中没有接入任何 LLM。没有证据表明这些工作流可以通过 AI 真实执行——例如「论文解析模块」能否真的从一篇 PDF 中提取研究问题/方法/结论/局限性？没有 demo 输出证明。 **3.4 10 个 Skills 的粒度差异大** 10 个 Skill 虽然格式统一，但内容深度差异明显。paper-reading 和 research-design 的 SKILL.md 有详细的工作流步骤和输出格式；但 data-analysis-advisor 和 result-interpretation 的 SKILL.md 则相对空泛（尤其是对于「数据分析」这种需要具体方法推荐的模块，目前的 SKILL.md 只说「推荐分析方法」而没有给出决策树或分类标准）。 **3.5 技术架构仍然比较初步** architecture.md 选型规划多是「候选技术」列表（GPT/Claude/Qwen/GLM 等），缺少具体的技术选型和实现优先级。例如 PDF 解析——是用 PyMuPDF 还是 GROBID？embedding model 用什么？向量数据库选 Milvus 还是 Pinecone？这些选型会影响开发路线图但没有决策。 --- ## 4. 建议 **4.1【最高优先】实现最小可运行后端闭环** 不要试图一次实现全部 10 个环节。选择一个高频核心链路（推荐：文献查询 → 论文解析 → 信息汇总 → 课题生成），用 Python/FastAPI 实现：接入 PubMed API 或 Semantic Scholar API → 用 LLM 解析论文摘要 → 存储结果 → 前端展示真实数据。哪怕只实现这 4 个环节，也比 10 个 mock 环节更有说服力。 **4.2 将 SKILL.md 升级为 Agent 可执行格式** 参照医势推演项目的 SKILL.md 格式，为每个 Skill 添加：触发词（trigger phrases）、路由逻辑（何时激活此 Skill）、输入契约（需要什么参数）、输出契约（返回什么结构）、与其他 Skill 的上下文传递协议。 **4.3 为论文解析 Skill 补充 Demo 证明** 即使后端未完成，至少手动调用一次 LLM（如 DeepSeek/GPT-4），输入一篇真实论文的摘要，输出符合 SKILL.md 定义的结构化解析结果（研究问题/方法/数据/结论/创新点/局限性），将结果作为 Demo 样例加入项目。这能证明「AI 确实可以完成论文解析任务」。 **4.4 收敛 Skills 粒度** 10 个 Skills 对 W2 阶段可能过多。建议标注 3-4 个作为「核心 Skills」（如 literature-query、paper-reading、literature-synthesis、research-question-generation），其余标注为「后续扩展」，并为核心 Skills 补充更详细的执行逻辑。 **4.5 补充技术选型决策** 在 architecture.md 中明确第一阶段的选型（如 PyMuPDF + BGE-small-zh + Milvus Lite + DeepSeek V4），而非罗列候选列表。这体现执行能力。 --- ## 5. 综合评价从当前材料来看，该项目： - ✅ Specs 文档质量最高，评测标准最完善 - ✅ 10 个 SKILL.md 格式统一，上下文流转设计出色 - ✅ 前端 Prototype 交互质量高，mock 数据专业 - ⚠️ **核心短板：缺少可运行后端，无法验证 AI 的真实能力** - ⚠️ SKILL.md 更接近设计规范而非 Agent 可执行 Skills **这是一个在「产品设计/Specs/规划」维度上最出色的项目**——从 spec 到 context-flow 到 user-validation-plan 形成了一套完整的从设计到验证的文档体系。但当前最大的风险是「只有设计没有实现」——建议集中精力打通最小可运行闭环，哪怕只实现 3-4 个核心模块。 --- *评测人：jackeyun* *评测时间：2026年5月* *评测依据：赛事说明 S1W2 复赛标准 / SynNovator交叉评测指南*

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

JunjieCai/scienith-research-booster#5

No description provided.

Rows
Columns