girishlade111/Reverse-Engineering
GitHub: girishlade111/Reverse-Engineering
一个由 36 个 Prompt 文件组成的模块化 AI 框架，通过 9 阶段分析流水线引导 LLM 自动对任意软件仓库进行逆向分析并生成高质量架构文档。
Stars: 0 | Forks: 0
# 企业级逆向工程 Prompt 框架
一个模块化、可扩展且可复用的框架，用于对任意软件仓库进行 AI 驱动的逆向工程——从单文件工具到具有 AI/agent 工作流的多服务分布式系统。该框架引导基于 LLM 的 AI agent 通过系统化的多阶段分析 pipeline，从而生成完整、准确且具有可操作性的文档。
## 目录
- [本框架是什么](#what-this-framework-is)
- [为什么需要它](#why-it-exists)
- [架构概述](#architecture-overview)
- [框架变体](#framework-variants)
- [快速开始](#quick-start)
- [9 阶段 Pipeline](#the-9-phase-pipeline)
- [阶段 1 — 发现](#phase-1--discovery)
- [阶段 2 — 结构分析](#phase-2--structural-analysis)
- [阶段 3 — 架构重构](#phase-3--architecture-reconstruction)
- [阶段 4 — 深度代码分析](#phase-4--deep-code-analysis)
- [阶段 5 — AI 与自动化分析](#phase-5--ai--automation-analysis-conditional)
- [阶段 6 — 集成与边界分析](#phase-6--integration--boundary-analysis)
- [阶段 7 — 文档生成](#phase-7--documentation-generation)
- [阶段 8 — 验证与质量](#phase-8--validation--quality)
- [阶段 9 — 重构包](#phase-9--rebuild-package-optional)
- [质量保证系统](#quality-assurance-system)
- [输出结构](#output-structure)
- [设计原则](#design-principles)
- [前置条件](#prerequisites)
- [文件清单](#file-inventory)
- [Prompt 依赖图](#prompt-dependency-map)
- [术语表](#glossary)
- [扩展框架](#extending-the-framework)
- [贡献指南](#contributing)
- [许可证](#license)
## 本框架是什么
这不是一个软件应用程序。它是一个 **prompt 工程框架** —— 一个由 36 个相互关联、版本化且跟踪依赖关系的 prompt 文件（Markdown `.md` 文件）组成的集合，被组织为 9 个顺序阶段。每个 prompt 文件都是一个独立的分析单元，可以在不同的仓库中复用。组合在一起，它们形成了一条 pipeline，引导 AI agent 从首次接触到完整记录任意软件系统的全流程。
该框架生成的文档质量极高，任何有能力的工程师都可以仅凭文档就能完全理解、修改、扩展或 **从零开始重构整个系统**。
## 为什么需要它
软件仓库是知识的孤岛。源代码中编码的设计意图、架构决策和运维知识，对于没有编写过它的人来说是不可见的。该框架的存在是为了：
1. **从代码中提取知识** —— 将隐式设计转化为显式文档
2. **保留架构意图** —— 不仅捕捉代码的功能，还要捕捉*为什么*这样设计
3. **实现知识传递** —— 让新工程师、审计员和 AI 系统能够理解任意仓库
4. **支持重构和迁移** —— 提供足够的细节以便从零开始重构系统
5. **识别改进机会** —— 揭示架构债务、反模式和优化目标
6. **加速入职培训** —— 用结构化的文档学习时间代替数周的代码阅读时间
### 范围
**涵盖范围：**
- 任意编程语言（编译型、解释型、转译型）
- 任意软件领域（Web、移动端、桌面端、嵌入式、AI/ML、数据 pipeline、基础设施）
- 任意仓库规模（从单文件到多仓库 monorepo）
- 任意架构风格（单体、微服务、事件驱动、serverless、agent-based）
- 任意 AI 成熟度（从无 AI 组件到复杂的多 agent 系统）
**不涵盖范围：**
- 安全漏洞利用（这是为了理解，而不是攻击）
- 法律/取证逆向工程（不涉及二进制反编译或绕过 DRM）
- 性能基准测试（侧重架构理解，而非 runtime 分析）
- 代码修改（仅限分析；不生成或重构代码）
## 架构概述
### 三层架构
```
┌─────────────────────────────────────────────────────────────────┐
│ LAYER 1 — INFRASTRUCTURE │
│ │
│ MASTER_INDEX MISSION OPERATING_RULES QUALITY_STANDARDS │
│ PROJECT_SPEC PROMPT_DESIGN_GUIDE FRAMEWORK_PHILOSOPHY │
│ PROMPT_DEPENDENCY_MAP GLOSSARY DIAGRAM_TEMPLATES │
│ VALIDATION_CHECKLISTS OUTPUT_RULES │
│ (12 non-executable configuration & reference files) │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ LAYER 2 — ORCHESTRATION │
│ │
│ MASTER_PROMPT.md │
│ Sequences, loads, and coordinates all sub-prompts │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ LAYER 3 — EXECUTION │
│ │
│ 36 prompt files organized into 9 sequential phases │
│ Each prompt has: MISSION → PREREQUISITES → SYSTEM PROMPT │
│ → EXECUTION INSTRUCTIONS → OUTPUT SPEC → QUALITY GATE → HANDOFF │
└─────────────────────────────────────────────────────────────────┘
```
### Pipeline 架构
```
[Repository]
→ Phase 1: DISCOVERY (inventory, stack detection)
→ Phase 2: STRUCTURAL (architecture skeleton)
→ Phase 3: ARCHITECTURE (component map)
→ Phase 4: DEEP CODE (code-level understanding)
→ [Branch Point]
├─ → Phase 5: AI & AUTOMATION (if AI patterns detected)
└─ → (skip if no AI patterns)
→ Phase 6: INTEGRATION (boundaries & contracts)
→ Phase 7: DOCUMENTATION (handbooks, guides, diagrams)
→ Phase 8: VALIDATION (quality gates & sign-off)
→ Phase 9: REBUILD PACKAGE (optional — rebuild from docs)
→ [Complete Documentation Set]
```
## 框架变体
本仓库包含 **5 种框架变体**，每种都针对特定的 AI 模型或工具链进行了定制。所有变体都实现了相同的核心 9 阶段 pipeline，但在 prompt 结构、格式、深度以及针对 AI 的优化方面有所不同。
| # | 变体 | 目录 | 文件数 | 状态 |
|---|---------|-----------|-------|--------|
| 1 | **Hermes + Deepseek v4** | `Hermes With Deepseek v4 flash/` | 49 | **规范（参考版）** |
| 2 | **Opencode + Deepseek v4 — V1** | `Opencode With Deepseek v4 flash/Version 1` | 37 | 完整版 |
| 3 | **Opencode + Deepseek v4 — V2** | `Opencode With Deepseek v4 flash/Version 2` | 39 | 完整版 |
| 4 | **Claude** | `Claude/` | 20 | 完整版 |
| 5 | **Gemini 3.1 Pro** | `Gemini With Gemini 3.1 Pro/` | 3 | 基础版 |
### 变体详情
**Hermes With Deepseek v4 flash** —— 规范参考框架。包含完整的 36 个 prompt 和 13 个支持文件的实现，具有标准的 9 阶段 pipeline 和全面的质量保证系统。这是本 README 中详细描述的变体。
**Opencode With Deepseek v4 flash** —— 针对 Opencode agent runtime 优化的两个版本。Version 1 包含 23 个可执行 prompt 以及大量补充文件（清单、模板、故障排除）。Version 2 重组为 10 个核心 prompt 和 14 个专门 prompt，并附带预先生成的手册文档。
**Claude** —— 针对 Claude Code 的精简 20 文件改编版。采用组合式主 prompt 方法，包含 10 个涵盖从仓库情报到验证/QA 的带编号分析 prompt。专为在 Claude 的上下文窗口内进行单会话执行而设计。
**Gemini With Gemini 3.1 Pro** —— 轻量级的 3 文件基础变体（Master Index、Mission Directive、Operating Rules）。专为 Gemini 3.1 Pro 的扩展上下文窗口设计的最小起点。
**Opencode With Nemotron 3 Ultra** —— 用于未来针对 Nemotron 优化的变体的占位目录。
### 选择变体
| 如果你正在使用... | 从这里开始 |
|-------------------|------------|
| 任意 AI agent（通用） | `Hermes With Deepseek v4 flash/` |
| Opencode 与 Deepseek v4 | `Opencode With Deepseek v4 flash/`（推荐 V2） |
| Claude Code | `Claude/` |
| Gemini 3.1 Pro | `Gemini With Gemini 3.1 Pro/` |
## 快速开始
### 1. 加载框架
将 MASTER_PROMPT.md 作为系统级指令提交给你的 AI agent。此文件包含负责为所有子 prompt 排序的 orchestrator 逻辑。
### 2. 提供目标仓库
使 AI agent 能够访问目标仓库（本地文件系统、URL 或上传的归档文件）。
### 3. 分阶段执行
该框架遵循严格的顺序 pipeline。每个阶段的输出都会作为下一阶段的输入。该 agent 将会：
- 阅读当前阶段的子 prompt
- 对仓库执行分析
- 生成带有图表的结构化输出
- 通过内置的质量检查点
- 将上下文移交给下一阶段
### 4. 审查与验证
阶段 8（验证与质量）会在最终签发之前，自动交叉验证所有输出的准确性、完整性和一致性。
### 5. 输出
所有文档都将写入目标仓库中的 `docs/reverse-engineering/` 目录。
### AI Agent 需求
| 需求 | 最低要求 | 推荐配置 |
|-------------|---------|-------------|
| 上下文窗口 | 32K tokens | 128K+ tokens |
| 文件 I/O | 读取文件，写入文件 | 完整的文件系统访问权限 |
| 图表支持 | Mermaid 渲染 | 带样式的 Mermaid |
| 多步执行 | 顺序 prompts | 全流水线自动化 |
## 9 阶段 Pipeline
### 阶段 1 — 发现
**Prompts：** P01–P03（3 个文件） | **状态：** 强制执行
入口点。AI agent 对仓库执行初步扫描，以建立基准认知。
| Prompt | 目的 | 关键输出 |
|--------|---------|------------|
| P01 — 仓库扫描 | 识别仓库类型、构建系统、语言分布和顶层结构 | 语言细分、构建系统识别、仓库类型分类 |
| P02 — 文件清单 | 全面的文件列表，按类型、语言和目的进行分类 | 带有分类的完整文件清单 |
| P03 — 技术栈检测 | 检测框架、库、工具和基础设施依赖 | 包含版本和用途的技术栈矩阵 |
### 阶段 2 — 结构分析
**Prompts：** P04–P06（3 个文件） | **状态：** 强制执行
构建仓库的结构骨架 —— 即文件和模块是如何组织的。
| Prompt | 目的 | 关键输出 |
|--------|---------|------------|
| P04 — 文件夹架构 | 分析目录结构、命名约定和组织模式 | 文件夹架构图及设计理据 |
| P05 — 模块依赖图 | 映射模块、package 和 namespace 之间的依赖关系 | 包含 import/require 分析的依赖图 |
| P06 — 入口点分析 | 识别所有入口点 —— CLI、API、构造函数、main 函数、事件处理程序 | 带有调用签名的入口点注册表 |
### 阶段 3 — 架构重构
**Prompts：** P07–P10（4 个文件） | **状态：** 强制执行
重构系统架构 —— 即组件如何交互以及它们遵循什么模式。
| Prompt | 目的 | 关键输出 |
|--------|---------|------------|
| P07 — 系统架构 | 从代码结构重构高层系统架构 | 带有组件关系的架构图 |
| P08 — 组件分解 | 识别、分类并记录所有组件 | 包含职责和接口的组件目录 |
| P09 — 层级分析 | 识别架构层级及其交互 | 带有各层间数据流的层级图 |
| P10 — 设计模式识别 | 检测并记录应用的设计模式 | 包含代码位置和设计理据的模式目录 |
### 阶段 4 — 深度代码分析
**Prompts：** P11–P15（5 个文件） | **状态：** 强制执行
最深入的分析阶段 —— 理解代码的实际运作方式。
| Prompt | 目的 | 关键输出 |
|--------|---------|------------|
| P11 — 数据流分析 | 追踪数据从输入到输出的整个系统流转 | 数据流图和转换 pipeline |
| P12 — 执行路径重构 | 映射主要执行路径和控制流 | 带有分支逻辑的执行流图 |
| P13 — 状态管理分析 | 分析状态管理方法 | 状态机图和状态转换表 |
| P14 — 错误处理与重试策略 | 记录错误处理模式 | 错误分类、处理矩阵和恢复流 |
| P15 — 并发与性能分析 | 分析并发模型和性能架构 | 并发模型图和瓶颈分析 |
### 阶段 5 — AI 与自动化分析
**Prompts：** P16–P20（5 个文件） | **状态：** 条件执行
**仅在仓库中检测到 AI 模式（prompts、agents、LLM 调用）时执行。** 这是框架的条件分支 —— 当阶段 3 或阶段 4 识别出 AI 组件时，它会自动激活。
| Prompt | 目的 | 关键输出 |
|--------|---------|------------|
| P16 — Prompt 架构分析 | 分析 prompt 文件、模板和 system prompt | 带有依赖链的 prompt 架构图 |
| P17 — Agent 工作流重构 | 分解 agent 工作流和决策树 | 带有交接点的 agent 工作流图 |
| P18 — 工具集成分析 | 映射工具定义、MCP server 和外部集成 | 带有调用模式的工具注册表 |
| P19 — 规划与推理 Pipeline | 分析规划/推理系统（ReAct、Chain-of-Thought 等） | 包含推理步骤分解的规划 pipeline |
| P20 — 记忆与 RAG 工作流分析 | 分析记忆系统和检索 pipeline | 带有向量存储和检索拓扑的记忆架构 |
### 阶段 6 — 集成与边界分析
**Prompts：** P21–P24（4 个文件） | **状态：** 强制执行
分析系统如何进行内部和外部通信。
| Prompt | 目的 关键输出 |
|--------|---------|------------|
| P21 — 内部 API 契约分析 | 记录内部 API、接口和契约 | 带有请求/响应 schema 的 API 契约目录 |
| P22 — 外部服务集成 | 映射所有外部依赖和集成 | 带有集成模式的外部依赖矩阵 |
| P23 — 事件流与工作流 | 分析事件驱动通信和异步工作流 | 带有生产者/消费者映射的事件目录 |
| P24 — 配置与环境分析 | 记录配置系统和环境管理 | 带有环境变量注册表的配置 schema |
### 阶段 7 — 文档生成
**Prompts：** P25–P30（6 个文件） | **状态：** 强制执行
将所有分析综合成结构化的文档交付物。
| Prompt | 目的 | 关键输出 |
|--------|---------|------------|
| P25 — 架构手册 | 全面的系统架构参考 | 包含所有图表的完整架构手册 |
| P26 — 开发者手册 | 实用开发指南 | 带有代码规范的开发者入门指南 |
| P27 — 重构指南 | 逐步的重构说明 | 从零开始的完整重构规范 |
| P28 — API 参考与类目录 | 完整的 API 和类文档 | 包含所有 endpoint 和类目录的 API 参考 |
| P29 — 工程笔记与交叉引用 | 捕捉边界情况、陷阱和经验 | 带有跨模块引用的工程笔记 |
| P30 — 验证与交接协议 | 最终交接文档 | 带有已知缺口和假设的交接摘要 |
### 阶段 8 — 验证与质量
**Prompts：** P31–P34（4 个文件） | **状态：** 强制执行
在最终交付前交叉验证所有输出。
| Prompt | 目的 | 关键输出 |
|--------|---------|------------|
| P31 — 跨阶段准确性验证 | 验证所有阶段的事实准确性 | 带有已验证/已更正发现的准确性报告 |
| P32 — 完整性深度审计 | 审计是否存在缺口和遗漏的覆盖范围 | 带有缺口分析的完整性报告 |
| P33 — 一致性与矛盾验证 | 查找各阶段之间的矛盾 | 带有解决方案的一致性报告 |
| P34 — 最终质量关卡与签发 | 最终质量检查与签发 | 带有质量评分的签发证书 |
### 阶段 9 — 重构包
**Prompts：** P35–P36（2 个文件） | **状态：** 可选
针对计划重构系统的团队的可选阶段。
| Prompt | 目的 | 关键输出 |
|--------|---------|------------|
| P35 — 重构包组装 | 打包所有重构构件 | 带有依赖列表的完整重构包 |
| P36 — 重构验证协议 | 定义如何验证重构 | 带有验收标准的验证清单 |
## 质量保证系统
该框架内置了多层质量系统 —— 无需外部测试框架。
### 第 1 层：单 Prompt 质量关卡
36 个 prompt 中的每一个都有一个强制的 **QUALITY GATE** 部分，其中包含通过/失败标准。每个关卡会在移交给下一个 prompt 之前，验证该 prompt 的输出是否达到了其特定的质量基准。
### 第 2 层：10 项质量标准 (Q1–Q10)
定义在 `QUALITY_STANDARDS.md` 中：
| ID | 标准 | 描述 |
|----|----------|-------------|
| Q1 | 准确性 | 所有结论均对照源代码进行了验证 |
| Q2 | 完整性 | 没有遗漏的组件、文件或关系 |
| Q3 | 可追溯性 | 每一个架构主张均可追溯到代码 |
| Q4 | 结构质量 | 清晰的图表，一致的格式 |
| Q5 | 图表质量 | 每个图表都有明确的用途和图例 |
| Q6 | 一致性 | 各阶段之间没有矛盾 |
| Q7 | 清晰度 | 易于不熟悉该代码库的工程师理解 |
| Q8 | 可验证性 | 每一个结论均可由读者测试 |
| Q9 | 质量关卡 | 在阶段完成前通过了所有关卡 |
| Q10 | 持续改进 | 为未来的运行捕捉经验教训 |
### 第 3 层：验证清单
`VALIDATION_CHECKLISTS.md` 提供了阶段级别的清单 —— 针对 9 个阶段中每一个的全面通过/失败标准。
### 第 4 层：阶段 8 专门验证
四个专门的 prompt（P31–P34）负责执行跨阶段验证、准确性核查、完整性审计以及最终签发。
## 输出结构
当针对目标仓库执行时，该框架会生成如下文档树：
```
docs/reverse-engineering/
├── SUMMARY.md # Executive summary
├── _analysis/ # Working notes (internal)
│ ├── 01_scan_notes.md
│ ├── 02_dependency_trace.md
│ └── ...
├── 01_discovery_report.md
├── 02_structural_analysis.md
├── 03_architecture_reconstruction.md
├── 04_deep_code_analysis.md
├── 05_ai_automation_analysis.md (conditional)
├── 06_integration_boundary_analysis.md
├── 07_documentation/
│ ├── ARCHITECTURE_HANDBOOK.md
│ ├── DEVELOPER_HANDBOOK.md
│ ├── REBUILD_GUIDE.md
│ └── diagrams/ # Mermaid diagrams
├── 08_validation_report.md
└── 09_rebuild_package/ (optional)
├── BUILD_INSTRUCTIONS.md
└── DEPENDENCIES.md
```
预期总输出：**50–500+ 页** 结构化的逆向工程文档，具体取决于仓库的规模和复杂度。
## 设计原则
### 1. 模块化
每个 prompt 都是一个具有明确输入、输出、依赖关系和成功标准的自包含单元。这带来了以下优势：
- **复用** —— 单个 prompt 可以被提取并在其他上下文中使用
- **测试** —— 每个 prompt 都可以独立评估
- **替换** —— 替换某个 prompt 不会影响 pipeline 的其余部分
- **并行化** —— 独立的 prompt 可以同时运行
### 2. 关注点分离
每个 prompt 精确对应一个分析关注点。没有 prompt 会涵盖属于另一个 prompt 领域的主题。这确保了：
- 没有重复的分析
- 对每个分析维度有明确的所有权
- 在所有维度上保持一致的深度
- 可验证的完整性
### 3. 逐步深化（漏斗架构）
随着阶段的推进，该框架会缩小范围但加深分析深度：
```
Phase 1: ████████████████████████████████ (100% files, shallow)
Phase 2: ████████████████████████████████ (100% files, structural)
Phase 3: ██████████████████████░░░░░░░░░░ (80% files, architectural)
Phase 4: ████████████░░░░░░░░░░░░░░░░░░░░ (40% files, deep)
Phase 5: ██████░░░░░░░░░░░░░░░░░░░░░░░░░░ (20% files, AI-specific)
Phase 6: ████████████████████░░░░░░░░░░░░ (60% files, integration)
Phase 7: ████████████████████████████████ (100% consolidation)
Phase 8: ████████████████████████████████ (100% verification)
```
### 4. 多分辨率分析
分析同时在三个层面上进行：
- **宏观：** 系统架构、组织结构、部署拓扑
- **中观：** 组件职责、模块依赖关系、通信模式
- **微观：** 函数行为、状态转换、错误处理、边界情况
在某一层面得出的任何发现，都必须能够向下追溯到下一层面的实现，并在上一层面得到合理化验证。
### 5. 先理解，后记录
在系统被完全理解之前，不进行任何文档编写。每个 prompt 都强制执行“先理解，后记录”的原则。
### 6. 操作规则
该框架强制执行 12 条约束规则（定义在 `OPERATING_RULES.md` 中），用于约束 AI agent 的行为：
1. 绝不猜测 —— 如果你无法验证，请说明不确定性
2. 将每个发现都追溯回源代码
3. 如果某个 prompt 的质量关卡失败，不要继续执行
4. 为依赖它的 prompt 保留上下文
5. 严格遵守输出格式化规则
6. 如果仓库模式与框架假设相矛盾，记录该偏差
## 前置条件
### 执行要求
- 具备 **32K+ token 上下文窗口** 的 AI agent（推荐 128K+）
- 在目标仓库上具备文件读/写能力
- 支持 Mermaid 图表渲染（用于图表输出）
- 目标仓库必须**能作为一个整体被访问**（不能是部分提取）
### 框架本身要求
- 该框架**不需要安装、依赖项或运行环境**
- 它是一个 Markdown 文件集合 —— 可被任何文本编辑器或 LLM 读取
- **零外部依赖** —— 不需要 npm、pip、Docker 或任何包管理器
## 文件清单
### 基础设施与 Orchestrator 文件 (13)
| 文件 | 行数 | 用途 |
|------|-------|---------|
| `MASTER_INDEX.md` | 307 | 框架图、目录、快速入门指南 |
| `MASTER_PROMPT.md` | 192 | Orchestrator —— 加载并排序子 prompt |
| `MISSION.md` | 110 | 核心使命、理念、原则、成功标准 |
| `PROJECT_SPECIFICATION.md` | 251 | 正式规范 —— 架构、接口、契约 |
| `PROMPT_DESIGN_GUIDE.md` | 199 | 设计决策、语言适配、常见陷阱 |
| `FRAMEWORK_DESIGN_PHILOSOPHY.md` | 191 | 设计思路、故障模式分析、设计理据 |
| `OPERATING_RULES.md` | 174 | 针对 AI agent 的 12 条约束规则 |
| `OUTPUT_RULES.md` | 243 | 文档格式、图表、表格、风格规则 |
| `QUALITY_STANDARDS.md` | 188 | 带有可衡量标准的 10 项质量标准 (Q1–Q10) |
| `GLOSSARY.md` | 155 | 40+ 标准化术语定义 |
| `PROMPT_DEPENDENCY_MAP.md` | 180 | 完整的有向依赖图和上下文交接表 |
| `DIAGRAM_TEMPLATES.md` | 410 | 13 个可复用的 Mermaid 图表模板及样式指南 |
| `VALIDATION_CHECKLISTS.md` | 284 | 用于签发的阶段级别质量检查清单 |
### 可执行 Prompts (36)
| 阶段 | ID | Prompt | 状态 |
|-------|----|--------|--------|
| **阶段 1 — 发现** | P01 | 仓库扫描 | 强制执行 |
| | P02 | 文件清单 | 强制执行 |
| | P03 | 技术栈检测 | 强制执行 |
| **阶段 2 — 结构分析** | P04 | 文件夹架构 | 强制执行 |
| | P05 | 模块依赖图 | 强制执行 |
| | P06 | 入口点分析 | 强制执行 |
| **阶段 3 — 架构重构** | P07 | 系统架构重构 | 强制执行 |
| | P08 | 组件分解 | 强制执行 |
| | P09 | 层级分析 | 强制执行 |
| | P10 | 设计模式识别 | 强制执行 |
| **阶段 4 — 深度代码分析** | P11 | 数据流分析 | 强制执行 |
| | P12 | 执行路径重构 | 强制执行 |
| | P13 | 状态管理分析 | 强制执行 |
| | P14 | 错误处理与重试策略 | 强制执行 |
| | P15 | 并发与性能分析 | 强制执行 |
| **阶段 5 — AI 与自动化分析** | P16 | Prompt 架构分析 | 条件执行 |
| | P17 | Agent 工作流重构 | 条件执行 |
| | P18 | 工具集成分析 | 条件执行 |
| | P19 | 规划与推理 Pipeline | 条件执行 |
| | P20 | 记忆与 RAG 工作流分析 | 条件执行 |
| **阶段 6 — 集成与边界** | P21 | 内部 API 契约分析 | 强制执行 |
| | P22 | 外部服务集成 | 强制执行 |
| | P23 | 事件流与工作流分析 | 强制执行 |
| | P24 | 配置与环境分析 | 强制执行 |
| **阶段 7 — 文档生成** | P25 | 架构手册生成 | 强制执行 |
| | P26 | 开发者手册生成 | 强制执行 |
| | P27 | 重构指南生成 | 强制执行 |
| | P28 | API 参考与类目录 | 强制执行 |
| | P29 | 工程笔记与交叉引用 | 强制执行 |
| | P30 | 验证与交接协议 | 强制执行 |
| **阶段 8 — 验证与质量** | P31 | 跨阶段准确性验证 | 强制执行 |
| | P32 | 完整性深度审计 | 强制执行 |
| | P33 | 一致性与矛盾验证 | 强制执行 |
| | P34 | 最终质量关卡与签发 | 强制执行 |
| **阶段 9 — 重构包** | P35 | 重构包组装 | 可选 |
| | P36 | 重构验证协议 | 可选 |
## Prompt 依赖图
`PROMPT_DEPENDENCY_MAP.md` 文件定义了完整的有向依赖图。关键结构规则如下：
- **阶段内顺序执行：** 一个阶段内的 prompts 是有顺序的，必须按顺序执行
- **跨阶段顺序执行：** 每个阶段都依赖于其之前的所有阶段
- **条件分支：** 阶段 5 仅在检测到 AI/自动化模式时执行（决策点在阶段 4 之后）
- **可选扩展：** 阶段 9 是完全可选的，且依赖于阶段 7（文档），而不是阶段 8
- **上下文交接：** 每个 prompt 接收来自其前置者的上下文，并将输出传递给其继任者
```
P01 → P02 → P03
↓
P04 → P05 → P06
↓
P07 → P08 → P09 → P10
↓
P11 → P12 → P13 → P14 → P15
↓
├─ → (AI patterns detected?) → P16 → P17 → P18 → P19 → P20
└─ → (no AI patterns) ─────── skip
↓
P21 → P22 → P23 → P24
↓
P25 → P26 → P27 → P28 → P29 → P30
↓
P31 → P32 → P33 → P34
↓
P35 → P36 (optional)
```
## 术语表
在所有 prompt 中标准化的核心术语。完整定义请见 `GLOSSARY.md`。
| 术语 | 定义 |
|------|------------|
| **Repository (仓库)** | 正在被逆向工程的目标软件系统 |
| **Prompt** | 包含 AI agent 令的单个 `.md` 文件 |
| **Phase (阶段)** | 具有共同分析目标的一组逻辑 prompt |
| **Analysis Artifact (分析构件)** | 通过执行 prompt 生成的结构化输出 |
| **Quality Gate (质量关卡)** | 每个 prompt 结束时的强制性通过/失败检查点 |
| **Context Handoff (上下文交接)** | 从一个 prompt 传递给其依赖项的结构化信息 |
| **Architecture Handbook (架构手册)** | 全面的系统架构文档 |
| **Developer Handbook (开发者手册)** | 针对在该系统上工作的工程师的实用指南 |
| **Rebuild Guide (重构指南)** | 从零开始重构系统的规范 |
| **Dependency Graph (依赖图)** | prompt 之间或代码模块之间关系的映射 |
| **Design Pattern (设计模式)** | 在代码中检测到的循环出现的架构解决方案 |
## 扩展框架
### 添加新 Prompt
1. 遵循标准的 prompt 模板结构：
- 标题、阶段、依赖项、输入、输出、工作量
- MISSION 部分
- PREREQUISITES 部分
- SYSTEM PROMPT 部分（可执行指令）
- EXECUTION INSTRUCTIONS 部分
- OUTPUT SPECIFICATION 部分
- QUALITY GATE 部分（带有通过/失败标准）
- HANDOFF 部分（向依赖 prompt 传递的内容）
2. 更新依赖图 (`PROMPT_DEPENDENCY_MAP.md`)
3. 将新 prompt 添加到 `MASTER_INDEX.md`
4. 如有需要，更新 `VALIDATION_CHECKLISTS.md`
### 适配特定领域
- 该框架在设计上是语言无关的
- 对于特定于 AI 的系统，启用阶段 5（由框架自动检测）
- 对于嵌入式系统，在新的阶段中或作为替换添加特定领域的 prompt
- 对于数据 pipeline，强调数据流 (P11) 和事件工作流 (P23)
### 常见陷阱
- **过早编写文档：** 在分析完成之前不要编写输出
- **分析浅尝辄止：** 每个 prompt 必须达到深度，而不仅仅是覆盖范围
- **上下文丢失：** 在 prompt 之间使用结构化的移交部分
- **绕过质量关卡：** 绝不跳过质量关卡 —— 它们是框架的免疫系统
## 贡献指南
该框架被设计为一个持续演进的项目。欢迎任何能够改善其覆盖范围、准确性、深度或可扩展性的贡献。
### 贡献准则
1. 保持模块化架构 —— 每个 prompt 必须只处理一个关注点
2. 保留依赖结构 —— 使用任何更改更新 `PROMPT_DEPENDENCY_MAP.md`
3. 所有 prompt 必须包含质量关卡 —— 没有关卡，不予合并
4. 保持向后兼容性或记录破坏性变更
5. 遵循标准的 prompt 模板结构
6. 根据需要更新 `MASTER_INDEX.md` 和 `GLOSSARY.md`
7. 将图表模板保留在 `DIAGRAM_TEMPLATES.md` 中并保持一致使用
### 扩展方向
- **新阶段：** 为嵌入式系统、游戏或固件等领域添加专门的阶段
- **特定语言的下钻：** 为特定语言生态系统创建聚焦的 prompt
- **工具集成：** 添加用于分析 Docker、Kubernetes、Terraform 等的 prompt
- **合规性覆盖：** 为法规合规性分析添加 prompt（SOC2, HIPAA, PCI-DSS）
- **侧重安全的变体：** 针对安全审计用例进行扩展
## 许可证
本项目目前未授权。保留所有权利。
*企业级逆向工程 Prompt 框架 v1.0 —— 36 个 prompts，9 个阶段，12 个基础设施文件。零依赖。极致深度。*
标签：AI智能体, 云资产清单, 代码分析, 凭证管理, 提示词框架, 自动化文档, 逆向工程, 防御加固