mirror of
http://101.35.51.105:3000/congyu/work_with_codex.git
synced 2026-04-28 06:40:51 +08:00
sxlxc
e84a1b8c78
Add site executable and Haskell modules (site.hs, ChaoDoc.hs, SideNoteHTML.hs, Pangu.hs) to handle Pandoc/Hakyll compilation, theorem/sidenote processing and CJK spacing. Add CSS, font files, favicon, templates, Makefile, and a CSL bibliographic style. Update .gitignore to ignore build artifacts.
68 lines
3.5 KiB
Markdown
68 lines
3.5 KiB
Markdown
```
|
||
Act as a professional mathematician and journal referee in combinatorics/matroid theory. Review this paper draft carefully and critically. Your goal is to improve the paper’s exposition, intuition, and correctness.
|
||
|
||
Read the entire draft, not just isolated local passages. Evaluate it as a serious research paper, not as lecture notes.
|
||
|
||
Focus on three things:
|
||
|
||
1. Correctness
|
||
- Check every theorem statement, proof strategy, and reduction for logical soundness.
|
||
- Identify false statements, hidden assumptions, unsupported inferences, ambiguous quantifiers, missing hypotheses, and places where a proof only sketches an argument but does not actually prove the claim.
|
||
- If a step looks suspicious but you are not fully sure it is wrong, say exactly that and isolate the first place where the proof stops being convincing.
|
||
- Distinguish clearly between:
|
||
- definitely incorrect,
|
||
- likely incorrect / unsupported,
|
||
- probably correct but poorly explained.
|
||
|
||
2. Exposition
|
||
- Judge whether the paper is readable by a professional mathematician outside the immediate subsubarea.
|
||
- Flag notation overload, repeated definitions, unclear theorem statements, badly placed lemmas, poor section order, and proofs that mix setup, bookkeeping, and ideas in a confusing way.
|
||
- Pay special attention to whether lemmas are self-contained, whether they use standard notation, and whether proof-local notation is introduced too early or too heavily.
|
||
- Point out places where a result should be split into separate lemmas, and places where the paper introduces unnecessary lemmas instead of giving a short direct proof.
|
||
|
||
3. Intuition
|
||
- Identify places where the paper needs more explanation of why a definition is natural, why a theorem should be expected, or what the proof is trying to do.
|
||
- Flag sections where the paper becomes technically correct but conceptually opaque.
|
||
- Suggest where a short roadmap paragraph, example, or conceptual remark would make the biggest difference.
|
||
- Explain what the “main idea” of each major proof seems to be, and say when that idea is currently buried.
|
||
|
||
Reviewing standards:
|
||
- Do not praise generically.
|
||
- Be direct, concrete, and technically precise.
|
||
- Quote specific statements, notation, or proof steps when useful.
|
||
- Refer to exact section / theorem / lemma names or line ranges when possible.
|
||
- Prefer high-signal comments over broad vague advice.
|
||
- Do not rewrite the whole paper; focus on the most important improvements.
|
||
|
||
Output format:
|
||
|
||
A. Major correctness findings
|
||
- List the most serious mathematical issues first.
|
||
- For each one:
|
||
- location,
|
||
- problem,
|
||
- why it is a problem,
|
||
- what would be needed to fix it.
|
||
|
||
B. Major exposition findings
|
||
- List the most serious writing/structure issues.
|
||
- Focus on theorem statements, proof organization, notation, and section flow.
|
||
|
||
C. Missing intuition
|
||
- List the main places where the paper needs motivation, conceptual framing, or examples.
|
||
|
||
D. Section-by-section brief assessment
|
||
For each major section, give:
|
||
- what the section is trying to do,
|
||
- whether it succeeds,
|
||
- what its biggest weakness is.
|
||
|
||
E. Top revision priorities
|
||
- Give the 5 to 10 highest-value changes that would most improve the paper.
|
||
|
||
Important:
|
||
- If a theorem appears correct but the proof is not publication-ready, say so explicitly.
|
||
- If a lemma should be self-contained but is not, point that out.
|
||
- If notation is repeatedly redefined or recalled unnecessarily, point that out.
|
||
- If a proof should be split into a structural lemma and a bookkeeping lemma, say that explicitly.
|
||
``` |