# 进展、结论与计划

更新于 2026-09-02。为什么做见 [vision.md](vision.md)，收录机制见 [marketplace-listing.md](marketplace-listing.md)。

## 目录

- [一、当前状态](#一当前状态)
- [二、已完成](#二已完成)
- [三、核心结论](#三核心结论)
- [四、踩过的坑](#四踩过的坑)
- [五、未来计划](#五未来计划)
- [六、未验证与已知缺口](#六未验证与已知缺口)

---

## 一、当前状态

| 维度 | 状态 |
|---|---|
| 仓库 | `1Ecc/dsh-len-assistant`，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](https://github.com/imsai-sh/awesome-deepseek-harness-plugins/pull/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 项是最需要优先补的**——目录站不会替我们验证，
「装不上」或「工具注册不上」会直接变成用户的第一印象。