CodeX/CC科研向使用经验

发表于 更新于 分类于

结合最近一段时间的科研实践（主要是论文复现）以及 Datawhale 的公众号经验贴，这里整理一些使用 CodeX / Claude Code 这类编程 Agent 辅助科研开发的经验。

核心思路可以概括为一句话：模型能力固然重要，但上下文、长期规则和验收标准同样重要。

总工作流

比较稳定的一套流程是：

读上下文 -> 写计划 -> 确认范围 -> 小步实现 -> 跑验证 -> 总结结果 -> /new 开新对话

Agent 很适合做“有明确边界的工程任务”，但不适合在上下文混乱、目标模糊、验证缺失的情况下自由发挥。因此，每次让它动手之前，都要先让它理解项目、对齐任务，并明确最后如何验收。

一、先让 Agent 阅读项目框架

进入一个新的代码仓库后，不要一上来就让 Agent 改代码。更稳妥的方式是先让它阅读项目结构，建立最基本的上下文。

可以使用类似下面的 Prompt：

1
2
3
4
5
6
7
先不要修改代码。请先阅读这个项目，告诉我：

1. 项目结构是什么
2. 主要入口在哪里
3. 训练/测试/运行命令分别是什么
4. 哪些文件最可能和当前任务有关
5. 你不确定的地方有哪些

这样做的好处是，Agent 会先主动梳理工程结构，而不是凭借文件名或局部代码直接猜测实现方式。对于论文复现类项目尤其重要，因为很多仓库的训练入口、配置文件、数据集注册逻辑并不直观。

二、在 AGENTS.md 中写长期规则

如果一个项目会反复使用 Agent 协助开发，建议在仓库中写一个 AGENTS.md，用于记录长期规则。这样每次新会话都能继承基本约束，减少重复说明。

例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
## 工作规则

- 默认先阅读相关代码和文档，再开始修改。
- 修改前先说明影响范围。
- 只做和当前任务相关的最小改动。
- 提交前必须运行最小验证。
- 说明用中文，代码、命令、文件名保持英文。
- 不要修改无关文件。

## 实验原则

- 实验必须服务于明确假设或决策。
- 不要为了补齐表格而穷举低价值 ablation。

这类规则的价值不在于“控制模型”，而在于给 Agent 一个稳定的工作边界。特别是在科研代码中，很多修改看似只是小改动，实际可能会影响实验公平性、配置一致性或结果可复现性。

三、先对齐 Plan，再开始实现

对于稍微复杂一点的任务，不建议直接说“帮我实现某功能”。更好的方式是先进入计划阶段，让 Agent 明确问题、影响范围和验证方式。

可以使用下面的 Prompt：

1
2
3
4
5
6
7
8
9
先不要写代码。请进入计划模式，帮我设计实现方案：

1. 明确这次要解决的问题
2. 列出会影响哪些模块
3. 拆成 3-7 个步骤
4. 每一步怎么验证
5. 哪些地方最容易出错

等我确认后再开始实现。

这个步骤可以有效避免 Agent 在需求还没对齐时就开始大范围修改。尤其是模型训练、数据预处理、评估指标这类任务，一旦改错位置，后面排查成本会很高。

四、复现和研究类任务要先查证

论文复现、方法解释、官方实现对照这类任务，不要直接让 Agent “按论文实现”。更稳妥的做法是先让它查证论文和官方代码，再决定是否需要实现。

可以使用下面的 Prompt：

1
2
3
4
5
6
7
8
9
请先阅读论文和官方 repo，不要开始写代码。

先输出：

1. 论文核心 idea
2. 关键公式/模块
3. 官方实现和论文描述是否一致
4. 复现最小路径
5. 可能复现不出来的风险点

这样可以减少“为了完成而完成”的情况。很多论文的官方代码和论文描述并不完全一致，甚至有些细节只存在于配置文件或 issue 讨论中。如果不先查证，Agent 很容易生成一个看似合理但并不忠于原实现的版本。

五、任务完成后及时开新会话

一个任务完成后，建议让 Agent 先总结当前状态，然后开启新会话。长上下文会提高幻觉和错误假设的概率，尤其是当中间经历过多次修改、回滚、报错和调试时。

可以使用下面的 Prompt：

1
2
3
请用一句话总结刚完成的任务、修改过的文件、当前状态和下一步注意事项。

然后 /new，在新会话里贴这个总结，再开始下一个任务。

这样可以保留必要信息，同时避免旧上下文中的错误判断继续影响后续任务。

六、不要只相信“已完成”

Agent 说任务完成，并不等于任务真的完成。最后一定要让它对齐修改内容和验证结果。

可以让它按下面几个问题总结：

1
2
3
4
5
6
7
请总结这次任务：

1. 修改了哪些文件
2. 每个文件为什么改
3. 运行了哪些验证
4. 还有哪些没验证
5. 哪些地方需要我人工确认

这一步很重要。它可以帮助我们区分“代码已经写了”“验证已经跑了”和“结果确实可信”这三件事。科研场景里，尤其不能把能运行等同于实验正确。

总结

使用 CodeX / Claude Code 这类 Agent 做科研开发时，关键不只是选择哪个模型，而是建立一套稳定的工作方式：

  • 先让 Agent 理解项目，而不是直接改代码。
  • 把长期偏好和约束写进 AGENTS.md。
  • 复杂任务先做 Plan，再确认实现。
  • 论文复现任务先查证论文和官方实现。
  • 每个任务结束后及时总结并开新会话。
  • 最后用文件、原因和验证结果来验收，而不是只听 Agent 的完成声明。

简单来说，Agent 更像一个执行力很强的研究助理。给它清晰的上下文、边界和验收标准，它才能稳定地产出有用结果。