先搜索，后编码：工程师最容易跳过的一步

每次要加一个新功能，我的第一反应曾经都是「开始写」。不是偷懒，而是搜索感觉「浪费时间」——毕竟我大概知道怎么实现，搜出来的东西也不一定合用。

这个直觉是错的。

在实际项目里吃了几次亏之后，我慢慢意识到：「先搜索」不是一个风格偏好，而是一个降低成本的理性选择。写出来再发现已有一个维护良好的库，代价是拆掉自己的实现、迁移调用方、补测试。而搜索的成本，最多五分钟。

搜索的四个层次

按从近到远的顺序，我会依次检查：

第一层：当前仓库本身。 用 rg（ripgrep）在相关模块和测试里搜关键词。团队里往往已经有人解决过类似问题，只是你不知道。跳过这一步，很容易在同一个代码库里造出两个功能相似的 util。

第二层：包生态（npm / PyPI / crates.io）。 搜索关键词，看前三个结果的 star 数、最近 commit 时间、issue 关闭率。一个「5 年没人维护但功能完整」的包往往比「自己写」风险更低；一个「每周有人更新但 API 经常 breaking」的包则反之。

第三层：MCP server 和工具链。 当前环境里已经有哪些能力？某个操作可能已经有现成的 MCP 工具或 CLI，不需要写任何代码就能调用。

第四层：GitHub 上的参考实现。 不一定要直接用，有时候看别人怎么解决同类问题，就够了——能快速校验自己的思路，或者发现自己没想到的边界情况。

找到之后：一个简单的决策矩阵

搜索结果出来之后，有四种处理方式：

| 情况 | 行动 | |------|------| | 完全匹配、维护活跃、许可证友好 | 直接用，安装依赖，零自定义代码 | | 部分匹配，有好的基础 | 扩展，安装 + 写薄薄一层 wrapper | | 多个弱匹配 | 组合，拼接 2-3 个小包，各取所长 | | 没有合适的 | 自己写，但此时你已经看过参考实现，写的东西质量会更高 |

注意最后一行：「没找到合适的」是完全合理的结果。搜索的目的不是「一定要用别人的」，而是「在做决定之前充分知情」。带着研究结果写的自定义代码，和直接上手写的代码，质量往往不一样。

最常见的失误：跳过第一层

实践中最容易省略的是「先搜本仓库」这一步。

原因也容易理解：大家对外部生态比对自己的代码库更熟悉。npm 上的包有文档、有例子、有 star；而自己仓库里的工具函数藏在某个 utils/ 目录下，没有文档，也没人宣传。

结果就是：一个项目里出现两个功能几乎相同的 HTTP wrapper，或者两套格式不一样的日期处理函数，互相漂移。每多一个重复实现，维护成本就乘以一次。

一个好的习惯是，在写任何 util 之前先用 rg 搜一遍关键词，看看有没有类似的函数名或者注释。三十秒，但收益长期复利。

一句话心法

搜索不是找「能不能省事」，而是在动手之前充分知情——知情之后，你的每个选择都会更便宜。