arXiv Chinese Summary Methodology

This file records the reusable workflow for daily arXiv paper summaries in this repository.

Input Handling

• Input is a dated list of arXiv links, usually https://arxiv.org/abs/<id> or https://arxiv.org/pdf/<id>.
• Parse the arXiv ID without version suffix for final output, for example 2604.22986v1 becomes 2604.22986.
• Final links must always use https://arxiv.org/abs/<id>.
• Preserve the input date as the top-level heading: ## YYYY-MM-DD.

Retrieval Priority

For each paper, try sources in this order:

1. arXiv HTML: https://arxiv.org/html/<id>
2. ar5iv HTML: https://ar5iv.labs.arxiv.org/html/<id>
3. PDF text: https://arxiv.org/pdf/<id>, extracted with pdftotext or another PDF text tool.
4. arXiv abstract page, only if full text is unavailable.

If arXiv HTML works, prefer it over PDF because it is faster and avoids PDF extraction errors. If HTML is malformed or clearly incomplete, fall back rather than trusting it.

Cache Layout

• Keep all paper retrieval caches under .paper_cache/.
• Use one subfolder per date, preferably .paper_cache/YYYYMMDD/.
• Do not create date-specific cache folders at the repository root such as .paper_cache_YYYYMMDD.
• Store downloaded HTML, extracted HTML text, PDFs, and PDF text in that date subfolder.

Extraction Checklist

For each paper, confirm from the available text:

• Exact English title.
• arXiv abs link.
• Research field and 2-5 English keywords.
• Research problem or goal.
• Method, model, observation, simulation, theoretical framework, or experimental setup.
• Data/sample/instrument details when relevant.
• Main conclusions and contributions.
• Project, code, data, or documentation links only when explicitly present and relevant.

Do not infer details from the title alone. If only the abstract is available, write conservatively and do not claim full-paper details. For titles, cross-check the arXiv abstract page when possible because converted HTML can alter capitalization, punctuation, math symbols, or dashes.

Reading Strategy

• Read the title, abstract, introduction, methods/data, results, discussion/conclusion, data availability, and acknowledgments/link sections.
• Use text search for terms such as Conclusion, Summary, Results, Data availability, github, zenodo, code, software, repository, and http.
• For numerical claims, verify the exact values in the results or conclusion sections.
• For tool/model/data papers, verify links by checking that line breaks in extracted text did not corrupt URLs.
• Include only links that are already public and useful for understanding or reusing the paper's data, tool, model, or project. Ignore placeholders such as future GitHub links, and usually omit generic dependency links unless the dependency is central to the paper.
• When there are several papers, use parallel subagents for independent structured notes, then locally verify the important numbers and links before final output.

Figure Selection and Embedding

Apply this section by default for daily batches. Omit figures only when the user explicitly asks not to include them, or when no original article figure can be acquired without violating the rules below.

• Include exactly one original article figure per requested paper. Choose it only after reading both its caption and the surrounding results or methods text; never choose from the title, a search thumbnail, or visual appeal alone.
• Preference order: (1) the final data product, decisive result, or main comparison; (2) a figure that makes the central mechanism or workflow intelligible; (3) the most visually legible substantive figure. For data-product or technical reports, a clear final-product frame is usually the strongest choice.
• A multipart figure may contribute one complete, labeled subfigure when that panel alone directly carries the paper's main result. Do not assemble editorial composites from separate figures or use a partial crop that removes essential axes, labels, or the figure's meaning.
• Avoid author or institute logos, decorative front matter, generic instrument photographs, redundant diagnostic plots, and intermediate processing panels when a more direct result figure is available.
• Retrieve the highest-resolution original figure asset from arXiv HTML or source assets when available. Otherwise render the relevant PDF page with pdftoppm and crop only the published figure. Never generate, redraw, recolor, or otherwise alter scientific image content.
• Visually inspect the candidate and the saved final image. Confirm the figure number and caption, readable labels/axes, intact boundaries, and that the selected image actually matches the summarized claim.
• In this repository, save the final asset under YYYY/MM/Figures/ with a unique name such as image-YYYYMMDDHHMMSSmmm.png; never overwrite an existing asset. Check that the saved file exists and retains a useful resolution.

Keyword Style

• Keywords are English, comma-separated, 2-5 per paper.
• Use clean domain terms such as Fast Radio Burst, Cosmology, Solar, Observation, Theory, Simulation, Tool, Deep Learning, LLM, AGN, FRB, QPO, RFI.
• Do not use hyphenated keywords when a non-hyphenated phrase works.
• Add Review for review papers, Tool for software/platform papers, Observation for observational results, Theory for theoretical modeling, and Simulation for simulation-heavy papers.

Output Format

Final output must be a single fenced markdown code block and nothing else, so the user can copy the raw Markdown without rendered formulas being rewritten by the chat UI:

```markdown
## YYYY-MM-DD

1. [Title](https://arxiv.org/abs/xxxx.xxxxx)

    > Keyword1, Keyword2, Keyword3

    Chinese summary content.
```

Rules:

• Number papers continuously from 1.
• Indent every continuation block inside a numbered item with exactly 4 spaces, including the keyword blockquote, all prose paragraphs, nested bullets, and standalone $$ equation blocks. Do not use 3 spaces; otherwise items numbered 10. and above can render as broken list content in local Markdown viewers.
• Use the exact English title.
• Use only arXiv abs links for title links.
• Do not output logs, retrieval details, tool output, or a preface.
• Do not put explanatory text before or after the fenced code block.
• Do not add citation links after every paragraph.
• Include code/data/project links in the prose only when the paper explicitly provides them and they are useful.
• If no code/data link exists, say nothing about missing links.
• Place each included figure's image tag immediately after that paper's summary paragraph, still indented by exactly four spaces:

  <img src="./Figures/<filename>.png" alt="<filename-without-extension>" width="680px" />

  Use the relative ./Figures/ path for the dated APOD Markdown page and keep the tag inside the fenced Markdown output.

Chinese Summary Style

• Write directly and densely in Chinese.
• Cover purpose, method, and conclusion.
• Avoid formulaic wording such as 作者如何如何, 本文如何如何, 目的是, 方法是, 结论是.
• Avoid empty praise and marketing language.
• Avoid overusing quotation marks.
• Use affirmative declarative sentences by default: directly state what the paper studies, how it proceeds, and what it finds. Do not manufacture a contrast target just to frame the summary.
• Avoid 不是……而是……, 并非……而是……, 而非……, and similar adversative-negative constructions unless the distinction is indispensable for correct use of the result. When a scope boundary matters, state it as a short declarative caveat, for example: 这项工作给出 DSA/Chronoscope 的参考设计和科学预报。预报依赖仪器、源计数和算力假设。 Do not write a contrast such as 这不是实际巡天数据发布。
• For an ordinary daily paper, use one paragraph of about 180-300 Chinese characters and usually 4-6 sentences. Use a second paragraph only for a complex review, major data release, or tool paper whose method and deliverables cannot be explained clearly in one paragraph.
• Treat the output as a digest, not as reading notes. A normal summary should retain only:
  1. the research question or target;
  2. the defining method, dataset, sample, or instrument;
  3. the main result, including at most 2-3 decisive numerical values;
  4. one limitation or interpretation caveat that materially changes how the result should be used;
  5. one verified public code/data/project link when it is genuinely useful.
• Prefer one sentence for the problem, one or two for the method and sample, two for the results, and one final sentence for the main caveat or reusable resource. Merge these roles when possible.
• Remove general field background, routine processing details, full parameter lists, secondary validation exercises, repeated uncertainty metrics, speculative future applications, generic significance claims, and multiple caveats that do not change the headline conclusion.
• When the paper reports many measurements, keep the sample size or observing scale plus the 1-2 numbers that best establish the result. Do not reproduce every threshold, intermediate fit, catalog comparison, or observing setting.
• Do not explain standard instruments, surveys, algorithms, or statistical terms unless that explanation is necessary to understand what is novel in the paper.
• If the abstract already states the main result accurately, use the full text to verify and sharpen it rather than expanding the summary with every additional detail found in the paper.
• Use concise bullets only for complex reviews or broad tool/data papers when bullets improve clarity.
• Preserve important equations with Markdown math, for example $DM$, $RM$, $B_8 \equiv \sigma_8(\Omega_b/0.05)^{1/2}$.
• Use inline math only for short symbols or short expressions. Any display equation must use a standalone $$ block with opening and closing $$ on separate lines:

  $$
  ...
  $$

Quality Gate

Before final output, check:

• Dates and numbering are correct.
• Titles and arXiv abs links are correct.
• Keywords are English and not awkwardly hyphenated.
• Each summary includes purpose, method, and conclusion.
• Important sample sizes, instruments, models, and numerical results are verified from the text.
• Ordinary papers are one paragraph and roughly within the 180-300 Chinese-character target; any extra paragraph or substantial overrun is justified by the paper being a complex review, data release, or tool paper.
• No more than 2-3 numerical values are retained unless additional numbers are essential to distinguish multiple primary results.
• The summary reads as a prioritized digest rather than a section-by-section walkthrough: background, routine implementation details, secondary checks, and redundant caveats have been removed.
• The prose uses direct declarative statements and does not create a rhetorical target through unnecessary adversative or negative phrasing.
• A reader can identify what was studied, how it was tested, what was found, and the single most important usage caveat without reading the paper.
• Tool/data links are included only when explicitly present.
• Unless figures were explicitly omitted, there is exactly one appropriate original figure per paper; its number/caption and scientific relevance were checked from the paper; the saved file is visually legible at the target size; and its ./Figures/ path, filename-stem alt, and four-space indentation are correct.
• No retrieval logs or process notes appear in the final answer.