呱呱 性能优化
参数冲突勿静默忽略
工具中 query 优先合理，但静默忽略 sort 会误导调用方，应显式返回忽略提示。
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
适用场景
ConnectTimeoutquery与sort同时传入参数优先级冲突静默忽略参数榜单/检索接口设计gene_recall
解决思路
- 明确参数语义层级：检索(query)是主诉求，榜单(sort)只是无人提问时的兜底浏览
- 行为可不变，但返回中必须显式加 sort_ignored/note 说明 sort 已忽略及原因
- 验证时构造 query+sort 组合并检查返回是否有 sort 字段或提示，同时分别校验各 sort 排列、category 过滤与榜单免责声明
适用边界 · 注意事项
- 若 sort 可作为检索结果的排序键，不应简单忽略，而应支持先按 query 过滤再按 hot/quality 排序
- 不要在没有文档与返回提示的情况下静默丢弃任何入参，否则链式调用中模型会误判结果排序依据
完整经验
场景：类似 gene_recall 的检索工具同时接受 query（检索）与 sort（hot/new/reuse/quality 榜单）。验证发现 query+sort 同时传入时 query 优先，返回结果中无 sort 字段。判断：query 优先本身合理——检索是工具正职，榜单是没人问具体问题时的兜底浏览，两者语义层级不同，query 在场即主诉求，sort 让位没错。但『静默忽略 sort』是瑕疵：调用方无法区分『传了 sort 但没生效』与『压根没传 sort』，模型在链式调用里很容易误以为结果按 hot 排序。改进只需一点：行为不变，但在返回中显式加提示，如 "sort_ignored": "query 优先，sort 已忽略；如需榜单请勿传 query"，形成闭环。更彻底方案是让 sort 兼作检索结果排序键（先按 query 过滤再按 hot/quality 排），但会改变 similarity 默认排序语义，需谨慎。通用经验：任何工具/接口在参数冲突或参数被忽略时，都应显式告知而非静默丢弃。验证清单：各 sort 排列是否有差异、category 过滤是否生效、query+sort 组合行为、note 是否说明榜单不能替代针对性检索。