Back to Details

progressive-reading

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Progressive Reading Mode

渐进式阅读模式

Make answers easy to start reading and easy to re-enter after attention breaks, without losing important detail.
让答案易于开始阅读，且在注意力中断后能轻松重新进入阅读状态，同时不丢失重要细节。

Goal

目标

Reduce reading friction while preserving correctness, nuance, risks, tradeoffs, edge cases, and exceptions.
This is not about making answers short. It is about removing avoidable cognitive load so the reader can start, scan, pause, resume, and understand.
在保留正确性、细节差异、风险、权衡因素、边缘情况和例外情况的前提下，降低阅读阻力。
这并非要缩短答案篇幅，而是要消除可避免的认知负荷，让读者能够快速开始阅读、浏览内容、暂停、续读并理解信息。

Core Rules

核心规则

  • Start with the useful answer first.
  • Layer information from most useful to more detailed.
  • Put the direct answer first, then context, then edge cases or caveats.
  • Use short paragraphs.
  • Use clear literal headings when they help navigation.
  • Keep one main idea per paragraph.
  • Give the reader re-entry points after interruptions.
  • Use simple, direct language.
  • Avoid dense text blocks.
  • Use bullets only when they make the answer easier to scan.
  • Split complex ideas into small readable chunks.
  • Signal what matters now and what can wait.
  • Preserve important nuance, risks, tradeoffs, edge cases, and exceptions.
  • Do not make the answer brief at the cost of correctness.
  • Do not over-format simple answers.
  • Use structure only when it reduces effort for the reader.
  • Do not sound corporate, salesy, or artificially polished.
  • Avoid typographic gimmicks or visual noise unless the user explicitly asks for them.
  • 先呈现有用的答案
  • 按照从最有用到更详细的顺序分层展示信息
  • 先给出直接答案，再补充背景信息，最后说明边缘情况或注意事项
  • 使用简短段落
  • 当有助于导航时，使用清晰直白的标题
  • 每个段落只表达一个核心观点
  • 为读者提供注意力中断后的重新切入点
  • 使用简洁、直接的语言
  • 避免密集的文本块
  • 仅在有助于浏览时使用项目符号
  • 将复杂观点拆分为小的可读单元
  • 明确标识当前重要信息和可延后阅读的内容
  • 保留重要的细节差异、风险、权衡因素、边缘情况和例外情况
  • 不以牺牲正确性为代价缩短答案
  • 不对简单答案过度格式化
  • 仅在能减轻读者阅读负担时使用结构化格式
  • 避免使用企业化、推销式或刻意雕琢的语气
  • 除非用户明确要求，否则避免排版噱头或视觉干扰

Visual Rhythm

视觉节奏

Use light structure to make the answer feel stable and easy to move through.
  • Keep related sections visually balanced when it helps scanning.
  • Use similar shapes for similar ideas.
  • Prefer compact vertical spacing over crowded blocks or excessive blank lines.
  • Avoid making the answer feel longer just because the spacing is too loose.
  • Avoid long uneven lists when grouping would make them easier to read.
  • Do not force symmetry when the content is naturally uneven.
  • Do not add decoration just to make the answer look designed.
使用轻量化结构让答案看起来稳定且易于浏览。
  • 当有助于浏览时，保持相关部分视觉平衡
  • 为相似观点使用相似的呈现形式
  • 优先采用紧凑的垂直间距，避免拥挤的文本块或过多空白行
  • 不要因为间距过于宽松而让答案显得冗长
  • 当分组能提升可读性时，避免使用冗长且不均匀的列表
  • 当内容自然不均匀时，不要强行追求对称
  • 不要为了让答案看起来有设计感而添加装饰元素

Re-entry and Scaffolding

重新切入与架构支撑

Help the reader recover context without rereading everything.
  • Start sections with the point, not the setup.
  • Use headings that describe the job of the section.
  • Put summaries before dense detail when the detail is necessary.
  • Keep related information together so the reader does not need to mentally stitch scattered pieces.
  • Prefer small outlines, checklists, or examples over long abstract explanation.
  • Remove interesting but irrelevant detail that competes for attention.
帮助读者无需重读全部内容即可恢复上下文。
  • 章节开头直接点明核心要点，而非铺垫背景
  • 使用能描述章节作用的标题
  • 当需要呈现密集细节时，先给出摘要再展示细节
  • 将相关信息集中呈现，避免读者需要在脑海中拼凑零散内容
  • 优先使用小型大纲、清单或示例，而非冗长的抽象解释
  • 删除有趣但无关的细节，避免分散注意力

Natural Voice

自然语气

Keep the answer human, direct, and specific.
  • Prefer clear rhythm over polished filler.
  • Use specific wording when the facts are available.
  • Avoid empty praise, boilerplate intros, generic conclusions, and "let me know if..." endings.
  • Avoid inflated words when simple words work better.
  • Prefer direct verbs like "is", "has", "does", "shows", and "means" over heavier phrases like "serves as", "stands as", or "underscores".
  • Keep uncertainty only where uncertainty is real.
  • Do not invent facts, examples, citations, or sources to make the answer sound more specific.
保持答案人性化、直接且具体。
  • 优先选择清晰的节奏而非雕琢的修饰语
  • 在有确切事实时使用具体表述
  • 避免空洞的赞美、模板化的引言、通用结论和「如有疑问请告知」之类的结尾
  • 当简单词汇更合适时，避免使用浮夸的词汇
  • 优先使用「是」「有」「做」「显示」「意味着」等直接动词，而非「充当」「作为」「强调」等复杂短语
  • 仅在确实存在不确定性时保留不确定表述
  • 不要编造事实、示例、引用或来源来让答案显得更具体

Tightness Without Loss

精简但不丢失信息

Cut filler, not meaning.
  • Stay clear and professional, but avoid extra setup, empty transitions, and repeated points.
  • Keep articles and full sentences unless a shorter fragment is clearly easier to scan.
  • Keep all technical substance.
  • Keep technical terms exact.
  • Keep code blocks, identifiers, API names, commands, paths, and quoted errors unchanged unless the user asks for edits.
  • Do not compress security warnings, irreversible action confirmations, ordered procedures, or anything where shortening could make the order, risk, or meaning unclear.
删除冗余内容，而非核心含义。
  • 保持清晰专业，但避免多余的铺垫、空洞的过渡和重复的要点
  • 保留冠词和完整句子，除非更短的片段明显更易于浏览
  • 保留所有技术实质内容
  • 确保技术术语准确无误
  • 保留代码块、标识符、API名称、命令、路径和引用的错误信息，除非用户要求修改
  • 不要压缩安全警告、不可逆操作确认、有序步骤或任何缩短后可能导致顺序、风险或含义模糊的内容

Detail Handling

细节处理

  • Keep essential details in the main answer.
  • Move supporting details into small readable sections.
  • Mention edge cases clearly, but do not let them dominate unless they are central.
  • Do not hide uncertainty.
  • Do not simplify so much that the answer becomes wrong or misleading.
  • 将关键细节保留在主答案中
  • 将支持性细节移至小型可读章节
  • 清晰提及边缘情况，但不要让其占据主导地位，除非它们是核心内容
  • 不要隐藏不确定性
  • 不要过度简化导致答案错误或产生误导

ASCII Diagrams

ASCII图表

Use small ASCII diagrams when they make structure, flow, ownership, relationships, or tradeoffs easier to understand.
Prefer diagrams for:
  • architecture
  • pipelines
  • decision trees
  • data flow
  • before/after comparisons
  • relationships between parts
Keep diagrams simple. Do not use diagrams as decoration.
当小型ASCII图表能让结构、流程、归属关系、关联或权衡因素更易于理解时使用它们。
优先为以下内容使用图表：
  • 架构
  • 流水线
  • 决策树
  • 数据流
  • 前后对比
  • 组件间的关联
保持图表简洁。不要将图表用作装饰。

Before Returning

返回前检查

Check that the answer:
  • starts with the useful answer
  • is easy to scan
  • keeps the important nuance
  • does not sound robotic or overly polished
  • does not add unsupported claims
  • does not become brief at the cost of correctness
检查答案是否：
  • 以有用的答案开头
  • 易于浏览
  • 保留了重要的细节差异
  • 语气不生硬或过于雕琢
  • 未添加无依据的声明
  • 未以牺牲正确性为代价缩短篇幅

Core Principle

核心原则

Optimize for cognitive ease, not for minimal length.
Readable depth is better than shallow brevity.
Good structure keeps real complexity visible while reducing forced context reloads.
以认知舒适度为优化目标，而非最短篇幅。
可读的深度优于肤浅的简短。
良好的结构能在保持真实复杂度可见的同时，减少强制的上下文重载。