读研读博真正消耗人的，往往不是"想不出 idea"，而是被切碎在几十件琐事上：读不完的文献、跑不通的代码、画不完的图、改不完的稿、回不完的邮件、整不完的参考文献格式。一天十几个小时下去，真正的深度思考时间可能不到两小时。
这篇讲的是怎么把其中大约 80% 的机械性工作交给 AI 智能体（AI Agent）去做，把自己的时间压缩回"提问、判断、决策"这三件事上。重点不是推荐某一个具体产品，而是讲清楚一套可落地的科研智能体工作流：它由什么组成、本地跑还是走接口、需要什么硬件、怎么启动、怎么验证效果、批量任务怎么设计、踩坑了怎么排查。
需要提前说明的是，本文不涉及任何论文代写、数据伪造、文献编造的内容。智能体在科研里的正确定位是"降低摩擦的执行层"，不是"替你产出结论的思考层"。这条边界在后面会单独用一节展开，因为它决定了你是真的提效，还是在给自己埋雷。
下面从能力拆解开始，逐步走到部署、测试、接口和排错，读完你应该能自己搭一套跑起来。
1. 核心能力速览
先给一张表，把科研智能体的能力边界、门槛和形态说清楚。表里凡是材料无法确认的参数，统一写"需按实际环境测试"，不做数字层面的承诺。
| 能力项 | 说明 |
|---|---|
| 项目类型 | 科研工作流自动化，基于大模型 + 工具调用的智能体编排 |
| 主要功能 | 文献抓取与摘要、批量阅读笔记、代码生成与调试、数据分析脚本、图表绘制、写作润色、审稿意见归类、参考文献格式化 |
| 运行形态 | 本地脚本 / WebUI / 接口服务 / 定时任务，四种形态可组合 |
| 模型来源 | 云端 API（OpenAI 兼容接口为主）或本地开源模型（7B~32B 量级常见，具体取决于量化方式和上下文长度） |
| 硬件门槛 | 纯 API 方案对本地硬件几乎无要求；本地推理需要独立显卡，显存需求以实际模型和上下文长度为准 |
| 是否支持 CPU | 支持，但速度明显低于 GPU，适合小批量、非实时任务 |
| 是否支持批量 | 支持，核心就是批处理队列设计 |
| 是否支持 API | 支持，主流框架都提供 HTTP 服务和函数调用能力 |
| 启动方式 | 命令行脚本 / Docker / 一键启动面板 |
| 适合场景 | 文献综述初筛、实验代码脚手架、数据清洗、期刊回复整理、周报日报自动化 |
| 不适合场景 | 代替你下结论、代替你验证实验、生成不可核查的参考文献 |
这张表里最值得关注的是"运行形态"和"模型来源"两行。因为它们直接决定了你要不要买显卡、要不要折腾环境。如果你的科研任务主要是文本类（读文献、写代码、整理笔记），走 API 方案性价比最高，本地一台普通笔记本就能跑编排层，模型推理交给远端。如果你的任务涉及敏感数据、未发表成果、临床或涉密材料，那必须走本地推理，硬件投入就绕不开。
另一个容易被忽略的点是"是否支持批量"。科研里绝大多数痛点是批量问题：100 篇 PDF、50 组实验数据、30 份审稿意见。单次对话式交互解决不了这类问题，必须用队列 + 循环 + 失败重试的结构。后面第 7 节会专门讲这个。
2. 科研场景拆解：哪 80% 可以交给智能体
要谈"交给 AI"，先得把科研流程拆成颗粒度足够细的任务，再逐个判断哪些适合自动化、哪些必须人来做。粗颗粒地说"用 AI 写论文"是没有操作性的，细颗粒地说"用智能体把 PDF 转成结构化笔记并写进本地知识库"才是可执行的。
2.1 文献层：从"读不完"到"筛得准"
文献环节的机械劳动集中在三块：检索、初筛、结构化记录。
检索阶段，智能体能做的是把你的研究问题拆成多组检索式，分别去不同数据库跑一遍，把结果去重合并。这一步的价值在于"穷举"，人手动做很容易漏掉同义表述。初筛阶段，智能体可以按摘要做相关性打分，把明显不相关的先剔掉，你只需要看剩下的那部分。结构化记录阶段，智能体把每篇论文的方法、数据集、指标、局限性抽成固定字段，写进本地笔记库。
这里有个关键设计：不要让智能体直接给"这篇论文好不好"的结论，而是让它抽取客观字段。因为"好不好"需要你的领域判断，而"用了什么数据集、对比了哪些基线、报告了什么指标"是可以客观核验的。把主观判断留给人类，把客观抽取交给机器，这是文献环节最稳的分工。
2.2 代码与实验层：脚手架 + 调试助手
实验代码的痛苦在于重复劳动：读数据、切分、训练循环、日志、指标记录、画图。这些每次都要写，每次都有细微差异。智能体在这里的定位是"脚手架生成器"——你说清楚数据格式和目标，它给你一个能跑的最小骨架，然后你自己往里填核心逻辑。
调试环节价值更大。报错堆栈贴进去，让它先做归因，再给修复建议。注意这里必须保持怀疑：智能体给出的修复方案有相当比例是"看起来对但实际会让另一处崩掉"。稳妥的做法是让它先解释报错原因，你确认原因判断对了，再让它改代码。跳过原因确认直接改，返工率会很高。
2.3 数据与图表层：脚本化优先
数据分析这块，智能体最擅长的是把"我想要一张什么图"翻译成绘图代码。你描述清楚 x 轴是什么、y 轴是什么、分组维度是什么、要什么风格，它给代码，你跑一遍看结果。改图的时候也不用重新描述，直接说"字号调大、图例放右上、去掉网格线"就行。
但要注意一个红线：统计检验和结论性分析不能让智能体替你决定。它可以把 t 检验、方差分析、相关性分析的代码写出来，但用什么检验、样本量够不够、假设是否满足，必须你自己判断。代码错了可以重跑，统计方法选错了，整篇论文的结论都要推翻。
2.4 写作与投稿层：润色可以，观点不行
写作环节适合交给智能体的是：语言润色、结构检查、逻辑连接词优化、参考文献格式统一、图表标题规范化、投稿信模板化生成、审稿意见归类。
审稿意见回复这个场景特别值得做自动化。把审稿人的所有意见拆成条目，逐条判断是"需要补实验"、"需要改表述"还是"需要解释澄清"，然后生成一个回复框架。这一步能省掉大量整理时间，因为审稿意见往往是散落在几段话里的，人工拆条很费神。
不合适的部分也很明确：核心论点、创新点表述、实验设计思路，这些必须你自己写。智能体润色出来的语言确实更顺，但它不知道你的贡献边界在哪，很容易把"我们做了 A"润色成"我们首次实现了 A"，这种表述在审稿场上是要命的。
2.5 事务层：真正被低估的部分
还有一类完全不属于"科研"但占用大量时间的任务：组会 PPT 整理、周报生成、日程安排、邮件分类、报销单填写、文献 PDF 重命名归档、参考文献库维护。
这些任务的共同特点是规则明确、容错率高、失败了也没什么大后果。正是最适合全自动化的部分。很多人只想着用 AI 搞科研，结果被这些琐事拖垮。先把事务层自动化掉，你会立刻感觉到时间被释放出来了。
3. 适用边界与学术合规红线
这一节必须单独讲，因为它决定你的提效是正收益还是负资产。
第一条红线：智能体不能作为结论来源。它生成的任何事实性陈述都需要你回溯到原始文献或原始数据去核验。尤其是参考文献，大模型编造文献是已知的常见问题，作者名、期刊名、年份、DOI 都可能看起来极其真实但完全不存在。所有引用必须回到数据库里逐条确认。
第二条红线：不能把未发表数据传给不可控的第三方服务。如果你的实验数据涉及合作方保密协议、临床伦理审批、专利申请中的技术方案，那必须走本地推理或者经过审批的内部服务。这一点没有变通空间。
第三条红线：不能用于代写。语言润色和结构建议属于工具使用，整段生成属于学术不端。判断标准很简单：如果审稿人问"这段的核心思路是怎么来的"，你能不能说清楚推导过程。说不清楚的部分，就不该由智能体生成。
第四条红线：涉及人的数据要额外谨慎。图像、语音、访谈记录、问卷原始数据，即使做了匿名化，也可能通过组合特征被重新识别。这类数据进入任何自动化流程前，都要先确认伦理审批覆盖范围。
除了红线，还有一层"效率边界"值得说：不是所有任务都值得自动化。判断标准是这个任务重复频率 × 单次耗时 是否大于 搭建自动化的成本。一次性任务、每月一次的任务，直接手动做更快。天天做的、每周做好几次的，才值得投入时间搭流程。这个判断做错了，你会陷入"为了自动化而自动化"的陷阱，花三天搭的流程省了二十分钟。
4. 环境准备与前置条件
4.1 硬件与系统
分两条路线看。
API 路线：编排层本身很轻，普通的办公笔记本就能跑。真正的要求是稳定的网络和对接口调用的额度管理。本地只需要 Python 环境和几个依赖包，内存 8GB 以上基本够用。
本地推理路线：需要独立显卡。显存需求取决于模型参数量、量化精度和上下文长度三个变量，同样一个模型，4bit 量化和 8bit 量化的显存占用差异明显，上下文从 4K 拉到 32K 也会显著增加显存。所以任何"XX 模型需要 XX G 显存"的绝对说法都不可靠，实际必须以你选择的量化版本和运行框架为准。稳妥的做法是先用小参数量模型跑通全流程，确认工作流没问题，再换大模型看效果提升是否值得。
磁盘空间也要留够。本地模型文件动辄几个 GB 到几十个 GB，加上文献 PDF、实验数据、输出结果，建议单独准备一块盘做数据盘，和系统盘分开。
4.2 软件栈
通用清单如下，具体版本以你选用的框架官方文档为准：
- Python 3.10 或以上
- 虚拟环境工具（venv / conda 任选，别装全局）
- 向量数据库（本地轻量方案即可，用于文献知识库检索）
- PDF 解析库（处理扫描版文献需要额外的 OCR 组件）
- 一个模型服务：云端接口或本地推理服务
4.3 目录结构约定
这一步很多人跳过，但它是后面所有批量任务能不能稳住的基础。建议从第一天就按固定结构组织：
research-agent/ ├── config/ # 配置与提示词模板 │ ├── agent.yaml │ └── prompts/ ├── inputs/ # 原始输入 │ ├── papers/ # 文献 PDF │ ├── data/ # 实验数据 │ └── drafts/ # 稿件 ├── outputs/ # 生成结果，按日期分目录 ├── queue/ # 批量任务队列 │ ├── pending/ │ ├── done/ │ └── failed/ ├── logs/ # 运行日志 └── scripts/ # 编排脚本关键设计是queue/下的三个目录。任务文件放在pending/，处理成功移到done/，失败移到failed/。这个结构极其朴素，但它让你随时能看出"还剩多少没跑、多少跑挂了"，比任何复杂的任务管理系统都直观。
5. 部署与启动：搭一个最小可用的科研智能体
5.1 环境安装
先用虚拟环境隔离，避免和系统 Python 打架：
# 创建并激活虚拟环境 python -m venv .venv source .venv/bin/activate # Windows 用 .venv\Scripts\activate # 安装基础依赖，具体包名按你选用的框架调整 pip install --upgrade pip pip install openai pyyaml python-dotenv tqdm pip install pypdf # PDF 文本抽取 pip install pandas matplotlib # 数据处理与绘图如果走本地推理，还需要额外安装推理框架，并按框架文档下载模型权重。这一步的耗时和磁盘占用都比较可观，建议单独安排一个时间段做，不要和实际工作混在一起。
5.2 配置文件
把所有可变参数抽到配置文件里，代码里不要写死。这是一个最简配置模板：
# config/agent.yaml model: # 走 API 时填服务地址，走本地时填本地服务地址 base_url: "http://127.0.0.1:8000/v1" name: "your-model-name" # 按实际部署的模型填写 temperature: 0.2 # 科研任务偏低温度，减少发散 max_tokens: 4096 timeout: 120 paths: paper_dir: "./inputs/papers" data_dir: "./inputs/data" output_dir: "./outputs" log_dir: "./logs" batch: concurrency: 2 # 并发数，本地推理建议从 1 开始 retry: 2 # 失败重试次数 retry_delay: 5 # 重试间隔，单位秒 task: chunk_size: 6000 # 长文档切块大小，按模型上下文调整 chunk_overlap: 300temperature这一项在科研场景里建议压低。高温度会让输出更"有创意"，但你要的是稳定可复现的结构化结果，不是文采。concurrency是本地推理最容易踩坑的地方，开太大直接把显存打满，从 1 开始慢慢往上试。
5.3 启动服务
如果你用的是本地推理服务，一般是一个独立进程：
# 本地推理服务启动示例，参数需按实际框架调整 python -m your_inference_server \ --model-path /path/to/model \ --host 127.0.0.1 \ --port 8000 \ --max-model-len 8192如果你走云端接口，就不需要这一步，把base_url改成服务商地址、配好密钥即可。密钥一定要通过环境变量注入，不要写进代码或配置文件：
# .env 文件，加入 .gitignore export AGENT_API_KEY="your-key-here"# 读取方式 import os from dotenv import load_dotenv load_dotenv() api_key = os.getenv("AGENT_API_KEY")配置完做一次连通性测试，确认服务能通再往下走：
# 检查服务是否响应 curl -s http://127.0.0.1:8000/v1/models \ -H "Authorization: Bearer ${AGENT_API_KEY}" | head -c 500返回里能看到模型列表，说明服务通了。看不到就回第 9 节排查。
6. 功能测试与效果验证
环境跑通只是开始，真正要做的是逐个功能验证效果。下面按五个场景给测试流程，每个场景都说清楚输入什么、预期什么、怎么判断成功。
6.1 文献结构化抽取
测试目的：验证智能体能否从 PDF 中稳定抽出固定字段。
输入：选 3 篇你非常熟悉的论文，这样你能一眼看出抽取对不对。不要用不熟悉的论文测，你判断不了准确性。
操作步骤：把 PDF 文本抽出来，按chunk_size切块，喂给模型，要求输出固定 JSON 结构，字段包括：研究问题、方法、数据集、评价指标、主要结论、局限性。
预期结果：三个 JSON 对象，字段齐全，内容能和原文对上。
判断成功的标准：抽取的"局限性"字段不是空话（比如"未来可以进一步提升性能"这种），而是真的指出了论文自己承认的约束条件。如果全是套话，说明提示词需要加约束，要求它必须引用原文句子。
常见失败原因：PDF 是扫描版导致抽不出文字；切块把关键段落切断了；模型上下文不够导致后半部分被截断。
6.2 代码脚手架生成
测试目的：验证生成的代码能不能直接跑。
输入：给一个具体的数据格式描述，比如"CSV 文件，三列：timestamp、value、group，group 有三类"。
操作步骤：要求生成完整的读取、清洗、分组聚合、绘图脚本，要求包含异常处理和日志。
预期结果：脚本能直接执行，无需修改路径以外的内容。
判断成功的标准：跑完之后图能出来，数据没有静默丢失。特别要检查一点——很多生成的脚本在遇到缺失值时会静默 dropna，导致样本量悄悄变少而你不自知。要求它把每一步的行数变化打印出来。
常见失败原因：依赖包版本不匹配；编码问题（中文 CSV 常见）；时间列格式假设错误。
6.3 长文档批处理
测试目的：验证队列机制在几十个文件上的稳定性。
输入：20 篇 PDF 放queue/pending/。
操作步骤：跑批量脚本，观察日志。
预期结果：全部处理完，pending/空，done/有 20 个结果文件。
判断成功的标准：不只是"跑完了"，还要抽查 3 个结果文件内容是否正确。跑完但内容是错的，比跑挂了更危险。
常见失败原因：单个文件超时导致整个批次卡住；并发过高触发接口限流；某个文件解析异常后没有隔离，把整批带崩。
6.4 写作润色
测试目的：验证润色是否保留了原意。
输入：选一段你自己写的、包含明确技术判断的段落。
操作步骤：要求"仅优化表达，不改变技术结论，不增加原文没有的断言"。
预期结果：语言更顺，技术判断不变。
判断成功的标准：逐句比对。重点看有没有把"在 A 条件下成立"润色成"A 成立"，这是最危险的一类改动，它把一个有条件的结论变成了无条件断言。
常见失败原因：提示词没加约束；模型倾向于"加强语气"；长段落被截断。
6.5 审稿意见归类
测试目的：验证多意图文本的拆分能力。
输入：一段包含 5 条以上意见的审稿回复原文。
操作步骤：要求拆成条目，每条标注类型（补充实验 / 修改表述 / 解释澄清 / 格式问题 / 其他）。
预期结果：条目数正确，分类合理。
判断成功的标准：没有漏条，没有把一条拆成两条。数量对不上就是提示词没约束好。
常见失败原因：审稿人一条意见里包含多个要求，模型只抓了第一个；跨段落的意见被截断。
7. 接口 API 与批量任务
7.1 通用接口调用模板
绝大多数据模型服务都提供 OpenAI 兼容接口，下面是最小可用的调用模板。注意这是通用模板，具体路径和参数需要按你实际使用的服务调整：
import os from openai import OpenAI client = OpenAI( api_key=os.getenv("AGENT_API_KEY"), base_url=os.getenv("AGENT_BASE_URL", "http://127.0.0.1:8000/v1"), ) def ask(prompt: str, system: str = "你是一个严谨的科研助理，只输出可核查的事实。") -> str: resp = client.chat.completions.create( model="your-model-name", messages=[ {"role": "system", "content": system}, {"role": "user", "content": prompt}, ], temperature=0.2, timeout=120, ) return resp.choices[0].message.content if __name__ == "__main__": print(ask("把下面这段话改写成结构化要点：……"))用 curl 也可以，适合快速验证服务是否通：
curl -s http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer ${AGENT_API_KEY}" \ -d '{ "model": "your-model-name", "messages": [{"role": "user", "content": "测试一下"}], "temperature": 0.2 }'7.2 批量任务队列设计
批量的核心不是"循环调用"，而是"可恢复"。因为跑 50 个文件跑到第 37 个挂了，你最不想看到的是从头再来。所以队列必须落盘：
import json import shutil import time from pathlib import Path QUEUE = Path("./queue") PENDING, DONE, FAILED = QUEUE / "pending", QUEUE / "done", QUEUE / "failed" MAX_RETRY = 2 def process_one(path: Path) -> str: # 这里替换成你实际的处理逻辑 text = path.read_text(encoding="utf-8", errors="ignore") return ask(f"请抽取以下文献的结构化信息：\n{text[:6000]}") def run_batch(): for name in (PENDING, DONE, FAILED): name.mkdir(parents=True, exist_ok=True) for task in sorted(PENDING.glob("*")): if not task.is_file(): continue for attempt in range(1, MAX_RETRY + 2): try: result = process_one(task) out = DONE / f"{task.stem}.json" out.write_text( json.dumps({"source": task.name, "result": result}, ensure_ascii=False, indent=2), encoding="utf-8" ) task.unlink() print(f"[OK] {task.name}") break except Exception as e: print(f"[RETRY {attempt}] {task.name}: {e}") if attempt > MAX_RETRY: shutil.move(str(task), str(FAILED / task.name)) else: time.sleep(5) if __name__ == "__main__": run_batch()这个脚本的价值在于三点：任务文件是物理落盘的，进程挂了重启能接着跑；成功的移到done、失败的移到failed，状态一眼可见；每个结果都带source字段，方便回溯是哪个输入产生的。
7.3 任务清单文件
如果任务不是文件而是纯文本条目，用 JSONL 更合适，一行一条，天然支持追加和断点续跑：
{"id": "p001", "type": "summarize", "input": "papers/xxx.pdf", "status": "pending"} {"id": "p002", "type": "polish", "input": "drafts/intro.md", "status": "pending"} {"id": "p003", "type": "classify", "input": "reviews/r1.txt", "status": "pending"}每跑完一条就把status改掉并写回。这种结构的另一个好处是你可以按type分组，不同类型的任务用不同的提示词模板和不同的模型，成本和质量都能兼顾。
8. 资源占用与性能观察
不管走哪条路线，都建议养成"看资源"的习惯，否则出了问题你连方向都判断不了。
观察显存：Linux 下用nvidia-smi -l 1持续刷新，Windows 下用任务管理器的性能页或者显卡厂商自带的监控工具。重点看两个数：峰值占用和稳定占用。峰值决定你会不会 OOM，稳定占用决定你能开几个并发。
观察内存：本地推理时内存占用经常被低估。模型加载、PDF 解析、向量库检索都会吃内存，尤其是处理大 PDF 的时候。如果发现处理到某个文件时进程被杀，先看是不是内存爆了。
影响性能的四个变量：
| 变量 | 影响方向 | 调优建议 |
|---|---|---|
| 上下文长度 | 越长越吃显存，且增长不是线性的 | 按任务实际需要设置，不要盲目拉满 |
| 并发数 | 线性吃显存和内存 | 本地从 1 开始，逐步加 |
| 输出长度 | 影响生成时长 | 用max_tokens卡住上限 |
| 切块大小 | 影响单次请求量和总请求数 | 块大请求少但容易超限，块小请求多但稳 |
降低显存占用的几个方向：换更小的模型、用量化版本、缩短上下文、降低并发、把长文档改成"先摘要再精读"的两段式。最后这一条效果往往最明显——先用小模型把 100 篇 PDF 摘要成 100 段短文，再用大模型精读其中筛出来的 10 篇，总开销比直接大模型读 100 篇低得多。
避免进程残留：批量任务中断后，后台可能还有推理进程占着显存。养成习惯，重跑前先确认端口和显存状态，端口被占用或者显存没释放，重跑必然失败。
9. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 服务启动后接口不通 | 端口被占用或服务未就绪 | curl探测 + 查看启动日志 | 换端口，或等服务完成加载后再请求 |
| 依赖安装失败 | Python 版本不匹配或版本冲突 | 看报错的首个 Error 行 | 新建干净虚拟环境重装 |
| 显存不足 OOM | 模型太大、上下文太长、并发太高 | nvidia-smi看峰值 | 降并发、缩上下文、换量化版本 |
| PDF 抽不出文字 | 扫描版或加密 PDF | 直接打开看能否选中文字 | 加 OCR 组件，或换解析库 |
| 输出内容中途截断 | 超出max_tokens或上下文 | 统计输入输出长度 | 缩小切块，提高输出上限 |
| 结果里出现不存在的文献 | 模型幻觉 | 逐条核对 DOI | 加"不确定则留空"的强制约束，人工复核 |
| 批量任务卡住不动 | 单任务超时未设置 | 看日志最后一条停在哪个文件 | 加超时和重试，隔离异常任务 |
| 接口频繁报限流 | 并发过高 | 看返回的状态码 | 降并发，加重试退避 |
| 中文输出乱码 | 编码未指定 | 检查读写时的 encoding | 统一用utf-8 |
| 结果重复率高 | 温度太低或提示词太模板化 | 换输入对比 | 调整提示词，加入差异化要求 |
排查有一个通用原则：先确认输入对不对，再怀疑模型。大量"效果不好"的问题，根因是 PDF 没解析出文字、切块把关键信息切掉了、提示词里没说清楚输出格式。这三种占了绝大部分。把输入和提示词检查一遍，比换模型有效得多。
另一个原则是小样本先验证。任何新流程，先拿 3 个样本跑通，确认输出结构对、内容能核验，再去跑全量。直接上 100 个文件然后发现输出格式全错，返工成本极高。
10. 最佳实践与落地节奏
讲了这么多，最后给一套能直接照做的落地节奏。不要一次性把所有环节都自动化，那样你会陷入配置地狱，一周下来一个能用的流程都没有。
第一周：只做文献抽取。目标很单一，把 PDF 批量转成结构化笔记。这一步跑通，你会立刻感受到价值，因为它解决的是最痛的"读不完"。同时这一步也帮你把环境、队列、日志这套基础设施搭好了，后面所有任务都复用这套骨架。
第二周：加代码脚手架。不改基础设施，只加一个提示词模板和一个任务类型。这时候你会开始积累自己的提示词库，建议单独建一个目录管理，按任务类型命名，每个模板里写清楚输出格式和约束条件。
第三周：加写作辅助和审稿整理。这两类任务的共同点是"输入是文本、输出是文本"，不需要额外工具链，接入成本最低。
第四周：补事务自动化。PDF 重命名归档、周报生成、参考文献格式化。这些任务单独看价值不大，但加起来能省掉每周好几个小时。
几条工程化建议：
- 保留一套"最小可运行配置"，用最简单的方式跑通全流程。不要一上来就上复杂的编排框架，先用脚本跑起来，等确实遇到瓶颈再换。
- 模型文件、输入素材、输出结果必须分目录。混在一起，一周后你自己都找不到东西。
- 所有批量任务都要有日志和失败重试。日志里至少记录：任务名、开始时间、耗时、状态、错误原因。
- 接口服务不要默认监听
0.0.0.0，本地用就绑127.0.0.1。需要多机访问时再单独配置访问控制。 - 提示词模板要版本化。改了模板之后效果变差，你得能回滚。
- 任何涉及人脸、声音、访谈记录、未发表数据的处理，先确认授权范围再动手。
- 商用或投稿前，所有 AI 参与过的内容都要做一次人工复核，尤其是事实性陈述和引用。
回到标题里那个"80%"。这个比例不是精确测量出来的，它表达的是一个结构性判断：科研工作里真正需要你独特判断的部分，占比其实很小；大部分时间消耗在信息搬运、格式转换、重复编码、机械整理上。把这部分交出去，你才有余力去做那 20% 真正决定论文高度的事。
最值得先验证的功能是文献批量抽取，因为它投入最小、见效最快、复用性最高。最容易踩的坑是"跑完了但结果是错的"——所以每批任务之后一定要抽查，不能只看日志显示成功。后续可以继续扩展的方向包括：把文献库做成可检索的本地知识库、把实验日志接入自动汇总、把审稿回复做成可复用的模板库。
先把最小流程跑起来，再谈优化。
