mturac /search-first — 编码前先研究
系统化“在实现之前先寻找现有解决方案”的工作流程。
触发时机
在以下情况使用此技能：
- 开始一项很可能已有解决方案的新功能
- 添加依赖项或集成
- 用户要求“添加 X 功能”而你准备开始编写代码
- 在创建新的实用程序、助手或抽象之前
工作流程
┌─────────────────────────────────────────────┐
│ 1. 需求分析 │
│ 确定所需功能 │
│ 识别语言/框架限制 │
├─────────────────────────────────────────────┤
│ 2. 并行搜索（研究员代理） │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ npm / │ │ MCP / │ │ GitHub / │ │
│ │ PyPI │ │ 技能 │ │ 网络 │ │
│ └──────────┘ └──────────┘ └──────────┘ │
├─────────────────────────────────────────────┤
│ 3. 评估 │
│ 对候选方案进行评分（功能、维护、 │
│ 社区、文档、许可证、依赖） │
├─────────────────────────────────────────────┤
│ 4. 决策 │
│ ┌─────────┐ ┌──────────┐ ┌─────────┐ │
│ │ 采用 │ │ 扩展 │ │ 构建 │ │
│ │ 原样 │ │ /包装 │ │ 定制 │ │
│ └─────────┘ └──────────┘ └─────────┘ │
├─────────────────────────────────────────────┤
│ 5. 实施 │
│ 安装包 / 配置 MCP / │
│ 编写最小化自定义代码 │
└─────────────────────────────────────────────┘
决策矩阵
| 信号 | 行动 |
|---|---|
| 完全匹配，维护良好，MIT/Apache 许可证 | 采纳 — 直接安装并使用 |
| 部分匹配，基础良好 | 扩展 — 安装 + 编写薄封装层 |
| 多个弱匹配 | 组合 — 组合 2-3 个小包 |
| 未找到合适的 | 构建 — 编写自定义代码，但需基于研究 |
使用方法
快速模式（内联）
在编写实用程序或添加功能之前，在脑中过一遍：
- 这已经在仓库中存在吗？ → 首先通过相关模块/测试检查
rg - 这是一个常见问题吗？ → 搜索 npm/PyPI
- 有对应的 MCP 吗？ → 检查
~/.codex/settings.json并进行搜索 - 有对应的技能吗？ → 检查
~/.codex/skills/ - 有 GitHub 上的实现/模板吗？ → 在编写全新代码之前，先运行 GitHub 代码搜索以查找维护中的开源项目
完整模式（代理）
对于非平凡的功能，启动研究员代理：
任务（子代理类型="通用型"，提示="
研究现有工具用于：[描述]
语言/框架：[语言]
约束：[任何]
搜索：npm/PyPI、MCP 服务器、OpenAI Codex 技能、GitHub
返回：结构化对比与推荐
")
按类别搜索快捷方式
开发工具
- Linting →
eslint,ruff,textlint,markdownlint - Formatting →
prettier,black,gofmt - Testing →
jest,pytest,go test - Pre-commit →
husky,lint-staged,pre-commit
AI/LLM 集成
- Codex SDK → 使用 Context7 获取最新文档
- 提示词管理 → 检查 MCP 服务器
- 文档处理 →
unstructured,pdfplumber,mammoth
数据与 API
- HTTP 客户端 →
httpx(Python),ky/got(Node) - 验证 →
zod(TS),pydantic(Python) - 数据库 → 首先检查是否有 MCP 服务器
内容与发布
- Markdown 处理 →
remark,unified,markdown-it - 图片优化 →
sharp,imagemin
集成点
与规划器代理
规划器应在阶段 1（架构评审）之前调用研究员：
- 研究员识别可用的工具
- 规划器将它们纳入实施计划
- 避免在计划中“重新发明轮子”
与架构师代理
架构师应向研究员咨询：
- 技术栈决策
- 集成模式发现
- 现有参考架构
与迭代检索技能
结合进行渐进式发现：
- 循环 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：“添加配置文件 linter”
需求：根据模式验证项目配置文件
搜索：npm "config linter schema"、"json schema validator cli"
发现：ajv-cli（评分：8/10）
操作：采用 + 扩展 —— 安装 ajv-cli，编写项目特定的模式
结果：1 个包 + 1 个模式文件，无需自定义验证逻辑
反模式
- 直接跳转到编码：不检查是否存在就编写实用程序
- 忽略 MCP：不检查 MCP 服务器是否已提供该能力
- 过度定制：对库进行如此厚重的包装以至于失去了其优势
- 依赖项膨胀：为了一个小功能安装一个庞大的包