diff --git a/AGENTS.md b/AGENTS.md index 0787c58..459daf9 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -181,9 +181,10 @@ curl -s -X POST -H "Authorization: Bearer $TOK" "$A/gateway/apply" curl -s -X POST -H "Authorization: Bearer $TOK" -H 'Content-Type: application/json' \ -d '{"name":"常用服务"}' "$A/section" > ⚠️ **两个分组是系统管理的,不要往里手工加条目**: -> - `常用服务`:按**导航项点击次数**自动取前 5(**不置顶任何服务**),服务端重建; +> - `常用服务`:收录**所有被点击过**的导航项,按点击次数降序(**不置顶任何服务、不设条数上限**),服务端重建; > 计数来自 `POST /api/history/nav-visit`(导航页点击自动上报,落盘 `nav-visits.json`),**不使用浏览器历史** -> - `历史访问`:按浏览器同步的浏览记录重建(安装入口由它自己放在首位) +> - `历史访问`:按浏览器同步的浏览记录重建,**不限条数、且包含站内服务**(相当于"最近访问",安装入口由它自己放在首位)。 +> 数据量取决于浏览器扩展的同步(`history.json` 的 mtime 可判断是否还在同步) > > 因此 `navEnabled` 的 `navSection` 必须指向**用户分组**(如 `AI & 工具`、`系统管理`)。 > 实测教训:把新服务直接塞进 `常用服务` 会污染频次榜,且该条目会被下一次重建挤掉。 diff --git a/README.md b/README.md index 85db0d7..15883f8 100644 --- a/README.md +++ b/README.md @@ -130,7 +130,7 @@ appConfig: openingMethod: newtab sections: - - name: 常用服务 # 系统分组:按「导航项点击次数」取前 5(不置顶) + - name: 常用服务 # 系统分组:收录所有被点击过的导航项(按次数降序,不置顶、不限条数) icon: fas fa-star collapsed: false items: @@ -209,8 +209,9 @@ icon: fas fa-star # Font Awesome - 每 30 秒检查本地队列,**仅在有新数据时 POST** - 搜索引擎 URL 在本地过滤,不上传 -- 「常用服务」按**导航项点击次数**(`nav-visits.json`)自动取前 5;「历史访问」按浏览器同步的浏览记录重建。 - 两者数据源互相独立:**常用服务不看浏览器历史**(站外浏览再多也不会影响它) +- 「常用服务」= **所有被点击过**的导航项(按 `nav-visits.json` 的点击次数降序,**不设条数上限**; + 0 次点击的不算"常用",不会塞进来);「历史访问」= 浏览器同步来的**全部**浏览记录(同样不限条数, + **包含站内服务**——它是"最近访问",会与其它分组有重叠)。两者数据源互相独立:**常用服务不看浏览器历史** - 历史条目的图标由服务端自动抓取并缓存(见下) ### 历史条目的站点图标 @@ -669,8 +670,8 @@ curl -s http://127.0.0.1:18080/api/schema | jq # 人读:items + resourc echo "$code" ``` -> **注意 `常用服务` 与 `历史访问` 是系统管理的分组**:前者按**导航项点击次数**自动取前 5(**不置顶任何服务**), -> 后者按浏览记录重建。新增服务要放进用户分组(如 `AI & 工具`);`navEnabled` 的 `navSection` +> **注意 `常用服务` 与 `历史访问` 是系统管理的分组**:前者收录所有被点击过的导航项(按次数降序,不置顶、不限条数), +> 后者按浏览器同步的浏览记录重建(含站内服务,不限条数)。新增服务要放进用户分组(如 `AI & 工具`);`navEnabled` 的 `navSection` > 若指向 `常用服务`,条目会在下次重建时被挤掉。 **示例:让 agent 一次性把站点改成你要的样子**