Authors who can explain complex things so people understand them—Feynman, Paul Graham, Julia Evans, Polya, Carl Sagan—all share a common stance in their minds:
I understand this thing; the reader does not. My job is not to show what I understand, but to use the materials already in the reader's mind to build a similar understanding in their mind.
This is the stance of atranslator, not the stance of someone on a podium. A translator holds both ends in mind—the meaning of the source text and the expressions that readers of the target language can grasp—and builds a bridge between the two ends. AI by default only attends to one end: it neatly lays out the knowledge structure in its own mind (complete, categorized, listing rules, giving positive and negative examples), and then it's done. The reader finishes without actually having built that understanding, because no one helped them build the bridge.
The following sections describe the specific actions the masters take when building bridges.
Start from where the reader already is
When Feynman explains physics, his first sentence is not "force equals mass times acceleration," it's "imagine you're holding a glass of water..." When Paul Graham writes startup essays, the opening is not "a startup is..." but a sentence that came up when he was having dinner with a friend last week. When Julia Evans writes about debugging, the opening is "yesterday I ran into a weird bug." When Sagan talks about the universe, the opening is "if you compress Earth's 4.6 billion years of history into one year..."
They all enter through a scene from the reader's life or a concrete event—not because they're too lazy to write a definition, but becausethe reader needs an anchor pointfor new concepts to hang onto. The formal starting point of a topic (definition, classification, historical background) is usually not the reader's anchor point; it's a starting point agreed upon within the field.
Specific action: before writing, ask yourself "what is the most relevant thing in the reader's mind before they open this article?"—start the first paragraph from that thing.
Analogies come from the reader's life, not from another concept within the field
AI's favorite analogy is "X is like Y," but Y is often another technical concept. For example, "a promise is like a future"—when the reader doesn't understand promise, they also don't understand future. This analogy builds no bridge; it's just a lateral move.
A Feynman-style analogy is "X is like that thing that happens when you brush your teeth in the morning." Pulling an analogy from the technical domain into everyday life requires the author to do an extra step—abstract the concept and then find something in daily life with a similar structure. This step is the author's homework, and AI bypasses it by default.
A good analogy doesn't pursue precision; it pursues sufficiency. "An atom is like a small solar system" is not precise, but it helps the reader first build a usable model, to be corrected later. A bad analogy pursues technical precision from the outset, and the reader ends up unable to build any model at all.
Write along the "path of discovery," not the "path of presentation"
Textbooks organize according to the final knowledge structure—definition → properties → corollaries → examples. This is the path of presentation.
Masters write along the path of discovery—"at first I thought it was A, then I found that phenomenon B couldn't be explained by A, so I changed to C." As the reader walks along this path, they get the illusion that they figured out each step themselves. This illusion is a good one; it is understanding itself.
Polya's entire book How to Solve It is like this—it doesn't give the answer directly, it asks you a few questions, and if you follow the questions you walk to the answer yourself. When writing explanatory articles, occasionally inserting a line like "here you might want to ask..." and then answering it yourself is a simplified version of the same move.
Don't hide behind terminology
The first time each technical term appears, earn the right to use it by putting plain language next to it—"by X here, I mean...". A term that can't earn that right means the author themselves hasn't thought it through clearly, and it should be replaced with another word or broken into a few sentences.
Julia Evans's illustrated blog often spends an entire page unpacking a single term. This unpacking process is the main action of the writing, not an incidental footnote.
Self-check: circle every technical word you've written and ask, "Have I explained this word in plain language before?" If not, either explain it or replace it.
Don't invent compressed compound words
When AI writes Chinese, it has a very deep bad habit—it loves to compress a sentence into a four-character word or a two-character coinage: mess up → flip the car, finish → close the mouth, stop → intercept, write down → file it away, changed a bunch of places that shouldn't have been changed → scope out of control, the name given doesn't match the old code → terminology collision.
This habit comes from training data. AI has learned too much product copy, technical blogs, and growth/management writing. Over the past decade or two, this kind of writing has coined a pile of invented words as industry jargon—"empower" "closed loop" "grip point" "precipitate" "align" "playbook" "middle platform"—using these words makes you look professional and forceful. AI thinks "the hallmark of good copy is this kind of compressed word," so when writing ordinary articles it automatically leans in that direction too.
The problem is that these words didn't grow in everyday Chinese. Real people don't say "this thing flipped the car" (unless chatting online); they say "this thing got messed up." When readers hit a compressed word, their brain pauses for a moment—"flip the car = something went wrong"—decodes it once, then keeps reading. It saves characters, but smoothness is lost.
Self-check: circle every two-character or four-character noun/verb in what you've written and ask, "Did I hear this word in everyday conversation, or did I compress it myself to sound concise?" For the latter, change it back to plain language, even if it adds a few characters.
Acknowledge difficulty, don't pretend it's simple
When you hit a genuinely hard part, just say, "This part is a bit convoluted, I'll go slowly." Readers relax when they read this—because they already found it convoluted, and now it's confirmed that they're not stupid.
By default, AI glosses over hard parts or smears through them with more abstract words. Readers get stuck at the glossed-over parts, but they won't come back and tell the author—they'll just give up.
Preserve the author's voice
Master writers' articles all have a clear personality—Paul Graham's calm, Feynman's playfulness, Julia Evans's sincerity, Sagan's awe. This isn't stylistic decoration; it's the source of trust. Readers are more willing to follow a voice with personality than an anonymous document.
By default, AI sands personality flat—it outputs neutral expository prose. This style is the easiest to write and the least worth reading. Before you start writing, ask yourself: if I were telling this to a friend face to face, how would I say it? Write it down that way.
Teach the reader, don't command the reader (same when writing for AI)
Articles written for people don't use a tone like "you must X" or "never Y"—it comes across as condescending. But instruction documents that AI writes for AI to read (SKILL.md, process files, rule sets) are especially fond of MUST / NEVER / ALWAYS / strictly forbidden / must, thinking this makes them "harder" and more reliable.
Actually it's the reverse. Imperative rules only cover the few listed cases; when an edge case not listed comes up, the executor has only two reactions: rigidly apply the rule's result and do the wrong thing, or completely lose any basis for judgment and guess wildly. Instructional explanations makewhy do it this wayclear, so when the executor hits a new situation they can reason it out themselves—"oh, it's to avoid X, so in this case it should be Y."
Writing for AI is the same as writing for a smart apprentice: you wouldn't tell a new engineer "you must run lint before committing," you'd say "run lint before committing, otherwise CI will fail and you'll have to push again, which is annoying." Only then does he know how to weigh things when lint fails, and how to adjust when CI changes its config.
This principle also applies to writing a skill's description—don't pile up a "trigger word list: 'add feature', 'new API', 'implement X'...". When AI invokes a skill it matches by concept; giving concepts ("triggered when doing new feature development") covers more ground than giving a dead string list, and it can still hit when the user uses a phrasing not listed.
Self-check: whenever MUST / NEVER / ALWAYS / 严禁 / 必须 appears in the instructions you wrote, stop and ask "did I explain why?" If not, add the reason, so the reader (human or AI) can judge for themselves in edge cases. The harder the rule, the more rigid the executor.
Reason through the reader's state along the reading timeline
When writing each paragraph, simulate the reader's mental state after finishing the previous paragraph: what they understand now, what they don't yet, what they most want to ask next, and whether they have the drive to continue. The next paragraph connects exactly to their current state.
The experience of reading this kind of article is "hey, I was just about to ask this, and the next paragraph answers it." This isn't mysticism; it's the author anticipating paragraph by paragraph as they write.
How to judge: after finishing each paragraph, stop and ask yourself "what's the first question that pops into their head right now?" Then write the answer to that question in the next paragraph. If you can't answer it, either the previous paragraph didn't set it up well (the hook has no value), or the order is wrong (the reader isn't ready to receive the next paragraph).
The tone of different sections follows their function
A translator's stance doesn't mean the whole text uses a conversational tone. Different sections in an article have different functions, and the tone changes with them:
- Narrative section(pulling the reader in at the start, explaining why, explaining the philosophy)—use a conversational feel, so the reader feels an author is beside them
- Navigation section / reference section(routing table, table of contents index, external link list, field quick reference)—use declarative sentences. Readers come here to scan for the line they want, not to listen to a lecture
- Counterexample / pitfall-avoidance section—state the phenomenon and the reason directly; no need to play at conversation
How to judge: if a section reads like chatting but its function is to let readers quickly locate information, it's over-conversationalized. Replace the "how are you" in headers, subheadings, and lead sentences with neutral statements.
Scan once after writing
- Does the first paragraph start from where the reader already is, or from the topic's formal starting point? If the latter, rewrite it
- Has each term earned its right? Pick out the ones you haven't explained and explain them once in plain language, or replace them
- Are the analogies drawn from everyday life, or transposed from another technical concept? If the latter, replace them
- Is there anywhere you pretend it's simple? Where readers get stuck, just say "this part is a bit convoluted"
- Does the article have the author's voice? If it's all neutral expository prose, it's gone
- If you read the first sentence of each paragraph together, is it a cognitive path that a reader would naturally follow? If it jumps, rearrange it.
- Has the reference/navigation section been written as conversational sentences? Replace them with neutral statements.
- Is there any hard command like MUST / NEVER / ALWAYS / strictly prohibited? Have you explained why? If not, add the reason so readers can judge the boundaries themselves.
- Are there any compound words you coined yourself (such as flip-over, closing, settling into place, scope out of control)? Change them back to plain language.
- If you delete any sentence, can readers still follow the cognitive path to the end? If they can, it should be deleted.