在 Hacker News 上有一个几乎是“长期置顶”的问题How do you use LLMs for your research?每次讨论都会吸引大量研究人员分享自己的 workflow。有人把 LLM 当作文献阅读加速器有人用它生成数据处理代码有人只用它润色英文表达。仔细看这些回答会发现真正从 LLM 里获益的人没有一个指望模型直接替自己“完成研究”。他们都在做同一件事把研究流程拆成可校验的小任务然后为每个任务设置一道人工把关的关卡。这个判断是本文的核心。LLM 在科研中的价值不是自动生成结论而是把研究人员从重复劳动里解放出来。它改变最明显的环节是文献阅读、综述整理、代码编写和论文润色——这些工作耗时、繁琐又不构成研究的核心智力产出。至于研究判断、实验设计、结果审查和最终结论依然必须由人完成。本文会从研究者的真实工作流出发分四个部分展开LLM 适合做科研中的哪些任务、如何用 RAG 搭建个人研究知识库、如何让 LLM 辅助代码与数据分析以及自己跑模型时 fp16/fp32/bf16 精度选择会带来哪些影响。文章最后会整理常见问题的排查思路和工程建议。如果你正在做文献综述、跑实验、写论文或者打算把本地论文资料做成个人知识库这篇文章会比较贴近你的需求。1. 研究人员用 LLM真正卡在哪个环节很多研究新手第一次接触 LLM 时都会尝试一种“终极用法”把整个研究问题丢给模型希望它返回一段可直接写进论文的答案。结果通常不理想得到的是一堆笼统的正确废话甚至还有虚构的引用。于是有人得出结论LLM 对科研没有用。这个结论下得太早了。真正的问题不在模型而在使用方式。回顾常见的失败场景大概有三种典型误区。第一种误区是把 LLM 当成搜索引擎。直接向模型询问一个具体事实比如某篇论文的准确结论、某个数据集的版本然后不加验证直接引用。LLM 是语言模型不是数据库它的答案是“根据训练数据生成的最可能文本”不是“查到的确切事实”。一旦训练数据里没有这个信息模型就会用自己的方式补全幻觉就此产生。第二种误区是把 LLM 当成论文代写器。让它直接生成摘要、引言甚至实验章节。LLM 确实能写出结构完整的段落但这些内容没有真实实验支撑也经常缺少关键细节。用它生成的段落做骨架再填充自己的实验内容效果会好很多直接当成成品用论文质量会非常空洞。第三种误区是把它当成万能 Agent。一个提示词里塞进五六个任务比如“读完这些论文总结它们的方法比较优缺点再给出我的创新点”。模型看起来完成了但每个子任务都没有达到足够深度而且一旦某个环节依赖外部事实错误就会一路传导。正确做法是把研究当成一条流水线让 LLM 负责流水线上可自动化的“中间产物”环节。比如文献阅读阶段让 LLM 生成论文结构化摘要而不是让它评价论文价值。综述阶段让 LLM 生成对比表格初稿再由人工核对原文。实验阶段让 LLM 编写数据处理函数而不是设计整个实验。写作阶段让 LLM 改写句子、优化表达而不是生成实验结果。这个思路的关键在于LLM 的输出始终是初稿不是终稿是候选不是结论。开发者需要在这些输出上建立校验点把模型结果转成自己确认过的知识。2. 研究流程中的 LLM 任务清单哪些能用哪些要谨慎为了更好地判断 LLM 在科研中能做什么、不能做什么下面按研究阶段整理了一份任务清单。每个任务都标注了 LLM 的参与程度和人工需要承担的职责。研究阶段LLM 可承担的工作人工必须负责的部分风险等级文献检索生成关键词组合、语义查找相关论文、筛选候选集确认论文是否与课题相关核对来源中文献阅读提取摘要、整理方法、生成论文结构化笔记核对关键公式、实验数据、引用是否准确中高文献综述生成比较矩阵、横向对比图表初稿逐条验证对比结论补齐遗漏文献高研究想法头脑风暴提问、反向思路、列出备选假设评估可行性查阅文献支撑设计验证方案中实验设计拆分消融实验、列出基线方案、生成实验提纲确认实验逻辑合理、资源可承受、指标可复现中代码编写编写数据处理脚本、生成绘图代码、定位报错审查逻辑、运行测试、监控输出是否合理中论文写作生成段落初稿、润色语言、改写投稿信核对数据、实验细节、引用准确性和定稿决策高审稿反馈模拟审稿人提问、列出论文弱点判断问题是否真实存在决定修改方向中从风险等级可以看出一个规律凡是需要“生成事实”的任务风险都偏高凡是“优化表达”和“转换结构”的任务风险都偏低。这不是说高风险任务不能用 LLM而是说使用时必须引入外部校验。以文献阅读为例传统的做法是下载 PDF 后自己通读全文标重点、记笔记、写总结。一篇论文少则三四页多则十几页一个阶段读几十篇论文纯人工整理对比信息会消耗大量时间。用 LLM 辅助后可以先把 PDF 里的内容抽出来让模型按要求输出“研究问题、方法、数据集、指标、结论”五个字段生成结构化笔记。人只需要核对这些字段是否和原文一致再去判断这些字段对当前研究有什么意义。从“从零整理”变成“校对初稿”节省的正是整理动作本身。文献综述阶段是 LLM 最容易“翻车”的场景。让模型对比两篇论文的方法差异它可能会编造一个论文里根本没有的细节。稳妥的用法是先让模型分别提取每篇论文的方法描述再由人工确认然后让模型基于已确认的描述做对比。所有对比结论都必须能回指到原文否则不放进综述草稿。实验设计阶段LLM 更适合做“发散候选”而不是“最终方案”。比如告诉模型你的研究问题和资源约束让它列出可能的消融实验组合、潜在基线和评测指标。这些候选会有很多不切实际的选项但也能提供一些容易被忽略的角度。人再根据领域知识和资源条件做筛选。论文写作阶段LLM 最适合做两件事第一把口语化的中文描述改写成规范的学术表达第二把一段冗长的表述压缩成投稿要求的长度。让 LLM 直接生成实验结果、生成对数据的解读则是高风险行为因为语言模型对数字和实验细节没有真实感知生成的内容看起来流畅实际上可能与实验结果完全脱节。3. 直接对话不够用RAG 是研究场景的必修课在研究场景里直接和大模型对话往往不够。原因有三个知识截止日期、幻觉、私有资料无法访问。知识截止日期意味着模型只知道训练数据截止之前的论文和方法最新研究进展它看不到幻觉意味着模型会在不确定时生成看似合理的虚构内容而且越流利越有欺骗性私有资料无法访问意味着你实验室内部的技术报告、你自己写的实验笔记、没公开的推导过程模型完全不知道。这三类问题不能靠“换个更大模型”解决因为它们本质上是信息获取问题不是推理能力问题。解法就是RAG检索增强生成。RAG 的思路非常简单模型回答之前先从外部知识库里检索出与问题相关的片段把这些片段作为参考材料拼进上下文再让模型基于这些材料作答。RAG 的核心链路是五步采集、切分、向量化、检索、生成。第一步采集把论文 PDF、网页、笔记统一收进一个目录。第二步切分因为大模型上下文有长度限制也为了让检索更精准文本需要按一定粒度切成片段。第三步向量化用嵌入模型把每个片段变成向量。第四步检索把用户的问题也变成向量在文档向量里找最相似的几个片段。第五步生成把检索到的片段和问题一起交给 LLM让它只依据片段内容生成答案。把“直接问 LLM”和“RAG”对比着看差别会更清楚维度直接对话RAG 检索增强知识来源模型内部训练数据外部知识库可自主控制时效性受训练数据截止时间限制可随文档更新幻觉风险较高通过约束“只依据上下文回答”能明显降低私有资料无法访问可以纳入检索范围实现成本低需要向量化与检索组件RAG 特别适合研究者的一个原因是它能和大家的文献管理习惯无缝衔接。比如很多人在 Obsidian 里管理论文笔记用 LLM Wiki 之类的插件把笔记和论文变成可检索的个人知识库。这个所谓的“LLM Wiki 范式”本质上就是 RAG 在个人知识管理场景的具体落地论文库变成向量数据库提问时不是让模型凭记忆答而是先从库里检索相关段落再回答。你收藏的每一篇论文、写过的每一段笔记都变成了模型回答时可参考的“私有资料”。对刚开始接触这个方向的开发者我的建议是不要一上来就搭建复杂的编排框架先把一条最小链路跑通准备 5 篇论文 PDF用脚本切分并向量化写一个检索函数再调用模型基于检索结果提问。跑通之后再考虑加更复杂的重排序、多路召回或者引入 Agent 编排框架。4. 搭建个人研究知识库从论文 PDF 到可检索向量的最小示例这里用一个最小示例演示如何把论文 PDF 变成可检索的个人知识库。示例使用 Python依赖尽量少只用到三个基础库pymupdf负责 PDF 文本抽取sentence-transformers负责向量化numpy负责相似度计算。这个方案不依赖特定的向量数据库方便理解 RAG 的完整链路也方便将来迁移到更工程化的组件。4.1 安装依赖pip install pymupdf sentence-transformers numpy如果你的机器没有 GPUsentence-transformers依然可以在 CPU 上运行速度慢一些但可用。嵌入模型建议选择一个适合中文或英文文献的通用模型比如BAAI/bge-small-zh-v1.5或BAAI/bge-small-en-v1.5实际选型可以根据你的语料语言决定这里只演示流程。4.2 文档加载与切分新建build_index.py写入以下代码import fitz import numpy as np from sentence_transformers import SentenceTransformer def extract_text_from_pdf(pdf_path: str) - str: doc fitz.open(pdf_path) pages [] for page in doc: pages.append(page.get_text()) return \n.join(pages) def chunk_text(text: str, chunk_size: int 500, overlap: int 50) - list[str]: chunks [] start 0 while start len(text): end start chunk_size chunk text[start:end] if chunk.strip(): chunks.append(chunk) if end len(text): break start end - overlap return chunks if __name__ __main__: pdf_path paper.pdf raw_text extract_text_from_pdf(pdf_path) chunks chunk_text(raw_text) print(f切分得到 {len(chunks)} 个片段) model SentenceTransformer(BAAI/bge-small-zh-v1.5) embeddings model.encode(chunks, normalize_embeddingsTrue) np.save(paper_chunks.npy, np.array(chunks, dtypeobject)) np.save(paper_embeddings.npy, embeddings)这段代码做了三件事读取 PDF 全文按固定长度切分成片段用嵌入模型把每个片段转成归一化向量。normalize_embeddingsTrue表示向量已归一化后续计算余弦相似度时可以直接用点积。这里的切分方式是为了演示实际项目中可以更精细。比如按标题切分或者按段落边界切分。切分粒度直接影响检索效果太小信息不完整太大噪音多而且容易超过模型上下文限制。一个常见的经验值是把片段控制在 300 到 800 字之间并保留少量重叠避免关键信息被切断。4.3 语义检索新建search.py实现检索功能import numpy as np from sentence_transformers import SentenceTransformer chunks np.load(paper_chunks.npy, allow_pickleTrue) embeddings np.load(paper_embeddings.npy) model SentenceTransformer(BAAI/bge-small-zh-v1.5) def search(query: str, top_k: int 3) - list[str]: q_emb model.encode([query], normalize_embeddingsTrue)[0] scores embeddings q_emb top_idx np.argsort(scores)[::-1][:top_k] return [(chunks[i], float(scores[i])) for i in top_idx] if __name__ __main__: query 这篇论文提出的方法核心是优化哪个环节 for chunk, score in search(query): print(得分:, round(score, 4)) print(chunk[:200].replace(\n, )) print(---)运行python search.py会看到检索出的片段和相似度得分。这一步可以验证两件事论文文本是否正确抽取向量检索是否能找到与问题相关的段落。如果检索结果明显不相关优先检查 PDF 文本抽取是否完整以及切分粒度是否合适。4.4 让 LLM 基于检索结果回答检索到相关片段之后下一步是让 LLM 基于这些片段回答。这里的关键是提示词约束明确要求模型只使用上下文中的信息。先准备一个 Prompt 模板你是一名研究助理请根据提供的资料回答问题。 要求 1. 只能引用资料中明确出现的信息。 2. 如果资料中没有相关信息直接回答“资料中未找到相关内容”不要编造。 3. 回答时标注信息来源引用原句时用引号标注。 资料 {context} 问题 {question}然后用本地模型或 API 模型调用。以本地模型为例使用 Ollama 的 Python SDK 调用import ollama question 这篇论文提出的方法核心是优化哪个环节 retrieved search(question, top_k3) context \n\n.join([f[片段{i1}] {chunk} for i, chunk, _ in enumerate(retrieved)]) prompt f你是一名研究助理请根据提供的资料回答问题。 要求 1. 只能引用资料中明确出现的信息。 2. 如果资料中没有相关信息直接回答“资料中未找到相关内容”不要编造。 3. 回答时标注信息来源。 资料 {context} 问题 {question} response ollama.chat( modelqwen2.5:7b, messages[{role: user, content: prompt}] ) print(response[message][content])这段代码中的模型名qwen2.5:7b只是一个例子实际必须以你本机安装的模型为准。如果你的环境里没有 Ollama也可以把这段逻辑替换为 OpenAI 兼容接口只需要把base_url指向本地推理服务并配置对应的 API Key。从这一步开始你已经拥有一个最小可用的“个人论文知识库”。当需要扩展到更多论文时可以按论文标题维护独立的向量文件也可以引入真正的向量数据库。但建议先把这条路跑通再考虑工程化。5. 用 LLM 辅助代码与数据分析的正确姿势科研代码和工程代码不同科研代码的核心诉求是“验证想法”而不是“长期维护”。研究人员写出能跑通数据预处理、回归分析、结果绘图的代码往往比写一个设计精良的软件系统更急迫。LLM 在科研场景的代码能力恰恰适合这种短周期任务。一个比较稳妥的使用方法是把需求描述成“输入、处理、输出”三件套让 LLM 生成最小函数。下面是一个数据分析场景的提示词示例。我正在用 Python 分析实验数据请帮我写一个数据处理函数。 输入一个 CSV 文件文件名是 logs.csv包含列 timestamp, user_id, action, duration, status 处理要求 1. 过滤掉 status 为 failed 的行 2. 只保留 action 为 click 和 view 的记录 3. 统计每个 user_id 每天的平均 duration 4. 输出结果保存为 daily_user_duration.csv。 要求 1. 使用 pandas 2. 先简单解释你的思路再给出完整代码 3. 代码中标注中文字段名的含义 4. 如果某一步存在边界情况比如时间格式不一致请在注释里说明。提示词里的“先解释思路再给代码”很关键。因为 LLM 在生成代码时如果先进行推理代码质量通常会更高结构也更清晰。要求它标注注释则能让你快速判断代码是否符合预期也方便后续人工修改。数据预处理类任务的成功率通常比较高因为需求明确、输入输出清晰、依赖库标准化。但有两类任务要特别小心。第一类是可视化代码。LLM 生成的绘图代码经常出现“看似合理但运行失败”的情况最常见的原因是 Matplotlib 的中文字体配置以及不同版本之间的 API 差异。稳妥做法是不要把整个绘图需求一次性丢给模型而是分两步。第一步让模型生成“读取并处理数据”的部分确认数据正确之后第二步再让模型生成“绘图”的部分。绘图部分如果失败把完整报错信息贴给模型修复。第二类是涉及外部数据的代码。如果数据文件路径、列名、编码方式没有描述清楚模型生成的代码很难直接跑通。把这些信息当作提示词里必须描述的部分可以有效减少错误。数据隐私是科研场景里经常被忽略的问题。不要把包含受试者隐私、患者信息、未公开实验数据的内容直接发送到公开 API 服务。优先使用本地模型或者对数据做脱敏处理后再调用外部服务。在团队协作场景中还要确认数据使用是否符合机构的数据管理制度。代码辅助方面还有另一个容易踩的坑LLM 会生成“看起来对但不完整”的代码比如缺少异常处理、没有设置随机种子、忽略了数据泄露问题。科研代码里随机种子和数据划分顺序直接决定实验结果能否复现。建议在提示词里显式要求模型设置随机种子并在代码运行后检查结果是否符合预期。6. 自己跑模型必须懂的精度问题fp16、fp32、bf16很多研究者用 LLM 做辅助时只是调用 API这种场景下精度由服务提供方管理使用者不需要关心。但如果你想在本地跑模型、做微调或者复现别人论文里的实验就必须理解精度问题。从最近很多人的搜索习惯来看关于 fp16、fp32、bf16 的精度问题已经成为本地跑模型的高频坑。先解释为什么精度重要。大模型的参数和中间计算结果需要保存为浮点数。浮点数用有限的二进制位表示数值位数不同能表示的数值范围和精度就不同。如果精度不够训练时可能出现 loss 不下降、梯度爆炸、NaN 等问题推理时则可能出现输出质量下降、生成内容不可复现。三种常见精度的区别如下fp32单精度浮点数用 8 位指数和 23 位尾数表示数值动态范围和精度都高但占用的显存也最大。通常作为训练的基准精度。fp16半精度浮点数用 5 位指数和 10 位尾数表示数值显存占用减半但动态范围较小。当数值超过可表示范围时容易溢出成无穷大或 NaN。bf16脑浮点数用 8 位指数和 7 位尾数表示数值动态范围与 fp32 一致但尾数精度低。表示大数时不容易溢出但小数部分的精度较差。三者的对比可以放在一张表里精度类型指数位尾数位动态范围精度显存占用典型场景fp328 位23 位大高高训练基准、对精度敏感的计算fp165 位10 位小中中部分推理加速注意溢出风险bf168 位7 位大低中大模型训练、梯度计算在 PyTorch 中如果直接强制把模型转换成 fp16 再推理遇到动态范围不够的情况就可能出现数值异常。一个更稳妥的做法是用混合精度也就是让模型在 fp32 下计算关键部分在 fp16 或 bf16 下计算其他部分。import torch model model.to(cuda) # 使用自动混合精度bf16 更适合大模型训练 with torch.autocast(device_typecuda, dtypetorch.bfloat16): output model(input_ids) loss output.loss loss.backward()这段代码展示的是混合精度训练中 forward 和 backward 的典型写法。torch.autocast会自动决定哪些算子使用低精度、哪些保持高精度比手动强制转换更安全。如果你遇到 loss 变成 NaN可以先检查精度设置把低精度切回 fp32 验证。在研究和复现场景精度选择有一个基本原则如果实验结果是稳定的、可复现的用什么精度不重要如果实验结果不稳定或者和论文报告不一致请先检查精度设置。很多所谓的“模型效果变差”根本不是模型能力问题而是推理或训练时的精度设置导致数值发生了偏移进而引发输出质量下降。给实际使用者的建议是分场景对待。如果你只是做推理显存不足时可以先尝试 fp16 或量化方案用验证集检查输出质量是否可接受。如果你是做微调建议优先尝试 bf16因为它动态范围和 fp32 一致不容易溢出显存压力也小。如果你在做数值敏感的计算比如语言模型的对数概率计算、指标评估或者复现论文中的数值结果尽量使用 fp32避免精度损失影响结论。对大模型训练而言bf16 已经成为非常常见的选择核心原因就是尾数精度低一点通常不影响收敛方向而动态范围大能避免梯度溢出。不过具体选型还要依赖你的 GPU 是否支持对应精度以及代码框架的能力。遇到不确定的情况最简单的验证办法是用同一份数据跑两次不同精度对比结果差异是否在可接受范围内。7. 常见问题与排查思路研究场景接入 LLM 后问题最容易出现在检索、调用和精度这三个环节。下面整理了几个高频问题方便按图索骥。问题现象可能原因排查方式解决方案模型回答出现不存在的论文或引用LLM 幻觉生成了训练数据中不存在的组合检查回答内容是否能在检索片段中找到对应语句启用 RAG并要求模型只依据提供的上下文回答上下文越长回答质量越差超出模型有效注意力范围关键信息被淹没观察问题所需信息在上下文中的位置缩短单次上下文长度检索 top_k 控制在 3 到 5向量检索经常搜不到相关内容文本切分不当或嵌入模型选型不匹配打印检索片段检查语义相关性调整切分粒度和重叠长度尝试不同嵌入模型本地模型推理很慢或爆显存模型规模太大或精度选择不当查看显存占用与推理耗时换更小模型或使用量化方案调用 API 时报“文本向量 API 未配置”没有配置嵌入模型的接口、密钥或模型名检查环境变量和 SDK 配置项补全 base_url、API Key 和模型名配置本地结果和论文报告不一致随机种子、精度或依赖版本不同对比复现环境的依赖清单固定随机种子统一依赖版本必要时切换到 fp32幻觉是研究场景最严重的风险点。开发者需要意识到模型的流畅回答和真实信息不是一回事。RAG 能显著降低幻觉但不能完全消除。即使模型基于检索片段回答它仍然可能在归纳时引入偏差。因此在使用 RAG 时提示词里必须明确约束模型“如果资料中没有相关内容必须说不知道”。同时任何写进论文的引用都必须回到原始文献里核实。上下文长度不够也是一个高频问题。很多人习惯把整篇论文复制进对话结果生成的总结丢失了大量细节。更合理的做法是先用检索找到关键段落只把相关段落放进上下文。这样既节省模型额度也提高回答精准度。向量检索效果不好时首先要排查的是切分。如果切分后片段太短检索可能只命中局部信息如果太长片段主体可能与问题无关。其次是嵌入模型选型。通用嵌入模型对领域术语的理解有限如果预算允许可以尝试针对学术文本做过适配的嵌入模型或者增加候选检索数量再做重排序。本地推理的显存问题通常需要和精度选择一起考虑。大模型用 fp16 推理比 fp32 节省一半显存量化方案还能进一步压缩。但如果量化导致输出质量明显下降就要权衡是换更小模型还是增加显存。“文本向量 API 未配置”这类问题在调用 OpenAI 兼容接口或本地推理服务时比较常见。排查顺序是先确认环境变量名和 SDK 读取的配置名是否一致再确认 base_url 是否正确最后确认模型名是否与服务端实际模型匹配。这类问题多数情况下是配置项拼写或路径问题。8. 科研工作流接入 LLM 的最佳实践与工程建议从工程角度把 LLM 接进科研工作流不是为了追求“全自动”而是为了把人的注意力集中在真正需要判断力的地方。要做到这一点建议在流程上做三层隔离。第一层是“事实层”。论文、报告、笔记这些外部资料应该进入 RAG 知识库由检索环节负责定位。模型在这层不允许凭记忆回答事实问题只能引用检索到的内容。这层的关键是资料的组织方式和检索质量。第二层是“草稿层”。文献总结、代码初稿、段落润色都可以让 LLM 生成。草稿层的核心原则是保持可丢弃的心态模型生成的初稿只是参考不是必须沿用的结果。如果你发现自己舍不得丢弃模型的任何输出说明你对质量的控制力正在下降。第三层是“结论层”。实验设计、数据解读、最终投稿版本这些必须由人完成。模型可以辅助提供候选方案但最终决策必须建立在你自己的判断之上。除了流程分层还有一些具体的工程建议值得落实。保持 prompt 模板的版本化。把常用的提示词写进统一文件标注版本号。文献总结模板、代码生成模板、审稿模拟模板都可以单独存档。这样即使模型升级或接口变化你也能知道之前用的是什么样的提示词实验结果的可复现性会强很多。重要实验记录 LLM 的模型版本、温度参数、检索到的片段和 prompt 版本。研究中一个容易被忽略的事实是同一个问题换一个模型版本回答可能完全不同。如果不记录这些参数后续想追溯结果会非常困难。引用必须回原文。用户问“这篇论文的观点是什么”时先让模型输出原文引用再让模型做改写和总结。不要在 RAG 环节跳过原文引用直接让模型生成综述。养成这个习惯后综述里的每个观点都能定位到原始论文。数据隐私和合规边界要单独把关。本地模型通常是更安全的选择至少在数据离开本机前要明确知道它去了哪里。涉及敏感数据的场景建议完全使用本地模型并且使用与外部服务隔离的网络环境。关于工具链选型有一个容易被忽略的建议不要过度纠结哪个框架最流行、哪个工具最先进。先把一个最小链路跑通比同时尝试五个框架更有价值。Ollama、LM Studio 这类本地推理工具随便选一个跑通即可知识库可以先用文件和一个 Python 脚本之后再迁移到更完整的方案。如果你在团队场景里使用还建议做一个共享的约定。至少包括哪些环节允许使用 LLM、哪些环节禁止使用、调用外部 API 时哪些数据可以传、prompt 模板谁来维护、LLM 生成内容是否需要经过第二人校对。这些约定看起来不产生代码价值但能避免很多协作中的灰色地带。9. 总结把 LLM 嵌进研究流程而不是让 LLM 代替研究回到开头那个问题How do you use LLMs for your research? 答案不在模型本身而在工作流设计。把 LLM 当成研究流程的加速器它就能在文献阅读、RAG 知识库搭建、代码辅助、论文润色这些环节里帮你节省大量时间把 LLM 当成研究本身它就会用流畅而空洞的文本制造一种“研究已经完成”的错觉。现在已经不需要争论“要不要用 LLM 做研究”真正值得投入精力的是研究流程中的人工校验点。模型可以生成摘要、草稿、候选方案、代码初稿但研究者的判断力——什么值得探索、什么结果可信、什么证据充分——是 LLM 无法替代的。建议从一个小任务开始实践挑选 5 篇你最近要精读的论文放进本地知识库用 RAG 的方式总结它们的方法和结论。跑通之后再逐步扩展论文库规模尝试加入重排序、更细的切分策略或者引入 Agent 编排框架做更复杂的自动化。这个过程中的每个步骤都是一次关于“哪些环节能自动化、哪些环节必须人来做”的深入理解。