A Research Proposal Is Really Just Six Sections: What to Write in Each and Where People Often Go Wrong
A month before my proposal, I held a template a senior classmate had given me and stared at it for ages, not knowing where to start.
The template only had headings: research background, research significance, domestic and international research status, research content, technical route, and schedule. Six lines of text, with blank space under each.
Later I realized thatthe six sections are actually six questions; as long as each section answers its question, the report takes shape.
Section 1: Research Background—Answer “Why does this need to be done now?”
At first, I wrote the background as an industry review: starting from twenty years ago, I wrote eight hundred words and still hadn't gotten to my question.
Later I changed it to a three-sentence pattern:
1. What this field is doing now (one sentence)
2. Where it is stuck (one sentence)
3. So this is worth doing (one sentence)
I usually keep the background within six hundred words.When the background gets long, it usually means you haven't figured out where the problem is.
Section 2: Research Significance—Answer “What use is it once it's done?”
Significance has two layers: what it adds in theory and where it can be applied in practice. Two sentences for each layer is enough; don't turn it into slogans.
My current approach is “Without this research, ×× would still depend on ××,” which is much more specific than “of great significance.”
Section 3: Domestic and International Research Status—Answer “How far have others gotten?”
This section is the easiest to turn into a laundry list. My approach is to search first, classify second, and close with one final sentence.
For searching, I use MuchSci's paper search assistant, filtering by keyword plus year. I first look at reviews from the past five years, then follow their citations back to classic literature. The library has 180 million Crossref papers, searchable by title, author, and DOI; finding reviews this way is faster than digging through databases one by one.
After classifying, I write one sentence for each category: “how far it has gotten and what is still missing.”The value of this section is not how many papers you list, but that final sentence about “what is still missing”—it leads directly into my research content.
Section 4: Research Content—Answer “Which things do I need to do?”
I write it as three items, each starting with a verb: what to measure, what to compare, what to build.
No more than three; more than that and I can't finish. After each item, add one sentence: “What result do I expect?” If you can't write it, that item shouldn't be there.
Section 5: Technical Route—Answer “What comes first and what comes later?”
I use a flowchart to show it, which is clearer than text: sample → characterization → data processing → comparative analysis → conclusion.
When drawing the chart, I ask myself one question:Which step might fail? For the step that might fail, write a backup plan in advance so I won't get stuck if asked during the defense.
Section 6: Schedule—Answer “When will each step be finished?”
Plan by week, not by day. Each line should read “Week X–Week Y + deliverable,” and the deliverable should be specific, such as “data table,” “first draft,” or “revised draft.”
How I Filled In the Six Sections
I wrote the first two sections myself, because they reflect my judgment about the problem; for the third section, I used search results as a foundation; for sections four to six, I gave the content of the first three sections to MuchSci's chat + agent, asked it to provide a first version of the structure, and then revised it according to my own experimental conditions.
The “technical route” it gives is usually a generic process, so I delete steps that don't apply—this step can't be skipped, because applying a generic process to a specific experiment often adds two steps that simply can't be done under the available conditions.
After filling in the six sections, I read through the whole thing and check whether each section answers only its own question. Keep what answers correctly; delete what drifts off.
Foruniversity student AI assistants, what I need most when writing a proposal is “don't leave me staring at a bunch of blank headings,” not writing the whole thing for me. MuchSci does just two things for me here: finding literature and building structure.