easy-learn-ai: a status column for sixty AI concepts, which is rarer than it sounds

A status column, which is rarer than it sounds

The readme contains a long table of concepts, and the table has three columns. The first is the category, the second is a link with a one-line description, and the third is a status.

That third column is the whole article. Roughly sixty concepts are listed, and each is marked either as complete or as under construction. The unfinished rows are not greyed out or omitted; they are named, described in one line, and marked.

That is a small decision with a large effect on how a reader uses the site. A curated list without status markers is a promise: everything linked exists and is finished. A list with status markers is an inventory: some of this exists, and here is exactly which. For a beginner-oriented site, where the whole value proposition is not knowing what to read first, the difference is the difference between a confident wrong answer and a partial right one.

It also changes what a reader can expect from the project. A site that ships a placeholder link and calls it a placeholder is signalling that the work is ongoing and that the gaps are known. A site with a promise-shaped list and missing pages is signalling the opposite, and you will discover the difference on your fifth click.

The status markers are doing double duty, though, because they also let a reader skip. Someone who already knows what a decoder-only architecture is can see at a glance that eleven architecture entries are done and move on to the deployment section. That is a real usability gain, and it is not available to a list without markers.

The one thing the table does not do is say when a page was last touched. A concept finished three years ago and a concept finished last week look identical. For a field where the naming and the vendor landscape move every quarter, a second column with a date would have made the inventory considerably more useful, and its absence is a reasonable thing to note rather than a criticism.

What got finished reveals the editorial rule

Read the two lists side by side, the complete entries and the unfinished ones, and a consistent rule falls out.

Complete: the prompting concepts. The system prompt, few-shot examples, chain of thought. Complete: the model architectures, one page each for the encoder-only family, the decoder-only family, the sequence-to-sequence family, the mixture-of-experts architecture, multimodality, how modalities get encoded, how meaning gets represented, and one recent reasoning model. Complete: the training stages, from pretraining through supervised fine-tuning, preference alignment via reinforcement learning with human feedback, the reward model, the direct preference method, and then the data topics, which get three pages of their own for annotation, cleaning and construction. Complete: the fine-tuning section, which is the longest run of consecutive pages in the table, covering the methods side by side, the adapter technique, and then separate pages for each of the four parameters you would actually set: rank, learning rate, epochs and batch size.

Unfinished: grouped query attention, an efficient attention variant. Sliding window attention. A chunked approach to extending context. Positional encoding by rotation. Gradients and backpropagation. Optimisers. Perplexity. Fitting and overfitting. Model evaluation generally. The whole evaluation section except one page. The two inference engines, both of them, while the page comparing them is marked done.

The rule that fits is this: concepts that map to a setting, a file or a named product get written. Concepts that are mechanisms get deferred.

That is a defensible editorial choice and it is arguably the right one for the audience. Someone following a fine-tuning tutorial needs to know what a rank parameter does, because they are going to type a number into a configuration file. Someone following a tutorial on attention variants needs to understand what is being computed, and a one-paragraph explanation would be worse than nothing.

But it is a choice, and it produces a site that is strong on vocabulary and configuration and weak on mechanism. The tell is the pair of entries about the two inference engines: the comparison page is finished and the individual engine pages are not, so a reader who lands on the comparison has a summary of two things they cannot then read about. A reader coming to understand how attention actually works will find a linked entry marked unfinished, and the alternative is the attention overview page, which is finished and presumably a diagram.

For a beginner site, that is the right trade. For anybody who wants to reason about why something is slow, it is the wrong one.

Three server-side packages in a browser bundle

The manifest lists thirteen runtime dependencies, and at least three of them cannot run in a browser.

The application is a client-rendered single-page application: React, a router, a markdown renderer with GitHub-flavoured extensions, a syntax highlighter, a toast library, an icon set, an HTTP client and a stylesheet. That is ten packages that all belong in a browser.

Then there is an HTML parser. Parsing HTML is a server-side activity, and there is no browser use for it at all, because the browser has a parser built in and it is not yours to call. Then there is a module whose entire job is to read an environment file from disk, which is a Node feature and has no meaning in a browser. And then there is the HTTP client, which is the only one of the four that legitimately belongs on both sides.

So three server-side packages are declared as runtime dependencies of a browser application. Two of them cannot work client-side by construction. The likely explanation is that both are used at build time, and the author put them in the wrong section of the manifest. The cost of that mistake is that the bundler tries to resolve them for the browser, which either fails the build or pulls in a shim that does nothing.

The HTML parser is the interesting one, because it is a strong hint about how the site is built. A parser in the dependency list suggests something at build time reads documents from elsewhere and turns them into the site's own data, which would explain a data directory, a build step and a directory of generated output at the repository root. That is a sensible way to maintain a reference site that aggregates information from many places: you scrape or fetch once, commit the result, and the site renders from committed data rather than from a live request. It also means the site's freshness is a function of when somebody last ran the build, which is a fact a reader cannot see.

The icon library is the one dependency pinned to an exact version rather than a range, which is a reasonable choice for a visual asset and an unusual one for a library, and it suggests the icons were regenerated rather than upgraded.

So the manifest tells you two things worth knowing before you clone this: there is a build-time data step that scrapes or fetches, and the dependency sections have been tidied less carefully than the content.

A package name with a space in it

The manifest's name field is two words, the second of which is capitalised, and there is a space between them.

Almost every package registry and every version control convention expects a single lowercase token with no whitespace. A name with a space in it is not installable by the usual tooling, cannot be scoped, and will be mangled by shells, CI runners and container registries in different ways depending on which layer touches it first. It is the sort of thing that works perfectly on the author's machine, where the name is used as a display label, and breaks the first time somebody builds it in a place that validates names.

It is worth mentioning because it sits in the same file as a version of one point zero point zero and a description, and none of the three is a thing the build actually depends on. The name is inert metadata. It is inert, and it is also the first thing anybody reading the manifest looks at, and it is the one field that could not be used as written by a tool.

The build tooling itself is unremarkable and current: a Rust-based bundler with a React plugin, three scripts, one of which opens a browser on start. There is no test script, no lint script and no type check script, in a project with a TypeScript configuration file present.

That last combination is worth pausing on. A type check configuration with no script to run it means the types are checked by an editor and not by a build, which is a common and defensible choice for a small site. But combined with a build-time data step, it means nothing verifies that the data still matches the components that render it. If a field in a data file is renamed, or an entry loses a property a card reads, the site does not fail. It renders a card with a blank field, and nobody finds out until a reader does.

For a content site, that is survivable, because the failure is cosmetic and somebody will report it. For a site whose value is a large curated dataset, the more interesting failure is silent: a page that was supposed to be complete stops being reachable, and the status markers that would tell you are in the readme rather than generated from the data.

Model lineage as a tree view

One module in the site is described as holding information about mainstream models, with search, filtering, a card view, and a separate view described as a family tree.

The other two views are table stakes. Search and filters are what you expect from any list of dozens of things. A card view is a layout choice.

The family tree is the one worth stopping on. Model lineage is genuinely hard to look up and almost nobody does it well. The information exists: a base model, the datasets and architecture it was built from, the fine-tuned derivatives released by the original lab, the open weights released by somebody else, the quantised versions, and the fine-tunes of those. That graph is spread across model cards, release announcements, community wikis and a great many blog posts, and no single place holds it.

Rendering it as a tree rather than a list is the right form, because the relationships are hierarchical and a list flattens them. It also answers a question people actually ask, which is whether a particular model is a fine-tune of something they already know. That question comes up constantly when you are choosing between two models and want to know whether one is a repackaging of the other.

The risk with a lineage view is the same as with any maintained dataset: it goes stale. New base models appear, and a tree that is six months old is confidently wrong rather than obviously wrong. Nothing in the description suggests a freshness signal, so a reader has to check a date on the base model itself to know how much to trust the structure above it.

The neighbouring module has a related ambition. It aggregates evaluation benchmarks, and the description says the purpose is to help readers understand the boundaries of model capability. That is a harder goal than displaying numbers, because benchmark scores are only interpretable relative to a saturation point, a contamination caveat and a choice of prompt template, none of which fits in a card. A benchmark summary that omits all three is a set of numbers with a direction and no scale, and it is the module where a reader is most likely to be misled by a well-designed interface.

A prompt corpus with originals, translations and analysis

The prompt module is the one most likely to still be useful in three years, and the reason is the same as the one most likely to be overlooked.

It collects prompts from shipping products and dissects them. Each entry has three parts according to the description: the original prompt, a Chinese translation, and a learning analysis.

The three-part structure is the contribution. A prompt without its original is folklore. A prompt with its original and no translation requires you to read English to learn from a Chinese-language site, which defeats the purpose for a large part of the audience. And a prompt with an original and a translation and no analysis is just text: the interesting thing about a real production prompt is why it is shaped that way, what constraint produced each clause, and which parts would break if you copied them into a different context.

The stability argument matters too. Model documentation changes every few months. Architecture explainers go out of date when a new variant appears. But a prompt extracted from a product that shipped eighteen months ago is a fixed artefact. It will still be a fixed artefact in three years, and it will still teach the same thing about how instructions are structured, because the reasoning behind it has not changed. It is the highest-quality content on the site in terms of decay rate, and it is the module that a site about concepts will update least.

There is a legitimate question about whether this is a copyright question, and the answer depends on how much of each prompt is reproduced. A prompt is often a small part of a larger artefact, and the analysis is the original work. A reasonable position is that a quotation for the purpose of critique is fine and a wholesale collection of prompts is not, and the site as described is a collection. But this is a legal question rather than an engineering one, and the practical advice to a reader is simply to treat the originals as quotations to be read critically rather than as templates to be lifted.

The final module in the list is a paid community space. That is the business model, and it is worth naming because it tells you how the rest of the site is financed and what the incentive structure is. The reference sections are the free part, and a free reference that is also the funnel is normal. The pressure it creates is the pressure every such site has, which is to favour breadth and recency over depth, and it shows up in exactly the place we found it: the mechanism-level entries are the ones left unfinished.

Two application directories, a data directory, and a build step nobody can see

The repository has two application directories, a data directory, a scripts directory, a public directory, a deployment configuration file, and a lowercase readme. That is a shape worth unpacking.

Two application directories next to each other, with a shared data directory, is not a single-page application. It is two sites sharing content. Given that one of the described modules is long-form articles delivered as standalone single-page documents, the likely arrangement is that the main application serves the interactive reference while a second directory holds generated or pre-rendered pages that are served as static files. That is a sensible split, because the long-form articles do not need a router or a data fetch, and shipping them as static files means they work without JavaScript and can be indexed.

It also means two build outputs, two things to keep consistent, and a question about which one a given URL serves. Nothing in the description resolves that, and a reader following a link from the readme lands in a hash route, which is the main application, while the static pages are presumably reached by path. Two addressing schemes in one site is a small navigational tax that most visitors will not notice and every regular will.

The data directory plus the scripts directory plus the server-side parsing dependency from the previous section together describe a content pipeline. The shape is almost certainly: a script fetches or parses material from elsewhere, writes structured data into the data directory, and the application renders from that committed data. The build scripts then produce the two outputs from it.

This is a good architecture for a reference site, because it makes the site buildable offline and reviewable in version control. A change to a model entry is a diff in a data file. It is also the architecture where staleness is invisible, because the data is a snapshot with no expiry, and the status markers in the readme are maintained by hand rather than generated from it.

That last point is the one structural weakness worth naming. The readme's most valuable feature, the honest status column, is maintained in a different place from the thing it describes. There is no sign of a script that checks whether a page exists and writes the marker. So the inventory is accurate as of the last time somebody updated the readme, and the site is accurate as of the last build, and nothing keeps the two in step. That is a small automation, and it would make the best feature of the site self-maintaining.

Editorial conclusion

Easy AI is worth reading if you want a Chinese-language map of the field that tells you which pages actually exist before you click, because the status markers make the site's real coverage visible in one screen rather than page by page. It is a poor fit as a technical reference, since the completed topics skew towards concepts you can configure or look up rather than mechanisms you need to understand, and the entries that would answer most questions about inference engines are the ones still marked unfinished. If you use it, check the marker before bookmarking, and treat the model and benchmark sections as starting points rather than as sources, since they are summaries with no visible provenance for the numbers.

Frequently asked questions

Official sources

1. ConardLi/easy-learn-ai on GitHub
2. Issues
3. Project website
4. README