Using AI Agents to Write Research Experiment Logs: A Complete Methodology and Workflow

In scientific research, experiment logging is often the most overlooked yet most critical component. This article is based on the content from Chapter 0, Section 4 of the Bilibili series "AI-Accelerated Research Workflow," systematically outlining how to leverage AI Agents to establish a Research Log that spans an entire project — turning experiment records into a powerful tool for scientific reflection and decision-making.

Why You Need a Unified Research Log

Information in research projects typically falls into three categories: experiment records, research ideas, and method/code changes. Splitting these into three separate documents creates two obvious problems. First, it leads to information loss and fragmentation — experiments, ideas, and code changes should be interconnected, and separating them destroys that context. Second, when using AI Agents, managing three documents results in excessive token consumption and low efficiency.

Tokens here refer to the basic unit of text processing for large language models. One Chinese character corresponds to approximately 1.5–2 tokens, while one English word corresponds to roughly 1–1.5 tokens. Although current mainstream models like GPT-4o and Claude 3.5 offer context windows of 128K or larger, token consumption directly impacts API call costs and inference speed. Feeding three separate documents to the AI means redundantly loading background information with every interaction. Consolidating everything into a single document allows the AI to load the complete context in one pass, potentially saving several times the API costs over the course of a long-term project.

The better approach is to merge all three types of information into a single Markdown document, keeping it within a manageable context length. Markdown is a lightweight markup language written in plain text that uses simple symbols (such as # for headings, - for lists, and ** for bold) to generate structured documents. It's particularly well-suited for research records because: plain text is natively compatible with version control systems like Git, making every change traceable; virtually all AI models can perfectly parse Markdown structure, helping Agents understand document hierarchy; and files can be opened in any text editor without depending on specific software, ensuring long-term readability.

The core value of this approach is: when you need the AI to reflect on experimental issues, it has access to the complete context. Based on coherent historical records, the AI can compare daily experimental results, help you analyze problems in your experiments, and even design future experiment plans and daily workflows for you.

This document is essentially a "research diary" that runs continuously from project kickoff to project completion, recording the complete information flow of the entire research process.

The Skeleton Structure of Experiment Records

A complete experiment record should have a clear hierarchical structure:

Project Starting Point: Defining the Research Position

The document begins by establishing the overall project positioning, including the current research question, research scope, and goals to achieve. This section serves as the anchor for the entire Research Log, providing background reference for all subsequent experiments.

Daily Records Organized by Date

Each day's record is organized by date, containing one or more experiments internally. Daily records follow a fixed framework:

• Today's goals and plan: Set today's objectives before starting experiments in the morning
• Experiment execution and changes: Multiple experiments are typically conducted throughout the day, appended sequentially as experiment001, experiment002, etc.
• End-of-day summary: Wrap up at the end of the day or before leaving work

Project Closure: Overall Retrospective

When all experiments are complete, conduct an overall project retrospective. There's an important principle here: if certain sections are missing information, leave them blank — never let the AI fabricate content to fill the gaps.

Operational Workflow During Project Progression

Using a typical experiment day as an example, we can clearly see the progression logic of the Research Log. Suppose you start experiments at 9 AM — first write down today's plan in the document, then conduct the first experiment (experiment001) and check whether the output has any anomalies.

If anomalies are discovered in the afternoon, the correct approach is to create a new experiment002 referencing experiment001, rather than deleting or overwriting experiment001. This is a core principle repeatedly emphasized throughout this methodology — failed experiment records are equally valuable. In the evening, provide the day's interpretation and summary, explaining why new evidence changed your judgment and what should be done tomorrow.

Four Components of the Daily Closing Summary

Before ending each day, divide the daily summary into four distinct sections:

1. What happened: What actually occurred in today's experiments, what was accomplished
2. Interpretation: Provide explanations for the results (this section requires the researcher's personal verification)
3. Issues and corrections: What problems existed in today's experiments, what needs to be fixed
4. Next steps: What to do tomorrow, what conditions need to be met, where to start

These four sections form the closing portion of a day's record, completing the day's documentation.

Structured Thinking Standards Before Experiments

Before conducting an experiment, a set of structured thinking logic can significantly improve experiment quality. Before experimenting, you should ask yourself several key questions:

• What question is this experiment trying to answer?
• Controlled variables: What conditions are being changed in this experiment, and are other conditions held constant?
• Success criteria: What experimental results are expected, and what constitutes getting an answer?
• Failure handling: What happens if the experiment fails — should you stop?

The "controlled variables" here follows the most fundamental principle in experimental science — the Controlled Variable Method. Its core idea is to change only one variable (independent variable) in a single experiment while keeping all other conditions constant, thereby establishing the causal relationship between that variable and the experimental results. In machine learning and deep learning experiments, this means adjusting only one hyperparameter at a time (such as learning rate, batch size, or a specific layer of the model architecture) to accurately attribute the source of performance changes. If multiple variables are changed simultaneously, even if experimental results improve, you cannot determine which change was responsible — this is known as the "confounding variable" problem in research. Formalizing this classic scientific methodology into an actionable checklist is precisely the value of structured thinking standards.

Regarding failure handling, there's a clear rule: if an experiment fails, record it honestly as-is — don't try to overwrite it with a new approach. If experiment one fails, conduct experiment two, synchronizing experiment one's conditions but without overwriting experiment one's records and outputs. This "append-only, never overwrite" principle runs throughout the entire methodology.

How to Write Records After Experiment Completion

After an experiment is complete, changes to experimental conditions and code modifications should be written in the same record entry, explaining why the changes were made and what was actually changed.

For computer science experiments, here's an efficient technique: if code files have been modified, first make a git commit, then have the Agent read the git log of changes and automatically summarize what code was changed today and what effects were achieved.

Git is currently the most widely used distributed version control system, originally developed by Linux creator Linus Torvalds for managing the Linux kernel code. In research scenarios, Git can manage not only code but also track every change to data processing scripts, configuration files, and even paper LaTeX source files. Each git commit generates a unique hash value recording who modified what content at what time. Using git diff, you can see exact differences between two versions, while git log displays the complete modification history. Having an Agent read git records to automatically generate code change summaries essentially leverages Git's natural change-tracking capability, transforming machine-readable diff information into human-understandable natural language descriptions. This ensures record accuracy while reducing the burden of manual documentation.

For experimental sciences like biology, the Agent will proactively ask about detailed conditions, which the researcher fills in themselves. The complete closed loop of daily experiment recording is: define the experiment plan and objectives → conduct the experiment → verify facts → record code changes with git (or manually fill in experimental conditions) → manually judge experimental results → proceed to the next experiment. The next experiment must follow along from the original records, which significantly reduces overhead in terms of computing resources and costs.

Division of Labor Between AI Agents and Researchers

The most commendable aspect of this methodology is its clear delineation of responsibilities between AI Agents and human researchers.

An AI Agent refers to an AI system with autonomous planning, tool invocation, and environment interaction capabilities, distinct from simple conversational language models. A typical Agent can decompose complex tasks into sub-steps, call external tools (such as file read/write, code execution, web search), and adjust subsequent behavior based on execution feedback. Current mainstream Agent frameworks include AutoGPT, LangChain Agent, and Claude's Computer Use. In research scenarios, Agents can automatically read experiment logs, analyze data files, and pose hypothetical questions, but their core limitation lies in the lack of real perception of the physical world — they cannot judge whether experimental data is authentic or whether conclusions are reliable. This is precisely why this article emphasizes human-machine division of labor.

What the Agent Handles

The Agent can collect problem context, organize file structures, flag missing information, and audit contradictions. Its core responsibility is to "ask the questions clearly" — guiding researchers to supplement factual information through questioning.

What the Researcher Handles

The researcher is responsible for summarizing each experiment record, planning next steps, and approving plans. It is strongly recommended not to use fully automated mode — each experimental step should be confirmed by a human, which is safer and more reliable.

Risks to Watch for When Using Agents

When using Agents, you need to guard against several types of issues:

• Whether the Agent has produced sensitive information
• Whether it has overwritten historical records
• Whether the factual sources in its suggestions are accurate
• Whether evidence across experiments conflicts
• Whether it has executed tasks beyond its authority

The most critical warning is: you must not let the Agent make its own fabricated content appear real. This warning directly addresses a core technical challenge in the AI field — AI Hallucination. AI hallucination refers to large language models generating content that appears reasonable but is actually incorrect or unsubstantiated. Its root cause lies in the generation mechanism of language models: they predict the next most probable token based on statistical probability, rather than based on understanding and verifying facts. In research record scenarios, the risk of AI hallucination is particularly severe — an Agent might fabricate non-existent experimental data, invent citations, or present speculative reasoning as definitive conclusions. This not only misleads researchers' judgment but may also constitute academic misconduct. In recent years, there have been multiple paper retractions directly related to AI-generated false references.

Therefore, you must never write "possible causes" as conclusions, nor equate "modified code" with "produced results" — code changes alone do not represent successful verification.

The correct approach is: let the Agent flag items pending confirmation, pose verification questions, and once it has asked clearly, the researcher inputs the real information. This is the proper posture for human-machine collaboration.

Conclusion: Start with a research_log.md

The core deliverable of this lesson is actually quite simple — create a research_log.md, write your first experiment record, and establish the daily logging standards and per-experiment logging standards for all subsequent experiments.

But behind this seemingly simple document lies a rigorous philosophy of research documentation: append-only, never overwrite; failures are valuable experience; clear human-machine division of labor; never let AI fabricate conclusions. These principles ensure the authenticity and traceability of experiment records, making AI a genuine aid for research reflection rather than a liability. According to the content creator's preview, the next section will cover "extremely important" prompt engineering — worth following closely.