auto-paper-demo

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

You need to come up with a compelling story to tell from a paper. Do not ask the user for feedback/input. You need to apply thinking and come up with the best story yourself.

你需要从论文中构思一个引人入胜的故事。不要向用户寻求反馈/输入。你需要自主思考，构思出最佳的故事。

Fetching Papers via AlphaXiv

通过AlphaXiv获取论文

Use alphaxiv.org to get structured, LLM-friendly paper content. This is faster and more reliable than trying to read a raw PDF.

使用alphaxiv.org获取结构化、对LLM友好的论文内容。这比尝试读取原始PDF更快、更可靠。

Extract the paper ID

提取论文ID

Parse the paper ID from whatever the user provides:

Input	Paper ID
`https://arxiv.org/abs/2401.12345`	`2401.12345`
`https://arxiv.org/pdf/2401.12345`	`2401.12345`
`https://alphaxiv.org/overview/2401.12345`	`2401.12345`
`2401.12345v2`	`2401.12345v2`
`2401.12345`	`2401.12345`

从用户提供的任何内容中解析论文ID：

输入	论文ID
`https://arxiv.org/abs/2401.12345`	`2401.12345`
`https://arxiv.org/pdf/2401.12345`	`2401.12345`
`https://alphaxiv.org/overview/2401.12345`	`2401.12345`
`2401.12345v2`	`2401.12345v2`
`2401.12345`	`2401.12345`

Fetch the AI-generated overview (try this first)

获取AI生成的概述（优先尝试）

bash

curl -s "https://alphaxiv.org/overview/{PAPER_ID}.md"

Returns a structured, detailed analysis of the paper as plain markdown. One call, no JSON parsing.

bash

curl -s "https://alphaxiv.org/overview/{PAPER_ID}.md"

返回结构化、详细的论文分析，格式为纯markdown。一次调用，无需解析JSON。

Fetch the full paper text (fallback)

获取完整论文文本（备选方案）

If the overview doesn't contain the specific detail you need (e.g., a particular equation, table, or proof):

bash

curl -s "https://alphaxiv.org/abs/{PAPER_ID}.md"

Returns the full extracted text of the paper as markdown.

如果概述中没有你需要的特定细节（例如某个公式、表格或证明）：

bash

curl -s "https://alphaxiv.org/abs/{PAPER_ID}.md"

返回提取后的完整论文文本，格式为markdown。

Error handling

错误处理

404 on the overview: Report hasn't been generated for this paper yet. Try the full text instead.
404 on the full text: Text hasn't been processed yet. As a last resort, direct the user to the PDF at
```
https://arxiv.org/pdf/{PAPER_ID}
```
.
No authentication is required — these are public endpoints.

概述返回404：该论文的报告尚未生成。请尝试获取完整文本。
完整文本返回404：文本尚未处理。最后一招是引导用户访问PDF链接
```
https://arxiv.org/pdf/{PAPER_ID}
```
。
无需身份验证——这些都是公开端点。

What is a good implementation?

什么是优秀的实现？

A good implementation tells a story, that's the most important thing. The story should be simple, but it should not be missing.

Papers typically have more than one concept in them. So that means you need to pick a story! It isn't the goal to fully implement the paper or to rerun a giant benchmark. The goal is to take a lesson/idea and to explain that very clearly in a notebook that can simply run on a CPU. That way, a user can easily run learn something from it. When you look at the notebook, what is the main concept or idea that you think is worth exploring? What is the concept that tells a story?

Pick the idea that is easiest to explain with a minimum code example. For a minimum code example to really work, it tends to help to have one, maybe two charts to look at. Maybe there's a dropdown that lets you try out different settings. Possibly even a slider. But the one thing we would want to do is prevent that the user needs to do a lot of scrolling.

It will be typical that you'll want to compare two approaches. But take a moment to think about the example, because that matters most to the story. Most of the time you don't want to use a toy example. They're not informative and they are overdone. It may be better to generate a creative example that shows where one approach can really shine. We don't want to cherry pick, but we also don't want to do examples that have been overdone either.

I cannot stress enough how important it is to actually think about the story and the example before you write any code whatsoever. You should really ultra think this. Give the user some interaction but really try to prevent scrolling. A good example tells a story, it doesn't just state some facts.

Feel free to think about this decision, but once you've got it clear what idea is best to showcase, immediately proceed to build the marimo notebook.

Use the marimo-notebook skill for this, and possibly the anywidget skill, but only if a custom widget makes for a better story. If you strongly feel that it makes sense to use a custom anywidget, refer to references/ANYWIDGET.md.

When you are ready, make sure that you hide all the code and that you move the cells with inputs/outputs to the top of the file.

Example:

@app.cell
def _(hide_code=True):
    import marimo as mo
    return mo

优秀的实现要能讲述一个故事，这是最重要的一点。故事应简洁，但不能缺失。

论文通常包含多个概念。这意味着你需要挑选一个故事！我们的目标不是完整实现论文内容或重新运行大型基准测试。目标是选取一个知识点/想法，在可在CPU上轻松运行的notebook中清晰地进行解释。这样用户就能轻松运行并从中学习。当你查看notebook时，你认为哪个核心概念或想法值得探索？哪个概念能构成一个好故事？

选择最容易通过极简代码示例解释的想法。为了让极简代码示例真正发挥作用，通常搭配一到两个图表会有所帮助。也许可以添加一个下拉菜单让用户尝试不同设置，甚至是滑块。但我们要避免用户需要大量滚动。

通常你会想要比较两种方法。但花点时间思考示例，因为它对故事至关重要。大多数时候，我们不希望使用玩具示例——它们信息量不足且过于常见。最好生成一个有创意的示例，展示某一种方法的真正优势。我们不希望刻意挑选数据，但也不希望使用过度泛滥的示例。

我再怎么强调在编写任何代码之前先构思故事和示例的重要性都不为过。你应该仔细思考这一点。为用户提供一些交互性，但尽量避免滚动。好的示例会讲述故事，而不只是陈述事实。

你可以花时间做这个决策，但一旦明确要展示哪个最佳想法，就立即着手构建marimo notebook。

使用marimo-notebook技能，必要时可使用anywidget技能，但只有当自定义widget能让故事更出色时才使用。如果你强烈认为使用自定义anywidget是合理的，请参考references/ANYWIDGET.md。

准备就绪后，确保隐藏所有代码，并将包含输入/输出的单元格移至文件顶部。

示例：

@app.cell
def _(hide_code=True):
    import marimo as mo
    return mo