进展、结论与计划
September 3, 2026 · View on GitHub
更新于 2026-09-02。为什么做见 vision.md，收录机制见 marketplace-listing.md。
目录
一、当前状态
| 维度 | 状态 |
|---|---|
| 仓库 | 1Ecc/dsh-lenovo-toolkit，public |
| 形态 | Skill（项目级）+ Cordis Plugin（bundle） |
| 工具组 | 本地源码 4 个（电池、Windows 设备、Wi-Fi、受控操作），共注册 17 个 DSH 工具 |
| 平台 | 电池：macOS ✅、Windows ⏳；新增非电池能力仅支持 Windows，原 MCP 已验证但 DSH 注册壳待验证 |
| 测试 | 新增迁移结构/安全单测 9 项通过；电池原有集成测试本次未重复执行 |
| 生态收录 | 1024Store ✅ 已合并；topic 聚合站 ✅ 已打 topic；awesome-dsh-plugin ⏳ 等门槛 |
| 埋点 | ❌ 无 |
二、已完成
能力
- 电池健康检测：机型、电池型号、设计容量、当前满充容量、双口径健康度、循环次数、 温度与寿命统计、硬故障标志
- 容量衰减趋势图（SVG，自适应明暗主题，浏览器直接打开）
- 系统官方电池报告（Windows 为 powercfg HTML，macOS 为系统原生数据汇总）
- 判读规则体系：健康度分级、循环次数分级、衰减速率公式、异常信号清单、结论四档
- 服务推荐策略：纪律三条、触发公式、试点商品、保外直客的推荐顺序
- Windows 非电池能力（本地迁入）：设备、性能、进程、存储、应用、Wi-Fi、网络监测、脱敏报告和四个需确认的低风险操作，共 14 个工具；另含 8 个 DSH Skill（含总路由）
工程
- 采集端零第三方依赖：macOS 只用
system_profiler/ioreg/plutil/pmset， Windows 只用powercfg+ WMI - 趋势图渲染只用 Python 标准库
- 插件用 ESM JavaScript，无构建步骤，从源码装不需要
allowBuilds授权 - 纯逻辑与 Cordis 壳分离，纯逻辑可在没有 peer 依赖的环境里完整测试
- 新增能力保留统一
ToolEnvelope、URL 白名单、数据最小化和逐次确认边界；原想帮帮工程文件保持不变
生态
| 动作 | 结果 |
|---|---|
打 dsh-plugin topic | ✅ 2026-08-28，dshfind 等 topic 聚合站自动收录 |
| 1024Store 目录仓 PR | ✅ #263 两项 CI 通过后自动合并 |
| awesome-dsh-plugin | ⏳ 条目已备好在 docs/listing/，等仓库满 1 天 + 10 提交 |
H1 假设已验证：从零开始到被公共插件目录收录，用了不到一天，且全程没有任何平台方授权环节。
三、核心结论
生态侧
1. DSH 没有官方插件市场，「上架」本质是打一个 GitHub topic。 十几个社区目录站每天自动扫描收录。这意味着准入门槛极低——但也意味着 这是一次不可选择目标的广播，做不到只发给某一个站点。
2. 需要提 PR 的目录都要求 package.json 声明 dsh.bundle。
纯 SKILL.md 仓库进不去。想被正式收录就必须做成真插件。
3. 收录速度比预想快得多。 1024Store 是静态检查通过即自动 squash merge， 无人工介入、无仓库年龄门槛。从提 PR 到合并只花了几分钟。
产品侧
4. 双口径健康度是这类硬件诊断的通用问题。 系统对外公布的数字和硬件实测值经常差很多（实测样本：macOS 报 88%，电量计实测 97.9%， 差 9.9 个百分点）。处理原则是取较低者判风险、取系统口径对客户陈述、差异必须主动解释。 后续做存储、内存等诊断时大概率会遇到同类问题。
5. 单点数据不能做线性外推。 两种口径各自外推，一个说 125 次循环到更换线，另一个说 714 次。 如果只取难看的那个画成一条确定的线，一台其实很健康的机器会被呈现为即将报废—— 这种图拿去做服务推荐是自毁信任。现在画成推算区间楔形带。
6. 推荐必须由结论触发，不能反过来。
诊断报告的全部价值来自可信度。这条写进了 lenovo-offers.md 的第一节，
是所有后续工具组都要遵守的原则。
四、踩过的坑
留在这里是因为后续工具组大概率会再遇到同类问题。
| 坑 | 后果 | 处理 |
|---|---|---|
plutil 把错误文本打到 stdout 而非 stderr | Could not extract value... 冒充字段值写进报告 | 过滤含该文本的返回值；测试里加断言 |
SPPowerDataType 的 _items 分段顺序不固定 | 写死下标必漏字段 | 前 6 段逐个探测取第一个非空值 |
Intel 与 Apple Silicon 的 MaxCapacity 含义相反 | 容量算错 | 按数量级判断（>1000 视为 mAh） |
| 单点线性外推过于激进 | 健康机器被画成快报废 | 改为推算区间楔形带 |
| 已跌破 80% 仍按「未来预测」播报 | 输出「预计 2026 年 6 月触及」而那月份已过 | 改为「约在 X 时已越过」 |
.gitignore 写 battery-health-*/ | 把 skill 目录 battery-health-check/ 也忽略了 | 改为 battery-health-[0-9]*/ |
| semver 预发布范围 | 站点文档推荐的范围已过期，用户撞 ERESOLVE | 补齐元组，见 marketplace-listing.md |
YAML 值含 : 未加引号 | DSH 静默拒绝 skill；目录站 YAML 解析失败 | 一律加引号（我们自己也踩了一次） |
五、未来计划
近期（本周）
| 事项 | 目的 | 阻塞 |
|---|---|---|
| Windows 实机验证 | 补上能力矩阵最大的空白 | 需要 Windows 机器 |
| 提交 awesome-dsh-plugin | 权重最大的目录站 | 仓库满 1 天 + 10 提交 |
| 更新 1024Store 条目 | 仓库已改名，id 与现名失配 | 更新既有条目需人工审核 |
| CI 跑测试 | 目录站看重活跃维护 | 无 |
screenshots.json + 趋势图样例 | 市场详情页展示 | 无 |
中期
| 事项 | 对应假设 |
|---|---|
| 埋点 —— 触发原因、机型是否匹配、推荐是否输出、是否点击 | H3，当前最大数据缺口 |
| npm 发布 | 免构建授权，且目录站能显示下载量（H2 指标） |
| 第二个工具组 | H4，验证边际成本是否真的下降 |
| 商品链接核对与巡检机制 | 商品 ID 会失效，需要责任人 |
远期
- 知识检索路径（服务知识库、保修政策、备件价格）
- 内部策略与公开代码分离（见 vision.md 风险章节）
- 归属问题定论：迁到 Lenovo 组织，还是明确为个人试点
六、未验证与已知缺口
必须诚实记录的部分，不要在对外材料里跳过。
| 项 | 状态 |
|---|---|
| Windows 采集脚本 | 已实现，从未在真实 Windows 上运行过。重点核对 powercfg /batteryreport /xml 里 HistoryEntry 的容量字段层级 |
dsh plugin add 实际安装 | 未实测。CI 只校验 manifest 形状，不安装不执行 |
| Cordis 工具注册 | 按官方文档写的，未在真实 DSH 运行时验证过 |
| 转化数据 | 无埋点，H3 完全没有数据 |
| 品牌归属 | 未定论 |
商品 ID 1045747 | 需求方给的链接显示文本与 href 不一致，待核对 |
上面第 2、3 项是最需要优先补的——目录站不会替我们验证， 「装不上」或「工具注册不上」会直接变成用户的第一印象。