企业官网建设流程全解析

REA 贡献指南：AI 逆向工程 Agent 项目，7 步走到第一个 PR

【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea

REA 是一个让 AI 代理完成逆向工程的开源项目：它把 Hopper、Ghidra、浏览器、.NET 等分析工具统一成一套 CLI 加 MCP 工具集（MCP 即 Model Context Protocol，连接 AI 代理与外部工具的标准协议）。本文带你走读完代码、搭环境、选任务、跑验证到提交 PR 的完整流程，不需要先懂逆向工程。

🗺️ 五分钟读懂项目地形：先读哪几个文件、目录怎么导航

这一节帮你用最快速度建立全局地图，避免在几千个文件里迷路。先读三个文件：README.md 讲项目是什么、怎么快速用起来；CONTRIBUTING.md 讲贡献规则与 PR 要求；AGENTS.md 讲仓库必须遵守的不变量。重点记住最后一份里的依赖方向即可。

目录导航可以按职责切：

• src/：生产代码，按领域切分，如domain/（无副作用的纯逻辑）、contracts/（调用方可见的 schema）、各 provider 目录（hopper/、ghidra/、browser/等）、application/（共享工作流）、server/（MCP 请求处理）
• docs/：全部用户与开发者文档
• tests/：七层测试的归属地
• scripts/：CI 与验证脚本
• bridge/：运行在外部引擎内部的桥接脚本（Hopper 的 Python、Ghidra 的 Java）

架构一句话：依赖严格向内流，domain 语义与契约 → provider 适配器 → 共享应用工作流 → CLI/MCP 适配器，provider 专属协议不允许渗入上层。完整接线图见 docs/architecture.mermaid。

🧱 环境先搭对：版本怎么锁、装完先跑什么

这一节解决「第一次 clone 下来，哪些命令按什么顺序敲」。开发工具链锁死在两个文件：.nvmrc固定 Node.js 24.22.1，package.json的packageManager固定 npm 11.16.0。先切版本再装依赖：

git clone https://gitcode.com/GitHub_Trending/rea2/rea # 克隆仓库 cd rea nvm use # 切换到 .nvmrc 锁定的 Node 版本 npm ci # 按锁文件安装精确依赖，并准备 Husky 钩子（不构建） npm run check:fast # 首次自检：缓存的类型检查 + lint

最后一条就是你的环境体检：过了就可以开始改代码。日常迭代不必全量构建；只有需要独立 CLI 或 MCP server 时才执行npm run build:cached。

🧩 选一块属于你的砖：五类贡献方向，门槛从低到高

你不需要熟悉整条逆向工具链就能开始。CONTRIBUTING.md 明确欢迎以下方向，按门槛从低到高排：

1. 文档修复：发现表述不清或误导性的用户指引，值得单独纠正；纯外观类建议应汇总到一个 issue，而不是拆成多个 PR。
2. 测试补充：给薄弱模块补回归场景；添加或移动测试后要跑npm run verify:test-discovery。
3. 翻译：docs/readme/ 的多语言 README 与 website/locales/ 的站点文案是两套独立来源，动手前先确认改哪一份。
4. 逆向工作流改进：优化既有 provider（负责对接某个具体分析引擎的适配层）的工作流脚本，provider 专属协议留在适配器层。
5. 新工具与功能开发：新增 MCP 工具需遵循 docs/tool-design.md，canonical contracts 与生成的工具目录必须同步维护。

涉及契约或架构的大改动，必须先开 Issue 说清预期范围并关联讨论，对齐后再写代码。REA 的主要交流阵地在官方 Discord 服务器（入口写在 README.md）：提问答疑、展示成果、大改动前对齐都发生在那里。

让每笔改动都配得上它的评审与维护成本——这是社区判断一个 PR 是否受欢迎的底层标准。

🔬 改动之后怎么自证没坏：七层测试加一条红线

测试哲学是「用最能证明行为的证据」，目录即归属。从浅到深七层：

红线：真实 provider（Hopper、Ghidra、IDA 等）的行为声明，必须走对应的npm run verify:*真实验证通道，例如 macOS 上的npm run verify:hopper、Linux 演示 runner 上的npm run verify:hopper:linux——打包检查或模拟 provider 的 mock 测试不能冒充平台级证据。

完整确定性测试套件与覆盖率由 CI 兜底，门槛为语句 65%、分支 60%、函数 60%、行 68%；src/domain/子目录更严，分别为 80%、75%、75%、80%。

🚪 出门前的最后一道门：提交自检清单与命令对照

把这张清单贴在提交流程旁边，逐条过：

1. 对齐大改动——契约或架构调整，范围先写在 issue 里。
2. 保持改动内聚——依赖沿domain → contracts → provider → application → server方向内流，provider 专属协议留在适配器层，共享 CLI/MCP 工作流放应用层。
3. 跑相关测试与npm run check；动了契约或生成元数据，再加跑npm run docs:check。
4. 添加或移动测试后，运行npm run verify:test-discovery。
5. 新增 MCP 工具时维护好生成的工具目录，canonical contracts 与 catalog 不能只改一边。
6. 在 PR 描述里写清两件事：行为变化是什么、你跑过哪些检查；涉及真实 provider 时说明执行了哪条verify:*通道。
7. 永远不要提交二进制文件、凭据、dist/、node_modules/及本地规划产物。

按场景挑命令：

注意test:changed的选择基于导入图，可能漏掉运行时注册、bridge 和生成数据——涉及边界行为时要显式补跑相关边界测试。

📚 进阶：文档站怎么维护、版本怎么发出去

文档站是基于 docs/ 目录 Markdown 的 VitePress（基于 Markdown 生成文档站的工具）站点：npm run docs:dev启动本地热编辑，npm run docs:build校验生产构建与链接，每个 PR 都会跑npm run docs:check。站点导航在docs/.vitepress/config.ts，指南内链接保持相对路径。

翻译维护有两套独立来源：README 各语言版按website/locales/languages.json中的路径找文件编辑；网站文案改website/locales/<language>/messages.po里的msgstr。

发布由维护者按 docs/releasing.md 的 checkpoint 流程执行：main 分支的推送只会自动刷新 Release Please 的版本预览 PR，普通推送不能直接发包；可选的手动release/VERSION分支保留显式准备与发布，保证每个版本都经过完整验证。

❓ 新人常问的三个问题：先答掉再动手

不会写 TypeScript 也能贡献吗？可以。文档修复、测试补充、翻译都是受欢迎的贡献类型，很多贡献者就是从一条文档修复开始的。

本地测试全绿就等于功能正确吗？不一定。test:changed的选择只是反馈信号，不是完整证据；涉及边界或 provider 行为时要显式补边界测试和verify:*通道，完整套件与覆盖率由 CI 兜底。

不知道该先读哪份文档？贡献规则看 CONTRIBUTING.md，测试体系看 docs/testing.md，安装与 setup 看 docs/installation.md，MCP 工具设计看 docs/tool-design.md。

在这个项目里，一条精准的文档修复和一个聚焦回归测试，与一次大型重构一样被认真对待。别等「准备充分」才动手——先让一个小改动带着完整的验证证据走完一轮流程，剩下的只是重复。

【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea