eli5

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

ELI5

Turn the referenced spec or change into an accurate mental model for a technical reader who does not live in the code. Plain language, full precision: simplify the telling, never the claims.

将参考的规范或变更转化为适合不熟悉代码的技术读者的准确心智模型。语言通俗易懂，内容精准无误：简化表述方式，但绝不弱化核心信息。

The Register

适用场景

Other skills point here when their output must be readable by someone who didn't live the work. The reader is technical — pseudocode and precise claims land fine — but they have read none of the code and none of the session's messages: no diff, no transcript, no labels the work invented along the way. Writing ELI5 means:

Walk one concrete scenario end to end — the triggering event, what happens today, what the change (or the unbuilt alternative) would do — instead of describing properties in the abstract.
Define every term of art at first use; never lean on labels the spec, code, or session invented.
Use small concrete examples without replacing precise claims with analogies.
Reach for pseudocode when explaining control flow, ordering, or timing. Prose describing when-something-fires reads as plausible and hides the gap; five lines of pseudocode make the gate visible and let the reader see the case you missed. Write it at the level of the decision, not the implementation — the conditions and their order, not real function signatures. The tell that you needed it: your prose contains "only when", "before", "unless", or "as soon as" and the reader still cannot say what happens on the second call.
The test: the text stands alone, without the diff, the spec, or the transcript. If the reader must ask "explain this part", it failed.

当其他技能的输出需要让未参与相关工作的人能够读懂时，就会指向这里。读者具备技术背景——伪代码和精准表述完全可以接受——但他们没有读过任何相关代码，也没有看过会话中的任何消息：没有差异文件、没有对话记录、没有工作过程中发明的任何标签。撰写ELI5内容意味着：

从头到尾讲解一个具体场景——触发事件、当前的处理方式、变更（或未实现的替代方案）会带来什么变化——而非抽象地描述特性。
在首次使用专业术语时给出定义；绝不依赖规范、代码或会话中发明的标签。
使用具体的小示例，但不要用类比替代精准表述。
解释控制流、顺序或时序时，尽量使用伪代码。用散文描述“何时触发”看起来合理，但会隐藏细节；五行伪代码能清晰展示逻辑节点，让读者发现你遗漏的情况。伪代码要聚焦决策层面，而非实现细节——即条件及其顺序，而非真实的函数签名。判断是否需要伪代码的依据：当你的文字中出现“仅当”“在……之前”“除非”或“一旦”，但读者仍无法说出第二次调用时会发生什么，就需要伪代码了。
测试标准：文本可以独立存在，无需依赖差异文件、规范或对话记录。如果读者必须问“解释一下这部分”，说明内容不合格。

Workflow

工作流程

Read the complete referenced artifact and inspect current owners when the spec alone cannot establish behavior. When no artifact is named, explain the session's current change (working tree or branch diff). Separate what exists today from what is only proposed.
Explain the problem through its user or operational consequence, including why the current design produces it.
Explain the solution as one simple before/after data flow. Introduce each component by responsibility, not by filename or internal symbol.
Inventory schema and durable-contract changes exhaustively: added, changed, removed, reset, and deliberately unchanged. Include cursor or wire-format cutovers when they affect stored data or readers. Say explicitly when there are no schema changes.

完整阅读参考的工件，当仅靠规范无法确定行为时，查看当前负责人。如果未指定工件，则解释会话中的当前变更（工作树或分支差异）。明确区分现有内容和仅为提议的内容。
通过用户或操作后果来解释问题，包括当前设计导致该问题的原因。
将解决方案解释为一个简单的前后数据流对比。按职责介绍每个组件，而非按文件名或内部符号。
全面梳理模式和持久化契约的变更：新增、修改、删除、重置以及刻意保留不变的内容。包括影响存储数据或读取器的游标或有线格式切换。明确说明没有模式变更的情况。

Output

输出要求

Use these headings in order:

```
Problem
```
```
Solution
```
```
Schema changes
```

End with one short sentence stating what users should notice after the change.

按以下顺序使用这些标题：

```
Problem
```
```
Solution
```
```
Schema changes
```

结尾用一句话简述变更后用户应该注意的事项。

Rules

规则

Lead with behavior and boundaries; mention implementation names only when they clarify ownership or a contract.
Distinguish canonical records from derived indexes, caches, summaries, and presentation grouping.
Call out destructive resets, migration requirements, compatibility behavior, eventual consistency, and intentional data loss directly.
Do not omit a schema change because it is operational rather than user-visible.

先讲行为和边界；仅当有助于明确归属或契约时才提及实现名称。
区分规范记录与派生索引、缓存、摘要和展示分组。
直接指出破坏性重置、迁移要求、兼容性行为、最终一致性和有意的数据丢失。
不要因为模式变更是操作层面而非用户可见的就省略不提。