學術寫作潤飾 Academic Writing Refiner

\begin{abstract}
Large language models (LLMs) are widely used for code generation, but their outputs are often unreliable on long programs. We propose SketchFix, a method that repairs generated programs using many lightweight unit tests. SketchFix is model-agnostic. On HumanEval and MBPP, it outperforms [BASELINES], improving [METRIC] by [X] points on average.
\end{abstract}

Notes on changes

• Citation removed. NeurIPS abstracts should be self-contained and not cite. The opening sentence about growing attention was filler, so I replaced it with a direct statement of the problem. If you want the citation, put it in the introduction.
• Filler and hedging cut. I deleted "It is worth noting that" and "it could potentially be argued that". I replaced "in the case of" with "on", "in order to" with a direct verb, and "a plethora of" with "many".
• "Leverages" became "uses".
• "Novel paradigm" became "method". "Paradigm" overstates the contribution unless you are proposing a new way of framing the problem. "Novel" is better shown by the results than claimed.
• Passive to active. "The approach was designed by us to be model-agnostic" became "SketchFix is model-agnostic", a short claim stated directly.
• Vague results replaced with placeholders. "Performs quite well" and "seems to achieve better results" are now a firm comparison with bracketed slots for you to fill in.

Missing, to fill in or confirm

1. Baselines. "The aforementioned baselines" refers to nothing in the abstract. Name them or describe them, for example "prior repair methods".
2. Quantitative result. Give the metric (for example pass@1), the size of the improvement, and ideally the models it was measured on. I did not invent these numbers.
3. Whether "outperforms" is justified. Your draft says "seems to achieve better results". If the gains are not consistent across both benchmarks, or are not statistically meaningful, soften the claim to "improves on" or limit it to the cases that hold.
4. Evidence for "model-agnostic". Reviewers will want to know which LLMs you tested. Consider "works with N different LLMs" if that is true.
5. Support for "unreliable on long programs". Add a number or a short qualifier if you have one, such as the pass-rate drop as program length grows. Otherwise it is an unsupported claim.
6. Where the unit tests come from. Say whether they are given, generated, or model-written. This is a key detail of the method and is absent from the draft. One clause would help.
7. Length. The abstract is about 55 words, well under the usual 150–250. Items 2, 5 and 6 would bring it closer to that range.