【交叉评测S1W3】ResearchFlow AI — 科研端到端一体化工作台 (JunjieCai/scienith-research-booster-w3) #1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
评测基于完整仓库文件：README.md、spec.md、10个Skill契约、4份设计文档、vite.config.ts、src/App.tsx（55KB核心代码）等。
本项目是一个面向科研人员（研究生、博士后、青年科研人员）的AI端到端科研一体化平台，品牌名为 ResearchFlow AI。核心主张是：将科研工作的10个连续环节（项目建档→文献查询→论文解析→信息汇总→课题选择→方案设计→数据分析→结果解读→论文写作→期刊选择）串联成同一个项目工作流，通过AI辅助减少重复整理成本。
项目当前为前端mock原型，使用React+TypeScript+Vite+Ant Design构建，所有展示数据（文献列表、研究问题、期刊候选等）均为硬编码。右下角AI Chat已接入智谱GLM API，通过Vite自定义插件将skills/目录下的10个SKILL.md动态注入为系统prompt。
2.1 端到端科研工作流设计非常完整
项目覆盖了科研全流程的10个阶段，每个阶段都有独立的UI界面、mock数据和交互逻辑：
项目建档：表单收集研究方向、用户类型、目标、已有材料，AI判断当前阶段并推荐下一步。
文献查询：8篇mock文献（肿瘤免疫治疗方向），含优先级、推荐理由、研究空白。
论文解析：左侧论文列表 + 右侧结构化解析（研究问题、方法、数据、结论、创新点、局限性）。
信息汇总：5个主题分类（预测标志物、耐药机制、临床转化、模型报告规范、可解释AI），含争议点和研究空白。
课题选择：5个候选研究问题，含创新性/可行性评分、风险、数据需求、验证方式。
方案设计：研究目标、假设、设计、变量、分析方法、时间规划（Timeline）。
数据分析：6步分析计划（字段理解→清洗→探索→主分析→稳健性→解释）。
结果解读：mock模型结果（AUC=0.81）+ 6条解释建议。
论文写作：大纲、摘要、讨论、修改建议4个Tab。
期刊选择：6个候选期刊，含匹配度进度条、定位标签、推荐理由、风险、来源。
评测验证：4个指标卡片 + 6项可靠性检查清单。
这种全流程覆盖在同类科研辅助工具中非常罕见，产品价值呈现清晰。
2.2 Skill Prompt设计规范且统一
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）均采用统一结构：
目标（Purpose）
工作流程（Workflow）
输出格式（Output Format，Markdown模板化）
可靠性要求（Reliability Requirements）
每个Skill都强调：不编造引用、标注不确定性、保留人工确认、区分事实与推测。这种可靠性护栏前置的设计值得肯定。
2.3 AI Chat接入设计巧妙
vite.config.ts中实现了自定义Vite插件glmChatPlugin：
开发服务器拦截/api/ai/chat请求，代理到智谱GLM API。
动态读取skills/目录下所有SKILL.md文件，拼接为系统prompt注入GLM对话。
支持模型选择（glm-4.7/glm-4-flash/glm-4-plus）、流式响应、错误处理。
这种"前端零依赖接入LLM"的设计在原型阶段非常实用，且避免了API Key泄露风险。
2.4 竞品分析清晰
docs/competitor-analysis.md对比了Elicit、Consensus、SciSpace、Zotero、Paperpal等6类工具，明确提出了3个差异化假设：
端到端上下文串联（vs 单点工具复制粘贴）
面向科研训练而不只是结果生成
可靠性护栏前置
分析客观、有依据，不是空泛的"我们更好"。
2.5 用户验证计划具体可执行
docs/user-validation-plan.md定义了：
3
5名测试对象（硕士生/博士生/博士后）5分评分）+ 定性反馈8步测试任务 + 观察点
定量指标（完成率、1
对照方式（传统方式 vs ResearchFlow AI）
成功标准（80%理解率、4/5有用性评分、2名愿意继续试用）
这是本次评测中见过的最具体的用户验证计划之一。
3.1 缺少Agent化改造（核心问题）
当前项目本质上是一个带AI Chat的前端展示原型，而非"Agent"。具体表现为：
没有agent.yaml：缺少Agent清单、入口命令、Skills与评测标准的统一定义。
没有意图路由：用户输入如何匹配到具体Skill没有明确机制。AI Chat只是把所有Skill prompt一次性塞给GLM，由GLM自由理解，没有parseIntent → runSkill的确定性路由。
没有结构化输出契约：GLM输出是纯文本Markdown，没有AgentResponse（answer/actions/widgets/references）的schema约束，前端无法对AI输出做结构化解析和验证。
没有审计链：缺少从intent到action的6步审计日志，无法重建AI执行链。
没有自动评测：缺少eval.mjs或类似脚本，无法自动验证"查看文献→解析论文→汇总信息→生成课题"的端到端链路。
建议：参考工业数字孪生赛道中Agent的设计模式（如agent.yaml + skill-router + contracts.mjs + audit.mjs），将当前"前端展示+AI Chat"升级为"Agent驱动的科研工作流"。
3.2 纯Mock数据，无真实数据源接入
所有展示数据均为硬编码：
literatureData：8篇文献的标题、年份、来源、关键词、样本、方法、结果全部写死。
researchQuestions：5个候选问题的创新性/可行性评分是固定数字（86、78等）。
synthesisRows、journalRows、analysisPlanRows等全部是静态数组。
这意味着：
用户无法输入自己的研究方向并获取真实文献。
无法验证"语义检索"vs"关键词检索"vs"研究空白"三种模式的差异（点击后数据不变）。
无法验证AI Chat在真实科研场景下的表现（因为系统prompt中的Skill只是指导GLM如何回答，没有真实数据支撑）。
建议：至少接入一个开放文献API（如Semantic Scholar、PubMed E-utilities、arXiv API）做真实检索演示，或声明当前为"UI原型+Prompt设计验证"阶段。
3.3 上下文流转未真正实现
docs/context-flow.md设计了完整的ResearchProjectContext对象和Skill间的输入输出关系，但src/App.tsx中：
各stage之间没有数据传递（如文献查询的结果不会自动流入论文解析，论文解析的结果不会自动流入信息汇总）。
用户在一个stage的操作（如选择某篇论文、选择某个课题）不会自动影响下游stage的展示。
所有stage切换只是React state的activeStage变化，没有项目上下文的持久化。
建议：在agent化改造时，实现ResearchProjectContext的内存存储（或localStorage），让下游Skill能消费上游的输出。
3.4 Skill契约缺少技术深度
相比工业数字孪生赛道中规范的Skill设计（如locate-asset的Output Contract、Failure Modes、Evals），本项目的Skill更偏向prompt模板，缺少：
明确的Input/Output JSON Schema。
Failure Modes（如文献检索失败、PDF解析失败、GLM API超时时的降级策略）。
Evals验收条件（如"生成5个候选问题"的自动验证）。
分层设计（first-layer deterministic vs second-layer LLM-assisted）。
建议：为每个Skill补充Output Contract（期望的JSON/Markdown结构）、Failure Modes和至少1个Eval用例。
3.5 可靠性护栏尚未工程化
虽然所有Skill都声明了"不编造引用"、"标注不确定性"，但：
前端代码中没有对GLM输出做引用校验（如DOI格式检查、PMID存在性验证）。
没有Limited Evidence降级状态（当检索不到文献时，系统不会明确告知"证据不足"）。
没有人工确认节点的工程化实现（如关键结论必须点击"确认"后才能进入下游）。
建议：增加GLM输出的后处理层（post-processing），对引用、数据、结论做格式校验和可信度评分。
3.6 缺少明确的评测可验证性
spec.md中定义了5个评测维度（任务完成、输出质量、效率、体验、可靠性），但：
没有自动化评测脚本。
没有Golden Prompt覆盖核心场景。
没有固定输入→预期输出的映射表。
这使得评审方难以快速验证"输入'如何提高肿瘤免疫治疗响应率'，系统是否真的能输出符合科研要求的文献列表和研究方案"。
建议：增加eval/目录，包含至少5~8个端到端测试用例（如"输入研究方向X，期望输出包含Y篇文献的列表和Z个候选问题"）。
表格
优先级 建议 说明
P0 增加agent.yaml 定义Agent清单、入口命令、Skills、评测标准和约束条件。
P0 实现意图路由层 将用户输入解析为具体intent，再调用对应Skill，而非一次性注入所有prompt。
P0 补充结构化输出契约 为每个Skill定义JSON/Markdown输出schema，前端做解析和验证。
P1 接入至少一个真实文献API Semantic Scholar、PubMed、arXiv均可，用于验证文献检索和解析的真实表现。
P1 增加自动评测脚本 覆盖核心场景的固定输入→预期输出测试，包含通过/失败断言。
P1 工程化上下文流转 实现ResearchProjectContext的内存存储，让下游Skill消费上游输出。
P2 增加Failure Modes 为每个Skill补充失败场景（API超时、检索为空、解析失败）的降级策略。
P2 补充Evals验收条件 每个Skill至少1个可自动验证的Eval用例。
P2 增加审计日志 记录用户输入→intent→Skill调用→GLM请求→输出的完整链路。
这是一个产品价值清晰、工作流设计完整的项目，但当前阶段更偏向"AI辅助科研的UI原型和Prompt设计验证"，而非"可评测的Agent"。
项目最大的优势在于：
全流程覆盖：从项目建档到期刊选择的10个环节全部有UI和Prompt设计，这在科研辅助领域非常罕见。
可靠性意识强：从Skill设计阶段就强调不编造引用、标注不确定性、保留人工确认。
迭代响应快：根据交叉评测反馈迅速补充了架构、竞品、上下文流转和用户验证文档。
项目当前最需要解决的问题是：
Agent化改造：增加agent.yaml、意图路由、结构化输出契约、自动评测，让项目从"前端展示"升级为"可验证的Agent"。
真实数据源接入：至少接入一个开放文献API，验证AI在真实数据下的表现。
上下文流转工程化：实现项目上下文的持久化和Skill间的数据传递。
如果能在下一轮迭代中完成上述改造，该项目在科研辅助赛道的竞争力将显著提升。