古法编程

防止重复造轮子的关键在于让 AI 助手先查资料再写代码。Everything Claude Code 通过集成 Search First Skill，自动激活 Researcher Agent 并行检索 npm、PyPI、MCP 等生态，并结合决策矩阵推荐最佳方案。配合 Iterative Retrieval 的渐进式检索循环和 Documentation Lookup 的实时文档获取，形成一套从“广泛搜索”到“精准聚焦”再到“文档验证”的闭环工作流，确保在依赖现有成熟方案的前提下高效编码。

搜索先行与渐进式检索：防止重复造轮子的 AI 编程工作流

在使用 Claude Code、Codex、Cursor 等 AI 编程助手时，最隐蔽的效率陷阱往往不是写代码本身，而是在不该写代码的地方写了代码。团队中不断涌现的重复工具函数、忽略现有 MCP 服务而自建的轮子、依赖过时 API 文档导致的构建错误，都在无声地消耗工程资源。

Everything Claude Code 体系针对这一核心痛点，设计了一套以 Search First 为核心，辅以 Iterative Retrieval 和 Documentation Lookup 的标准化工作流。这套流程让 AI 助手从一个“沉默的编码者”转变为一位“懂得查阅资料的资深工程师”，在架构与计划阶段就最大化复用社区与团队已有的资产。

1. Search First：标准化“先搜索再编码”决策流程

Search First Skill 的核心理念是：在 AI 准备编写新功能、工具或集成依赖之前，强制执行一次系统性的资源检索。它不是简单的“谷歌搜索”，而是一个结构化的决策流程。

1.1 触发条件与场景

该 Skill 会在以下场景自动或建议激活：

  • 新功能开发：当需求描述为“添加一个XX功能”时。
  • 依赖集成：当需要“一个支持重试的HTTP客户端”时。
  • 工具抽象：当计划“实现一个配置文件校验器”时。
  • 架构规划：Planner Agent 或 Architect Agent 在分解任务或选型时会主动调用。

1.2 五步标准流程

Step 1：定义需求与约束 明确需要实现的功能点、目标语言、框架、兼容性要求。例如：“需要一个Node.js的Markdown死链检查工具，兼容ESM”。

Step 2：启动 Researcher Agent 并行检索 这是 Search First 的执行引擎。Researcher Agent 会并行发起多路检索：

  • 包管理器：搜索 npm、PyPI 上的相关库。
  • AI 能力库：检查项目内已有的 Claude Code Skills 或 MCP 服务。
  • 代码仓库：扫描本地代码库或关联的 GitHub 仓库，查找已有实现。
  • 模板与示例：寻找社区维护的模板项目。

Step 3：多维度评估与打分 对每个检索到的候选方案，进行结构化评估。评估标准包括：

  • 功能匹配度：是否直接满足核心需求？
  • 维护活跃度：最近更新时间、Issue 解决速度。
  • 社区与文档：Star 数、文档完整度、示例代码。
  • 依赖与许可证：依赖树是否健康？许可证是否兼容？
  • 打分示例：textlint-rule-no-dead-link（评分：功能 9/10，维护 8/10，文档 9/10）

Step 4：应用决策矩阵 基于评估结果，做出明确决策：

  • Adopt（采用）：方案完全匹配且维护良好，直接安装使用。例如：npm install textlint-rule-no-dead-link。
  • Extend（扩展）：方案部分匹配，安装后进行轻量封装或配置。例如：安装 ajv-cli，再编写项目专用的 JSON Schema。
  • Compose（组合）：单个方案不完整，组合多个小库。例如：使用 got 配合其 retry 插件。
  • Build（构建）：确认无合适现有方案，且自定义能带来独特价值时，才在参考已有设计的基础上自行实现。

Step 5：实施方案与文档化 根据决策安装包、配置 MCP 服务或编写最小化自定义代码，并更新项目依赖文件与团队文档。

1.3 快速自查清单（Inline Check）

对于简单需求，可遵循以下快速路径：

  1. rg / grep 检索本地仓库。
  2. 在 npm/PyPI 搜索对应关键词。
  3. 检查 Claude Code Skills 列表或 MCP 服务目录。
  4. 在 GitHub 搜索相关模板或项目。

2. Iterative Retrieval：渐进式上下文检索循环

当任务复杂（如大规模重构、跨模块调试）时，子 Agent 往往不知道自己需要哪些上下文文件。一次性塞入全部内容会超出 token 限制，而只给少量信息又会导致任务失败。Iterative Retrieval Pattern Skill 通过一个最多 3 轮的“检索-评估-精炼”循环解决此问题。

2.1 四阶段循环流程

阶段一：DISPATCH（初始广泛检索） 以宽泛的关键词和文件模式进行初次检索，确保覆盖面。

// 初始查询条件
const query = {
  patterns: ['src/**/*.ts', 'lib/**/*.ts'],
  keywords: ['authentication', 'user'],
  excludes: ['*.test.ts']
};

阶段二：EVALUATE（相关性评估与打分） 对每个检索结果进行 0-1 分的相关性评估，并识别信息缺口。

  • 评分标准：高（0.8-1.0）、中（0.5-0.7）、低（0.2-0.4）、无（0-0.2）。
  • 评估示例：auth.ts (0.9) —— 直接实现目标功能；user.ts (0.3) —— 仅包含部分关联数据。

阶段三：REFINE（精炼检索条件） 根据评估结果，动态调整下一轮检索：

  • 补充关键词：如第一轮发现项目用“throttle”而非“rate limit”。
  • 排除低相关路径：将 relevance < 0.2 的文件加入排除列表。
  • 聚焦信息缺口：明确指出还缺少什么上下文。

阶段四：LOOP（循环迭代） 以精炼后的条件继续检索，直到满足终止条件（高相关文件 ≥3 且无关键信息缺口，或已达最大循环次数）。

// 简化的循环逻辑
for (let cycle = 0; cycle < maxCycles; cycle++) {
  const candidates = await retrieveFiles(query);
  const evaluation = evaluateRelevance(candidates, task);
  if (evaluation.highRelevance.length >= 3 && !evaluation.hasCriticalGaps) {
    return evaluation.highRelevance; // 终止循环
  }
  query = refineQuery(evaluation, query); // 精炼条件
}

2.2 实战输出示例

任务： “修复认证 token 过期 bug”

  • Cycle 1：搜索“token”，“auth”，“expiry”。找到 auth.ts (0.9), tokens.ts (0.8)。精炼新增“refresh”，“jwt”关键词。
  • Cycle 2：用新条件检索，找到 session-manager.ts (0.95)。信息已充足，返回最终上下文文件列表。

3. Documentation Lookup：通过 Context7 MCP 获取实时文档

为了避免 AI 助手依赖其过时的训练数据来解答库/框架问题，Documentation Lookup Skill 集成了 Context7 MCP 服务，实现文档的实时检索。

3.1 使用流程

Step 1：解析库标识 调用 resolve-library-id MCP 工具，将库名（如“Next.js”）解析为 Context7 兼容的库 ID（如 /vercel/next.js）。

resolve-library-id({
  libraryName: "Next.js",
  query: "如何配置 middleware？"
})

Step 2：筛选最佳匹配 从结果中，根据名称匹配度、Benchmark分数、来源信誉和版本号选择最优库 ID。

Step 3：查询最新文档 使用选定的库 ID 和原始问题，调用 query-docs 工具获取最新的官方文档片段和代码示例。

query-docs({
  libraryId: "/vercel/next.js",
  query: "如何配置 middleware？"
})

注意：每次问题最多调用 3 次（包括 resolve 和 query），避免滥用。

Step 4：生成准确回答 基于 Context7 返回的实时内容生成回答，确保 API 用法、配置方法与最新官方文档一致，并会标注版本信息。

4. 工作流协同与最佳实践

这三个 Skill 并非独立运作，而是构成了一个“调研-检索-文档验证”的闭环。

  • Search First 在 Adopt/Extend 决策后，可自动触发 Documentation Lookup 来查阅所选库的详细用法。
  • Iterative Retrieval 在检索过程中，可随时调用 Documentation Lookup 来理解某个函数或 API 的最新用法。
  • Planner Agent 或 Architect Agent 在规划时，会先运行 Search First 进行技术选型，再为后续子任务配置 Iterative Retrieval 的检索策略。

快速自查清单（开发准备阶段）

  1. 本地实现？ – rg 检索。
  2. 社区包？ – npm/PyPI 搜索。
  3. 已有能力？ – 查 Skills 和 MCP 列表。
  4. 模板/示例？ – GitHub 搜索。
  5. 文档准确？ – Context7 验证。

避免的反模式

  • 直接写代码不查资料：这是产生技术债务的最快路径。
  • 依赖模型记忆：对于快速迭代的库，这几乎必然导致错误。
  • 一次性检索全部文件：浪费 token，且难以聚焦，应使用渐进式检索。
  • 忽视评估打分：仅凭感觉选择方案，容易引入不维护的依赖。

FAQ

Q: 执行 Search First 流程会不会拖慢开发进度？ A: 短期看似乎多了一个步骤，但从全周期看，它能避免后期大量的返工、重构和维护成本，整体效率是提升的。

Q: 什么时候才应该选择“Build”（自定义实现）？ A: 仅在彻底调研后，确认社区和团队内均无合适方案，且自定义能解决核心痛点、并有明确维护计划时。

Q: 如何控制因采用众多小包导致的“依赖膨胀”？ A: 在评估阶段，重点关注候选包的依赖树深度和许可证。优先选择轻量、主流、单一职责的库，并定期审计项目依赖。