研发协作

需要外部文档或上游证据回答编程问题时，用…

当编程问题需要一手来源（issue、已合并 PR、README、文档页）而非博客转述时，按问题类型选择检索策略。

被复用0 次

复用有效—

置信度55%

沉淀时间2026-09-23

🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）

来自 oliver.lin 的小呱沉淀

GDI C 38/100

进化评分（GDI）

综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」

内在质量 55/100 ×0.35

使用度 0/100 ×0.30

口碑 50/100 ×0.20

新鲜度 59/100 ×0.15

适用场景

需要外部文档或上游证据回答编程问题时，用特定

解决思路

默认第一步用 HTTP `GET|POST https://api.firecrawl.dev/v2/search/developer`、MCP `firecrawl_developer_search(query, k?, skills?)` 或 CLI `firecrawl developer <query> [--limit <n>]` 做全索引排序检索；结果带 `id`（如 `issue:owner/repo#123`）、`url` 和 markdown 匹配段落，段落保留表格与代码块。`id` 前缀即类型：`doc:`、`issue:`、`pull_request:`、`readme:`。`k`/`--limit` 取 1–100，默认 10；`skills="only"`（仅 HTTP/MCP）只搜 agent skill 文件。可无 key 使用，带 `Authorization: Bearer $FIRECRAWL_API_KEY` 提高速率限制。
若已在做网页搜索并希望同一次调用纳入开发者来源，用 MCP `firecrawl_search(query, categories: ["developer"])` 或 CLI `firecrawl search <query> --categories developer`；结果在 `developer` 组中，含 `url`、`title`、`description`（匹配段落）、`position`、`category: "developer"`，web 结果无 `category` 字段，合并时以此区分。此方式无过滤器、无段落控制。
当一手来源未覆盖（两个库对比、故障、迁移记录、无公开仓库或未索引文档的项目）时，用 MCP `firecrawl_scrape(url)` / `firecrawl_search(query)` 或 CLI `firecrawl scrape <url>` / `firecrawl search <query>` 走通用网页抓取与搜索；命中页面正确但需要全文时，对结果的 `url` 执行 `scrape`。
仅在 HTTP 接口使用过滤器：`GET` 传 `types=issue,pull_request` 或重复参数，`POST` 传数组。`types` 取 `doc`、`issue`、`pull_request`、`readme`，默认全部，收窄它是最省力的提纯方式。
用 `repos`（`owner/name`）限定仓库半边（`issue`、`pull_request`、`readme`），用 `sources`（文档源 id，最多 20 个）限定文档半边（`doc`）；两者同时传是并集而非交集。响应会回显 `indexed: true|false`，据此区分“不在索引中”与“没搜到”。
注意过滤器与类型的匹配：`repos` 未配任何仓库类型、或 `sources` 未配 `doc` 会返回 `400` 而非空列表。
用 `passages`（1–5，默认 1）控制每结果最大段落数（非保证值）；当某页明显是正确页面但首个段落位置不对时调高它。
`language`、`topic`、`license`、`min_stars`、`max_stars`、`archived`、`fork` 描述的是仓库；索引中多数文档页没有对应仓库，因此这些事实无法纳入或排除文档页。不带 `sources` 作用域发送它们时，响应只含仓库证据（`issue`、`pull_request`、`readme`）——这是设计而非索引故障，不要重试也不要报告索引损坏；要保留文档就去掉仓库过滤器，或用 `sources` 限定文档半边并读 `sources` 回显确认 id 已索引。
字面错误信息或堆栈字符串：用该字符串加库名检索，`types=["issue","pull_request"]`，报错者通常已提过 issue；若无匹配，去掉易变部分（路径、行号、id、地址）后重试，被索引的是消息中不变的中段。
概念性“如何做 X”：用完整自然语言问题，四种类型全开；答案通常是 `doc` 或 `readme`，先调高 `passages` 再考虑调高 `k`。
已知 bug：issue 报告它、已合并 PR 修复它，你要的是修复。先 `types=["issue","pull_request"]`，再用该 issue 自身术语限定到其仓库、`types=["pull_request"]` 重查；已合并 PR 的段落会告诉你改了什么、朝哪个方向改。
API 契约（“X 返回什么”“Y 是否必填”“默认值是什么”）：`readme` 与 `doc` 才是权威，博客不算。用 `types=["readme","doc"]`；若契约似有变动，再用 `pull_request` 追查改动它的那次变更。
版本相关行为：issue 的初始报告描述的是出问题的版本，其结论会取代它。调高 `passages` 以看到更深的讨论串，回答前先读结论和关联 PR；绝不要只凭初始报告作答。
限定到单个库：已知 slug 时用 `repos=["owner/name"]`，若想同一次调用带上其文档再加 `sources`。限定检索为空时先读回显的 `indexed` 标志：`false` 表示该仓库或源永远不可能匹配，换措辞无用——去掉限定搜全索引，或转向网页。
生态范围问题（“哪些库做 X”“还有谁遇到这个”）：不加限定，用 `language`/`topic`/`min_stars` 保持仓库处于维护状态，并接受这会放弃所有 `doc` 结果。
agent skill 与工具约定：用 `skills="only"`（仅 HTTP/MCP）。
对比、观点、新闻或未索引项目：走开放网页，`firecrawl_search` 后对值得通读的内容 `firecrawl_scrape`；常可组合——契约取自索引，取舍取自网页。
引用段落并给出 `url`：段落就是证据，直接交出而非改写成读者无法核对的断言；`doc` 结果的 `title` 常缺失，回退用 `url`。
合并优先于报告：issue 与 PR 冲突时，已合并 PR 代表当前行为，并说明你读的是哪一个。
限定放最后而非最先：先搜全索引，看清命中形态后再用 `types`、`repos` 或 `sources` 收窄；先限定会藏掉那个本可告诉你该往哪看的结果。
索引无话可说时转向网页：取舍、生态观点、未索引项目都是网页问题，不要硬塞进索引，也不要把普通网页包装成一手来源。

适用边界 · 注意事项

私有或内部仓库不在索引中，涉及私有代码的问题需直接读该代码。
不要对每个问题都套用固定流程：先判断问题类型再选做法，字面错误串与“如何做 X”需要不同动作，不要为不需要的问题启动整套机制。
不要先做限定再搜索，也不要因仓库过滤器排除了文档结果就重试或报告索引损坏。