AI编程助手科研实战：先立规矩，再谈效率

一、先看清症状：为什么AI助手“什么都懂，却干不好活”

典型的翻车过程往往高度相似：第一轮对话令人惊艳，第二轮开始反复交代背景，第五轮它开始“自由发挥”，第十轮你发现自己在替它返工。整个过程里，AI更像一个被临时拉进项目群的实习生——能力并不差，但对你的课题一无所知，每件事都要从头交代。

把症状拆开看，通常有三个具体表现：

1. 上下文失忆：换一个会话或隔几天再问，此前的结论、约定、写作偏好全部清零，一切重来；
2. 产出泛化：答案放之四海而皆准，却没有一条贴合你的数据、文献与研究习惯；
3. 返工成本高：表面上节省了初稿时间，实际上核对引用、补来源、大改结构的时间远超预期。

很多人的第一反应是“模型还不够聪明”。但只要观察那些用得好的研究团队，就会发现同样的模型在别人手里能稳定输出高质量结果。差异不在模型，而在用法：前者把它当聊天机器人，后者把它当成一个需要工位、文档与规范的合作者。

二、根因分析：没有“现场”，就只能靠猜

命令行式、想到什么问什么的用法，存在三个结构性局限：

• 材料不可检索：文献、数据、笔记全散落在对话流里，AI无法系统性地回看与定位；
• 规则不可沉淀：你要求过“引用必须带来源”，但这条约定只存在于某一轮对话中，下次会话即告失效；
• 操作不可积累：AI做的每个决定都是一次性的，无法在项目层面形成连续的协作记忆。

换句话说，它手头根本没有“现场”——看不到你的项目文件、研究背景与工作规则。没有现场，它就只能基于通用知识去“猜”你的意图；靠猜，返工就一定会多。这是使用方式造成的结构性缺陷，而非模型能力的上限。

三、思路转变：把AI当成入职的研究协作者

想象一位新加入的研究助理：你不会只发一条消息就开始要成果，而是会给他一个工位、一套项目文档、明确的工作规范，并定期检查产出。对AI协作工具，标准应当一致：

• 它能读到项目文件，而不是只看到聊天框里粘贴的片段；
• 它按照你写下的规则行事，规则沉淀在文件中，跨会话持续生效；
• 它能在交付前主动参与核查，把问题拦在你看到之前。

无论使用本地命令行形态的智能编程助手，还是百度智能云等云厂商提供的云端智能开发服务，方法论都是同一套：先给上下文，再谈产出。下面分三步落地。

四、第一步：搭建结构化研究工作区

不必复杂，关键是“固定位置”。一个可用的最小结构如下：

my-research/
├── RULES.md              # AI 行为规则（下一节详述）
├── research-question.md  # 研究问题、假设与阶段进展
├── literature/           # 文献笔记
├── data/                 # 数据与分析脚本
├── drafts/               # 论文与报告草稿
└── outputs/              # 最终交付物

这个结构的价值不在于“整齐”，而在于可寻址：当AI需要某篇文献的笔记时，它知道去 literature/ 找；当它要产出交付物时，知道必须写入 outputs/。固定位置是后续一切自动化协作的前提。

如果不想手动创建，可以在选定工作目录后，直接向AI发出一条结构化指令：

请在本工作目录下建立学术研究用的文件夹结构：literature/ 存放文献笔记，data/ 存放数据与分析脚本，drafts/ 存放论文与报告草稿，outputs/ 存放最终交付物；同时创建 research-question.md，用于记录研究问题、核心假设与阶段进展。本次只创建空目录和空文件，不要写入任何内容。完成后，请逐项说明每个目录的规划用途。

这条提示词里有两个值得注意的细节：

其一，“先只建空目录、不写内容”。让AI一次性生成大量内容，等于把猜测直接写进文件；先让结构稳定，内容由你逐步沉淀，才能守住事实准确性这条底线。

其二，“完成后说明用途”。这是在建立双向确认的习惯——AI复述自己的理解，你有机会立即纠偏，避免误解像雪球一样越滚越大。

此外，research-question.md 值得单独强调：它是整个工作区的“单一事实来源”。研究问题、核心假设、当前卡点都集中记录在这一个文件里。每次会话开始，AI优先读取它，就能迅速对齐“我们在做什么、做到哪一步了”，而无需你重新口述背景。

五、第二步：编写可执行的规则文件

目前主流的智能编程助手大多支持一个通用机制：自动读取项目根目录下的规则文件，将其作为全程生效的行为约束。可以把它理解为给AI定的“员工守则”。不同工具的默认文件名有所差异，本文统一以 RULES.md 为例。

写这份文件时，最常见的失败方式是写成口号，例如：

请认真严谨地协助我完成科研工作，保证高质量输出。

对模型而言，这句话不含任何可执行信息——什么叫“严谨”？如何验证“高质量”？口号式约束的结果就是约束归零。正确的写法是具体到可验证的行为，一份起步版的规则文件可以长这样：

# 工作规则
## 事实与引用
- 回答中涉及文献、数据或结论时，须注明来源文件路径；
- 找不到依据时明确回答“未找到依据”，禁止编造文献标题、作者、年份或数据。
## 文件操作
- 修改 data/ 目录下任何文件前，先说明改动原因与影响范围；
- 新建分析脚本统一放在 data/scripts/，命名格式：日期_主题_v版本号。
## 写作规范
- drafts/ 中的正文默认使用中文，专业术语首次出现时附英文原文；
- 每个章节的图表编号必须与正文引用一一对应。
## 汇报方式
- 每完成一个阶段，用不超过 5 行的摘要说明：做了什么、改了哪些文件、还有什么待定。

撰写与维护规则文件，遵循三条原则：

1. 可验证：每条规则都要能明确判断“做到了还是没做到”。“禁止编造文献”可验证，“态度认真”不可验证；
2. 可操作：规则应指向具体的文件、目录与动作，而不是抽象价值观；
3. 渐进式：不要试图一次写完。起步控制在十条以内，之后每发现AI犯一类新错误，就补一条对应规则。规则文件是活文档，它的生长轨迹就是你们协作默契的沉淀过程。

六、第三步：建立“生成—核查”闭环

科研场景的特殊性在于错误代价极高：一段编造的引用、一个记错的统计口径，轻则返工，重则动摇整个结论的可信度。因此，仅有生成环节远远不够，必须补上核查环节。三种低成本的做法：

• 交付前自查：要求AI在提交产出前，对照规则文件逐条自检。例如下达指令——“请对照 RULES.md 检查本节草稿，列出所有缺少来源支撑的论断、编号不一致的图表以及不符合写作规范的段落，输出为待办清单，先不要直接修改原文。”
• 交叉核对：让AI把草稿中的每条引用与 literature/ 中的笔记逐一比对并标记不一致项。人工做这件事耗时且易遗漏，恰恰是机器的强项；
• 问题沉淀：核查中发现的每一类高频错误，都转化为规则文件中的新条目。闭环由此形成——同类错误不再重复，规则越用越准。

注意一个细节：让AI“先列清单、不要直接改”。核查与修改分离，既保留了你的最终判断权，也避免AI在自查过程中顺手引入新的问题。

七、避坑清单

• 规则写成口号：没有可验证标准的规则等于没有规则；
• 一次写太多规则：规则膨胀会稀释关键约束，从十条以内起步；
• 材料继续散落在聊天里：任何值得保留的中间结论，都应沉淀为工作区中的文件；
• 生成后直接采用：核查闭环不可省略，尤其在引用与数据层面；
• 多课题共用一个工作区：不同课题的上下文互相污染，建议一个课题对应一个独立工作区。

八、结语

AI协作工具的效率上限，一半取决于模型本身，另一半取决于你为它搭建的环境。工作区提供“现场”，规则文件提供“纪律”，核查闭环提供“质量闸门”——三者齐备，AI才能从需要反复交代的“临时实习生”，转变为可以托付流程性工作的研究协作者。下次打开工具准备提问前，不妨先停三十秒，问自己三个问题：它现在能看到什么、遵守什么、检查什么。想清楚这三点，返工量自然会降下来。