explain-code

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Explain Code

代码解释

Explain the user-scoped code as a short, scannable post. Prefer plain-English prose and small code sketches over exhaustive walkthroughs.
将用户指定范围内的代码解释为一篇简短、易读的文章。相比详尽的分步讲解,更倾向于使用通俗易懂的文字和小型代码示例。

Defaults

默认规则

  • Match the user's scope exactly.
  • Use this structure:
    #
    title,
    📋 TLDR
    , then one or more
    ##
    sections.
  • Each
    ##
    section covers one idea and includes at least one fenced code block.
  • Keep prose simple and snippets small.
  • Simplify code when useful, but stay faithful to behavior.
  • Do not invent intent that the code or prompt does not support.
  • 严格匹配用户指定的范围。
  • 使用以下结构:
    #
    标题、
    📋 TLDR
    ,然后是一个或多个
    ##
    章节。
  • 每个
    ##
    章节围绕一个核心观点展开,且至少包含一个围栏代码块。
  • 文字内容简洁,代码片段短小精悍。
  • 必要时可简化代码,但需保持原有功能逻辑。
  • 不得凭空捏造代码或提示中未体现的意图。

Format

格式规范

#
Title

#
标题

One plain-English line naming the topic.
用通俗易懂的一句话点明主题。

📋 TLDR

📋 TLDR

Write 2-3 short sentences that give the gist to someone who did not write the code.
Optional: include one small
mermaid
block only when the main story is easier to grasp as flow or handoff.
After the
📋 TLDR
, add a horizontal rule:
---
.
撰写2-3句简短的话,向未编写过该代码的人概括核心内容。
可选:仅当核心逻辑通过流程图或交互图更易理解时,添加一个小型
mermaid
代码块。
📋 TLDR
之后添加一条水平线:
---

##
Sections

##
章节

For each section:
  1. Write a plain-English
    ##
    title with at least one emoji.
  2. Add a one- or two-sentence lead-in.
  3. Show one fenced code block.
Stop the section after the code block.
Separate body sections with a horizontal rule:
---
.
每个章节需遵循以下步骤:
  1. ##
    标题添加至少一个表情符号,并用通俗易懂的文字表述。
  2. 添加1-2句导入性文字。
  3. 展示一个围栏代码块。
代码块结束后,该章节即告结束。
正文章节之间用水平线分隔:
---

Prose

文字要求

  • One main idea per sentence.
  • Use short, common words where possible.
  • Start with the simple story, then add detail.
  • Avoid dense sentences, unexplained jargon, and private shorthand.
  • 每句话仅表达一个核心观点。
  • 尽可能使用简短、常用的词汇。
  • 先讲述简单的核心逻辑,再补充细节。
  • 避免冗长复杂的句子、未解释的行话和私人简写。

Code

代码要求

  • Show only the code needed for the current section's point.
  • Default to about 10 non-blank lines or fewer.
  • Omit anything that does not help explain the current point.
  • Use
    ...
    ,
    // ...
    , placeholders, or simplified identifiers when that makes the idea easier to see.
  • Every snippet must include short intent comments on the key lines. Use them to tell the reader what this line is doing here and why it matters.
  • Prefer behavior-faithful sketches over verbatim excerpts.
  • 仅展示当前章节观点所需的代码。
  • 默认展示不超过10行非空白代码。
  • 省略对当前观点解释无帮助的内容。
  • 必要时使用
    ...
    // ...
    、占位符或简化标识符,以便更清晰地展示核心逻辑。
  • 每个代码片段必须在关键行添加简短的意图注释,告知读者该行代码的作用及其重要性。
  • 优先选择保留功能逻辑的简化示例,而非逐字照搬的代码片段。

Scope fallback

范围 fallback 规则

  • If the user gives no scope and there are unstaged changes, default to the unstaged diff.
  • If the user gives no scope and there are no unstaged changes, do not guess what to explain; explicitly ask the user to identify the file, diff, or area they want explained.
  • 如果用户未指定范围且存在未暂存的变更,默认解释未暂存的差异内容。
  • 如果用户未指定范围且无未暂存变更,请勿猜测解释内容;需明确要求用户指明想要解释的文件、差异或区域。

Guardrails

约束规则

  • Do not create prose-only
    ##
    sections.
  • Do not add explanatory text after a section's code block.
  • Do not include long literals, secrets, or opaque blobs when a placeholder teaches the same point.
  • Do not turn the answer into a line-by-line transcript unless the user asked for that.
  • 不得创建仅含文字的
    ##
    章节。
  • 不得在章节的代码块之后添加解释性文字。
  • 当占位符可以达到相同教学目的时,不得包含长字面量、机密信息或模糊的二进制数据。
  • 除非用户明确要求,否则不得将答案写成逐行讲解的形式。