研究优先工作流（Search-First Workflow）
概述
研究优先工作流系统化了"在编写自定义代码之前搜索现有解决方案"的方法论。它要求在实现任何新功能之前，先搜索现有工具、库和模式，然后根据搜索结果做出"直接采用"、"扩展包装"或"自行构建"的决策，避免重复造轮子。
二、工作流程
+---------------------------------------------+
| 1. 需求分析 |
| 定义需要什么功能 |
| 识别语言/框架约束 |
+---------------------------------------------+
| 2. 并行搜索（研究者代理） |
| +----------+ +----------+ +----------+ |
| | npm / | | MCP / | | GitHub / | |
| | PyPI | | Skills | | Web | |
| +----------+ +----------+ +----------+ |
+---------------------------------------------+
| 3. 评估 |
| 评分候选方案（功能、维护、社区、 |
| 文档、许可证、依赖） |
+---------------------------------------------+
| 4. 决策 |
| +---------+ +----------+ +---------+ |
| | 直接 | | 扩展 | | 自行 | |
| | 采用 | | /包装 | | 构建 | |
| +---------+ +----------+ +---------+ |
+---------------------------------------------+
| 5. 实施 |
| 安装包 / 配置 MCP / |
| 编写最少自定义代码 |
+---------------------------------------------+
三、决策矩阵
| 信号 | 行动 |
|---|---|
| 精确匹配，维护良好，MIT/Apache 许可 | 直接采用 -- 安装并直接使用 |
| 部分匹配，基础良好 | 扩展 -- 安装 + 编写薄包装层 |
| 多个弱匹配 | 组合 -- 组合 2-3 个小包 |
| 没有找到合适的方案 | 自行构建 -- 编写自定义代码，但基于研究成果 |
四、使用方式
快速模式（内联）
在编写工具函数或添加功能之前，心理快速检查：
- 这是一个常见问题吗？ -> 搜索 npm/PyPI
- 有对应的 MCP（Model Context Protocol）吗？ -> 检查
~/.claude/settings.json并搜索 - 有对应的技能（Skill）吗？ -> 检查
~/.claude/skills/ - 有 GitHub 模板吗？ -> 搜索 GitHub
完整模式（代理）
对于非平凡的功能，启动研究者代理：
Task(subagent_type="general-purpose", prompt="
研究以下需求的现有工具: [描述]
语言/框架: [语言]
约束条件: [任何约束]
搜索范围: npm/PyPI, MCP 服务器, Claude Code 技能, GitHub
返回: 结构化对比及推荐
")
五、按类别搜索快捷参考
开发工具
| 类别 | 推荐工具 |
|---|---|
| 代码检查（Linting） | eslint, ruff, textlint, markdownlint |
| 格式化（Formatting） | prettier, black, gofmt |
| 测试（Testing） | jest, pytest, go test |
| 提交前检查（Pre-commit） | husky, lint-staged, pre-commit |
AI/LLM 集成
| 类别 | 推荐工具 |
|---|---|
| Claude SDK | 使用 Context7 获取最新文档 |
| 提示管理 | 检查 MCP 服务器 |
| 文档处理 | unstructured, pdfplumber, mammoth |
数据与 API
| 类别 | 推荐工具 |
|---|---|
| HTTP 客户端 | httpx（Python）, ky/got（Node） |
| 数据验证 | zod（TypeScript）, pydantic（Python） |
| 数据库 | 优先检查是否有 MCP 服务器 |
内容与发布
| 类别 | 推荐工具 |
|---|---|
| Markdown 处理 | remark, unified, markdown-it |
| 图片优化 | sharp, imagemin |
六、与其他组件的集成
与规划代理（Planner Agent）集成
规划代理应在架构审查阶段之前调用研究者：
- 研究者识别可用工具
- 规划者将工具纳入实现计划
- 避免在计划中"重新发明轮子"
与架构师代理（Architect Agent）集成
架构师应就以下方面咨询研究者：
- 技术栈选型决策
- 集成模式发现
- 现有参考架构
与迭代检索技能集成
结合使用实现渐进式发现：
- 第 1 轮：广泛搜索（npm, PyPI, MCP）
- 第 2 轮：详细评估顶级候选方案
- 第 3 轮：测试与项目约束的兼容性
七、实际示例
示例 1："添加死链检查"
需求: 检查 Markdown 文件中的断开链接
搜索: npm "markdown dead link checker"
发现: textlint-rule-no-dead-link (评分: 9/10)
行动: 直接采用 -- npm install textlint-rule-no-dead-link
结果: 零自定义代码，经过实战检验的解决方案
示例 2："添加 HTTP 客户端包装器"
需求: 具有重试和超时处理的弹性 HTTP 客户端
搜索: npm "http client retry", PyPI "httpx retry"
发现: got (Node) 带重试插件, httpx (Python) 内置重试
行动: 直接采用 -- 直接使用 got/httpx 配置重试
结果: 零自定义代码，生产环境验证过的库
示例 3："添加配置文件检查器"
需求: 根据模式（Schema）验证项目配置文件
搜索: npm "config linter schema", "json schema validator cli"
发现: ajv-cli (评分: 8/10)
行动: 采用 + 扩展 -- 安装 ajv-cli，编写项目特定的模式
结果: 1 个包 + 1 个模式文件，无自定义验证逻辑
八、反模式
| 反模式 | 说明 |
|---|---|
| 直接编码 | 不检查是否存在现成方案就编写工具函数 |
| 忽略 MCP | 不检查是否已有 MCP 服务器提供所需功能 |
| 过度自定义 | 对库进行过度包装，使其失去原有优势 |
| 依赖膨胀 | 为一个小功能安装庞大的包 |