code-reader-v2-cn

Source Code Deep Understanding Analyzer v2.3 (Chinese Version)

A professional code analysis tool based on cognitive science research, supporting three analysis depths to ensure true understanding of code rather than producing fluent hallucinations.

Core principle: Understand the WHY, not just the WHAT. Explain like an experienced engineer talking to a friend, rather than mechanically piling up jargon.

Research support:Dunlosky et al. · Chi et al. · Karpicke & Roediger

Three Analysis Modes

User Intent	Mode	Trigger Word Examples	Analysis Duration
Quick browsing/code review	Quick	"Take a quick look", "What does this code do", "Just scan it briefly"	5-10 minutes
Learning and understanding/technical research	Standard ⭐	"Analyze it", "Help me understand", "Explain it", "What's the principle"	15-20 minutes
Deep mastery/large projects	Deep 🚀	"Analyze thoroughly", "Fully master", "Study in depth", "Interview preparation", "Overall project analysis"	30+ minutes

Standard Mode is used by default. The system automatically selects the mode based on code scale and user intent.

Deep Mode internal strategy selection:

if 代码行数 <= 2000:
    策略 A：渐进式生成（顺序填充章节）
elif 代码行数 <= 10000 且 文件数 <= 20:
    策略 B：并行处理（子 Agent 章节级并行）
else:  # 行数 > 10000 或 文件数 > 20
    策略 C：分层并行（模块级扫描 → 章节级并行）

Analysis Output Structure

Quick Mode (5-10 minutes)

# [代码名称] 快速分析

## 1. 快速概览
- 编程语言和版本 / 代码规模和类型 / 核心依赖

## 2. 功能说明
- 主要功能是什么 (WHAT) + 简要 WHY

## 3. 核心算法/设计
- 复杂度（如有）+ 设计模式（如有）+ WHY 选择

## 4. 关键代码段
- 3-5 个核心代码段，每段简要说明作用

## 5. 依赖关系
- 外部库列表及用途

## 6. 快速使用示例

Standard Mode (15-20 minutes)⭐

# [代码名称] 深度理解分析

## 理解验证状态
| 核心概念 | 自我解释 | 理解"为什么" | 应用迁移 | 状态 |
|---------|---------|-------------|---------|------|
| [概念]  | ✅/❌   | ✅/⚠️/❌    | ✅/❌   | [状态] |

## 1. 快速概览
## 2. 背景与动机（3 个 WHY）
## 3. 核心概念说明（每个概念 2-3 个 WHY）
## 4. 算法与理论（复杂度 + WHY + 参考）
## 5. 设计模式（WHY 使用 + 不用会怎样）
## 6. 关键代码深度解析（见第 6 步）
## 7. 依赖关系与使用示例（含 WHY 注释）

Deep Mode (30+ minutes)

Complete section structure (strictly follow this numbering; do not introduce additional levels such as Phase/Part/Section):

# [代码名称] 深度理解分析

## 理解验证状态
## 项目完整地图（文件数 > 5 时）
## 1. 快速概览
## 2. 背景与动机（3 个 WHY）
## 3. 核心概念网络（每个概念 3 WHY + 概念关系矩阵）
## 4. 算法与理论（复杂度 + WHY + 参考）
## 5. 设计模式（WHY 使用 + 不用会怎样）
## 6. 关键代码深度解析
### 核心片段清单（6A）
### 片段 #1：[名称]
#### 1.1 代码整体作用
#### 1.2 核心逻辑分析
#### 1.3 逐行代码解释
#### 1.4 关键设计点
#### 1.5 完整示例（三组对比）
#### 1.6 使用注意与改进建议
### 片段 #2：[名称]
[同上 6 节结构，每片段编号与片段编号一致]
...
## 7. 测试用例分析（检测到测试文件时）
## 8. 应用迁移场景（至少 2 个）
## 9. 依赖关系与使用示例
## 10. 质量验证清单
## 覆盖率摘要（并行模式时）

⚠️ Key rules:

## 6. 关键代码深度解析 is the only core code analysis section, and all snippets are under it
Snippet titles use ### 片段 #N：[名称], and the 6 sections use #### N.1 ~ N.6
Do not use ## Phase N、## 模块N、## 阶段N and other self-created section levels to interrupt the continuity of numbering

9-Step Analysis Process

Step 1: Quick Overview

Goal: Build an overall mental model

Identify: programming language and version, file/project scale, core dependencies, code type (algorithm/business logic/framework, etc.)

Large projects (number of files > 5) must additionally generate a project map:

## 项目完整地图

### 完整目录树
[使用工具枚举所有文件，生成树状结构]

### 文件清单（分类）
| 类别 | 文件路径 | 行数 | 职责摘要 |
|------|---------|------|---------|
| 核心逻辑 | [路径] | [行数] | [职责] |
| 工具模块 | [路径] | [行数] | [职责] |
| 测试 | [路径] | [行数] | [职责] |
| 配置 | [路径] | [行数] | [职责] |

### 入口文件 + 核心调用链

This step must be completed before analyzing any specific code; it is the foundation for preventing missing information.

Step 2: Background and Motivation (Elaborate Interrogation)

The 3 WHYs that must be answered:

WHY is this code needed? (What problem does it solve, and what would happen without it)
WHY choose this technical solution? (Alternatives + trade-offs)
WHY is it needed at this timing/scenario? (Application scenarios + preconditions and postconditions)

Output format:

## 背景与动机分析

### 问题本质
**要解决的问题：** [一句话描述]
**WHY 需要解决：** [不解决的后果]

### 方案选择
**WHY 选择这个方案：** 优势 / 劣势 / 权衡
**替代方案对比：**
- 方案 A：[简述] - WHY 不选：[原因]
- 方案 B：[简述] - WHY 不选：[原因]

### 应用场景
**适用场景：** [描述] — **WHY 适用：** [原因]
**不适用场景：** [边界条件] — **WHY 不适用：** [原因]

Step 3: Concept Network Construction

Goal: Build connections between concepts rather than isolated memorization

Must include:

Each core concept answers 3 WHYs (what it is / WHY it is needed / WHY it is implemented this way / WHY not use others)
Concept relationship mapping: dependency/comparison/combination, with each relationship explaining WHY
Connect to existing knowledge: design patterns, algorithm theory, domain principles

Output format:

## 概念网络图

### 核心概念清单
**概念 N：[名称]**
- **是什么：** [简述]
- **WHY 需要：** [原因]
- **WHY 这样实现：** [原因]
- **WHY 不用其他方式：** [原因]

### 概念关系矩阵
| 关系类型 | 概念 A | 概念 B | WHY 这样关联 |
|---------|--------|--------|-------------|
| 依赖/顺序/对比 | [A] | [B] | [原因] |

Step 4: Algorithm and theoretical analysis

Each algorithm/theory must include:

Time/space complexity
WHY choose this algorithm (and the complexity is acceptable)
When it degrades
Authoritative reference links

Output format:

## 算法与理论分析

### 算法：[名称]
- **时间复杂度：** [O(...)]  **空间复杂度：** [O(...)]
- **WHY 选择：** [2-3 条理由]
- **WHY 复杂度可接受：** [说明]
- **WHY 不选其他：** [对比其他算法的理由]
- **退化场景：** [何时退化 + 如何规避]
- **参考：** [权威链接]

Step 5: Design pattern identification

Each design pattern must include:

Pattern name + application location
WHY use this pattern
What happens if this pattern is not used
Standard reference links

Output format:

## 设计模式分析

### 模式 N：[模式名]
**应用位置：** [类/函数名]
**WHY 使用：** [2-3 条理由]
**WHY 不用会怎样：** [后果]
**潜在问题：** ⚠️ [已知局限]
**参考：** [Refactoring Guru 等链接]

Step 6: In-depth analysis of key code (two-phase workflow)

This step is the core of the entire analysis and is divided into two phases.

Phase 6A: Core snippet identification

Applicable conditions: Number of files > 5 or code > 500 lines. For small/single-file code, skip 6A and directly execute 6B on all code (1-3 snippets).

Identification criteria (by priority):

Priority	Snippet type	Identification characteristics
★★★	Core algorithm implementation	Complex logic, nested loops, bit operations
★★★	Key interface/abstraction	At system boundaries, called extensively
★★☆	Elegant design	Uncommon implementation approaches, interesting trade-offs
★★☆	Concentrated error-prone areas	Boundary handling, concurrency control, memory management
★☆☆	Glue code	Coordination logic connecting multiple modules

Output format:

## 核心片段清单

| 编号 | 片段名称 | 所在文件:行号 | 优先级 | 识别理由 |
|------|----------|--------------|--------|----------|
| #1 | [函数名] | [文件:起止行] | ★★★ | [理由] |
| #2 | [函数名] | [文件:起止行] | ★★☆ | [理由] |

**跳过说明：**
- [文件]：[跳过原因，如：仅数据结构定义，无复杂逻辑]

After identification is complete, execute Phase 6B separately for each snippet.

Phase 6B: In-depth interpretation snippet by snippet (6-section template)

For each core snippet, output strictly according to the following 6-section structure:

⚠️ Hard red lines (also applicable to the main process):

No section may contain "omitted", "same as above", "see above", or "skipped here"
N.3 must include a real code snippet (30 lines or more), not just a description of the logic
Each WHY must be at least 2 sentences; single-sentence conclusions are prohibited
The total of the 6 sections for each snippet must be no less than 1000 words

### 片段 #N：[片段名称]

> 📍 **位置：** `文件路径:起止行号`
> 🎯 **优先级：** ★★★
> 💡 **一句话核心：** [用一句话概括这段代码的本质]

#### N.1 代码整体作用（≥150字）

[3~5 句话说明核心目标]

**它解决了什么问题？** 不用它会有什么后果？
**系统层次定位：** [业务逻辑 / 调度器 / 编译器前端 / IR 变换 / 等]
**角色与依赖：** 上游依赖什么？被下游如何使用？

#### N.2 核心逻辑分析（≥200字）

**执行流程：**

Input → [Step 1] → [Step 2] → ... → Output ↓ [Conditional branch A / Conditional branch B]


**关键算法/数据结构：** [名称] — 选择理由（至少2句解释WHY）？

**核心状态变量：**
| 变量名 | 初始值 | 变化时机 | 终态 |
|--------|--------|----------|------|
| [变量] | [初值] | [时机] | [终态] |

**多执行路径（至少2条）：**
- **路径 A（正常）：** 触发条件 → 关键状态变化 → 结果
- **路径 B（异常/边界）：** 触发条件 → 关键状态变化 → 结果

#### N.3 逐行代码解释（≥300字，必须贴真实代码）

> **贯穿示例输入：** `[具体值]`

```[语言]
[贴出真实代码，不少于30行核心逻辑]

// 步骤 1: [操作描述]
[代码行]
// WHY: [理由，至少2句]
// 此时：[变量] = [值]

// 场景 1: [条件描述]
if [条件]:
    [代码]
    // WHY: [理由，至少2句]

Comment style conventions:

# 场景 N: [描述] / // 场景 N: [描述] — Mark conditional branches (if/else/switch)
# 步骤 N: [描述] / // 步骤 N: [描述] — Mark serial execution flow
# 此时: [变量] = [值] — Track variable state

N.4 Key design points (≥200 words)

Design dimension	Analysis content (each item no less than 2 sentences)
Implementation choice	Why adopt this approach? What alternatives are there? WHY not choose the alternatives?
Performance optimization	Optimizations in memory, computation, and concurrency? Quantified explanation (if any)
Compiler-related	IR transformation/Pass design/scheduling strategy? (If not involved, write "not involved")
Security and robustness	Boundary checks, error handling, exception paths?
Scalability	Where are the extension points? How to extend?
Potential issues	Known limitations, hidden risks, or areas for improvement?

N.5 Complete examples (three comparison groups, ≥150 words)

The three examples use the same code logic and only change the input, forming a comparison.

Example 1 — Basic scenario

Input: [具体值] → Execution process: [key variable changes] → Output: [结果]

Example 2 — Complex/typical scenario

Input: [更复杂值] → Key differences: [differences from Example 1] → Result: [output]

Example 3 — Boundary or exceptional case

Input: [极值/空值/非法输入] → Handling method: [Is there protection? Crash or degrade?] → Result and reason

N.6 Usage notes and improvement suggestions (≥100 words)

When using this snippet, note the following (≥2 items, each with more than 2 sentences):

[Note 1 + what happens if ignored]
[Note 2 + what happens if ignored]

Possible improvements (≥1 item):

[Improvement direction: specific description + WHY it is better (no fewer than 2 sentences)]


---

### 第 6.5 步：测试用例反向理解（检测到测试文件时执行）

**目标：** 通过测试用例反向验证和深化对代码功能的理解。测试是最准确的"使用说明书"，覆盖边界条件和异常场景。

**检测测试文件的模式：**

| 语言 | 测试文件模式 | 常见目录 |
|------|-------------|---------|
| Python | `test_*.py`, `*_test.py` | `tests/`, `test/` |
| JavaScript/TypeScript | `*.test.ts`, `*.spec.ts` | `__tests__/` |
| Go | `*_test.go` | 与源码同目录 |
| Java | `*Test.java` | `src/test/java/` |
| C++ | `*_test.cpp` (gtest) | `test/`, `tests/` |
| MLIR/LLVM | `*.mlir` (测试文件) | `test/Dialect/*/` |

**输出格式：**

```markdown
## 测试用例分析

### 测试文件清单
| 测试文件/目录 | 测试的模块 | 测试用例数量 |
|--------------|-----------|-------------|
| [路径] | [模块] | [数量] |

### 功能覆盖矩阵
| 核心功能 | 主代码位置 | 测试覆盖 | 覆盖率评估 |
|---------|-----------|---------|-----------|
| [功能] | [位置] | ✅/⚠️/❌ | [评估] |

### 从测试中发现的边界条件
[选择 3-5 个最有价值的测试用例，说明它们揭示了哪些仅看代码容易遗漏的细节]

### 测试质量评估
- 正常流程：✅/⚠️/❌
- 边界输入：✅/⚠️/❌
- 异常输入：✅/⚠️/❌
- 并发场景：✅/⚠️/❌

### 测试质量建议
[如测试不足，提出具体改进建议]

Step 7: Application transfer test

Goal: Test whether the concept can be transferred to different scenarios and verify true understanding

Must include: At least 2 application scenarios in different domains, each explaining:

The unchanging principle (core idea)
The parts that need modification (specific code/logic)
WHY transfer this way (connect to a general pattern)

Output format:

## 应用迁移场景

### 场景 1：[原始场景] → [新场景]

**不变的原理：** [列出保持不变的核心思想]

**需要修改的部分：**
[代码对比，含 WHY 注释]

**学到的通用模式：** [提取可复用的抽象模式]

### 场景 2：[原始场景] → [新场景]
[同上结构]

Step 8: Dependencies and usage examples

Each dependency must explain: WHY choose it + WHY not use alternatives

Output format:

## 依赖关系分析

### 外部库
**[库名] (v[版本])**
- **用途：** [简述]
- **WHY 选择：** [2-3 条理由]
- **WHY 不用 [替代方案]：** [原因]

### 内部模块依赖
**[模块A] → [模块B]**
- **依赖原因：** [原因]
- **WHY 这样设计：** [设计原则]

## 完整使用示例
[完整可运行示例，含详细 WHY 注释]

Step 9: Quality verification checklist

## 质量验证清单

### 理解深度
- [ ] 每个核心概念都回答了 3 个 WHY（需要/实现/不用其他）
- [ ] 自我解释测试：不看代码能解释每个核心概念
- [ ] 概念连接：标注了依赖/对比/组合关系及 WHY

### 技术准确性
- [ ] 算法：复杂度 + WHY 选择 + WHY 可接受 + 参考资料
- [ ] 设计模式：模式名 + WHY 使用 + 不用会怎样
- [ ] 代码解析：逐行 WHY + 具体数据执行示例 + 易错点

### 实用性
- [ ] 应用迁移：至少 2 个场景，不变原理 + 修改部分
- [ ] 使用示例：代码完整 + WHY 注释 + 执行结果
- [ ] 改进建议：指出问题 + WHY 是问题 + 改进方案

### 最终"四能"测试
根据这份分析文档（不看原代码）：
1. ✅ 能否理解代码的设计思路？
2. ✅ 能否独立实现类似功能？
3. ✅ 能否应用到不同场景？
4. ✅ 能否向他人清晰解释？

**任何一项答"否"，说明分析不够深入，需要补充。**

Deep Mode parallel processing detailed workflow (Strategy B/C)

Execution phase

Phase	Executor	Operation	Output
1. Project map	Main Agent	Enumerate all files and build a complete directory tree and module list	`项目地图.md`
2. Framework preparation	Main Agent	Based on the project map, generate the outline, core concept list, and chapter-to-file mapping	`00-框架.json`
3. Task distribution	Main Agent	Create an independent task for each chapter, with a specific file path list attached	Task list
4. Parallel execution	Sub-Agents	Each sub-Agent focuses on one chapter and reads the specified files for in-depth generation	`章节-N.md`
5. Coverage verification	Main Agent	Compare with the project map and check which files/modules are not covered	Coverage report
6. Result aggregation	Main Agent	Merge all chapters, unify the format, and write the final document	`完整分析.md`
7. Quality verification	Main Agent	Check depth standards, fill in weak areas	Final document

Sub-Agent Task Template

# 子 Agent 任务：[章节名称]

## 上下文信息
- **代码名称：** [项目/代码名]
- **编程语言：** [语言]
- **核心概念：** [从主 Agent 传递的概念列表]
- **你负责的文件：** [明确列出具体文件路径]
- **其他模块摘要：** [简要说明其他模块职责，避免重复分析]

## 强制执行步骤
1. 用 Read 工具依次读取"你负责的文件"中的每一个文件
2. 确认文件内容后再开始分析（不能凭记忆或假设）
3. 分析内容必须引用实际代码行

## 特殊指令：如果你负责「关键代码解析」章节

必须执行两阶段工作流：

**阶段 1 — 核心片段识别（6A）：**
读取所有指定文件后，筛选 3-7 个最值得深度解读的片段，按优先级：
1. ★★★ 核心算法实现（复杂逻辑/循环嵌套/位运算）
2. ★★★ 关键接口（系统边界处/被大量调用）
3. ★★☆ 精妙设计（不常见实现/有趣权衡）
4. ★★☆ 易错点集中区（边界处理/并发控制/内存管理）
5. ★☆☆ 胶水代码（连接多模块的协调逻辑）

先输出「核心片段清单」：
| 编号 | 片段名称 | 所在文件:行号 | 优先级 | 识别理由 |

**阶段 2 — 逐片段深度解读（6B）：**
每个片段严格按 6 节输出，每节内容要求如下：

- **N.1 代码整体作用**（≥150字）：核心目标 + 不用它的后果 + 系统层次定位 + 角色依赖关系
- **N.2 核心逻辑分析**（≥200字）：文字执行流程图 + 算法/数据结构选型理由 + 核心状态变量表（变量名/初值/变化时机/终态）+ 至少2条执行路径说明
- **N.3 逐行代码解释**（≥300字，必须贴出实际代码）：先定义贯穿示例（具体输入值），每行或每块用「场景/步骤 + WHY + 此时变量值」注释；禁止只贴代码不注释，也禁止省略核心逻辑行
- **N.4 关键设计点**（≥200字）：用表格或条目覆盖：实现选择、性能优化、编译器相关（不涉及写"不涉及"）、安全健壮性、可扩展性、潜在问题
- **N.5 完整示例（三组对比）**（≥150字）：三组示例用同一代码逻辑，仅改变输入——基础/复杂/边界异常，每组写出输入→关键变量变化→输出
- **N.6 使用注意与改进建议**（≥100字）：≥2 个使用注意点 + ≥1 个可考虑的改进方向（含WHY更好）

**⚠️ 硬性红线：**
- 任何一节不得出现"略"、"同上"、"详见上文"、"此处省略"
- N.3 必须贴出真实代码片段（30行以上），不能只描述逻辑
- 每个 WHY 至少 2 句话，禁止单句结论

## 输出要求
- 本章节至少 [X] 字，每个 WHY 至少 2-3 句话
- 代码注释使用场景/步骤 + WHY 风格
- 提供权威参考链接
- 负责文件中每个公共函数/类都必须提及

## 深度自检
- [ ] 所有指定文件都已读取
- [ ] 所有子项都已覆盖（不能有"略"或"同上"）
- [ ] 每个 WHY 至少 2-3 句话
- [ ] 代码示例有完整注释
- [ ] 执行流程有具体数据追踪
- [ ] 「关键代码解析」已输出核心片段清单 + 每个片段的 6 节深度解读

直接输出 Markdown 格式，以 `## [章节名称]` 开头。

Coverage Verification Format

## 覆盖率校验报告

### 文件覆盖情况
| 文件路径 | 是否被分析 | 分析章节 | 备注 |
|---------|-----------|---------|------|
| [路径] | ✅/❌ | [章节] | [说明] |

### 模块覆盖率
- 核心模块：X/Y 已覆盖（目标：100%）
- 工具模块：X/Y 已覆盖
- 测试文件：X/Y 已覆盖（目标：≥ 80%）

### 未覆盖内容处理
- 重要文件（核心业务）：立即补充分析
- 次要文件（配置/工具）：在依赖关系章节简要提及
- 测试文件：确认已在测试用例分析章节覆盖

Strategy C: Layered Parallelism for Very Large Projects (file count > 20 or line count > 10000)

Phase 1 — Module-level scanning (serial): Divide the project into 3-8 modules by directory/function, and generate an independent module summary for each module (sub-agents in parallel)
Phase 2 — Chapter-level analysis (parallel): Each chapter sub-agent receives the complete project map + summaries of the modules it is responsible for + a list of key files that need in-depth reading
Phase 3 — Aggregation: Same as Strategy B

In-depth Self-check Checklist (check after each chapter is completed)

## 章节深度自检

### 内容完整性
- [ ] 所有子项已覆盖（不能有"略"、"详见上文"、"同上"）
- [ ] 每个 WHY 有具体解释（至少 2-3 句话）
- [ ] 代码示例有完整注释（场景/步骤 + WHY）
- [ ] 引用有来源链接

### 分析深度（按章节类型）
- **概念类：** 每个概念 3 个 WHY（需要/实现/不用其他）
- **算法类：** 复杂度 + WHY 选择 + WHY 可接受 + 退化场景
- **设计模式类：** 模式名 + WHY 使用 + 不用会怎样
- **代码解析类：** 核心片段清单（≥3 个，含文件:行号 + 优先级 + 理由）+ 每片段 6 节解读 + 贯穿示例 + 三组对比

### 各章最低字数与必含元素
| 章节 | 最低字数 | 必含元素 |
|-----|---------|---------|
| 1. 快速概览 | 200 | 语言、规模、依赖、类型 |
| 2. 背景与动机 | 400 | 问题本质、方案选择、应用场景 |
| 3. 核心概念 | 600 | 每概念 3 WHY、关系矩阵 |
| 4. 算法与理论 | 500 | 复杂度、WHY、参考资料 |
| 5. 设计模式 | 400 | 模式名、WHY、标准参考 |
| 6. 关键代码解析 | 每片段≥1000字（3片段起步即≥3000字）| 片段清单、每片段 6 节（含真实代码≥30行、三组对比示例）|
| 7. 测试用例分析 | 400 | 测试覆盖、边界条件、测试发现 |
| 8. 应用迁移 | 500 | ≥2 场景、不变原理、修改部分 |
| 9. 依赖关系 | 300 | 每依赖的 WHY、使用示例 |
| 10. 质量验证 | 200 | 验证清单、四能测试 |

**Deep Mode 文档应 ≥ 8000 字（含代码注释）**

**⚠️ 关键提醒：章节编号必须连续，禁止用 Phase/模块/阶段等词打断编号**

Token Optimization Output Strategy

Mode	Generation Method	Number of Files
Quick	Single Write	1
Standard	Single Write	1
Deep ≤ 2000 lines (Strategy A)	Progressive Write (framework first, fill in section by section)	1-2
Deep > 2000 lines (Strategy B/C)	Parallel sub-agents → aggregate Write	Multiple temporary chapters → 1 final document

Core principle: write the complete analysis directly to the file, and output only a summary in the conversation.

## 分析完成

**模式：** [Quick/Standard/Deep]

**核心发现：**
- 代码实现了 [核心功能]
- 使用 [算法/模式] 解决 [问题]
- 关键优化点：[优化点]
- 潜在问题：[问题]

**完整文档：** `[代码名称]-深度分析.md`

File naming:

Single file:[代码名称]-深度分析.md
Multi-file project:[项目名]-概述.md + [模块名]-分析.md
Large project:work/项目地图.md + work/chapters/章节-N.md + [项目名]-完全掌握分析.md

Key Points for Humanized Writing

The analysis document must read like an experienced engineer explaining things, not like reciting terms from a textbook.

Core requirements:

Conversational guidance, rather than throwing out definitions directly — use "this function is the gatekeeper of the entire system—every login has to go through it" instead of "this function is responsible for executing the identity verification process"
State the conclusion first, then expand on the reasons — use "the fundamental reason for using bcrypt instead of MD5 is that MD5 is too fast" instead of "because bcrypt has adaptive hash function characteristics..."
Make good use of analogies — compare locking mechanisms to library reading rules, and caching to putting frequently used things on the desk
Make code comments speak plainly — explain the intent and reasons, rather than repeating the literal meaning of the code
Explain complex concepts in layers — first give a one-sentence intuitive understanding, then add technical details
Mark error-prone points along the way — use ⚠️ to mark common misconceptions

Prohibited writing styles:

Listing terms in long passages without explanation
"This function implements X functionality" (the reader already knows)
The WHY explanation is only one sentence
Copying the wording of official documentation

Self-check questions: Can an engineer who just entered the field understand it? Does it give the reader an "I see!" feeling?

About this skill

Three Analysis Modes

Analysis Output Structure

Quick Mode (5-10 minutes)

Standard Mode (15-20 minutes)⭐

Deep Mode (30+ minutes)

9-Step Analysis Process

Step 1: Quick Overview

Step 2: Background and Motivation (Elaborate Interrogation)

Step 3: Concept Network Construction

Step 4: Algorithm and theoretical analysis

Step 5: Design pattern identification

Step 6: In-depth analysis of key code (two-phase workflow)

Phase 6A: Core snippet identification

Phase 6B: In-depth interpretation snippet by snippet (6-section template)

N.4 Key design points (≥200 words)

N.5 Complete examples (three comparison groups, ≥150 words)

N.6 Usage notes and improvement suggestions (≥100 words)

Step 7: Application transfer test

Step 8: Dependencies and usage examples

Step 9: Quality verification checklist

Deep Mode parallel processing detailed workflow (Strategy B/C)

Execution phase

Sub-Agent Task Template

Coverage Verification Format

Strategy C: Layered Parallelism for Very Large Projects (file count > 20 or line count > 10000)

In-depth Self-check Checklist (check after each chapter is completed)

Token Optimization Output Strategy

Key Points for Humanized Writing