How I Turn Learning Into a Workflow in the AI Era

Categories: Share

Before AI, my way of learning was much more old school. I would read books, go through the blogs of well-known people in a field, both in China and outside China, and keep taking notes along the way. It was slow, but there was real joy in it. I still remember learning WebGL like that. Understanding it took me almost half a year of spare time, and I loved every bit of it.

Now that AI is here, my taste has not really changed. Things like “understand One Hundred Years of Solitude in 3 minutes” or watching lectures at 2x speed are not for me. I still prefer to choose good material and spend real time with it. Moving slower and truly understanding something beats rushing through a pile of summaries and ending up with nothing solid.

Recently, while writing my “You Don’t Know Claude Code” and Agent series, I realized there were still many areas I did not understand well enough. Some parts were familiar, but many were not. Luckily, I had saved a lot of related material before, so this became a good chance to finally clear that backlog, really understand the topic, and turn it into output. I have always felt that input alone is overrated. How much you read, hear, or consume matters less than how much you can actually produce. What you can explain clearly, write down, organize, and publish, that part becomes yours.

A couple of weeks ago, I decided to study the training process of large language models and explain it in a way that even non-specialists could follow. While doing that, I realized the process itself was worth sharing, because my way of learning now feels much closer to writing code than to traditional studying. I no longer treat learning as something vague. I treat it like a workflow.

Collecting high-quality source material comes first. That usually includes strong papers from recent years, key blog posts from major model labs, posts and essays from people leading model work on X, courses from places like Stanford from the last couple of years, and classic repositories that show how to build a model from scratch. Then I use tools to automate the boring parts: downloading, converting everything into Markdown, cleaning it up, organizing it, and structuring it into categories inside a dedicated research repo. Before I write anything, I want the whole information environment to be in good shape.

After that, I start reading and filtering. Material I can understand directly, I read carefully and decide whether it deserves to stay. Bad material gets deleted. For things I cannot understand, I use Claude to work through them. For harder pieces, I translate into Chinese and read again. If there is code I can run locally, I run it. If not, I still look through the structure and try to understand the core idea. At this stage, I am not trying to fully master everything. I just want a real working understanding of the field and its core technical logic. By the end of this round, half of the material is usually gone. That is normal. Filtering is part of learning. Keeping the right things matters more than reading more.

Once I have a rough but usable map of the field in my head, I can start outlining the article. I think about what I want to cover, which sources belong to which section, what order makes sense, and most importantly, what I want readers to understand when they finish. An article is written for other people, not just for yourself. You need to know what they already know, where they will get lost, and what level of explanation they need. In that sense, writing is very similar to giving a report. You are always thinking about the audience.

After that comes the real labor. I go section by section, filling in every part, adding missing explanations, and making the whole thing complete. It feels a lot like exam review back in school. What I usually end up with is a very long draft, and a wordy one too. This is where AI earns its place. I do not use it to replace my thinking. I use it to refine what I already have. I ask it to keep my meaning and tone while helping me remove useless repetition, fix weak transitions, point out places where the logic is incomplete, and identify missing background knowledge. In that process, AI is not writing the article for me. It is tightening the structure, cutting noise, and exposing gaps. A lot of times I learn more at this stage, because some missing pieces only become obvious after the draft already exists.

That is also why AI is most useful when attached to real output. If all you do is ask AI to summarize things, it is easy to feel productive while building nothing solid in your own mind. When you are seriously trying to write something, explain something, or build something, AI becomes much more useful. The tool amplifies what you are already doing.

When the draft is in decent shape, I read it again myself. AI stays a tool. Once you let it take over your judgment, the whole thing becomes less meaningful. So I read through the draft and keep editing, adjusting, and tuning. It feels like writing code and testing it yourself. You keep finding weak spots, fixing rough edges, and cleaning up places that do not feel right. After two passes like this, I usually know whether it is ready. Then I publish it.

This way of working is also why I made Waza, a small open source set of Skills built around how I actually work with AI. One of them is /learn, and this is what it is for: research, filtering, outlining, drafting, refining, and publishing as one continuous workflow.

I know some people worry that if they write something, nobody will read it, so they stop before they even begin. That is not a good reason. If your work is meaningful, it will find its readers. Maybe not immediately, maybe not all at once, but meaningful work is rarely wasted. “No one will read it” is usually just a reason to avoid the effort.

For me, this whole process made one thing clearer. In the AI era, learning is much faster than before, but depth still does not come for free. AI can help with collecting, translating, cleaning, organizing, comparing, and refining. It can make the whole process much more efficient. Real depth still depends on your judgment, your patience, your standards, and most of all, your willingness to turn input into output. That part has not changed. Now it matters even more.

Read More

You Don't Know LLM Training: Principles, Pipelines, and New Practices

【2026-04-03】Most people think model upgrades mean bigger parameters. But the real differences you feel day-to-day usually come from the back half of the training pipeline. This piece follows the full chain from pretraining through distillation and deployment, with a focus on how data engineering, system recipes, post-training, reward design, and agent training together shape the final product. The conclusion is that models getting stronger is almost always a joint effect of weights, training pipeline, and deployment decisions, not just scale.