Back to blog

Seven practices I find useful when writing papers

This is not a methodology, but the seven actions I have kept using after two years of revising and changing things. For each one, I write "what to do" and "why." 1. First write the research question as one sentence, then start searching. Practice: Before searching, write down in one complete sentenc

AI research agentAI office assistant agentAI AgentAI office assistant

This isn't a methodology; it's the seven actions I've kept using after two years of constant revision. For each one, I write "what to do" and "why."

1. Write the research question in one sentence before you start searching

What to do: Before searching, write down in one complete sentence "what problem I want to solve, what the research object is, and where the boundaries are." Then give that sentence to a tool to break down the search dimensions, instead of repeatedly piecing keywords together in the search box yourself.

Why: When keywords don't produce results, you can't tell whether "no one is really working in this direction" or "you didn't think of the word someone else would use." This is the trap beginners fall into most easily—mistaking a failed search for a research gap.

I use MuchSci's Paper Search Assistant: the literature comes from Crossref's 180 million records, supports exact or fuzzy search by title, author, and DOI, and can also filter by year and citation count. When it finds a match, it provides the DOI and automatically fills in citation information such as authors, journal, year, volume, issue, and page numbers, so you don't have to copy it by hand.

2. Build a literature ledger with fixed fields

What to do: A table with one row per paper. There are just eight fields: number, author-year, research question, method, main conclusion, limitations, whether cited, and which section of the paper it is cited in.

Why: If you don't build a table, you read 30 papers and end up citing 5; the only trace left by the other 25 is "I think I've seen that." If you do build it, when writing the literature review you can reorder the table by theme and the structure emerges on its own; when writing the methods section, you can immediately find "how others using similar methods explained their parameters."

After search results come back, let the tool break down each paper by research question, method, main conclusion, and limitations. These are exactly the four hardest columns to fill in the ledger; at the start, filling in the table first is far more reliable than "reading it all and then writing from memory."

3. Read literature on two levels; don't read every article the same way

What to do:

· Reviews and background papers—the goal is to understand how far the field has progressed; read through them quickly.

· Original papers closely related to your project—read the original text, focusing on methods, data, and supplementary materials.

Why: If you treat both types of literature the same way, the result is that you can't go fast where you should go fast, and you gloss over where you should be detailed. In the past I "read a lot," but in fact I didn't read either type properly.

4. Use translations only to build understanding; always verify facts against the original

What to do: On the first pass, use Paper Translation's paragraph-level side-by-side reading to read through and build understanding (the translation and original always stay aligned), and on the second pass, verify methods, parameters, values, and chemical formulas against the original. The purpose of translation is: bidirectional Chinese-English academic translation, preserving formulas and terminological consistency, and supporting paragraph-level side-by-side reading of entire PDFs.

Why: The cost of misreading a value once in a translation is far higher than the cost of checking it. In my first year of grad school, I misread an equivalent number and wasted three days.

One red line: a translation is not a basis for facts.

5. Keep a separate glossary; don't use Chinese translated terms as search terms

What to do: Keep a "Chinese translation + original English term" reference table and use it consistently throughout the text.

Why: If the same concept appears in two translations in the main text, reviewers will spot it immediately. Also, don't use Chinese translated terms to search databases—you won't find anything, and it's easy to be criticized; the original English term and DOI are what you should always carry with you.

6. Archive as soon as you finish reading; don't let materials scatter across your Downloads folder

What to do: When you finish reading a paper closely, archive the translation and key points together. Put them in the Personal Knowledge Base (supports importing PDF, DOCX, PPTX, XLSX, TXT, MD, and other formats; personal use by default, not shared). For materials from miscellaneous sources—handwritten notes, whiteboard photos, files exported from other software—use the personal database layer, which supports more sources and can also store reports generated by AI Note-taking.

Why: Two or three years later, when you start a new project, you'll still need these. Scattered materials are as good as no accumulation. If you often attend group meetings and talks, AI Note-taking supports real-time recording translation, AI summaries, translation editing, and report generation; after recording, you get something you can listen to, view, and archive, placed together with your literature notes.

7. Before you start writing, explain it out loud once

What to do: Organize the structure into an outline, generate a first draft of a PPT (Office Assistant Agent: describe your needs in one sentence and get editable PPT, Word, and Excel files; there are templates for proposal scenarios—enter the project title, research question, and initial ideas, and it outputs a first draft containing the research background, current status, methods, and technical route structure), then ask yourself while looking at these few slides: if I only present this, does the main thread hold up?

Why: If you can't explain something clearly out loud, writing it down will be messy too. When you read your own draft, you slide along smoothly, but when you explain it, you can't fool yourself.

Three boundaries need to be made clear

· Opinions, arguments, and conclusions must be your own. Searching, translation, organizing, formatting, and generating a first draft of a report can be handed to tools; what your research turns out to be cannot. Before submitting or defending, confirm for yourself the target journal's and your school's rules on AI use and plagiarism checks—this responsibility lies with the user.

· Fluent sentences do not mean the argument holds. When a review says "language needs improvement," in most cases the real problem isn't the language; it's that what you want to say was never clear in the first place.

· Calculate the cost yourself; judge confidentiality yourself. These tools charge by usage (MuchSci uses credits: AI chat, paper analysis, and document generation are deducted according to the model actually invoked and the amount processed, not a fixed charge per question; free registration gives 1,980 credits as a trial allowance). Whether to upload unpublished experimental results, partners' sensitive data, or materials that haven't been finalized is your own decision. One thing I have confirmed: uploaded papers, data, and recordings will not be used for model training, and encrypted transmission and access control are used.

·

Of the seven actions, the first four are searching and reading, and the last three are consolidation and output. Once the earlier steps go smoothly, writing follows naturally.

Back to articles