AI 助手做科研总返工？根因是缺失项目上下文

一、先看症状：一个“每次都要重新入职”的实习生

不少研究者初次接触大模型助手时，用法高度相似：今天问它综述该怎么搭结构，明天贴一段数据问怎么分析，后天再让它帮忙改摘要。乍看之下它什么都能答，但几轮对话之后，几个典型症状会陆续浮现：

• 背景反复交代：换个话题就得重新解释一遍研究方向、术语体系和方法选型；
• 产出假大空：答案听起来头头是道，落笔却发现全是通用套话，缺少针对你课题的具体性；
• 结论无法累积：上一轮敲定的分析框架，下一轮它已经忘得一干二净，所有进展散落在聊天记录里，想找也找不回来。

很多人第一反应是：模型还不够聪明。但真不是。真正的原因，出在使用方式上。

二、根因诊断：不是模型笨，而是它“没有现场”

把 AI 助手当成“命令行版聊天机器人”来用，是科研场景翻车的头号根因。这种用法下，你开一个对话框，想到什么问什么，文献、数据、草稿、约定全都散落在聊天记录的各个角落。模型每次响应时，手头根本没有“现场”——它看不到你的项目文件，不知道你的研究背景，更不了解你们之前定下的规则。

没有现场，它就只能靠通用知识去猜；靠猜，返工就必然增多。这就像让一位实习生全程靠电话办公：每次通话他只记得这几分钟的内容，你们的约定、他之前的产出，全都不在他手边。人如此，模型亦如此。

更值得注意的一点是：如今不少智能编程工具与 AI 助手已经具备读取本地工作区文件、执行多步任务、回溯检查产出的能力。问题不在能力，而在于你有没有把这些能力组织起来。

三、解法框架：三个支点，缺一不可

要让 AI 从“临时实习生”变成“可靠的研究协作者”，需要三个支点：

1. 现场感：让模型能直接读到工作区里的文献笔记、数据说明和草稿；
2. 规则感：把你的写作偏好、分析规范、禁忌事项写成文件，一次配置、长期生效；
3. 连续性：把每轮对话的结论沉淀回文件，形成可累积的项目记忆。

下面按步骤逐一展开。

四、第一步：搭建标准化的研究工作区

不管用什么工具，第一步都是给研究材料一个固定的家。一个够用的结构长这样：

my-research/
├── rules.md              # 规则文件：AI 的"员工守则"
├── research-question.md  # 研究问题与进展记录
├── literature/           # 文献笔记
├── data/                 # 数据与分析
├── drafts/               # 论文和报告草稿
└── outputs/              # 最终交付物

这个结构不必复杂，重点只有一个：让材料出现在模型看得到的地方。文献笔记进 literature/，数据说明进 data/，草稿进 drafts/，最终交付物统一归口 outputs/，避免“什么都往桌面堆”。

如果懒得手动建，可以在选定工作目录后，直接对 AI 说：

请在当前工作目录下，帮我建立一套学术研究用的文件夹结构：literature/ 放文献笔记，data/ 放数据与分析，drafts/ 放论文和报告草稿，outputs/ 放最终交付；再创建一个 research-question.md 记录研究问题与进展。先只建空目录和空文件，不要写任何内容，建完告诉我每个文件夹的用途。

这条指令有两个值得留意的细节：一是“先只建空目录，不要写内容”，避免模型自作主张填充你还没核实过的信息；二是“建完告诉我用途”，让你能立刻核对结构是否符合预期。这种“小步执行 + 及时确认”的节奏，会贯穿后面所有环节。

五、第二步：用规则文件替代口头交代

工作区建好后，最关键的一步是写规则文件。当前多数智能编程工具都支持自动读取项目根目录下的说明性规则文件（具体命名以所用工具的文档为准，常见如 rules.md 一类），你可以把它理解为给 AI 定的“员工守则”。

很多人容易把它写成口号，比如“请认真严谨地协助我”。这种话对模型来说几乎等于废话——它没有告诉模型任何可执行的动作。有效的规则必须是具体的行为约束，示例如下：

# 项目规则
## 角色定位
你是协助完成学术论文的研究助手，服务对象是计算机方向的博士生。
## 写作约束
- 默认学术书面语，避免口语化表达与营销式修辞；
- 涉及文献结论时，注明该结论出自我提供的哪份笔记；
- 我未提供材料支撑的观点，必须显式标注"待核实"，不得编造引用；
- 修改草稿时，输出修改后的完整段落，并附改动点清单。
## 数据分析约束
- 先阅读 data/ 目录下的说明文件，理解数据口径后再动手；
- 给出任何统计结论前，先报告样本量与缺失值处理方式；
- 方法适用性存疑时，先给出至少两种候选方案及取舍依据，等我确认。
## 工作习惯
- 每次对话开始，先阅读 research-question.md 再回答；
- 对话中确认的结论，提议追加到对应文件，经我同意后写入。

对比一下就能看出差别：口号给的是“态度”，规则给的是“动作”。后者的每一条，模型都能直接照做，你也能直接验收。写规则文件时可以把握三个原则：

• 具体化：把“严谨”翻译成“标注来源、标注待核实”这类可检查的动作；
• 分场景：写作、分析、检索分别立规矩，不同环节的容错标准不一样；
• 可演进：发现新问题就往文件里补一条，规则文件是活文档，不是一次性交付物。

六、第三步：沉淀研究背景，建立项目级记忆

如果说规则文件管的是“怎么做”，研究背景文档管的就是“为什么做、做到哪了”。research-question.md 不必写得多正式，但至少要回答四个问题：

# 研究问题与进展
## 核心研究问题
（一句话描述你要回答的问题）
## 当前假设
（目前倾向的解释，标注置信程度）
## 已确认的结论
- 某日：确认采用 XX 方法作为基线，理由：xxx
## 待办与卡点
- 下一步：补做消融实验，卡点：数据口径尚未对齐

这份文档的价值在于打破对话之间的遗忘：每次开新会话，先让模型读它，之前敲定的方案就不会被推翻重来。配合规则文件里“对话结论提议写入文档”的机制，研究背景会随项目推进自动增厚，模型手上的“现场”也就越来越充分。

七、第四步：建立“产出—核查”闭环

前几步解决的是输入端，最后还要管住输出端。一个实用的做法是让模型自查：每次交付前，要求它对照核查清单逐项确认，例如：

• 每个结论是否都能追溯到工作区内的具体文件？
• 引用是否真实存在，而非“看起来合理”的编造？
• 数据口径与 research-question.md 里的记录是否一致？

此外，建议每隔若干轮对话做一次“归档动作”：让模型把散落在聊天记录里的关键决定整理成清单，你审核后写入对应文件。这样即使会话被清理、上下文被截断，项目知识也不会丢。

八、延伸：从个人工作流到团队与云端

这套方法并不局限于个人。团队场景下，把规则文件和研究背景文档一并纳入版本管理，新成员入职时克隆工作区，AI 助手便自动继承团队的全部约定——这比口口相传稳定得多。

在算力与部署层面，负载可以灵活拆分：轻量的写作、总结类任务调用云端托管的大模型服务即可，敏感数据的处理则留在本地工作区执行；有需要时，也可以将百度智能云等厂商提供的大模型相关服务与本地文件工作流组合起来。唯一需要额外留心的是数据边界：未公开的实验数据上传前，先确认所用服务的合规策略，必要时对数据做脱敏或匿名化处理。

九、结语

回到开头的那个问题：为什么 AI 助手在科研场景里总像“临时实习生”？答案不是模型不够聪明，而是我们没有给它一个像样的工位。工作区给它现场，规则文件给它纪律，背景文档给它记忆，核查清单给它责任——四件事配齐，同一个模型，产出质量会发生肉眼可见的变化。

下次再觉得 AI“答非所问”时，先别急着换模型，低头检查一下：它的手边，有没有那份该有的规则文件。