Repository navigation
[UX] 设置里加一个「数据与统计」分组：本地用量历史 + 工作区索引 / A Settings group for local usage history and the workspace index #478
Description
Hi，先说来意：我最近拿 PI-Desktop 当日常主力做产品测试，用着用着觉得「我到底怎么用的」这件事看不见，就顺手在设置里做了个 数据与统计 分组。纯建议，不要求合并，你觉得方向不对直接说就行，我不会推。 (=^･ω･^=)
两个子页。使用统计读本地会话历史，用 host 自己的 turns 表算（累计/峰值 Token、年度热力图、每日趋势、模型占比、项目分布、诊断行），纯只读、不新增写入路径。工作区索引把 Grep 索引的开与关、状态、重建/清空收进一页。
有一处我知道是在动你的决定：D335 / ADR 0173 当初把 Settings 的 usage 目的地收掉、交给 pi.token-insights。我这版把它加回来，但只讲 host 自己这张表；插件继续做跨工具看板，两边读同一份数据。你要是觉得这层边界没必要，说一声我就把使用统计整页删掉，只留索引那页。
东西不轻（79 个文件、近 10k 行），一次 review 偏重，我自己的计划本来是拆成「使用统计 / 索引后端 / 索引页」三块分开提的。所以更想先听你的方向判断：值得做我就开 PR（要拆我也拆）；只当产品反馈聊两句也行，截图我可以先贴上来。 <*)))><
边界先交代一下，免得跟别人撞：#399 要的是配额和超限自动终止，#458 已经在做当前会话的用量读数，我这页是跨会话、跨项目的历史视图（热力图、每日趋势、模型占比），只读，不碰配额也不碰单次请求。
Reacted by Lan
Activity
vastsa commentedon Sep 16, 2026
我看了下，方向上我比较认可工作区索引这一块，但使用统计暂时还是希望维持 D335 / ADR 0173 的边界，不重新放回 Settings。
主要不是觉得统计没价值，恰恰相反，这块我觉得很有价值。只是 PI-Desktop Core 更希望负责 turns / usage / stats RPC 这些底层数据能力，跨会话、跨项目的 Dashboard 继续交给 pi.token-insights（也可以新建一个插件，都没关系的）。如果你做统计插件的过程中发现 Core 暴露的数据或插件 API 不够，这部分非常欢迎单独补，我们一定大力支持，这也是 pi-desktop 的一个特色，就是提供核心能力，剩下的都是大家共创，https://plugins.aiuo.net/，比如现在的主题工坊、还有 idea 的 git，都是大家在共创。
工作区索引就不一样了，开关、状态、重建、清空这些属于 Host/Workspace 自身生命周期，我觉得放 Core Settings 是合理的。不过我倾向放在现有 Workspace 分组里，不另外建「数据与统计」这个组。
十分感谢您的时间和付出，如果有任何问题，欢迎和我们交流
muzimu217 commentedon Sep 16, 2026
补几张实机图，都是合成数据截的，不是真实会话 (=^･ω･^=)
索引这块四个状态都跑通了：开关关着的时候「重建 / 清理」是禁用的，打开才能建，建完按钮文案翻成「重建索引」。
使用统计页的实现也放这儿，当参考：
你说的边界我收到了 —— 使用统计不往 Settings 里放，索引那页挪进现有的 Workspace 分组，不另外建组。后面真按插件那条路做统计，过程中要是发现 Core 的 stats 数据或者插件 API 不够用，我再单独开 issue 提 U・ω・U
refactor(settings): remove the stats UI layer; the dashboard ships as…
muzimu217 commentedon Sep 16, 2026
#478 回复草稿（中文）
感谢维护者裁决，已完全按两条结论落地（PR：#502）：
stats.summary/stats.topSessionsRPC 作为 Core 底层数据能力（ADR 已改记为 Superseded，D335 / ADR 0173 边界维持原状）。另外做插件功课时注意到
pi.token-insights目前是以只读方式直接访问本地数据库拿用量数据的。如果 Core 后续愿意暴露一个最小的pi.usage读数接口（比如summary/topSessions外加一个只读usage.read权限），它就可以切到正式契约上。这个正好落在"插件发现 Core 数据面不够就单独补"的邀请范围内，我准备在这个 PR 落地后另开一个小 PR 来做，先在这里报备一下方向。vastsa commentedon Sep 16, 2026
hhh，可以的，啥权限不够，你直接自己开发干就行，只要不涉及用户数据泄露的风险，都可以的，感谢
muzimu217 commentedon Sep 16, 2026
报备的 pi.usage 方向已成形：#503（pi.usage.summary / topSessions + 只读 usage.read 权限，基于 #502 保留的 stats RPC，叠层提交）。目标是让 pi.token-insights 可以从直读本地数据库切到正式契约。
muzimu217 commentedon Sep 16, 2026
收到！#503 就是按这个边界做的：只读聚合计数（turns 的 token/条数），不碰消息正文，无任何写路径，权限 usage.read 需用户安装时明示授予。感谢确认 🙏
Merge remote-tracking branch 'origin/main' into feat/data-stats-integ…
feat(plugins): add a read-only usage API for plugins
feat(plugins): add a read-only usage API for plugins
feat(plugins): add a read-only usage API for plugins
feat(plugins): add a read-only usage API for plugins
feat(plugins): add a read-only usage API for plugins
feat(plugins): add a read-only usage API for plugins
feat(plugins): add a read-only usage API for plugins
feat(plugins): add a read-only usage API for plugins
Tioit-Wang commentedon Sep 18, 2026
跨会话、跨项目那半边正好可以落在两份插槽需求上：
ui.shell.page今天先用插件面板（
contributes.views+ui.view）+ui.settings就能把页面搭起来，数据面按之前讨论的 stats RPC 走。工作区索引那一半仍然留在宿主 Workspace 分组，不在这两份清单里。上层计划：#528。两份目前都还是需求确认稿（v0.15.0 尚未实现）。
feat(plugins): add a read-only usage API for plugins
muzimu217 commentedon Oct 11, 2026
这条建议的两个半边都有了归属，收敛关闭以减少堆积：
index.*RPC + 设置页），在贡献窗口期由 feat(host): workspace index infrastructure behind an opt-in switch #697 承载，等维护者处置；docs/plugin-plan/ui/）与用量 API 现已齐备，作为插件形态实现比宿主内置分组更符合当前架构（与 ADR 0324 把可选功能下沉插件的方向一致）。如需重启为具体实现，以插件提案或 #697 线继续即可。