一份要交出去的研究报告，最怕的不是结论保守，而是别人问一句「这条数字哪来的」时你答不上来。dsh-research-report 解决的正是这件事：把每条论断绑定到一份不可变的证据快照，逐字节核对，再封存进一个带版本号的目录——连封存哈希本身都能被别人重新算出来。
它是什么，装完能得到什么
中文名「可验证报告引擎」，仓库 PerryLink/dsh-research-report，许可证 Apache-2.0。它不是帮你写报告的模型套壳，而是一台核对机器：论断必须落到字面量，落不到就如实标记。
安装只有一条命令（站点口径）：
dsh plugin --profile web add dsh-research-reportREADME 的示例 profile 名是 demo，与站点用的 web 不同，按实际用的那个填；装完用 dsh --profile web --dump-config | grep dsh-research-report 可确认已挂载。
先看「体检报告」：星标 214；npm 上周下载量 1,386（取自 npm 全网窗口，含 CI、镜像与爬虫流量，不代表装机人数）；安全扫描结论是「🔵 含敏感能力，尚无人工评估」。信任档位是「已验证（L4 · 真实安装）」，本站已在 dsh 0.2.0-rc.2 下真实安装成功；仓库 README 则写验证于 dsh-v0.2.1-alpha.1（2026-09-25）——两处口径不是同一条线，如实并列即可。当前 registry latest 是 0.3.21，安装命令不写小版本。
三件工具走完一条链路
一、登记证据：evidence_add
evidence_add({ origin, content?, title? }) 把一份证据变成账本里的一条快照。带 content 时文本原样存入；不带时 URL 经 ctx.web 抓取、工作区相对路径从磁盘读取，返回证据 id 与一个 SHA-256。账本内容寻址：相同内容只存一次，快照不可变，每次读取都重算哈希——篡改或删除会被「检测出来」，而不是被信任。
二、组装并封存：research_report
research_report({ topic, title?, sections, claims, evidenceRefs, gather?, depth?, background? }) 依次做：校验、逐条验证、渲染 report.md、写 manifest.json，返回封存哈希；未登记的主张引用会被大声拒绝。产物落在 <reportRoot>/<slug(topic)>/<YYYYMMDD-HHmmss>/，里面并排 report.md、manifest.json、verification.jsonl、disconfirmation.jsonl。关键设计：封存哈希就是 manifest.json 的 SHA-256，而 manifest 又携带报告哈希、每条证据哈希、每份审计日志哈希——别人拿到目录就能一层层重算。
三、回头查账：ledger_query
ledger_query({ claimId? | evidenceId? }) 是只读查询，读时重哈希：快照被篡改或缺失会显式报出 integrity: tampered 或 missing；不带 id 时返回账本摘要。
四种判定与看得见的标记
- unverified（未核实）：没有绑定证据，或主张里找不到可核对的字面量。
- insufficient（证据不足）：绑定了证据，但证据既不能确认也不能否认主张里的字面量。
- disproven（已证伪）：标签对应的快照值不一样，即主张声称的值在证据里并不存在。
- contradicted（与证据矛盾）：快照被篡改或缺失——最严重的一种。
四种判定都会落到报告正文的可见标记上：[未核实] / [证据不足] / [与证据矛盾] / [已证伪]，并列入附录 A，绝不悄悄放过。
配套两道闸门：封存前每条绑定主张离线重新核验并记入 verification.jsonl，一旦判定漂移、绑定证据被篡改或缺失、日志序列化失败就阻断封存（大声报错，没有可调开关）；封存后由确定性的 verifySealedReport 兜底重算封存哈希与审计哈希、重查每条主张，把结果写进 verifier-note.md——零网络、零模型。
对照同类插件的中文清单与安装形态，见 DeepSeek Harness Hub 插件清单。
两条必须知道的边界
K1 · 认的是字面量，不是意思
内置检查只逐字定位数字与引用片段，不做语义分析、不做嵌入（v1 的有意选择：可审计胜过聪明）。后果是：把证据里的「同比增长 18%」转述成「增长相当可观」，这条主张会因无可核对的字面量验成 unverified；反过来，真主张若数字缺失、标签却以另一个值出现，会被读成 contradicted。
K3 · 默认 profile 不挂 fetch 提供方
随附的 dsh-base 只挂 search，配置 fetch 提供方之前用 URL 做 evidence_add 会因抓取失败报错（WEB_UNAVAILABLE / WEB_PROVIDER_UNAVAILABLE）。最省事的绕法是先用 content 直接喂文本；基于搜索的 gather 会把没抓到的来源列进缺口清单，不假装抓到。
总结
能复核的报告靠的不是写作技巧，而是每条论断都能找到出处、每个缺口都被如实标注；想对照同类插件的中文清单与安装形态见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：要对数字和引文负责的对外交付物；以工作区文件或结构化数据集为依据的调研；要求审计痕迹可重算、可归档的团队。
不适合：以观点论述为主的长文作者——转述会验成未核实；想要自动联网深度检索的人——gather 只跑一轮且绝不自动组装；多工作区共用一套配置的人——两个根目录在挂载时按工作目录解析。
标签：dsh-research-report、DeepSeek Harness、可验证报告、证据账本、应用实践
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。