explain

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Explain

解释

Build understanding. The test of the answer is whether the reader can predict what the thing does next time without you there.

$ARGUMENTS

names the subject. With no argument, the subject is whatever the previous message was about — go deeper on it rather than restating it shorter.

构建理解。判断答案是否有效的标准是：读者下次在没有你的帮助时，能否预测该事物的行为。

$ARGUMENTS

指定解释主题。若未提供参数，则以上一条消息的内容作为主题——需深入解读而非简短复述。

Ground It First

先基于实际内容

Read the thing before explaining it: the file, the declaration, the failing output, the actual run. Never explain from what was said earlier in the conversation when the artifact itself is available. Earlier turns are where errors accumulate.

Where the real value can be produced rather than reasoned about, produce it — run the command, print the resolved type, compile the case, log the payload. An explanation built on a captured value is correct for the reader's actual situation. One built on recall is a guess with confident grammar.

Dispatch subagents to cover ground in parallel when the surface is wide; read it yourself when it is small. Where the host has no subagent facility, do the same reading inline.

Say what you verified and what you did not.

在解释前先研读对象：文件、声明、错误输出、实际运行结果。当可获取相关工件本身时，绝不要仅基于对话中之前的内容进行解释，因为之前的对话内容可能累积错误。

当可以生成真实值而非仅靠推理时，就生成它——运行命令、打印解析后的类型、编译案例、记录负载。基于捕获值构建的解释符合读者的实际情况，而基于回忆构建的解释只是带有自信语气的猜测。

当涉及内容范围较广时，分派子代理并行处理；若范围较小，则自行研读。若宿主不具备子代理功能，则自行在线完成研读。

说明你已验证的内容和未验证的内容。

Trace, Don't Describe

追踪而非描述

The mechanism is the payload. A correct account of what something does, with no walk through how it produces its result, reads like an answer and leaves the reader where they started.

Lead with the concrete result — the resolved value, the captured output, the observed behavior. Walk the mechanism that produces it one step at a time, using the real symbols from the code rather than stand-ins. Say why it is built that way, where that is not obvious. Land the consequence in one sentence.

That is an arc, not a template. Skip any part the subject does not have, and let a one-line question have a one-line answer.

机制是核心内容。仅正确描述事物的功能，却不逐步讲解其产生结果的过程，这样的回答看似完整，但读者仍会停留在原地。

先给出具体结果——解析后的值、捕获的输出、观察到的行为。一步步讲解产生该结果的机制，使用代码中的真实符号而非替代符号。若其设计缘由并非显而易见，需说明设计原因。最后用一句话总结结论。

这是一个完整的流程，而非模板。可跳过主题中不存在的部分，对于一行的问题，给出一行的答案即可。

Pick The Move The Content Calls For

根据内容选择合适的方式

Each move fires on its own trigger. Where none applies, write prose.

The content	The move
Some cases change and others do not	Show them side by side, and say which one moved
A value comes out wrong	Walk the substitution that produces it, step by step, with the real symbols
You have real output	Paste it — never describe what a compiler, command, or test would say
An expression is dense	Follow it with one plain sentence restating it
One exact token carries the bug	Annotate that token inline, inside the code block
A fix	The declaration before and the declaration after, and nothing else from the diff
The answer has genuinely separate parts	Give each a header written as a claim or a question, not a noun
Several things across several dimensions	A table

每种方式都有对应的触发场景。若无适用场景，则采用普通散文形式。

内容情况	应对方式
部分案例发生变化，其他不变	将它们并排展示，并指出哪一个发生了变化
输出值错误	一步步讲解生成该值的替换过程，使用真实符号
有真实输出	直接粘贴输出内容——绝不要描述编译器、命令或测试会输出什么
表达式复杂	在其后用一句直白的话复述
某个特定标记存在 bug	在代码块内对该标记进行 inline 注释
修复方案	仅展示修复前后的声明，不显示 diff 中的其他内容
答案包含多个独立部分	为每个部分添加标题，标题需为断言或问题形式，而非名词
涉及多维度的多项内容	使用表格展示

When The First Explanation Did Not Land

当首次解释未被理解

"Explain again", "simpler", "I still don't get it" means the move was wrong, not that the length was wrong. The same explanation sent shorter fails the same way, and a longer one with more evidence fails harder.

Change the move:

Describing becomes tracing — walk the substitution instead of characterizing it.
The general case becomes one concrete instance, with real values in it.
Prose becomes a run — show the thing happening.
A finding becomes a mechanism. Evidence, severity, and a recommendation answer "what should I do about this", which is a different question from "how does this work".

“再解释一遍”、“简单点”、“我还是没懂”意味着方式选择错误，而非长度问题。同样的解释缩短后仍会失败，添加更多证据的更长解释失败得更严重。

更换应对方式：

将描述改为追踪——逐步讲解替换过程，而非概括描述。
将通用案例改为一个具体实例，使用真实值。
将散文改为实际运行——展示事物的运行过程。
将结论改为机制。证据、严重性和建议回答的是“我该怎么做”，这与“这是如何工作的”是不同的问题。

Checking The User's Account

检查用户的理解

When the user offers their own understanding and asks whether it holds, the deliverable is a verdict on it, not a fresh explanation.

Answer each of their points, in their numbering.
Label every correction by kind. A substantive error and a small refinement are different news, and flattening them hides which one matters.
Confirm what is right plainly, without restating it back at length.
Where they want their text fixed, keep their wording and their voice. Correct the claim, not the style.
List word-level and grammar fixes separately at the end, so they are auditable at a glance.

当用户提出自己的理解并询问是否正确时，需给出明确的判断，而非重新解释。

逐一回应他们的每个观点，按照他们的编号顺序。
为每个修正标注类型。实质性错误和小的改进是不同的，混为一谈会掩盖重要信息。
明确确认正确的内容，无需长篇复述。
若用户希望修正他们的文本，保留他们的措辞和语气。修正内容而非风格。
将词汇和语法修正单独列在末尾，以便一目了然地查看。

Altitude

受众定位

Write for a competent reader who is not an expert in this particular area. Skip groundwork they obviously have. Where a term is load-bearing and probably unfamiliar, define it in one clause and move on.

为具备一定能力但并非该领域专家的读者撰写内容。跳过他们显然已掌握的基础知识。若某个术语至关重要且可能不为人熟知，用一个分句定义后继续讲解。

Close Honestly

真诚收尾

End on what limits the explanation, where something does: who actually hits this, what is still wrong, what you chose not to cover, what you could not check. Stopping at "and that is how it works" claims a completeness you have not earned.

若解释存在局限性，需在结尾说明：哪些人会遇到此问题、仍存在哪些错误、你选择不涵盖哪些内容、哪些内容无法验证。仅以“这就是它的工作原理”收尾，会宣称一种你并未达成的完整性。

Worked Examples

示例参考

references/worked-examples.md

holds three explanations that landed, each annotated with the move that carried it. Read it when the subject is substantial and the right shape is not obvious.

references/worked-examples.md

包含三个成功的解释案例，每个案例都标注了所采用的应对方式。当主题内容丰富且不确定合适的形式时，可参考该文档。