XtraGPT lets you revise papers with control

XtraGPT turns paper revision into a controllable human-AI workflow.

I've been messing with AI writing tools for academic drafts for a while, and honestly, most of them feel wrong in the same annoying way. You paste in a paragraph, ask for a revision, and the model comes back sounding polished but weirdly detached from the paper you actually wrote. It can clean up a sentence, sure. But it also happily flattens your argument, changes the tone, and slips in claims that sound plausible until you read them twice. That is not editing. That's a polite kind of sabotage.

What I wanted was boring, in the best way: keep the paper's intent, respect the surrounding context, and let me control how aggressive the rewrite should be. If I say “tighten this related work section,” I do not want a mini-essay that invents new structure. If I say “preserve terminology,” I mean preserve terminology. The annoying part is that most general-purpose assistants do not know where the boundaries are. They answer the prompt, but not the document.

The paper that pushed me to rethink this was a Zhihu post about XtraGPT, which points to the paper XtraGPT: Context-Aware and Controllable Academic Paper Revision via Human-AI Collaboration and the code repo XtraGPT on GitHub. The post says the work comes from a team led by He Bingsheng at the National University of Singapore and that it has been accepted to ACL 2026. I am not going to pretend the Zhihu post gives a full technical breakdown, because it does not. But the framing alone is enough to explain why this matters.

Stop asking a chatbot to “improve” your paper

Context-Aware and Controllable Academic Paper Revision via Human-AI Collaboration

What this actually means is that XtraGPT is not trying to be a generic writing buddy. It is trying to be a revision system. That distinction matters more than people admit. A chatbot is optimized to respond. A revision tool is optimized to transform text while staying inside constraints. Those are different jobs.

When I work on papers, the real pain is never “write me something from nothing.” It is “fix this paragraph without wrecking the surrounding argument.” General LLMs are decent at the first task and sloppy at the second. They do not naturally respect local context, section-level intent, or the paper’s own vocabulary. If you have ever had a model replace a precise term with a fancier synonym just because it sounded better, you know the problem.

XtraGPT’s framing tells me the authors are treating revision as a collaboration loop between human and AI, not as one-shot generation. That is the part I care about. The human provides intent, constraints, and judgment. The model handles candidate rewrites. Then the human decides what survives. That is much closer to how I already edit with a colleague: they suggest, I reject half of it, and the paper gets better because the feedback loop is tight.

How to apply it: stop prompting like you are chatting with an assistant and start prompting like you are specifying an editing task. Say what should stay fixed, what can change, and what level of aggressiveness you want. If you are building your own workflow, separate “draft generation” from “revision under constraints.” That split alone will save you from a lot of mushy output.

Context is the part most tools fake

Academic writing is full of references that only make sense in the surrounding section. A sentence can be technically correct and still be wrong for the paper. That is why context-aware revision is such a big deal. If the model only sees the local paragraph, it may improve fluency while breaking consistency with the abstract, method, or terminology used elsewhere.

I ran into this constantly when editing technical docs with LLMs. The model would rewrite “retrieval-augmented generation” as “knowledge-enhanced generation” because it thought it was being helpful. That kind of change is poison in academic writing. You are not just polishing prose. You are preserving a chain of meaning.

XtraGPT’s title says “context-aware,” and I read that as a promise that the system looks beyond the sentence in front of it. That could mean pulling in neighboring sections, preserving paper-specific entities, or conditioning edits on document structure. I am not going to invent details the source post does not spell out, but the direction is obvious: if revision is aware of the paper, it can stop acting like a blind paraphraser.

How to apply it: whenever you revise with AI, feed the model enough surrounding material to anchor the change. At minimum, include the paragraph before and after. Better yet, include the section heading and a short note describing the role of the passage. If you are building tooling, make context a first-class input instead of an afterthought.

• Give the model the section title, not just the paragraph.
• Tell it which terms are locked and must not change.
• Provide a one-line goal for the revision, like “reduce redundancy” or “make the claim sharper.”

Control beats “make it better” every time

The word “controllable” in the paper title is doing a lot of work, and I think that is where the real product idea lives. Most AI writing tools fail because they offer a vague quality boost with no steering wheel. You ask for improvement, and the model decides what improvement means. That is not a workflow. That is a gamble.

In academic writing, control usually means several things at once: how much to rewrite, whether to preserve wording, whether to keep the argument order, and whether to optimize for clarity, concision, or style. If the system exposes those controls, the output becomes usable. If it does not, you spend more time undoing the model than benefiting from it.

I like this framing because it respects the fact that authors are not all asking for the same thing. A first draft of a related work section may need heavy restructuring. A methods paragraph may only need grammar cleanup. A result interpretation paragraph might need stronger hedging, not bolder claims. One size fits nobody.

How to apply it: define revision modes in your own workflow. For example, create three levels: light edit, structural edit, and argumentative edit. Then decide which one applies before you send text to a model. If you are using an API or building a tool, expose those modes explicitly instead of hiding them inside a generic “improve” button.

• Light edit: grammar, clarity, punctuation, minimal wording changes.
• Structural edit: sentence reordering, trimming repetition, better transitions.
• Argumentative edit: sharpen claims, adjust emphasis, improve logical flow.

Human-AI collaboration is not a slogan here

I usually roll my eyes when I see “human-AI collaboration” because it often means “we put a human in the loop somewhere and called it a system.” But in this case, the phrase actually points to the right failure mode. Paper revision is not a pure generation problem. It is a negotiation problem.

The author knows the intended meaning. The model knows how to produce fluent alternatives. The editor, if there is one, knows the venue, the style, and the risk tolerance. Those pieces need to talk to each other. If you remove the human too early, you get confident nonsense. If you remove the model, you lose speed and breadth. The useful system is the one that keeps both sides active.

That is also why I think this line of work is more interesting than “write my paper for me” tools. The goal is not to replace the researcher. It is to compress the ugly middle part of editing, where people spend hours rephrasing sentences that already contain the right idea. That is the sweet spot. Not author replacement. Not autocomplete cosplay. Just fewer dead hours in the revision loop.

How to apply it: design your workflow so the model proposes and you dispose. Do not let it silently overwrite the source text. Keep diffs visible. Review changes by category, not just as a blob of new prose. That is how you preserve authorial intent while still getting the speedup.

Why this matters for papers, not blog posts

A lot of writing assistants are built for style. Academic writing is built for precision, traceability, and restraint. That is why a tool that works well on marketing copy can fail badly on a paper. Papers have claims that depend on citations, terminology that must stay stable, and section roles that are not interchangeable.

XtraGPT is interesting because it is aimed directly at that mess. The title suggests the authors are not trying to generalize to all writing. They are focusing on paper revision under constraints. That narrowness is a feature, not a limitation. When you aim at a specific document type, you can build stronger assumptions into the system and get better behavior.

I have seen this in my own work on technical docs and spec writing. The more specific the tool is about the document genre, the less time I spend correcting it. Generic writing tools keep trying to sound good. Domain-specific revision tools try to stay correct. I care about correct first.

How to apply it: if you are choosing or building an AI writing workflow for research, do not ask whether it is “good at writing.” Ask whether it understands document structure, preserves terms, and supports controlled rewriting. If the answer is fuzzy, the tool is probably too generic for serious paper work.

What I would copy from XtraGPT’s approach

The best thing I can steal from this paper is not a specific model trick. It is the product shape. XtraGPT treats revision as a structured operation over a document, with human intent as an input and controllability as a requirement. That is a much better mental model than “paste text, get nicer text.”

If I were building my own academic assistant, I would copy three things immediately: context windows that include neighboring sections, explicit edit modes, and visible diffs. I would also keep a hard rule that the model cannot silently change named entities, formulas, abbreviations, or citations unless the user approves it.

There is a reason editors exist. They do not just rewrite. They protect meaning. AI tools that ignore that end up feeling clever for five minutes and expensive for the next five revisions. XtraGPT’s pitch is that you can do better by making control and context part of the system itself.

How to apply it: build your prompts, UI, or agent flow around these questions before every revision: What must stay fixed? What can change? How aggressive should the edit be? What surrounding context does the model need? If you cannot answer those, you are not ready to revise with AI yet.

The template you can copy

# Academic Paper Revision Prompt Template

You are helping me revise an academic paper section.

## Goal
Revise the text below while preserving the paper's meaning, terminology, and citation intent.

## Hard constraints
- Do not change named entities, abbreviations, formulas, or citation markers unless I explicitly allow it.
- Do not invent new claims, results, or references.
- Keep the section's role in the paper intact.
- Preserve the technical meaning of every sentence.

## Revision mode
Choose one:
- light: grammar, clarity, punctuation, minimal wording changes
- structural: improve flow, reduce redundancy, reorder sentences if needed
- argumentative: sharpen logic, transitions, and emphasis without changing facts

## Context
Section title: [INSERT SECTION TITLE]
Paper topic: [INSERT TOPIC]
Neighboring context:
[PASTE THE PARAGRAPH BEFORE]
[PASTE THE TARGET PARAGRAPH]
[PASTE THE PARAGRAPH AFTER]

## Task
Revise the target paragraph according to the selected mode.
Return:
1. The revised paragraph
2. A short change log
3. Any places where you were uncertain and want human review

## Target paragraph
[PASTE TEXT HERE]

This template is my practical translation of the XtraGPT idea into something I can actually use today. It is not the paper itself, and it is not a claim about the implementation details beyond what the source post says. It is my copy-ready version of the workflow: context first, control second, revision third.

If you want the safest possible use of AI in paper writing, this is the pattern I would start with. Keep the model on a leash. Make the edit mode explicit. Review the diff. That is boring, yes. It is also how you stop AI from wrecking the paper while still getting real help.

Source attribution: I first saw this through the Zhihu post at zhuanlan.zhihu.com/p/2050234884409627149, which links to the paper at arXiv and the code at GitHub. The explanation and template above are my own synthesis, not text copied from the source.