ASD-STE100 提示詞如何減少 ChatGPT 和 Claude 的冗長回答

You ask a chatbot a simple question and get four paragraphs back. The first one repeats your question. The second one hedges. The third one finally says something useful, buried inside a sentence with two subordinate clauses and a "however". The fourth one summarizes.

The usual fix is to type "be concise" or "explain it simply". Both work for about one reply. A better fix comes from a place that has nothing to do with software: the aircraft maintenance manual.

The post that started this

Andrej Karpathy, a founding member of OpenAI and the former head of AI at Tesla (and the person who coined the term "vibe coding"), shared a long post on X on October 2, 2026 about how to get answers from a model that are easier to understand. It drew roughly 7.9 million views.

His main point is that AI models now generate text and code faster than humans can read it. The bottleneck is no longer writing the answer; the bottleneck is your brain trying to absorb and verify it. To fix that, he ranked AI output formats into four levels, ordered from slowest for a human to digest to fastest:

Controlled plain text: Instead of accepting a wall of conversational prose, you force the model to write in short, strict, unambiguous sentences.
Diagrams: When paragraphs are too slow to parse, you ask the model to draw an architecture chart, a flowchart, or a visual map so you can see how the parts connect at a glance.
Interactive web pages: Because modern models write front-end code effortlessly, you can ask them to build a small, disposable HTML and JavaScript page. Instead of reading about how an algorithm or equation behaves, you move a slider and watch it happen in your browser.
Custom explainer videos: At the top of the ladder, you have the model generate a narrated, animated video script (similar to a 3Blue1Brown lesson) that walks you through a hard topic step by step.

Each rung up the ladder takes less effort for your brain to process. Most daily questions, however, still start and end at step one: plain text. And Karpathy's tip for fixing step one is almost embarrassingly cheap. Tell the model to write the way aircraft maintenance manuals are written. That is a real standard with a real name, and the model already knows it.

What the standard actually is

The standard is ASD-STE100, Simplified Technical English, usually shortened to STE. It started as the AECMA Simplified English Guide, first published in 1986 by the European aerospace industry. The history is documented on Wikipedia if you want the details.

The reason it exists is practical. A large share of the people who service aircraft are not native English speakers. If a sentence can be read two ways, someone eventually reads it the wrong way, and in maintenance work that can hurt people.

So the industry wrote a rulebook for sentences. It covers grammar, a short list of approved words, and a longer list of words you are told not to use. You do not need all of it. Three rules carry most of the benefit.

Rule 1: One sentence, one idea

Short sentences are the headline feature. STE caps procedural sentences at roughly 20 words and descriptive ones at roughly 25. More important than the cap is the principle behind it: a sentence should carry one instruction or one fact.

Compare these two.

It may be advisable to consider restarting the service before proceeding any further with the configuration.

Restart the service. Then continue the configuration.

The second version is not dumber. It is easier to check. You can look at each sentence and decide whether it is true.

Rule 2: Active voice, with a named actor

"The file should be saved before the build is run" hides the person doing the work. "Save the file. Then run the build." puts the actor and the action up front.

Active sentences answer two questions immediately: who does it, and what do they do. Passive constructions let a model (and a human writer) skip both answers while still sounding authoritative.

Rule 3: One word, one meaning

This is the rule people underestimate. In STE, each approved word has one meaning and one part of speech. If "test" is approved as a noun, you do not use it as a verb. If a word means "stop", it does not also get used to mean "pause".

Chatbots love elegant variation. In one answer a "function" becomes a "routine", then a "method", then a "procedure". A reader reasonably wonders whether those are four different things. Fixing the vocabulary removes that doubt.

Why naming a standard beats saying "be concise"

This is the part I find most interesting, and I will call it my own opinion rather than something the thread proved.

"Be concise" is an adjective. The model has to guess how concise, for whom, and at what cost to completeness. Every model interprets it differently, and every conversation drifts back to the default register after a few turns.

"Write in ASD-STE100" is a pointer to a specific, heavily documented style. The rules are public. The training data contains manuals, documentation, and discussions of the rules. The model does not have to invent a meaning for the instruction because the meaning already exists.

I think of it as the difference between asking a contractor for "a solid foundation" and asking for "a foundation to the local building code". The second request has a checkable answer. This is the same logic behind role prompting, where a precise job title does more work than a paragraph of adjectives.

The practical lesson is broader than STE. When you want a style, look for an existing standard that names it. Plain Language guidelines, a newspaper style guide, a legal drafting convention, or a lab report format all work the same way.

The problem is the register, not the knowledge

There is a second argument hiding in the tip. Models are not verbose because they lack the ability to be clear. They are verbose because the default register of chat models rewards sounding thorough: hedges, framing sentences, and recap paragraphs.

You can see this by running the same question twice, once as typed and once with the STE instruction attached. The facts usually stay the same. What disappears is the padding. That tells you the clear version was available the whole time and simply was not selected.

This changes how you debug a bad answer. If the content is wrong, you need better context or a better model. If the content is right but exhausting to read, you need a style constraint. Treating those as one problem is why people keep adding "please be clear" to prompts that fail for other reasons.

Go for 80 percent, not 100

Strict STE has a cost. Full compliance means no phrasal verbs, a restricted vocabulary, and a flat tone that reads like a procedure card. That is perfect for "how do I replace this part" and slightly oppressive for "why did this project fail".

Karpathy's suggestion, in the gist of it, is to tell the model to follow the style about 80 percent of the way. I agree with that, and not only because it sounds friendly. Partial compliance gives the model room to keep technical terms, use an occasional longer sentence when a short one would split a thought badly, and stay readable as prose.

A good rule of thumb: the stricter the task, the closer you push to 100. Instructions, checklists, and troubleshooting steps get the full treatment. Explanations and opinions get the relaxed version.

A prompt you can paste

Here is a version I use, adapted from Karpathy's original X post. It works as a system prompt, a custom instruction, or the first message in a chat.

Write your answers in the style of ASD-STE100 Simplified Technical English, to about 80 percent compliance.

- Put one idea in each sentence. Keep sentences short.
- Use the active voice. Name who does what.
- Use one word for one meaning. Do not rename a concept once you have named it.
- Keep necessary technical terms and define each one once.
- Give the answer first. Do not repeat my question. Do not add a summary.
- If you are not sure, say so in one plain sentence.

Two notes from using it. First, the line about not renaming concepts does a lot of work. Second, the "answer first" line is not part of STE, but it targets the exact habit that makes chatbot replies feel padded.

If you want an interactive version with preset strictness levels (70%, 80%, or 100%) and output ladder toggles, you can open our ASD-STE100 Aircraft Manual Style Prompt template and copy it in one click. Or, to combine these rules with your own custom role and context, paste them into the Constraints field of Prompt Scaffold, which runs entirely in your browser.

Using it with the other rungs of the ladder

STE gets you a readable text answer. It does not replace the other steps on Karpathy's ladder; it sets a baseline for them. If a concept still does not land, ask for a diagram, then a small interactive page, and only then a video script.

You can also pair it with a depth strategy. The Feynman-style four-layer prompt controls how deep the explanation goes, while STE controls how cleanly each layer is written. They solve different problems and they stack well.

Where this breaks

A few pitfalls from real use.

Short sentences are not a guarantee of correct content. A model can state a wrong fact in perfectly clear English, and clear writing makes wrong claims look more believable. Keep verifying anything that matters.

Creative and persuasive writing suffers under strict STE. Rhythm and variation are part of the craft there, so drop the instruction.

Some models drift back to the default style after several turns. If that happens, restate the instruction in one line rather than adding more rules.

What to do today

Copy the prompt above into your custom instructions or the top of a long chat. Ask a question you already know the answer to, and check whether the response is easier to verify. If it is, keep the instruction. If it feels too stiff, tell the model to go 70 percent instead of 80.

The aircraft industry spent decades finding out which sentences people misread. You can borrow that result with one line.