企业官网建设流程全解析

REA 逆向工程 Agent 工具：让你的第一个 PR 顺利合并

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

REA（Reverse Engineer Anything，逆向工程任意目标）把 Hopper、Ghidra、IDA 和真实浏览器这类逆向工具收敛为一套 MCP 工具集，让 AI Agent 一路干到原生二进制层面。本地环境怎么把第一条检查命令跑通、仓库里每层测试各自证明了什么、提交 PR 前要走哪些关卡，下面按实操顺序讲清楚。

📌 先弄清 REA 是干什么的，以及去哪提问

架构上一句话概括：src/composition/里的生产工厂只负责构建 provider 而不启动引擎，各逆向工具的专有协议收在对应适配器里，共享的 CLI/MCP 工作流放在应用层，最终对外暴露为一组 MCP 工具。社区的日常阵地是 Discord 服务器，入口见 README.md：安装、provider 选型这类问题在这里问最快，你逆向出的结论也可以直接贴出来；打算动契约或架构级别的大改动前，建议先到那里把范围说清楚，别急着动手。

🛠️ 第一条检查命令的四步跑通流程

环境准备的最小目标是跑通npm run check:fast：

1. 把 Node 切到锁定版本——.nvmrc和package.json#packageManager各钉了一个（当前是 Node 24.18、npm 11.16），先执行nvm use；
2. 克隆仓库：git clone https://gitcode.com/GitHub_Trending/rea2/rea，进入 rea 目录；
3. npm ci装锁定依赖，顺带挂好 Husky hooks，此时不做编译；
4. npm run check:fast，即带缓存的类型检查加 lint，能过就算环境就绪。

只有当你需要单独拉起 CLI 或 MCP server 时才执行npm run build:cached，它会编译运行时并打包 skill；日常改源码看反馈即可，不必每轮都构建。

🧱 从单元测试到验收测试：每个目录各自证明了什么

docs/testing.md 的思路是用能证明行为的最强证据说话，按行为深度分了七层，目录就是边界。src/**/*.test.ts是模块层，只碰单个领域、服务或适配器的窄公开面，不起子进程也不开网络监听；tests/composition/是组合层，只验证不依赖具体 provider 的会话与注册表接线；tests/boundary/是边界层，每个用例恰好跨越文件系统、进程、网络、浏览器这类生产边界之一；tests/boundary/mcp/专门管 MCP 传输与工具契约；tests/acceptance/跑编译后的 CLI 或 MCP 完整旅程；tests/conformance/校验收各 provider 共享的契约；tests/evaluation/只覆盖确定性评分逻辑。

还有一条硬规则：涉及 Hopper、Ghidra、IDA、浏览器等真实工具的行为声明，必须走对应的npm run verify:*通道在真机上跑出来。mock 或录制式 provider 的测试只能证明 schema 漂移和失败投影这类事，不允许充当"引擎确实可用"的证据。

⌨️ 日常开发高频命令：四条覆盖 90% 场景

• npm run test:local——只跑被改动源文件的测试且不构建，改代码时最常用；
• npm run test:focused -- src/config.test.ts——按精确路径跑指定测试文件，路径对不上会直接报错；
• npm run test:changed——相对origin/main的选择受影响测试，提交前用它过一遍；
• npm run check:fast——缓存版类型检查与 lint，每次提交前的底线动作。

大范围改动或排查 CI 失败时，才需要跑全量本地门禁npm run check:pr，它包含完整静态检查、全量测试、docs 校验和重复代码扫描，耗时明显更长。

🚦 从分支到合并：一份不会被秒退的清单

• 先开 Issue 再动手：契约或架构级的大改动，先在 issue 里讲清范围和关联讨论。评审者要先确认方向，再看代码，没对齐的改动大概率白写。
• 改动保持内聚：provider 专有协议留在适配器里，共享 CLI/MCP 工作流放应用层，别把两类东西搅在一个文件里。导入边界有 lint（verify:module-boundaries），方向混了会直接挂。
• 按改动选检查：相关测试加npm run check是基础；动了契约或生成元数据补npm run docs:check；动打包加npm run verify:package和npm pack --dry-run。检查要和行为对得上，少跑多跑都要有理由。
• PR 描述写清验证情况：跑了哪些检查、哪条真实 provider 通道在哪个主机上跑过、还有哪些覆盖没跑。CI 负责完整确定性套件与覆盖率，本地只是反馈，主动交代比被追问体面。
• 这些东西不进仓库：二进制文件、dist/构建产物、node_modules/、凭据、provider 项目文档、本地规划产物。生成的输出（如docs/public/product-catalog.json）由 CI 校验，改的是源契约然后重新生成。

另外两个固定动作：新增或移动测试后跑npm run verify:test-discovery；新增 MCP 工具时遵循 docs/tool-design.md 并维护生成的工具目录。

文档站如何热更，发布分支为何冻结

文档站是 VitePress，源文件就是docs/目录下的 Markdown：npm run docs:dev本地热编辑，npm run docs:build校验生产构建与链接。发布由维护者按 docs/releasing.md 执行，main 的推送只会刷新版本预览 PR，真正的发包从冻结的release/VERSION分支出发，普通 main 推送发不出包。

🕳️ 入坑前看一眼三个最常见的误会

• 误会：本地全绿就是功能正确。表现：只跑了 changed 选择，边界和 provider 行为上的回归漏掉，等 CI 全量套件亮红灯。正解：把变更选择当提示而非结论，显式补跑对应的tests/boundary/用例，完整覆盖交给 CI 判定。
• 误会：mock 过了就说"引擎已验证"。表现：录制式集成测试全绿，PR 里却写 Hopper/Ghidra 行为已确认。正解：引擎类声明只有对应verify:*通道实跑后才有资格写，评审一定会追问你跑了哪条通道。
• 误会：加完测试直接提交。表现：新增或挪动测试文件后，发现目录与元数据不同步，CI 挂在不相干的地方。正解：提交前先跑npm run verify:test-discovery，lint 会顺带把模块边界查一遍。

安装与 provider 配置细节见 docs/installation.md。

最小可行贡献就一个：先修一条文档里的笔误，或给某个源文件补一个聚焦的单元测试，跑通check:fast加test:focused，把验证情况写进 PR 描述。走完这一圈最短闭环，再谈架构级的东西，评审体验会好很多。

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