AI-Assisted Research Writing and Proof Code Governance Guide

1. When an AI Suggestion Appears in a Paper

In research writing, papers have traditionally acknowledged funding agencies, peer reviewers, collaborators, or providers of computing resources. As generative AI becomes part of everyday research workflows, a new type of contribution is appearing more frequently. Researchers may now state in the main text, footnotes, or acknowledgments that a particular algorithm variant, a derivation step, a piece of proof code, or an experimental design was completed under the suggestion of a large language model.

These statements may look like minor writing details, but they raise several key technical questions:

1. At which level did AI actually contribute?
   Did it only assist with language polishing and code completion, or did it contribute to core algorithm design, mathematical proof construction, or experiment selection?

2. Are AI suggestions verifiable?
   If a model proposes a variant or a derivation path, has the researcher reproduced it, checked it, formally verified it, or submitted it to peer review?

3. How should responsibility be assigned?
   The authors of a research paper are responsible for all conclusions. Is AI merely an auxiliary tool, or a co-author? Current mainstream research ethics generally do not list AI as an author. Instead, they require disclosure of AI use in the methods, acknowledgments, or appendix.

4. How can incorrect suggestions be prevented from entering a paper?
   Generative models may produce seemingly reasonable but incorrect derivations, fabricated symbolic relationships, invalid code interfaces, or unreliable experimental results. Therefore, AI-assisted research should establish a closed loop of generation, verification, traceability, and review.

Behind this phenomenon is a shift in the research workflow: from pure manual derivation to human-machine collaborative verification. A typical scenario is as follows. A researcher designs the main algorithm framework. At a critical junction, the model proposes a possible variant, such as a more suitable loss function, an optimization path, a boundary condition, a proof lemma, or a code implementation detail. The researcher then performs strict verification and decides whether to incorporate the variant into the paper or codebase.

In this mode, AI behaves more like a “high-recall but unreliable suggestion generator.” It can expand the search space, accelerate trial and error, and provide cross-domain associations, but conclusions must be endorsed by human researchers, formal checks, experimental reproduction, and peer review.

---

2. A Three-Layer Contribution Model for AI-Assisted Research

To support paper writing, engineering audits, and ethics compliance, AI contributions to research can be divided into three layers.

1. Language Layer: Polishing, Rewriting, and Structural Optimization

This is the most common and least controversial layer. AI can help researchers:

• Improve the clarity and logical flow of a paper.
• Adjust figure captions and table descriptions.
• Draft abstracts.
• Convert research ideas into more standardized technical expressions.
• Explain complex terminology in accessible language.

This type of work usually does not need to be emphasized in the methods section, but it is advisable to disclose it briefly in the acknowledgments, methods description, or data availability statement. For example:

This paper used generative AI to assist with language polishing during writing. All technical conclusions, formula derivations, experimental designs, and final texts are the responsibility of the authors.

2. Engineering Layer: Code Generation, Experimental Scripts, and Data Processing

AI can also assist at the code level, for example by:

• Writing experiment scripts.
• Completing data processing pipelines.
• Generating visualization code.
• Designing unit tests.
• Constructing ablation study frameworks.
• Converting pseudocode into runnable prototypes.

The risk at this layer is that model-generated code may depend on nonexistent libraries, incorrect interfaces, outdated versions, or may appear runnable while producing incorrect results. Therefore, AI assistance at the engineering layer should follow the principle of being runnable, reproducible, and reviewable.

It is recommended to retain the following materials:

• Original prompts or task descriptions.
• Model version and time of use.
• Initial generated code.
• Records of manual modifications.
• Test results.
• Final submitted version.

3. Algorithm and Proof Layer: Idea Suggestions, Formula Transformations, and Proof Construction

This is the layer that requires the most caution. AI may propose:

• A mathematical equivalence transformation.
• An algorithm variant.
• A proof strategy.
• A counterexample construction.
• A boundary condition.
• A formal proof step.
• A code optimization strategy.

Such suggestions should not be incorporated into a paper merely because they “look correct.” Researchers should at least complete the following verification:

• Manual derivation review.
• Small-scale experimental validation.
• Large-scale reproduction experiments.
• Formal proof checking.
• Code review.
• Comparison with related work.
• Error-boundary testing.

If a paper explicitly states that “a certain step was suggested by a specific AI system,” the methods section or appendix should explain further: what verification was performed, whether the original algorithm was changed, whether the final conclusions were affected, and whether reproducible experimental records exist.

---

3. Turning Model Suggestions into a Verifiable Research Process

The key point of AI-assisted research is not simply asking a model to “propose an idea,” but placing that idea into an engineered and verifiable process.

A robust process can be summarized in six steps:

1. Define the research problem
   The researcher first provides a clear problem definition, constraints, evaluation metrics, and expected goals.

2. Generate candidate solutions
   AI generates multiple candidate ideas based on the problem context, such as different algorithm variants, formula forms, proof strategies, or code structures.

3. Automatically filter candidates
   Basic rules remove candidates that are clearly infeasible, redundant, or inconsistent with constraints.

4. Perform formal verification or experimental verification
   Candidates are checked through derivation review, unit testing, property testing, proof checking, or small-scale experiments.

5. Human review
   Researchers judge whether a candidate has theoretical value, engineering value, or publishability.

6. Record and disclose
   The AI-assisted process is recorded in experiment logs, code repository documentation, or paper acknowledgments.

The following is a schematic process and does not include any specific product names:

# Example: AI-assisted research candidate screening flow
from dataclasses import dataclass
from typing import List, Callable
@dataclass
class Candidate:
    name: str
    description: str
    source: str  # human / model / hybrid
    status: str = "proposed"
def generate_candidates(problem: str) -> List[Candidate]:
    # A model interface can be used here to return multiple candidate solutions
    return [
        Candidate("variant_a", "Boundary condition adjustment", "model"),
        Candidate("variant_b", "Introduction of an auxiliary variable", "model"),
        Candidate("variant_c", "Change of optimization path", "human"),
    ]
def filter_candidate(candidate: Candidate, constraints: List[str]) -> bool:
    return all(c in candidate.description for c in constraints)
def verify_candidate(candidate: Candidate, verifier: Callable[[Candidate], bool]) -> bool:
    return verifier(candidate)
def select_best(candidates: List[Candidate]) -> Candidate:
    # In practice, candidates can be ranked using theoretical proofs, experimental results, and complexity analysis
    return sorted(candidates, key=lambda c: c.name)[0]
def ai_assisted_research_flow(problem: str, constraints: List[str], verifier):
    candidates = generate_candidates(problem)
    feasible = [c for c in candidates if filter_candidate(c, constraints)]
    for c in feasible:
        c.status = "verified" if verify_candidate(c, verifier) else "rejected"
    return feasible

The core of this workflow is: AI expands the candidate space, verification mechanisms reduce the incorrect space, and human researchers make the final decision.

If a paper needs to disclose AI contributions, the wording can be more rigorous, for example:

The main algorithm in this paper was independently designed by the authors. In the model selection section, a generative AI system proposed a possible variant. The authors subsequently confirmed its validity through derivation review and experimental verification. The AI system was used only for auxiliary exploration, does not constitute a co-author, and the authors take full responsibility for the final content.

This formulation is more rigorous than simply saying “a certain step was suggested by AI,” and it is also easier to satisfy academic review and engineering audit requirements.

---

4. Why Proof Code Generation Must Go Through a Formal Verification Loop

In areas such as algorithms, cryptography, protocol security, compilers, databases, and distributed systems, proof code is becoming more common. Researchers often need to prove that a certain property holds, for example:

• An algorithm terminates.
• Boundary conditions are safe.
• A protocol state machine does not enter an illegal state.
• An encryption protocol satisfies confidentiality or integrity.
• A class of concurrent operations satisfies linearizability.
• A data structure design satisfies invariants.
• A piece of code satisfies resource bounds.

Large models can assist with drafting proofs, proposing lemmas, and completing proof steps. However, the biggest risk of proof code is that it “appears valid but is actually invalid.” Therefore, proof code should not rely solely on natural language judgment. It should enter a formal verification loop.

1. Generation Stage: Make the Model Output Structured Proofs

The model should be required to output structured content rather than a large block of natural language. For example:

Goal:
Prove that a state machine cannot transition from a safe state to an abnormal state.
Constraints:
1. The initial state is valid.
2. All transition functions preserve invariants.
3. Illegal external inputs are not allowed.
Requirements:
Provide proof steps, necessary lemmas, counterexample checks, and boundary conditions.

Structured output is easier to process in subsequent checks.

2. Checking Stage: Use Formal Proof Environments or Theorem Provers

Formal proof tools can convert natural language proofs into machine-checkable reasoning steps. Common practices include:

• Expressing propositions in a formal language.
• Splitting proofs into lemmas.
• Using a proof checker to verify each step.
• Performing inductive proofs for key invariants.
• Searching for counterexamples along exceptional paths.

Here, the emphasis should not be on specific product names, but on general technical capabilities, such as “interactive proof checkers,” “theorem proving environments,” “model checking tools,” and “static analyzers.”

3. Testing Stage: Perform Differential Testing and Property Testing on Code Implementations

Even if a mathematical proof is correct, the code implementation may still be wrong. Therefore, both proof code and experimental code require testing.

At a minimum, the following should be included:

• Normal input tests.
• Boundary input tests.
• Illegal input tests.
• Random input tests.
• Differential testing.
• Property-based testing.
• Long-running tests.
• Concurrency or state perturbation tests.

Schematic code:

# Example: A test loop for proof code
def assert_property(case):
    assert case.initial_state_is_valid()
    result = run_algorithm(case)
    assert case.final_state_is_valid()
    assert case.inv_not_violated(result)
    assert case.resource_bound_is_satisfied(result)
def test_generated_proof_with_property_cases(cases):
    for case in cases:
        assert_property(case)

4. Version Stage: Preserve the Correspondence Between Proofs and Code

Proof code especially requires version management. Researchers should retain:

• Proof drafts.
• Formal proof files.
• Prompts used during generation.
• Original model output records.
• Records of manual modifications.
• Verifier versions.
• Test set versions.
• Execution logs.
• Correspondence with the final paper version.

If reproduction is needed after publication, these materials can significantly reduce the understanding cost for reviewers and subsequent researchers.

---

5. How to Disclose AI Contributions in Research Writing

The academic community’s attitude toward AI-assisted research is shifting from “whether use is allowed” to “how disclosure should be made transparently.” For developers, researchers, and engineering teams, a layered disclosure approach is recommended in papers or technical reports.

1. Explain the Specific AI Participation in the Methods Section

If AI affected algorithm design, experimental design, or proof paths, this should be explained in the methods section. For example:

In Section 3.2, the authors used a generative AI system to assist in exploring several possible algorithm variants. All candidate solutions were verified through manual derivation and experiments. Compared with the original solution, the final adopted variant improved stability under the same data conditions, but did not change the main algorithm framework.

2. Explain Auxiliary Tool Use in the Acknowledgments

The acknowledgments are suitable for non-core contributions. For example:

The authors thank a generative AI system for assistance with code completion, text polishing, and organization of experiment scripts. All scientific judgments, technical conclusions, and the final manuscript were completed and are the responsibility of the authors.

3. Provide Complete Audit Information in the Appendix

If AI participation is substantial, an appendix is recommended, including:

• Usage scenarios.
• Model type.
• Usage time range.
• Main tasks.
• Manual review methods.
• Verification methods.
• Failure cases.
• Final adoption ratio.

This information does not weaken the researcher’s contribution. Instead, it improves transparency and credibility.

4. Make It Clear That AI Is Not an Author

Unless a journal or conference explicitly states otherwise, AI should generally not be listed as an author. Author responsibility includes:

• Responsibility for research design.
• Responsibility for data analysis.
• Responsibility for conclusions.
• Responsibility for responding to issues after publication.
• Responsibility for academic integrity.

Generative AI cannot bear these responsibilities and is therefore not suitable as an author. However, it can be disclosed as a tool or experimental resource that requires acknowledgment.

---

6. AI-Assisted Proofs and Code Generation in Enterprise R&D

Beyond academic research, enterprise R&D faces similar issues. Scenarios such as protocol security, payment systems, compilers, database kernels, distributed consistency, risk control models, and privacy-preserving computation may require substantial amounts of proof, testing, and code generation.

In enterprise settings, AI-assisted research or development requires additional attention to the following issues.

1. Data Isolation

Internal enterprise code, protocol details, business data, and user data may contain sensitive information. When using generative AI for assistance, a data classification mechanism should be established:

• Public data: may be used with general models or prompts.
• Internal data: should be processed in controlled environments.
• Confidential data: must not enter external models.
• Compliance-sensitive data: must satisfy permission, audit, and anonymization requirements.

2. Permission Management

Access permissions to AI-assisted workflows should be restricted according to roles. For example:

• Researchers can submit only abstract problems.
• Engineers may submit code snippets but must not submit keys.
• Reviewers may view generation records.
• Security teams may audit prompts and output logs.
• Management may view only statistical indicators.

3. Log Auditing

Every AI generation, modification, and verification should leave logs. Logs should include at least:

{
  "task_id": "proof_task_001",
  "timestamp": "2026-01-01T10:00:00Z",
  "model_family": "general_language_model",
  "prompt_type": "proof_suggestion",
  "input_hash": "sha256_placeholder",
  "output_hash": "sha256_placeholder",
  "human_reviewer": "researcher_01",
  "verification_method": "formal_checker_and_unit_test",
  "status": "accepted",
  "risk_level": "medium"
}

The schematic fields do not include specific products or version numbers. They only preserve general audit dimensions.

4. Cost Control

AI-assisted research introduces inference costs, storage costs, computing costs, and human review costs. Enterprises should establish budget mechanisms, for example:

• Set invocation limits per project.
• Prioritize resources for high-value tasks.
• Cache and filter low-quality generations.
• Use templated prompts for repeated experiments.
• Adopt staged verification for large-scale proof tasks.
• Archive failure cases to reduce repeated trial and error.

When building such workflows on the cloud, organizations can use general-purpose capability combinations. For example, object storage can preserve original materials, message queues can handle asynchronous tasks, container platforms can run verification environments, logging services can record invocation processes, monitoring and alerting can track abnormal tasks, and permission management can control access boundaries. If a research assistance or R&D verification platform is built on Baidu AI Cloud, similar general-purpose cloud capabilities can also be used, without binding to a specific model or tool.

---

7. Common Risks and Countermeasures

Risk 1: AI Produces Proofs That Look Correct but Are Wrong

Symptom: The derivation is complete and the symbols look elegant, but an implicit premise does not hold.
Countermeasure: Use formal checkers, counterexample search, boundary tests, and human review. Key theorems must be independently derived by human researchers.

Risk 2: Models Fabricate Experiments or Citations

Symptom: The output contains nonexistent experimental parameters, fabricated dataset names, or incorrect literature information.
Countermeasure: All citations must be manually verified; experimental data must come from real runs; code results must be reproducible.

Risk 3: Ambiguous Contribution Boundaries

Symptom: The paper does not explain the extent of AI participation, leading reviewers to question originality.
Countermeasure: Use layered disclosure: separately explain language polishing, engineering assistance, and algorithm suggestions, and provide verification records.

Risk 4: Code Interface Hallucination

Symptom: The model generates nonexistent functions, incorrect parameters, or outdated version interfaces.
Countermeasure: Use static checks, unit tests, dependency locking, and continuous integration. All code must run in an isolated environment.

Risk 5: Data Leakage

Symptom: Unpublished algorithms, internal protocols, or sensitive data are submitted to insecure model entry points.
Countermeasure: Establish data classification, anonymization mechanisms, access control, and audit logs. Sensitive projects should use controlled environments.

Risk 6: Overreliance on AI Leads to Research Homogenization

Symptom: Many teams use similar models to generate similar ideas, reducing research diversity.
Countermeasure: Treat AI as an exploration tool rather than the sole source. Preserve human hypotheses, domain intuition, and records of failed experiments.

---

8. A Practical Template for AI-Assisted Research Governance

To make implementation easier, teams can adopt a simple governance template.

AI-Assisted Research Usage Policy
1. Scope of Application
   - Paper writing
   - Code generation
   - Experimental design
   - Proof construction
   - Data analysis
2. Usage Principles
   - Human researchers are responsible for final conclusions.
   - AI output must be verified.
   - Key derivations must be manually reviewed.
   - Sensitive data must not enter external models.
   - All generation records must be traceable.
3. Disclosure Requirements
   - Language polishing: disclose in acknowledgments.
   - Code assistance: disclose in methods or appendix.
   - Algorithm or proof suggestions: must specify the specific stage and verification method.
4. Verification Requirements
   - Code: unit tests, static checks, reproduction experiments.
   - Proofs: formal checks, counterexample search, manual derivation.
   - Data: real sources, version records, reproducible generation.
   - Papers: citation verification, formula review, experiment consistency checks.
5. Risk Control
   - Establish generation logs.
   - Establish a failure case library.
   - Establish manual review checkpoints.
   - Establish permission isolation mechanisms.
   - Establish model output quality assessment.

---

9. Conclusion: AI Can Propose the Next Step, but Humans Remain Responsible

Generative AI is already a practical part of research writing and code proof development. It can propose candidate variants at critical junctions, help researchers broaden ideas, complete experimental code, organize derivation structures, and draft proofs. However, the core of research work still lies in human researchers: defining problems, making theoretical judgments, designing experiments, and taking final responsibility.

Therefore, when encountering phenomena such as “AI suggestions appearing in a paper,” the most important response is not to simply ban or blindly praise AI use, but to establish a clear governance framework:

• Human-led: Research questions, algorithm frameworks, and final conclusions are decided by researchers.
• Machine-assisted: AI is used to generate candidates, complete code, organize expressions, and accelerate trial and error.
• Verifiable: All AI suggestions must pass derivation, experiments, formal checks, or peer review.
• Traceable: Prompts, outputs, modification records, and verification results should all be retained.
• Disclosable: Papers should clearly explain the scope, method, and responsibility boundaries of AI participation.

For developers, this trend also implies new engineering capability requirements: not only invoking model APIs, but also building verification pipelines, audit logs, permission systems, cost control mechanisms, and quality assessment processes. For research teams, transparent disclosure is not a burden, but a means of improving credibility. Truly mature AI-assisted research does not list AI as an author, nor does it hide AI participation. Instead, it makes the human-machine collaboration process clear, verifiable, and reproducible.