内容
# 重用前生成
[](https://www.npmjs.com/package/reuse-before-generate)
[](https://github.com/aradar46/reuse-before-generate/actions/workflows/ci.yml)
[](LICENSE)
[](https://glama.ai/mcp/servers/aradar46/reuse-before-generate)
**你的想法可能已经存在。 在构建之前先了解，而不是之后。**
通常情况下，你有一个想法。 你询问一个前沿模型，它告诉你这个领域是开放的，人们会喜欢它。 所以你告诉你的代理构建它，它编写了数千行代码，但实际上已经有人做了。
我也遇到了这种情况。 我一直遇到相同的失败的Android CI构建，等待重新运行，再次遇到失败。 我想：应该有人能够暂停构建并进入其中的shell。 我问了一个AI，它告诉我这是一个好主意，于是我构建了 [fermata](https://github.com/aradar46/fermata)。
但后来我发现了 `action-tmate`。 它有 3,566 个星标，功能完全相同，已经存在多年了。
这个服务器是我希望运行的检查。 在构建之前，让你的代理检查：
> 在构建之前 —— 这已经存在：
>
> 1. **action-tmate** (3,566★，今天更新) —— “通过使用tmate调试你的GitHub Actions以获取运行器系统的访问权限。”
>
> 积极维护，广泛使用。 你想试试，还是有其他不同之处？
有时答案确实是“我的不同，我继续”。 有时可以节省你一个周末。 无论如何，你可以在十秒内找到答案，而不是之后。
为什么要费心：减少浪费的时间，减少被遗弃的项目，减少生成已经存在的代码所消耗的精力。 Jenna Pederson在 [*你能构建它，但你应该吗？*](https://dev.to/jennapederson/you-can-build-it-should-you-9e0) 中很好地阐述了一般情况 —— AI减少了曾经迫使你思考某件事情是否值得构建的摩擦力。
诚实地说，这个工具也没能通过自己的测试！ 但我必须构建它才能知道。 希望它能帮助我避免再次这样做。
## 安装
无需API密钥，无需账户，无需配置。
```bash
claude mcp add reuse-before-generate -- npx -y reuse-before-generate
```
或将其安装到用户范围，以便在任何地方加载：
```bash
# claude mcp remove reuse-before-generate
claude mcp add -s user reuse-before-generate -- npx -y reuse-before-generate
```
然后开始一个新的会话并在自己的想法上尝试 —— 你即将构建的那个。
或者自己将其添加到 `.mcp.json` 中 —— 这在Cursor、Claude Desktop和任何其他MCP客户端中都有效：
```json
{
"mcpServers": {
"reuse-before-generate": {
"command": "npx",
"args": ["-y", "reuse-before-generate"]
}
}
}
```
**可选但推荐：** 添加GitHub令牌。 没有它，GitHub限制你每分钟搜索10次；有它，则限制为30次。
```json
{
"mcpServers": {
"reuse-before-generate": {
"command": "npx",
"args": ["-y", "reuse-before-generate"],
"env": { "GITHUB_TOKEN": "ghp_your_token_here" }
}
}
}
```
### 从源代码运行
```bash
git clone https://github.com/aradar46/reuse-before-generate
cd reuse-before-generate
npm install && npm run build
claude mcp add reuse-before-generate -- node "$PWD/dist/index.js"
```
## 自动执行
默认情况下，你的代理只有在你要求时才会检查。 要使其每次都检查，请在你的 `CLAUDE.md` （或 `.cursorrules`）中粘贴以下内容：
```markdown
在搭建新项目或重要新模块之前，先调用 `check_before_building`。 如果它找到一个维护良好的替代方案，并且该方案确实能满足需求，请告诉我并询问是否应该扩展该方案，而不是从头开始构建。
```
这一段是工具的重点。 没有它，检查只会在你记得要求时进行。
## 它真的有效吗？
它是经过测量的，而不是靠感觉。 有12个测试用例，具有已知的正确答案 —— “从描述中查找 `gitleaks`”，诸如此类。 搜索结果会根据正确答案的排名进行评分。
当前分数：
| | |
|---|---|
| 在前10名中找到正确的工具 | **11 of 11** |
| 在前5名中找到正确的工具 | 10 of 11 |
| 在没有现有工具时杜撰工具 | 从未发生 |
最后一行最为重要。 一个报告所有内容都匹配的工具是无用的，所以一个测试用例描述了没有实际工具可以实现的功能。 它正确地返回了没有结果。
详细信息，包括它仍然失败的地方，参见 **[docs/findings.md](docs/findings.md)**。
## 设置
有一个值得了解的设置： **`GITHUB_TOKEN`**。 没有它，GitHub允许每分钟搜索10次；有它，则允许每分钟搜索30次。 在 [安装](#安装) 中所示的 `env` 块中设置它。
它还在 `~/.reuse-before-generate/events.jsonl` 中维护一个本地使用计数 —— 一个随机ID，一个时间戳和返回的结果数。 除了查看或禁用它之外，什么也不会被发送。 参见 [本地状态](docs/how-it-works.md#local-state) 以查看或禁用它，以及 [所有环境变量](docs/how-it-works.md#environment-variables) 以获取其他信息。
## 它仍然存在的不足
诚实的列表，因为你会遇到这些：
- **糟糕的搜索词会错过真正的工具。** 如果你将JSON查看器描述为“pretty-printer”，它可能会找不到任何结果 —— 真正的工具都称为“查看器”。 代理被告知要考虑维护者如何描述自己的工具，但它并不总是能正确理解。
- **非常小或奇妙命名的仓库很难找到。** GitHub自己的搜索功能会忽略它们。 有一个专门的搜索通道来帮助解决这个问题，但它并没有完全解决这个问题。
- **“维护”仅意味着“在去年被触及过”。** 它不会检查问题是否得到回答或项目是否真正健康。
所有这些都经过了测量，并在 [docs/findings.md](docs/findings.md) 中有详细记录。
## 更多
- [工作原理](docs/how-it-works.md) —— 流程，以及服务器为什么从不调用LLM本身
- [发现](docs/findings.md) —— 已经测量了什么，还有什么仍然存在问题
- [贡献](docs/how-it-works.md#development) —— 测试，本地CLI，评估
## 许可证
MIT
