技能介绍

要解决什么问题

工程师在接需求时，常见场景不是「不会写」，而是不确定是否已有可直集成的轮子：库、CLI、托管 API、参考实现各散在不同平台，搜一圈又容易把聊天机器人、演示仓库和真正可落地的包混在一起。WheelSpotter 面向的是「先找能接进项目的方案，再决定要不要自己写」这条路径，而不是泛泛的资讯检索。

技能如何工作

触发后，技能会先判断这次搜轮子是否值得花时间：复杂度分级（L1/L2/L3）决定 token、耗时上限和 star 门槛；意图分类（library / service / tool / reference）再决定去哪搜——例如库类走 GitHub、PyPI、npm 等，服务类偏向 MCP Hub、HuggingFace API、RapidAPI，避免在错误渠道里挖无效结果。

检索侧由 scripts/search.py 承担：抽取关键词、套用经反馈验证的关键词扩展、硬过滤掉不可集成或明显跑偏的候选，再按质量信号与学习权重排序。输出不是一长串链接，而是带明确状态的结论：found（有可集成方案）、not_found（建议自研）、needs_clarification 或 error，并倾向于给出 pip/npm 等安装线索 或 L1 场景下的自研估算。v3.0 起每次搜索会记入 wheel_memory.json；展示结果后应收集用户选择与 1～5 分满意度，累积条目后可 --teach 更新平台权重与扩展词，同时用探索下限、时间衰减等机制避免只推老面孔。

适用边界与注意点

不应触发的情况包括：用户明确要自己实现、纯学习目的、或技术栈已定只需写代码——此时应直接协助开发而非跑搜索。GitHub 未配置 GITHUB_TOKEN 时容易撞 60 次/小时的限流；PyPI 无关键词 JSON API，Python 包发现需 GitHub 为主、PyPI 补元数据。L3 查询扩展关键词宜少而精，避免 GitHub 搜索被 AND 语义拖死。核心原则在文档里写得很硬：推荐物必须能直接集成，不是好看但接不上的玩具。