Skip to content
Original
Kuaidao Qingyi· Kuaidao Radio Station·· 2 days agoSelectedAI score60

An AI skill based on Karpathy's aviation writing rules makes answers easier to understand

AI overview

The author packages Karpathy's proposal to constrain AI output with the ASD-STE100 aviation writing standard into an installable skill. Triggered by “Help me understand,” it automatically makes AI explanations of concepts, terms, and research-paper PDFs clearer and more precise.

Why it matters

The author turns the aviation writing principles highlighted by Karpathy into an installable skill, letting readers reuse this method of constraining AI output.

Full text · AI translation

Illustration accompanying this article

Illustration accompanying this article

The key is not just how you ask, but how you constrain the output.

On 10/2, the well-known AI expert Andrej Karpathy posted on X. Within just a few days, the post had surpassed 770 × ten thousand views.

If you are not familiar with Karpathy, here is a quick introduction. He previously led AI at Tesla and worked at OpenAI, and is a leading technical figure in the AI community.

He has also coined concepts that later became widely used around the world. For example, he introduced the term “vibe coding,” which we now hear so often.

What was this post about? It offered a practical framework for a problem many people have not noticed.

When AI does not work well for us, what is our first instinct? Change the prompt. Rephrase the question, assign it a role, or ask it to “explain that again in simpler terms.”

Karpathy's diagnosis, however, is that your input may be fine; the problem may lie in the format of the AI's output.

As AI becomes more capable, we may spend more and more time trying to understand its output. The challenge is making sense of what it hands back, while getting the AI to do the work has not itself become harder.

Seen this way, one important reason AI-generated articles often feel recognizably AI-written is that their output does not match our expectations.

Karpathy did more than point out the problem: he proposed four progressively more advanced ways to make AI output easier to understand.

I will introduce those four approaches first. At the end, I will also share a skill I made by distilling his method.

You can download it and give it to an AI tool you regularly use that supports installing skills, such as Codex, Claude Code, or WorkBuddy.

His first approach is to constrain the writing itself. No fancy tricks are needed: ask the AI to follow writing rules, use fewer long sentences and ambiguous words, and make each sentence convey just one point.

The standard he recommends is called ASD-STE100. I will explain it shortly. It is fascinating, and it was my biggest takeaway from his post.

The second approach is to add visuals. Ask the AI to place diagrams and flowcharts alongside the text. Often, one diagram is more useful than three paragraphs.

The third approach is to generate an interactive web page. Karpathy demonstrated this himself by having AI turn a technical concept into a small animated page that you can explore by dragging and clicking.

The fourth approach, which is a little more demanding, is to generate a video. Have the AI turn an explanation or unfamiliar technical terms into a video with visuals and narration, so you can simply sit back and watch.

From text to visuals, web pages, and video, the information becomes richer, while the demands on tools and technical skills increase.

There is a practical issue, though. The last three approaches—visuals, web pages, and video—get increasingly impressive, but they either depend on specific tools or require some visual judgment and taste to use effectively.

For most of us, everyday interactions with AI still happen most often through text. You ask a question and get a long answer, and naturally want to understand what it actually means.

That makes the first approach—constraining the AI's written replies—the most broadly useful, easiest to adopt, and ready to use today.

The ASD-STE100 standard Karpathy recommends may sound highly technical, but its origins are quite a story. It has been used in global aviation for nearly 40 years; it was not invented by an AI company.

Consider a real aviation disaster. On the evening of 1977-3-27, thick fog covered Tenerife airport. KLM captain Van Zanten, who had more than 12000 flying hours, was waiting impatiently to take off.

The first officer told the control tower they were ready for takeoff. The tower issued an en-route clearance and told them to wait for takeoff clearance. At the same moment, another aircraft, operated by Pan Am, transmitted on the same frequency to warn that it was still on the runway.

The KLM crew mistook the tower's reply for takeoff clearance. The crucial instruction to wait for takeoff clearance was drowned out by radio interference.

Captain Van Zanten then began accelerating at full power. By the time he saw Pan Am's Boeing 747 ahead on the runway, it was too late to stop.

The result was 583 deaths, the highest toll in a single accident in aviation history. Investigators identified communication failures as a key factor.

Nonstandard wording, ambiguous language, a word understood in a different sense, and radio interference combined to give the crew a mistaken understanding of their takeoff clearance, ultimately leading to disaster.

The accident drove further standardization of aviation communications. At almost the same time, European aviation faced another problem: ambiguity in maintenance documentation.

Many aircraft maintenance technicians worldwide are not native English speakers. The same English maintenance manual has to serve technicians in dozens of countries. A word with two possible meanings can, in aircraft maintenance, sow the seeds of another accident.

The aviation industry's response was to constrain the English used in its own field, rather than force technicians around the world to master English.

The predecessor to this standard was first published in 1986. Its rules were almost bluntly simple: each word must have only one meaning, each thing must have the same name throughout, and synonyms must not be alternated just to make the writing seem more sophisticated. It also called for short sentences, active voice, and one point per sentence.

The standard was later updated to issue 9, with 53 writing rules, around 900 approved basic words, and roughly 1200 words to avoid, each with a suggested alternative.

Think about it: these aviation writing rules run directly counter to how large language models usually write.

Models tend to pile on long sentences, vary their synonyms, and use analogies. Aviation's ASD-STE100 standard deliberately makes language “boring” in exchange for minimizing ambiguity.

Now consider how we usually judge an AI answer. Our first reaction is often to ask whether it reads smoothly and is well organized.

But nearly 40 years of aviation experience tell us that smoothly written text can actually be more dangerous. That smoothness sometimes comes from varied synonyms, metaphors, and elaborate sentences, all of which can introduce ambiguity.

Elegant wording and precise wording are often at odds.

Karpathy's approach is to bring these principles into AI use. The method is simple: ask the AI to explain a concept using the ASD-STE100 standard.

If full compliance feels too rigid, he suggests dialing it back to 80%, leaving twenty percent flexibility. The complete standard was designed for specialist documents such as aircraft maintenance manuals; applying every rule to everyday questions would make the answers unbearably stiff.

Back to my own experience. After reading Karpathy's post, I thought: his prompt is useful, but behind that single prompt are 53 rules, 900 approved words, and 1200 restricted words. We cannot fully grasp that entire system from just one sentence.

Besides, most people cannot be expected to remember to add that sentence every time they talk to AI.

So I made a skill. It is easy to use: download it, give it to your AI assistant, and say, “Help me install this skill.” Once installed, it is ready to use, without manually adding the prompt each time.

Next time you want to understand something unfamiliar, tell the AI, “Help me understand such-and-such.” That triggers the skill, and the AI automatically explains it more clearly and precisely.

workbuddy-skill-upload-guide.png

Three steps to upload a skill package in WorkBuddy

Below is the output I got after teaching WorkBuddy this skill and asking it to explain “personal agents.” Take a look at the details.

workbuddy-personal-agent.png

WorkBuddy explains personal agents using the “Help me understand” skill

It works with a wide range of tools, including mainstream AI assistants such as the “lobster” OpenCLaw you may already have installed, Claude Code, Codex, and WorkBuddy.

You can also adjust it to your preferences. Loosen the rules if they feel too strict, or tighten them for situations where you need greater precision.

Treat my skill as a starting point, not a definitive answer.

You can also try it on research papers and similar material. I set the trigger phrase to “Help me understand.” The subject can be a concept, a term, a company, or a research paper in PDF format.

One caveat up front: this skill helps AI use plain language and makes its output clear and concise, but it cannot tell you whether the content itself is correct.

That part is still up to you.

Finally, the download link for the skill package is below. You can start using it right away. If you get particularly good results after adjusting it, I would love to hear about them.

1. Skill package download link:

https://d.dedao.cn/1juJAwh

2. Karpathy's original post:

https://x.com/karpathy/status/2105819303471976479

After 1000 days of daily posts, I realized AI is not the only thing that has changed

Who is more valuable in the AI era? | 2026 AI Talent Market Report released

Read the original article

Source: Kuaidao Qingyi · mp.weixin.qq.com