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中清晰地进行解释。这样用户就能轻松运行并从中学习。当你查看论文时，你认为哪个核心概念或想法值得深入探索？哪个概念能构成一个完整的故事？
选择最容易通过极简代码示例解释的想法。要让极简代码示例真正发挥作用，通常配合1到2个图表会有所帮助。或许可以添加一个下拉菜单让用户尝试不同设置，甚至是滑块。但我们要避免用户需要大量滚动页面。
通常你会需要比较两种方法，但请花时间构思示例，因为它对故事的呈现至关重要。大多数情况下，我们不希望使用玩具示例——它们缺乏信息量且被过度使用。或许可以创作一个有创意的示例，展示某一种方法的优势。我们不希望刻意挑选有利结果，但也不希望使用过度泛滥的示例。
我再怎么强调在编写任何代码之前先构思故事和示例的重要性都不为过。你应该对此进行深入思考。为用户提供一些交互功能，但要尽量避免滚动操作。一个好的示例会讲述故事，而不仅仅是陈述事实。
你可以花时间做出这个决定，但一旦明确了最适合展示的想法，请立即着手构建marimo notebook。
请使用marimo-notebook技能，必要时可使用anywidget技能，但仅当自定义组件能优化故事呈现时才使用。如果你强烈认为使用自定义anywidget是合理的，请参考references/ANYWIDGET.md。
准备就绪后，请确保隐藏所有代码，并将包含输入/输出的单元格移至文件顶部。
示例：
@app.cell
def _(hide_code=True):
import marimo as mo
return mo