About
关于 · 方法论与指标体系
我们把口径公开到可以被反驳的程度——这是策展人和官方敢引用我们的前提。
关于 DSH Insights
DeepSeek Harness 的生态与动态全景观察站，三层：L1 插件洞察（真伪判定 → 权威集 → 健康分 → 收录矩阵）、L2 官方动态（releases/rc 节奏 + rc 兼容雷达，建设中）、L3 生态报告（「致作者的信」与生态周报）。我们不做目录、不做市场、不做榜单——只提供可引用、可复核的数据与观测，被生态吸收而非与之竞争。独立个人项目，与 DeepSeek 官方无隶属关系；数据、规则、管线全部开源（GitHub），发现误判请提 issue。
权威集门禁
非 fork / 非归档 · package.json 声明 dsh.bundle.patch · patch 文件已提交。这是下限口径：纯 tarball 分发的插件会进入分桶人工复核（invalid.jsonl）。
覆盖与完整性（为什么权威集 ≪ topic 总数）
GitHub topic:dsh-plugin 是官方唯一发现机制，打标即入、零门槛——其中混有大量蹭标、无关仓库、fork、monorepo 子路径与已删除仓库。我们的漏斗：topic 宇宙（≈13.7k，首页漏斗实时口径）→ 多源候选（topic 分片全量抓取 + 策展目录 + npm 映射，去重）→ manifest 门禁逐条校验 → 权威集 + 分桶。权威集是「货真价实可按官方 bundle 形态安装」的下限子集；no-dsh-bundle / no-package.json 桶里的候选可能是插件但形态非标，留待人工复核而不是混入权威集。校验按 API 预算滚动推进、断点续跑，权威集随每次快照扩大——覆盖率数字本身也公开（首页覆盖漏斗），这就是我们对「完整性」的回答方式：不报大数，报可核验的数。
插件评估指标体系（六维框架 v1）
每个插件从六个维度考察：计分四维进入总分（100 起扣 · fail −20 / 较重 −10 / 中 −5 / 轻 −2，当前 health-v7），展示两维只呈现不进分，兼容性为预留维度。阈值：S ≥ 95 A ≥ 90 B ≥ 75 C ≥ 60 D；插件详情页可见各维度子分（dimScores）。
| 维度 | 指标项 | 计分处理 |
|---|---|---|
| 工程质量 | client 导出 · main=lib 布局 · files 白名单 · npm 发布 · 版本一致 | 计分 |
| 文档完整性 | README（唯一的 fail 级）· 中文/双语文档 · LICENSE | 计分 |
| 可发现性 | dsh-plugin topic（计分）· 批量模板导入账号（计分）· 策展收录（只展示；awesome-dsh-plugin / imsai 均为民间社区目录，非官方渠道） | 部分计分 |
| 维护活跃 | 仓库年龄 · 30 天无提交 · 一次性导入无维护（npm ≥2 版本豁免） | 计分 |
| 安全卫生 | 写面 / 渲染消毒（深检抽样，启发式≠审计） | 增量信号，不进总分 |
| 采用度 | ★ · npm 周下载 · 收录渠道 | 只展示不进分（可刷/污染） |
| 兼容性 | engines.dsh 声明（实测仅 ~1% 插件声明）· API 符号 × rc changelog（M2 雷达） | 预留，暂缺测 |
原则：纯客观信号 · 星数不进分 · 探测不到的不虚构不扣分（missing 明示）· 每条扣分带证据 · 社区评分永不引入。规则全文与 changelog 见 SCHEMA §health。
engines.dsh 展示口径：详情页按 package.json 原文展示声明，预发布版本按「基础版本」解读（剥掉 -rc/-alpha 后缀再比较）——不做 npm semver 字面判定。原因：semver 字面语义下，预发布 comparator 只放行同三元组轨道，>=0.1.0-rc.6 会把 0.1.1-rc.x / 0.1.2-rc.x 全判不兼容，与作者意图相反（实测案例：dsh-dream-skin#47；插件作者侧的替代方案是运行时能力探测）。
校准
已知真/假插件编入校准集，每次快照跑回归（pipeline/validate/regress.mjs），回归非 100% 则当周快照不发布。口径变更必须 bump 规则版本并写 changelog。
指标体系（我们怎么衡量自己）
北极星：数据/报告被生态采纳——目录、市场或 dsh 官方引用我们的分数、观测或兼容预警。围绕它六组指标：
| 组 | 回答的问题 | 关键指标 |
|---|---|---|
| A 覆盖 | 做得全不全 | 权威集数量 · topic 全量覆盖率 · 候选池新鲜度 |
| B 新鲜度 | 更新勤不勤 | 快照滞后 ≤7 天（CI 每日则 ≤1 天）· CI 成功率 |
| C 公信力 | 分数信不信 | 校准回归通过率（目标 100%）· 争议工单数与解决时长 · 缺数据标注率 |
| D 内容运转 | 引擎转不转 | 周报连续外发期数（断更即警报）· 信件覆盖率 · 作者反馈数 |
| E 触达 | 有没有被看见 | 徽章部署仓库数 · repo ★ / 转载 · 站点访问 |
| F 采纳 | 北极星的计数 | 引用/集成我们数据的目录·市场数 · rc 预警被 PR 采纳次数 · 官方触点记录 |
红线：周报连续断更 2 期 → 内容产品线停新功能先修管线；校准回归非 100% → 当周快照不发布；采纳指标长期为 0 → 触发 go/pivot/kill 复盘。完整口径见 PRODUCT-DESIGN §四。
边界声明
启发式评估 ≠ 安全审计。不做社区评分/投票、不做安装托管交易、不做登录产品。深检（写面/消毒）为增量信号，单独标注。
站点统计（隐私披露）
本站使用 Umami（开源、无 cookie、不收集个人信息）统计 dsh-insights.com 的页面访问与来源，姊妹站 dsh-why.com 使用 GA4，两者都只用于衡量产品发展（指标体系 E 组）。覆盖/内容指标每周记入 data/metrics.jsonl 公开于仓库；站点访问统计记录在我们自己的数据库中，不随仓库发布。不使用任何其他跟踪。
可复核
数据、规则、管线全部开源：GitHub。发现误判请提 issue —— 争议工单本身是公信力指标（见上表 C 组）。产品版本与发布记录见更新日志。
About DSH Insights
An ecosystem and dynamics observatory for DeepSeek Harness (DSH), in three layers: L1 plugin insights (authenticity check → authoritative set → health score → listing matrix), L2 official dynamics (release/rc cadence + an rc compatibility radar, under construction), and L3 ecosystem reports (letters to authors and the weekly ecosystem report). We don't build a directory, a marketplace, or a leaderboard — we provide citable, verifiable data and observations, meant to be absorbed by the ecosystem rather than compete with it. This is an independent personal project with no affiliation to DeepSeek; the data, rules, and pipeline are all open source (GitHub) — please open an issue if you spot a misjudgment.
The Authoritative Set Gate
Not a fork, not archived · package.json declares dsh.bundle.patch · the patch file is committed. This is a lower-bound definition: plugins distributed as pure tarballs fall into bucketed manual review (invalid.jsonl).
Coverage & Completeness (why the authoritative set ≪ the topic total)
GitHub's topic:dsh-plugin is the official discovery mechanism — tag and you're in, zero barrier — so it is full of tag squatters, unrelated repos, forks, monorepo subpaths, and deleted repos. Our coverage funnel: topic universe (≈13.7k; see the live funnel on the home page) → multi-source candidates (full topic shard crawl + curated lists + npm mapping, deduplicated) → item-by-item manifest-gate verification → authoritative set + buckets. The authoritative set is the lower-bound subset that is "genuinely installable in the official bundle form"; candidates in the no-dsh-bundle / no-package.json buckets may be plugins in a non-standard shape, held for manual review rather than mixed into the authoritative set. Verification rolls forward within an API budget and is resumable, so the authoritative set grows with every snapshot — and the coverage numbers themselves are public (the coverage funnel on the home page). That is how we answer "completeness": not with a big number, but with a verifiable one.
Plugin Evaluation Metrics (six-dimension framework v1)
Every plugin is examined on six dimensions: four scored dimensions feed the total (start at 100 · fail −20 / major −10 / moderate −5 / minor −2; currently health-v7), two display dimensions are shown but never scored, and compatibility is a reserved dimension. Quality grades: S ≥ 95 A ≥ 90 B ≥ 75 C ≥ 60 D; per-dimension subscores (dimScores) are visible on each plugin's detail page.
| Dimension | Signals | Scoring |
|---|---|---|
| Engineering quality | client export · main=lib layout · files whitelist · published to npm · version consistency | Scored |
| Docs completeness | README (the only fail-level signal) · Chinese/bilingual docs · LICENSE | Scored |
| Discoverability | dsh-plugin topic (scored) · batch template-import accounts (scored) · curated listings (display only) | Partially scored |
| Maintenance activity | repo age · no commits in 30 days · one-shot import with no maintenance (npm ≥2 versions exempt) | Scored |
| Safety hygiene | write surface / render sanitization (deep-scan sampling; heuristic ≠ audit) | Incremental signal, not scored |
| Adoption | ★ · npm weekly downloads · listing channels | Display only (gameable/pollutable) |
| Compatibility | engines.dsh declaration (only ~1% of plugins declare it) · API symbols × rc changelog (M2 radar) | Reserved, not yet measured |
Principles: purely objective signals · stars never scored · what cannot be probed is never fabricated or deducted (missing is shown explicitly) · every deduction carries evidence · community ratings will never be introduced. Full rules and changelog: SCHEMA §health.
engines.dsh display semantics: detail pages show the declaration verbatim from package.json, and prerelease versions are read by base version (the -rc/-alpha suffix is stripped before comparing) — never as literal npm semver. Why: under literal semver a prerelease comparator only admits the same major.minor.patch track, so >=0.1.0-rc.6 rejects every 0.1.1-rc.x / 0.1.2-rc.x — the opposite of the author's intent (measured case: dsh-dream-skin#47; runtime capability detection is the plugin-author-side alternative).
Calibration
Known genuine/fake plugins are compiled into a calibration set; every snapshot runs a regression (pipeline/validate/regress.mjs), and if the regression is not 100% the week's snapshot is not published. Any definition change must bump the rule version and be recorded in the changelog.
Metrics (how we measure ourselves)
North star: our data/reports being adopted by the ecosystem — directories, marketplaces, or the dsh team citing our scores, observations, or compatibility warnings. Around it, six metric groups:
| Group | Question it answers | Key metrics |
|---|---|---|
| A Coverage | Are we complete? | authoritative set size · full topic coverage rate · candidate pool freshness |
| B Freshness | Do we update often? | snapshot lag ≤7 days (≤1 day with daily CI) · CI success rate |
| C Credibility | Are scores trusted? | calibration regression pass rate (target 100%) · dispute issues and time-to-resolution · missing-data annotation rate |
| D Content engine | Is the engine running? | consecutive weekly issues (a gap is an alert) · letter coverage · author feedback count |
| E Reach | Are we seen? | repos deploying the badge · repo ★ / reposts · site visits |
| F Adoption | The north star, counted | directories/marketplaces citing or integrating our data · rc warnings accepted via PR · official touchpoints |
Red lines: two consecutive missed weekly issues → the content line stops new features and fixes the pipeline first; calibration regression below 100% → the week's snapshot is not published; adoption stuck at zero long-term → triggers a go/pivot/kill review. Full definitions: PRODUCT-DESIGN §4.
Boundary Statement
Heuristic evaluation ≠ security audit. No community ratings or voting, no install hosting or transactions, no logged-in product. The deep scan (write surface / sanitization) is an incremental signal and is labeled separately.
Site Analytics (privacy disclosure)
This site uses Umami (open source, cookieless, collects no personal information) to measure page visits and referrers on dsh-insights.com; the sibling site dsh-why.com uses GA4. Both are used only to measure product development (metric group E above). Coverage/content metrics are still appended weekly to data/metrics.jsonl, public in the repo; site visit statistics are recorded only in our own database and are not published in the repo. No other tracking of any kind.
Verifiability
Data, rules, and pipeline are all open source: GitHub. If you spot a misjudgment, open an issue — dispute tickets are themselves a credibility metric (group C above). Product versions and releases: Changelog.