Analyze Open-Source Project
Systematically analyze an open-source project's codebase to help the user quickly understand its architecture, core logic, data flows, key APIs, and algorithm implementations.
All analysis output MUST be in Chinese (zh-CN).
Execution Workflow
Follow these steps strictly in order. Use parallel subagents (Task tool with subagent_type="explore") where noted.
Phase 1: Context Gathering
Read these files first (use parallel reads):
- 1.
README.md (or README.rst, README.txt) — project purpose, features, quick start - Primary config/dependency file — detect tech stack:
- Node.js:
package.json
- Python:
pyproject.toml >
setup.py >
requirements.txt
- Go:
go.mod
- Java/Kotlin:
pom.xml or
build.gradle
- Rust:
Cargo.toml
- C/C++:
CMakeLists.txt or
Makefile
- .NET:
*.csproj or
*.sln
- 3. CI/Docker files if present (
Dockerfile, .github/workflows/) — reveals build & deploy info
Summarize: project name, purpose, tech stack, major dependencies, and build/run commands.
Phase 2: Directory Structure Scan
Run a directory listing (depth 2) to map out the project layout.
Classify each top-level directory into one of:
- - core: main business logic
- api: HTTP/gRPC/CLI interface layer
- model/entity: data models or domain objects
- config: configuration and environment
- util/common: shared utilities
- test: test suites
- docs: documentation
- scripts/tools: build or deployment scripts
- other: anything else
Phase 3: Entry Point Identification
Search for program entry points based on the detected tech stack:
| Tech Stack | Typical Entry Points |
|---|
| Node.js | INLINECODE17 "main"/"scripts.start", index.js, src/index.ts, INLINECODE20 |
| Python |
__main__.py,
main.py,
app.py,
manage.py,
cli.py |
| Go |
main.go,
cmd/*/main.go |
| Java | classes with
public static void main,
@SpringBootApplication |
| Rust |
src/main.rs,
src/lib.rs |
| C/C++ |
main.c,
main.cpp |
| Web Frontend |
src/index.tsx,
src/main.ts,
src/App.vue |
Read the entry point file(s) and trace the initialization/bootstrap sequence.
Phase 4: Deep Analysis
Perform all four dimensions of analysis. Use parallel explore subagents for independent dimensions.
4a. Architecture & Module Dependencies
- - Identify the architectural pattern (MVC, Clean Architecture, Hexagonal, Microservices, Monolith, etc.)
- Map module dependencies — which modules import/call which
- Produce a Mermaid graph showing module relationships
4b. Core Business Flow & Data Flow
- - Trace the primary user-facing workflow(s) end-to-end
- Identify how data enters, transforms, persists, and exits the system
- Produce a Mermaid flowchart or sequence diagram for the most important flow
4c. Key API Interfaces & Call Chains
- - List public API endpoints or exported interfaces
- For the top 3-5 most important APIs, trace the call chain from handler to data layer
- Note middleware, interceptors, or decorators in the chain
4d. Algorithm & Function Implementation
- - Identify non-trivial algorithms or complex business logic
- Extract the key code snippets (keep concise, max ~30 lines each)
- Annotate each snippet explaining the logic step by step
Output Format
Use the template defined in template.md to structure the final report.
Key formatting rules:
- - Use Markdown headings (
##, ###) for clear hierarchy - Include at least 2 Mermaid diagrams (architecture graph + primary flow)
- Code snippets use CODE REFERENCE format (
startLine:endLine:filepath) when citing existing code - Keep the entire report readable in under 15 minutes
Guidelines
- - Depth over breadth: It is better to deeply explain 3 critical modules than to shallowly list 20.
- Follow the data: When in doubt about what to analyze next, follow the data flow.
- Cite code: Always reference specific files and line numbers — never make vague claims.
- Be opinionated: State clearly what the architectural strengths and weaknesses are.
- Progressive disclosure: Start with executive summary; put detailed analysis in later sections. The user should get 80% of the value from the first 20% of the report.
分析开源项目
系统性地分析开源项目的代码库,帮助用户快速理解其架构、核心逻辑、数据流、关键API及算法实现。
所有分析输出必须使用中文(zh-CN)。
执行工作流
严格按照以下步骤顺序执行。在标注处使用并行子代理(使用子代理类型为explore的任务工具)。
第一阶段:上下文收集
首先读取以下文件(使用并行读取):
- 1. README.md(或README.rst、README.txt)——项目目的、功能、快速入门
- 主要配置/依赖文件——检测技术栈:
- Node.js:package.json
- Python:pyproject.toml > setup.py > requirements.txt
- Go:go.mod
- Java/Kotlin:pom.xml 或 build.gradle
- Rust:Cargo.toml
- C/C++:CMakeLists.txt 或 Makefile
- .NET:
.csproj 或 .sln
- 3. 如果存在CI/Docker文件(Dockerfile、.github/workflows/)——揭示构建与部署信息
总结:项目名称、目的、技术栈、主要依赖项以及构建/运行命令。
第二阶段:目录结构扫描
运行目录列表(深度为2),绘制项目布局图。
将每个顶级目录分类为以下之一:
- - 核心:主要业务逻辑
- API:HTTP/gRPC/CLI接口层
- 模型/实体:数据模型或领域对象
- 配置:配置与环境
- 工具/通用:共享工具
- 测试:测试套件
- 文档:文档
- 脚本/工具:构建或部署脚本
- 其他:其他内容
第三阶段:入口点识别
根据检测到的技术栈搜索程序入口点:
| 技术栈 | 典型入口点 |
|---|
| Node.js | package.json中的main/scripts.start、index.js、src/index.ts、app.js |
| Python |
main.py、main.py、app.py、manage.py、cli.py |
| Go | main.go、cmd/*/main.go |
| Java | 包含public static void main的类、@SpringBootApplication |
| Rust | src/main.rs、src/lib.rs |
| C/C++ | main.c、main.cpp |
| Web前端 | src/index.tsx、src/main.ts、src/App.vue |
读取入口点文件,并追踪初始化/启动序列。
第四阶段:深度分析
执行所有四个维度的分析。对独立维度使用并行探索子代理。
4a. 架构与模块依赖
- - 识别架构模式(MVC、整洁架构、六边形架构、微服务、单体应用等)
- 绘制模块依赖关系图——哪些模块导入/调用哪些模块
- 生成展示模块关系的Mermaid图
4b. 核心业务流与数据流
- - 端到端追踪主要的面向用户工作流
- 识别数据如何进入、转换、持久化并离开系统
- 为最重要的流程生成Mermaid流程图或时序图
4c. 关键API接口与调用链
- - 列出公共API端点或导出的接口
- 针对最重要的3-5个API,追踪从处理器到数据层的调用链
- 记录调用链中的中间件、拦截器或装饰器
4d. 算法与函数实现
- - 识别非平凡算法或复杂业务逻辑
- 提取关键代码片段(保持简洁,每个片段最多约30行)
- 为每个片段添加注释,逐步解释逻辑
输出格式
使用template.md中定义的模板来构建最终报告。
关键格式规则:
- - 使用Markdown标题(##、###)实现清晰的层级结构
- 至少包含2个Mermaid图(架构图+主要流程)
- 引用现有代码时,使用代码引用格式(起始行:结束行:文件路径)
- 确保整个报告在15分钟内可阅读完毕
指导原则
- - 深度优先于广度:深入解释3个关键模块,优于浅显地列出20个模块。
- 跟随数据流:不确定下一步分析什么时,跟随数据流。
- 引用代码:始终引用具体文件和行号——绝不做出模糊断言。
- 有观点:清晰说明架构的优势和劣势。
- 渐进式披露:从执行摘要开始;将详细分析放在后续章节。用户应从报告的前20%内容中获得80%的价值。