科研工作台搭建

科研工作台改造计划：逐项验证与实施

版本：v0.1，2026-09-14。用途：个人实施清单、后续 Agent 任务入口和人工验收台账。

本文件是待实施计划。以下 29 项任务均未因本文生成而完成。本轮没有安装插件、修改采集服务、申请服务器或执行新实验。

1. 怎么使用这份计划

1. 先阅读第 2 节，确认最终体验符合你的科研习惯。
2. 按 A → B → C → D → E → F → G 的依赖推进；F01 的写作要求和 F04 的格式规则可提前收集。
3. 每次选一个编号，先验证它能不能解决实际问题，再实现和验收。任务标题的复选框只有验收完成后才勾选。
4. 每项完成后，在第 8 节填写证据路径、结论和下一步。测试通过、论文读懂、方向成立是不同的结论，要分别记录。
5. 可以直接对 Agent 说：“按桌面计划实施 C02，先检查现有内容，完成后给我验收材料。”
6. 桌面文件作为当前人工勾选主本；项目根目录保存同版初始副本。两份不会自动同步。后续实施前应读取桌面最新勾选状态，避免覆盖你的备注。

建议状态：未开始 / 验证中 / 实施中 / 待验收 / 已完成 / 阻塞 / 暂缓。复选框只表达“已完成”，详细过程填台账。

2. 最终要获得的体验

| 科研阶段 | 你实际怎么用 | 系统交付什么 | 进入下一步的依据 |
|---|---|---|---|
| 论文浏览 | 看候选列表，保留、忽略、补关键词 | 去重题录、推荐理由、来源、新旧关联 | 你选择值得精读的论文 |
| 论文理解 | 打开 PDF，与陪读 Agent 讨论问题、公式、图表 | 带页码的解释、疑问记录、论文思想卡、证据记录 | 你能解释作者的问题、假设、机制和边界 |
| 方向确定 | 比较现实问题、文献缺口与资源条件 | 候选方向、反证检索、可行性表、最小验证实验 | 选择一个主问题，知道什么结果会支持或否定它 |
| 深耕方向 | 复现、改动、观察失败、调整下一轮实验 | 有周期和预算的实验计划、可复现运行、结果分析 | 获得足以支持或反驳假设的证据 |
| 总结成文 | 审阅 AI 初稿，自己修改，再提交审核 | 内容初稿、证据审计、格式报告和交付稿 | 内容与证据一致，目标格式检查完成，作者最终确认 |

这五步会反复往返。先有一个宽泛问题再浏览文献；实验可能否定方向并触发重新检索。不要把它实现成只能向前点击的五个页面。

三个视角修正：

• “作者理念”应从论文问题设定、设计取舍和证据推导。论文未说明的个人意图只能标作解读，不能替作者断言。
• “现实问题 × 已有理解 × 工具 × 可完成性”适合用于候选筛选，但不能用一个乘积分数证明方向值得做。数据不可得、无法定义指标等硬约束先检查，再比较软评分。
• IT 实验可以是离线评测、API 调用、系统测试、用户研究或训练。先估资源；只有确实需要 GPU 的任务才租 GPU，真实用户和真实设备问题不能单靠云服务器替代验证。

3. 现有资产与证据边界

项目根目录：E:\vibe_coding\科研工作流探索。本节子路径均相对于该根目录。

| 资产 | 可复用内容 | 尚需补齐 |
|---|---|---|
| research-intel-agent/ | 采集、方向筛选、反馈、Zotero 导入队列、本地审核器、服务器总结 | 标准交接记录、交互式陪读入口、私有阅读与社区投稿分离 |
| project/research-workbench-template/ | 领域无关骨架、拒绝覆盖初始化、实验审计 | 通用阅读会话、方向比较、实验运行和写作适配 |
| project/laparoscopic-tracking-failure-detection/ | 真实参考项目、证据/实验合同、Claim、初稿与审计代码 | 当前版本、状态一致性、领域硬编码抽取 |
| 已有 skills | 精读、方向分析、实验计划、写作、文档审核等能力说明 | 实际接口、依赖、回归样例和统一入口 |

2026-09-14 本次只重新读取了情报工具与通用模板 README，确认上述设计说明仍存在。没有重新检查生产服务、插件运行状态、模型接口和 GPU 租赁产品。

2026-09-08 的历史验证曾得到试点 36 项测试通过、6 个实验/50 个哈希通过、写作审计 11/11、模板 17 项测试通过；当时试点没有 Git 提交。它们是历史基线，A01 必须刷新，不能当作今天的验收结果。

前一轮回答没有完成外部产品的实时充分调研。因此下文中的软件和成熟方案属于候选选型；产品功能、价格、API、维护状态和兼容性均须按 A03 核验，不能直接照单安装。

4. 总体实现约定

4.1 数据归属

• Zotero：题录、原始 PDF、批注和引用信息。现有情报工具通过受支持接口导入；读取使用 API 或受控导出，不直接编辑数据库。
• Obsidian：论文笔记、个人理解、知识综合、方向讨论和审核入口。保留现有 Sources/Papers → Knowledge → Writing 目录，不新造另一套相同内容目录。
• 项目目录与 Git：代码、配置、实验记录、机器可读证据/Claim、生成批次、审核历史。
• 数据存储：原始数据、权重、大型输出。Git 保存清单和哈希；另行验证备份与恢复。
• 模型：处理本次任务需要的材料，输出草稿、解释或检查结果；不把整座库默认塞进每个请求。

单一事实来源按对象确定，而不是把所有内容塞进一个大 JSON。建议机器可读 Claim 为正式生成输入，Obsidian Claim Matrix 为只读投影；人工修改经明确导入/审核流程提交。研究状态索引只保存 ID、路径和阶段，不复制正文。

4.2 状态与角色

证据强度与审核状态分开：observed/supported 描述证据支持程度，draft/human-reviewed/verified 描述审核过程。发布状态另记为 private/pending_review/released，不能把“已发布”理解为“研究已验证”。

阅读可保存 AI 草稿，探索性讨论不必逐句审批。只有主张进入稳定知识结论、正式实验决策或稿件事实时，才需要相应证据审核。人工确认不能把弱证据自动变成强证据。

角色先采用同一执行工具中的独立会话、不同任务说明和输入包：情报筛选、陪读、方向分析、实验规划、写作者、审核者。多角色不等于必须部署多个服务。独立审核会话有助于找错，但仍可能与写作者犯同类错误，需要原文和机械校验补充。

4.3 最小持久化对象

| 对象 | 必填信息 |
|---|---|
| Paper | 稳定 ID、DOI/arXiv/版本、来源 URL、Zotero key、全文状态、PDF 哈希 |
| Reading Session | 论文版本、讨论目标、已读位置、疑问、用户解释、会话摘要、下一步 |
| Evidence | 来源类型、页码/表图/实验定位、支持内容、限制、出处版本 |
| Claim | 主张、Evidence ID、适用范围、允许/禁止措辞、审核状态、审核记录 |
| Direction/Hypothesis | 现实问题、已有方案、缺口依据、资源约束、可证伪条件 |
| Experiment/Run | 假设、baseline、配置、数据/代码版本、运行 ID、指标、成本、结果路径 |
| Draft/Review | 冻结输入、段落/Claim 对应、稿件版本、审核对象哈希、问题和处理记录 |

优先沿用已有 ER、CLM、EXP、Draft ID。只有新增对象才引入新 ID，不重命名历史记录。新命令和路径在下面均是拟实现接口，不是现有可运行功能。

5. 逐项实施清单

A. 整理基础和验证选型

[ ] A01 刷新现状与可恢复基线

• 依赖：无。建议工作量：半天至一天。
• 验证：检查三个项目边界、Git 状态、已有修改、真实 Vault 路径、Zotero 状态及备份位置；按现有入口刷新必要测试。
• 实施：生成 docs/workbench-current-state.md 和文件清单；明确各目录版本管理归属，筛除密钥/数据/缓存后建立当前代码基线。历史实验继续如实保留 uncommitted，不能补填新提交伪装历史版本。
• 验收：能定位每项现有能力的入口；至少做一次小文件备份恢复；说明哪些数据仅有哈希、哪些有可恢复副本。
• 失败处理：备份或路径不清时先记录阻塞，不做目录搬迁。

[ ] A02 确定实际工作入口与资料归属

• 依赖：A01。建议工作量：半天。
• 验证：沿一篇选中论文追踪服务器、本地文件、Zotero、真实 Vault、项目快照与社区投稿位置。
• 实施：写出对象所有权和同步规则；确定一个真实 Vault 为日常笔记入口，项目中保存受控快照或机器记录；桌面审核器保留为论文入口。
• 验收：修改一次笔记后，能明确哪个副本是最新、谁负责同步、冲突如何报告；跨设备失败不覆盖用户修改。
• 失败处理：同步设计未定前使用显式导出/导入，不做双向自动同步。

[ ] A03 逐项核验软件、插件和成熟方案

• 依赖：A01。建议工作量：一天，产品试用时间另计。
• 验证：按第 6 节查官方文档、维护仓库、许可、价格、平台支持、数据去向和导出能力，记录检查日期与 URL。
• 实施：生成 docs/tool-selection.md，每种任务最多保留一个默认方案和一个替代；先检查已安装项，新增项记录版本、安装方式、配置和卸载方式。只配置当前阶段需要的工具。
• 验收：用同一篇论文或同一份实验样例做对比，得到明确“采用/暂缓/弃用及原因”；没有凭空填写价格或默认声称兼容。
• 失败处理：不具备稳定接口的 SaaS 可作为人工辅助，不能成为自动流水线硬依赖。

[ ] A04 建立可验证记录和统一状态入口

• 依赖：A02。建议工作量：一至两天。
• 验证：用当前一条文献 Claim 和一个 EXP 检查第 4.3 节字段是否足够；避免只检查 Markdown 里有没有关键词。
• 实施：从已有合同补充 schema、版本和链接校验；新增只读状态命令或入口，汇总待阅读、待审核、实验和稿件阻塞项，生成可读索引。
• 验收：缺失来源、断开的 Claim、冲突审核状态、输入哈希改变都会被明确报告；旧历史产物不被自动重写。
• 失败处理：导入失败保留原记录和错误报告；不可悄悄把未知状态映射成通过。

B. 论文浏览与筛选

[ ] B01 定义每日浏览规则

• 依赖：A03。建议工作量：半天。
• 验证：检查现有医疗/通用 Agent 的 70%/30% 和 Top 10 是否仍符合需要；区分推荐排序与学术质量判断。
• 实施：在现有 Focus 合同中表达主题、排除词、经典论文回溯、前沿论文和跨方向探索；试运行候选配额，不自行覆盖线上 Focus。
• 验收：连续若干次样本中能说明为什么推荐/不推荐；没有合格论文时允许不足额，不为凑数降低标准；用户反馈不会悄悄改研究方向。
• 失败处理：新规则只在影子评估中比较，原 feed 可继续使用。

[ ] B02 打通标准论文记录与 Zotero 去重

• 依赖：A04、B01。建议工作量：一天。
• 验证：测试已有条目、缺 PDF、预印本/正式版、DOI 缺失、Zotero 离线等样例。
• 实施：复用 core.py、collectors.py、zotero_client.py，增加稳定 Paper ID、版本信息、导入结果与原始 PDF 哈希的交接记录。
• 验收：同篇重复选择不产生重复条目；离线队列能恢复；abstract-only 与全文状态分开；版本合并有记录。
• 失败处理：保留失败任务和错误类别，支持单篇重试，不重复整批导入。

[ ] B03 分开私人精读与社区发布

• 依赖：B02。建议工作量：半天至一天。
• 验证：当前“选定论文”会触发 Zotero、服务器总结和网站待审核投稿，确认这一联动的实际调用链。
• 实施：保留选定、摘要、导入各自状态；新增私人精读入口，社区投稿作为独立明确操作。公开内容导读与内部证据元数据分别存放。
• 验收：启动私人阅读不会创建社区投稿；重试阅读不会重复导入；已有公开内容和待审稿不因迁移改变状态。
• 失败处理：新入口可关闭，旧记录可查询；不自动删除历史投稿。

[ ] B04 完成一次浏览阶段验收

• 依赖：B01–B03。建议工作量：三个实际使用日，每日约二十分钟。
• 验证/实施：记录实际候选、去重、选择、漏检原因与耗时，从中选出两篇进入 C 阶段。
• 验收：你能快速知道为什么读这篇；选中的真实论文可打开 PDF 或明确知道全文为何不可得；检索量、入选率和人工负担可查看。
• 产物：records/acceptance/discovery-pilot.md，包含样例 ID、操作结果、问题和取舍。
• 失败处理：优先修正来源和筛选，不盲目增加每日推荐数量。

C. 深读陪伴与信息整理

[ ] C01 建立全文与图表读取能力

• 依赖：B02、A03。建议工作量：一天。
• 验证：选文字 PDF 和公式/表格较多 PDF，检查提取是否丢页、截断、错列或损坏公式；必要时试用更强解析器。
• 实施：复用既有精读流程，保存页码、章节、图表定位、提取方式、原文哈希和失败提示；文本解释与页面图像对照。
• 验收：抽查至少五个含数字/公式/图表的定位，能回到正确原文；读不到的内容写明未知；论文或解析版本变化能使缓存失效。
• 失败处理：降级为按页人工阅读或 OCR，不能把摘要当全文继续。

[ ] C02 实现可恢复的论文陪读会话

• 依赖：C01、A04。建议工作量：一至两天。
• 验证：先用一篇论文手工演练“问题地图 → 单节讨论 → 追问 → 自己复述 → 纠错”，观察什么形式最有帮助。
• 实施：创建陪读角色说明与会话记录；支持“解释公式/举例/回原文/质疑/暂停/继续”；记住你的知识缺口和已讨论内容。先用现有对话界面，不必先开发聊天前端。
• 验收：重开会话能恢复具体阅读位置和疑问；你能用自己的话解释问题、假设、机制和局限；Agent 不把完成摘要等同于你已读懂。
• 失败处理：摘要不足以续读时回到原文和明确问题，不伪造对话记忆。

[ ] C03 生成思想卡与可核验的证据

• 依赖：C02。建议工作量：一天。
• 验证：把同一段解释分成“作者明说、实验观察、我的理解、Agent 推断”，检查能否区分。
• 实施：通过 deeppapernote 和文献桥接规则输出论文思想卡、证据记录、开放问题；新内容默认 draft，个人学习笔记可自由编辑，主张提升单独记录。
• 验收：每条计划复用的主张能定位原文；至少抽查五条；允许/禁止措辞及适用范围明确；不得为满足固定数量编造证据。
• 失败处理：证据不足保留为疑问或假设，不进入稳定综合结论。

[ ] C04 两篇论文的交叉理解验收

• 依赖：C03。建议工作量：两次阅读会话加半天整理。
• 验证/实施：比较两篇论文的问题、数据、假设、方法、指标和代价，更新 Knowledge/ 中的对比与研究疑问。
• 验收：你能说出二者真正分歧、指标是否可比、哪个实验能检验分歧；产出至少一个有来源的后续问题，不强求已经发现创新。
• 产物：来源链接齐全的对比笔记和阅读验收记录。
• 失败处理：缺乏背景知识时回到基础概念或综述，不直接生成“无人研究”的断言。

D. 方向确定与可行性判断

[ ] D01 建立现实问题与个人资源清单

• 依赖：C04。建议工作量：一天，外部访谈时间另计。
• 验证：收集公开 issue、benchmark 错误、行业报告、实际任务或导师反馈，标注哪些是直接需求、哪些是二手转述。
• 实施：记录目标使用者、失败场景、影响、现有替代；同时记录知识储备、可用代码、数据、时间、算力/API 预算和协作条件。
• 验收：每个优先问题有可检查依据；未知处明确列出；不把开源热度或一条 issue 自动当成普遍需求。
• 失败处理：无法证明现实价值时保留为方法探索，并如实降低优先级。

[ ] D02 形成候选方向并主动寻找反证

• 依赖：D01、A03。建议工作量：一至两天。
• 验证：让方向分析角色提出两至三个候选，再检索同义工作、近期论文、代码和否定结果。
• 实施：每个候选写清问题、缺口、已有方法、为何可能改善、所需资源、最小实验和放弃条件；先查数据和评价可行性，再给有理由的相对评分。
• 验收：每个候选至少列最接近工作和最大不确定性；“没有找到”明确受检索范围限制；缺数据的候选不能靠总分掩盖硬阻塞。
• 失败处理：发现已有工作已解决时记录并缩小问题或弃用候选，不包装虚假创新。

[ ] D03 选定主问题与最小验证合同

• 依赖：D02。建议工作量：半天讨论。
• 验证：你能否在三句话内说明输入、改动、比较对象和可测结果。
• 实施：由你选一个主问题及一个备用问题，更新 Research Question Card；固定 baseline、数据来源、主指标、成功/否证条件和首次验证周期。
• 验收：另一个人不看聊天记录，也能理解要做什么、为什么值得做、如何判断失败；需要导师判断的具体问题被列出。
• 失败处理：若评测无法区分不同假设，回 D02；不把模糊兴趣直接转成训练任务。

[ ] D04 可行性试验与方向复核

• 依赖：D03。建议工作量：两至三天的有界探测。
• 验证/实施：尝试合法数据样例、baseline 安装和小规模运行；给出实测资源和最早可获得证据的日期。这一探测不是正式效果验证。
• 验收：输出继续/缩小范围/暂缓及原因；下一阶段有实际输入、预算范围和可执行计划。
• 产物：方向决定记录及探测 run；失败结果也保留。
• 失败处理：到时或超预算即停，记录阻塞；不靠无限换环境拖延判断。

E. 有周期、可复现的实验

[ ] E01 制定首轮实验周期与停止条件

• 依赖：D04。建议工作量：半天至一天。
• 验证：检查每个实验改变了什么、能区分什么、最便宜的验证方式是什么。
• 实施：拆成环境/数据检查、baseline、单因素改动、消融/稳健性；先规划一个七至十四天周期，定义里程碑、费用上限、失败处置和数据划分。
• 验收：每个 EXP 都有假设、对照、指标、预计耗时、最大运行时间、预算和结果去向；不知道的成本先跑样例测量。
• 失败处理：周期结束无有效证据时回 D 阶段复核，不自动扩训练规模。

[ ] E02 建立一次性或可续租的远程运行环境

• 依赖：E01、A03。建议工作量：一天。
• 验证：确认 CPU/GPU/显存、区域网络、存储、出网、镜像和依赖；比较本机、API 和租 GPU 三种成本。
• 实施：选择一个供应商/环境，使用项目锁定依赖；需要环境隔离时使用 Docker；提供 SSH、日志和数据传输流程。预算未确定前只准备配置和小样本方案。
• 验收：新实例可运行同一 smoke test；凭据不进 Git；停止实例与删除磁盘的计费后果写清；关闭实例后关键结果可在本地恢复。
• 失败处理：连接/镜像失败有明确超时；保留故障信息并停止计费资源。

[ ] E03 实现可恢复的实验提交和结果回收

• 依赖：E02、A04。建议工作量：一至两天。
• 验证：测试断网、进程退出、磁盘不足和重复提交；实验 ID 与实际 run ID 分离。
• 实施：提交冻结 commit/config/data manifest；远端保存日志、指标、运行状态和计费时长；重试创建新 run，回收后校验哈希。先使用简单 SSH + 明确作业管理，按需升级调度平台。
• 验收：重复点提交不重复启动收费任务；断网后可重新连接查询；有终止入口；中止/失败与完成清晰区分；checkpoint 是否可恢复明确记录。
• 失败处理：仅对确定可恢复错误做有上限重试；失败日志和旧输出不覆盖。

[ ] E04 结果分析与下一轮决策

• 依赖：E03。建议工作量：随首轮实验进行。
• 验证：指标实现、统计单位、数据泄漏和公平比较；按任务选择重复种子、置信区间或其他必要分析，不套固定统计模板。
• 实施：从结构化指标生成表图、失败案例与报告，区分观察和解释；为可复用结果生成候选 Claim。
• 验收：任一图表/数字能回到 run、代码和数据；负结果不隐藏；没有事件或样本不足时报告不可评价；下一实验有证据动机。
• 失败处理：分析错误形成新版本；不能用看过的测试结果反向调参后仍称独立验证。

[ ] E05 完成一个实验周期验收

• 依赖：E04。建议工作量：首个七至十四天周期末半天复盘。
• 验证/实施：核对计划与实际成本、基线复现差距、候选变化、失败原因及停止条件，形成周期报告。
• 验收：至少完成一条可复核 baseline；候选实验有结果或明确失败原因；对假设作出支持/不支持/证据不足判断，并决定下周期任务。
• 产物：周期报告、运行清单、成本记录、待审核 Claim。
• 失败处理：证据不足可以是合格周期结果，但不能标为方法成功。

F. 内容初稿与独立审核

[ ] F01 确定写作输入和两类审核范围

• 依赖：A04；可在 E 阶段并行准备。建议工作量：半天。
• 验证：区分研究事实、研究计划、文献观点、推断、用户修改和缺失信息。
• 实施：作者角色负责内容初稿；独立审核会话负责证据/逻辑检查；格式审核流程负责模板、样式、图表、引用格式和渲染。内容初稿先不追求投稿排版。
• 验收：每类问题有明确处理方式；格式通过不代表科学结论通过；未审核材料可进入候选区但不能冒充确认结果。
• 失败处理：缺实验证据时允许写方法计划和局限，结果位置保留明确待补项。

[ ] F02 改造内容生成器

• 依赖：F01、E04 或已有足够审核证据。建议工作量：两至三天。
• 验证：检查既有 src/laptrack/draft_pipeline.py 的领域硬编码与 Claim 门禁，先保留已有审计能力。
• 实施：输入冻结的研究问题、证据包、Claim、图表和术语表；按“论点结构 → 段落计划 → 分节生成 → 一致性检查”生成 Markdown，保存段落到证据映射和不可覆盖批次。
• 验收：不存在编造引用或数字；缺失信息明确标出；研究计划不写成已完成；同一模型重新措辞不要求逐字一致，但输入和产物均可追溯。
• 失败处理：章节失败单独重试并创建版本，不重写已批准段落；不为改善流畅度删除边界。

[ ] F03 人工修改后的证据与逻辑复核

• 依赖：F02。建议工作量：一天实现，加人工修改时间。
• 验证：准备有意植入的错误：数字变化、错误引用、因果夸大、结果与摘要矛盾、删除限制、图表错号。
• 实施：记录人工修改稿的哈希，与上一稿和证据比对；审核角色输出问题位置、依据、严重程度和修改建议。Word 稿通过修订或文本提取接入，提取不足时明确提示人工复查。
• 验收：能定位样例中的关键错误；报告明确对应哪个稿件版本；内容改动会使受影响的旧通过状态失效；审核官不静默改研究结论。
• 失败处理：无法自动对齐段落时生成待核对清单，不假装全稿已验证。

[ ] F04 建立目标格式规则和独立格式审核

• 依赖：A03、F01；具体格式取决于目标期刊/会议/学校。建议工作量：一至两天。
• 验证：读取当期官方指南和模板，记录版本、日期、URL；目标未定时只做通用可读性检查，不猜投稿规范。
• 实施：将字数、章节、引用样式、图表、公式、匿名要求及所需声明转成检查表；Word 与 LaTeX 选一个主出口。自动检查结构，再渲染 PDF 全页检查溢出、截断、字体、分页和重叠。
• 验收：用故意错号、超宽表格和缺失声明的样例验证检查；区分机器确认、视觉确认和人工待确认；保留渲染版本与报告。
• 失败处理：复杂公式/表格不能可靠转换时用官方模板直接编辑；不以“生成成功”替代格式验收。

[ ] F05 完成一次写作与审核闭环

• 依赖：F02–F04。建议工作量：一次完整人工修改周期。
• 验证/实施：用真实项目材料生成短初稿，人工改动后重新做内容审核和格式审核，输出带版本的最终材料包。
• 验收：正文、图表、引用、证据映射和审核报告对应同一版本；已解决问题有复核记录；未解决问题清楚列出；作者决定是否用于内部交流或正式提交。
• 产物：Markdown 审计源、人工主稿、PDF、参考文献、证据映射、问题单和审核报告。
• 失败处理：有阻塞时保持内部稿状态；不得把残留 HOLD 的内部稿自动标成可投稿。

G. 集成、迁移与日常运用

[ ] G01 抽取通用能力并验证第二项目

• 依赖：C04、D04、E05、F05 中相应模块已通过。建议工作量：两至三天。
• 验证：识别真正跨领域复用的 schema、脚本、角色说明和样例；不把腹腔镜数据/论文/医学边界复制为通用默认。
• 实施：增量更新模板白名单与版本，提供迁移预览、冲突报告及备份；历史研究记录保持原始语义。
• 验收：用非腹腔镜项目生成空白工作台并跑通一条最小链路；已有项目修改不会被模板覆盖；领域无关检查通过。
• 失败处理：回退本次模板版本和新增文件；不覆盖真实 Vault 或清除实验历史。

[ ] G02 统一入口与每周证据复盘

• 依赖：A04、B04、C04；其他阶段完成后逐步接入。建议工作量：一至两天。
• 验证：你是否能在五分钟内找到当前问题、最近新增证据、失败实验、稿件问题和下一步。
• 实施：优先提供项目主页/命令和已有审核器入口；每周从新增证据、实验与决定生成简短复盘，展示阻塞项和唯一主任务。
• 验收：复盘中的关键结论都带来源；失败和无进展如实呈现；后台状态未变化不反复通知；开销和人工审核时间可查看。
• 失败处理：自动汇总不可用时退回同一份手工模板，科研工作不被界面故障阻断。

[ ] G03 总体验收与收缩复杂度

• 依赖：G01、G02。建议工作量：一周实际使用后的半天复盘。
• 验证/实施：完整走一次“论文选中 → 陪读 → 方向决定 → EXP → 初稿 → 人工修改 → 审核”，统计断点、手工步骤和成本。
• 验收：主要对象能双向追溯；核心资料可恢复；你能解释关键判断；不依赖某个聊天上下文才能继续；无用插件和重复记录有明确暂缓/退役决定。
• 产物：records/acceptance/workbench-v2.md，列出完成项、已知限制和下一版本最多三个优先事项。
• 失败处理：未完成模块继续标为待办，允许已通过模块独立使用；不以全自动程度作为验收指标。

6. 软件、插件与 skill 选型表

下面的链接是官方调研入口，不代表本次已逐页核验。执行 A03 时补充实时证据、版本和结论。

6.1 软件与成熟方案

| 任务 | 默认候选 | 使用方式及采用条件 | 调研入口 |
|---|---|---|---|
| 采集 | 现有 research-intel-agent | 优先维护现有 OpenAlex/arXiv/PubMed 接入；补引用追踪时再评估其他 API | https://developers.openalex.org/ ; https://info.arxiv.org/help/api/ |
| 文献管理 | Zotero + Connector | 检查现有安装、备份、去重和 PDF；只读与导入权限分开配置 | https://www.zotero.org/support/ |
| 稳定引用键 | Better BibTeX | 核验当前 Zotero 兼容性，先少量条目测试，再设置导出；避免破坏既有 citekey | https://retorque.re/zotero-better-bibtex/ |
| 知识库 | Obsidian | 确定真实 Vault，直接 Markdown 可用；CLI 不可用时不必阻塞阅读 | https://help.obsidian.md/ |
| 笔记导入 | Zotero Integration | 与自建桥接二选一作为主写入通道，检查是否覆盖人工段落 | https://github.com/mgmeyers/obsidian-zotero-integration |
| 笔记辅助 | Templater、Dataview、Excalidraw | 分别用于模板、索引、手绘关系；都是可选，不是深读门槛 | https://github.com/SilentVoid13/Templater ; https://github.com/blacksmithgu/obsidian-dataview ; https://github.com/zsviczian/obsidian-excalidraw-plugin |
| 跨论文发现 | ResearchRabbit、Litmaps、Connected Papers | 作为补充引用探索，对同一主题比较覆盖、导出和学习成本；不同时采购 | https://www.researchrabbit.ai/ ; https://www.litmaps.com/ ; https://www.connectedpapers.com/ |
| 现成陪读/综述辅助 | NotebookLM、Elicit、SciSpace | 用同一 PDF 比较证据定位、图表解释、中文讨论、会话导出和数据条款；选一个试用 | https://notebooklm.google/ ; https://elicit.com/ ; https://scispace.com/ |
| PDF 解析 | 现有提取工具；必要时 Docling/GROBID | 只有实测解析质量不足才引入；公式和图表依然要对照页面 | https://docling-project.github.io/docling/ ; https://grobid.readthedocs.io/ |
| Python 环境 | 现有 venv/锁文件；新项目可试 uv | 沿用可工作的环境；CUDA/项目特殊要求下评估 Conda，不并行维护多套 | https://docs.astral.sh/uv/ ; https://docs.conda.io/ |
| 远端运行 | SSH + 项目脚本；按需 Docker | 先跑通一个作业和结果回收，再考虑更复杂编排 | https://docs.docker.com/ |
| 实验跟踪 | JSON/CSV 起步；按需 MLflow 或 W&B | 多轮比较需要 UI 时二选一；不引入双重指标事实源 | https://mlflow.org/docs/latest/ ; https://docs.wandb.ai/ |
| 数据版本 | manifest + 哈希 + 独立备份；按需 DVC | 数据多版本或协作确有需求时引入；DVC 不能替代实际存储和备份 | https://dvc.org/doc |
| 配置/调度 | 现有配置；按需 Hydra、SkyPilot | 多配置组合或跨云作业增多时再评估；不把调度器列为起步必装项 | https://hydra.cc/docs/intro/ ; https://docs.skypilot.co/ |
| GPU 租赁 | 国内或境外供应商择一 | 比较显存、区域、镜像、磁盘、出网、闲置费用和自动停止；以实际预算选择 | https://www.autodl.com/ ; https://docs.runpod.io/ ; https://docs.vast.ai/ |
| 写作出口 | Word 或 LaTeX 主出口二选一 | 内容初稿用 Markdown；Word 保留修订；LaTeX 可用官方模板/Overleaf | https://www.overleaf.com/learn |
| 文档转换 | 已有生成器；按需 Pandoc/Quarto | 先验证目标模板、公式、表格和引用转换，不同时迁移多个排版工具 | https://pandoc.org/ ; https://quarto.org/docs/ |
| 语言与格式辅助 | Writefull 或 Paperpal | 可试用辅助润色；不能替代事实、引用和目标模板核验 | https://www.writefull.com/ ; https://paperpal.com/ |

成熟的是分阶段工具能力。整套“选题正确、实验可靠、论文可投”的通用自主系统不能在未验证情况下直接认定成熟。优先采购/复用软件已有能力，自建你的会话记录、证据交接、预算约束和验收规则。

每个候选的安装验收记录至少包含：官方来源、维护状态、许可、版本、安装命令/客户端步骤、配置位置、密钥保存方式、样例结果、费用/数据条款、卸载和回退办法。最终采用之前不写无法验证的安装命令。

6.2 已有 skill 的使用分工

下列 skill 在当前可用目录中已列出，优先检查并使用现有版本，不重复安装。skill 是执行方法说明，不等于运行中的服务或已配置的 API。

| 阶段 | 主 skill | 按需补充 | 调用示例 |
|---|---|---|---|
| 发现 | 现有情报工具；需要补检索时 paper-lookup | daily-paper-generator | “补查该问题的相近工作，保留检索式和出处。” |
| 陪读 | deeppapernote | pdf、zotero-obsidian-bridge | “陪我读这篇论文，先讲问题与假设，疑问保留到会话记录。” |
| 整理 | obsidian-literature-workflow | obsidian-markdown、obsidian-cli | “根据已读来源生成对比笔记，保留推断与原文的区分。” |
| 方向 | research-ideation | academic-research-suite 的 deep-research | “比较这三个候选，先找相近工作和反证，再检查资源可行性。” |
| 实验 | academic-research-suite 的 experiment-agent | results-analysis、results-report | “把这个假设拆成有时限、预算和停止条件的首轮实验。” |
| 成文 | research-writing-skill 或 ml-paper-writing 选一个主写作规则 | citation-verification | “只用本批次确认材料写内容初稿，附主张与证据映射。” |
| 内容审阅 | paper-self-review 或 ARS reviewer | citation-verification | “审核人工修改稿，定位数字、引用和结论不一致。” |
| 格式审核 | documents、pdf | journal-intelligence | “按指定官方模板审结构、引用、图表并逐页检查渲染。” |

同一步不要同时叠加多个互相竞争的总写作 skill。ARS 按当前阶段加载相应 workflow。统计和绘图 skill 只在实际分析需要时加载。文档类工具的格式能力要通过目标样例验收，不能只看 skill 名称。

7. 推荐推进节奏

时间为工作量规划，假设每天有连续可用时间；论文阅读、数据申请、实验排队和算力费用另计，不承诺固定完成日期。

| 批次 | 工作范围 | 结束时必须看到 |
|---|---|---|
| 第一批 | A01–A04、B01–B04 | 明确资料归属，现有采集稳定，两篇真实论文可交给陪读 |
| 第二批 | C01–C04 | 一次可恢复的陪读会话、两篇思想卡、有证据的横向比较 |
| 第三批 | D01–D04 | 一个主研究问题、相近工作/反证、可行性探测和实验预算 |
| 第四批 | E01–E05，准备 F01 | 一个有成本和证据记录的实验周期 |
| 第五批 | F02–F05 | AI 内容初稿、人工修改、独立内容和格式审核 |
| 第六批 | G01–G03 | 能复制到第二项目的能力，以及可持续的日常入口 |

最先执行 A01，然后 A02。取得两篇可靠全文后优先验证 C02 的陪读体验；若陪读本身没有帮助，就先调整交互方法，不急着扩展远程实验与自动写作。

8. 验收记录与后续任务模板

每项复制一份以下记录，放在任务下方或单独的 records/acceptance/<任务编号>.md。建议每条只记录最有用的证据，不粘贴全量日志。

任务编号：
当前状态：
执行日期：
实际改动：
代码/文档版本：
验证样例与命令：
验收证据路径：
人工体验结论：
耗时与费用：
剩余问题或阻塞：
回退方式：
验收人及日期：
下一项：

后续任务可以使用以下提示：

请读取桌面的《科研工作台改造计划-逐项验收版-2026-09-14.md》，只实施任务【编号】。先核对依赖、已存在的实现和我的最新备注；如已实现，验证并复用。按该项验收标准完成，记录文件路径、测试/样例结果和剩余问题。涉及尚未明确的真实费用或数据用途时先列出具体选择，其余可逆工作继续推进。不要把历史实验版本或人工审核状态改写成未经确认的新事实。

格式审核的明确入口示例：

请对【稿件路径】按【官方指南/模板路径】做最后一轮格式审核。先记录稿件和模板版本，检查章节、引用、图表、公式和声明，再导出 PDF 逐页检查。问题按位置列出；内容/证据疑点独立列出。审核报告必须说明未能自动或人工确认的项目。

9. 文档验收问题

• 能否找到现在应该从哪一项开始？答案：A01，然后 A02；取得可靠全文后验证 C02。
• 是否需要把表中软件全部安装？答案：不需要，A03 用相同样例选择最小组合。
• 能否让一个 Agent 包办所有角色？答案：可以复用同一运行工具，但写作和审阅应采用不同说明与独立会话，证据仍由原文和实验支撑。
• 何时租服务器？答案：D04/E01 得到资源需求和预算后，执行 E02。
• 人改过稿子后旧审核是否仍算通过？答案：不能自动沿用，F03/F04 对新稿版本重新核验受影响部分。
• 现在就能运行计划里拟新增的命令吗？答案：不能，先实施对应任务；现有入口应在 A01 中确认。
• 本计划是否已经调研确认所有软件当前功能和价格？答案：没有，A03 是必须补做的选型验证。

文档整理依据：本任务中 2026-09-08 的工作台盘点、2026-09-13 的五阶段需求讨论，以及 2026-09-14 对现有情报工具和模板 README 的复核。历史结论均保留日期，不充当当前在线验收证据。

原始文档

下载原始文档