dsh-noletme

uitested: passnpmMIT

Real-time 'We need…' and 'Let me…' reasoning-trajectory keyword stats for the DeepSeek Harness web chat.

下载量 / Downloads
957
依赖体积 / node_modules
0.27 MB
测试时间 / Tested
2026-11-06
DSH 版本 / Version
0.2.2-rc.1

Install

dsh plugin --profile web add dsh-noletme

Sandbox test results

StageResult
1 install✓
2 list✓
3 mount✓
4 boot—

Four stages run in an isolated sandbox: install (network on) → list → mount → boot (last three with no network).

README

<img width="1710" height="1082" alt="" src="https://github.com/user-attachments/assets/ef968872-f49b-4183-9b20-9e9fe6846466" />

NoLetMe · dsh 推理轨迹面板

![npm version](https://www.npmjs.com/package/dsh-noletme) ![dsh-std Community v0.15](https://github.com/Yuer6327/NoLetMe/blob/main/dsh-plugin.json) ![Awesome dsh-plugin](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin)

NoLetMe 是 DeepSeek Harness(dsh)网页端插件,在会话页右侧边缘挂载一块实时推理关键词统计面板。

模型流式输出时,NoLetMe 只统计其推理块(reasoning blocks)中出现的特征词,据此反映当前推理风格:

分类 · 关键词 · 依据

🟢 高效 · 直接行动 · We need… Let's… We should… We can… We will…;首行 Good./Great./Excellent. · minimal 类高分轨迹

🟠 犹豫 · 第一人称试探 · Let me… I think… I'm not sure… I wonder… I guess… maybe perhaps · standard 类低分轨迹

⚪ 中性 · 复述任务 · The user wants… The user asked… this task… the request… · Standard 目录开场框架

灰测是另一层、不改 0813 词表。面板只报命中态与数字;完整判定规则见 [灰测如何判定](#gray-test)。

面板是原生融入的悬浮层:复用 harness 设计系统(--dsw-alias-* 语义令牌、DetailsPanel 头/体结构、CSS Modules、明暗与 reduced-motion),通过官方 shell.overlay 插槽挂载,不改动、不补丁任何既有 UI。

证据链

本插件的分类体系并非杜撰,每一条都追溯至公开的 xiaobright/modeltest 仓库,及其对 DeepSeek V4 Pro GA 0813 后训练过拟合事件的调研:在 DeepSeek Harness「Minimal」预设(RL 训练所用的双工具脚手架)上训练出的 checkpoint,换到更宽的 Standard 工具目录后能力崩塌。

测试集:Project2 V4.1b —— 一个真实损坏的 ESP-IDF 嵌入式工程任务,已正式冻结(PROJECT_FROZEN.md,2026-07-23 冻结;评分规则与隐藏测试于 2026-07-19 做 SHA-256 固定)。

实测数据:evaluator/trajectory_evidence/derived/trajectory_stats.json(每次运行做 SHA-256 固定;只统计已完成的助手推理块,排除流式分块):

运行(模型 / 配置) · 得分 · we · let me · let's · I · 可见回复

V4 Pro / Minimal WSL · 99 · 272 · 0 · 101 · 17 · 1

V4 Pro / Minimal WSL · 96 · 231 · 0 · 117 · 18 · 1

V4 Pro / anchored-standard Win · 98 · 179 · 1 · 88 · 17 · 1

V4 Pro / anchored-standard Win · 99 · 165 · 0 · 98 · 18 · 1

V4 Pro / Standard WSL · 91 · 11 · 208 · 2 · 137 · 55

V4 Pro / PTC WSL · 92 · 16 · 194 · 0 · 237 · 33

高分运行(96–99)带 we/let's、let me ≈ 0;低分运行(91–92)let me 数以百计。这条干净的界线就是 🟢 高效 / 🟠 犹豫的划分来源。

分类器:仓库自带精确词法规则(evaluator/trigger_probe/src/classifier.mjs),NoLetMe 逐条镜像:首行 We need → minimal 类;有 we 无 let me → +2;出现任何 let me → standard 类;独立首行 Good./Great./Excellent. → +1。⚪ 中性类覆盖其余 ambiguous(模糊)及复述框架 —— Standard 目录开场 The user wants … Let me …(见 DEEPSEEK_V4_TRIGGER_MECHANISM_EXPERIMENTS_20260814.md),外加通用任务描述词汇。

诚实边界:原始矩阵原文警告:"词法轨迹标签是观测性指纹,而非路由或身份标签。" 词频只反映推理风格,不能判定后端、路由或 checkpoint;V4 Flash 会在分数不变时改变风格。灰测探针同样只报告社区观测到的特征组合,不能据此断言路由到了哪家模型。NoLetMe 是推理风格诊断工具,不是模型身份测试。

文献上的「LLM 风格指纹」分类器(例如 Bitton & Bitton, arXiv:2503.01659 的三分类器集成,或 Attestify 一类需训练语料的统计指纹)需要离线权重与校准集,不适合塞进这个浏览器插件。NoLetMe 只保留能本地、无模型地从 reasoning 算出的统计:列表密度、块长 p50、TTR、平均词长,作为灰测旁的完整数据,而不是把会话贴上 Claude/Gemini/GPT 标签。

完整事件报告见 [docs/research.md](docs/research.md)。

<a id="gray-test"></a>灰测如何判定

一句话:对会话里每个助手轮独立打分,score ≥ 5 命中、≥ 2 疑似、否则未命中;任一轮命中即整段会话显示命中。加分项:出现 I'm doing +4、开场即 I'm doing +2、概要/条目形 CoT(列表行占比 ≥ 35%)+2、脏 token(Nameeee 等)+2、泄漏 fp_… 串 +2、TTFT 超过本会话动态线 +1;减分项:Let me ≥ 2 且无 I'm doing −3、裸 we ≥ 3 且无 I'm doing −1。0813 词表完全不动。

面板「灰测」一行(未命中 / 疑似 / 命中)的规则写在这里。实现:[src/client/graytest.ts](src/client/graytest.ts)(信号表 [gray-signals.ts](src/client/gray-signals.ts)),GRAYTEST_VERSION = 3。

按轮判定,再聚合

灰测是抽卡——一次抽中一轮。探针因此逐轮独立计分:

1. 每个已加载的 assistant 节点各得一个 TurnProbe(verdict、score、I'm doing 数、列表密度、TTFT…);

2. 流式 partial 单独算一条 live 轮(无 timing);

3. 会话聚合:任一轮 likely → 命中;否则任一轮 possible → 疑似;面板徽章取最高分轮的家族。

这样第 3 轮抽中不会被前两轮 0813 的 Let me 稀释;反过来旧会话里偶然一次 I'm doing 也只影响那一轮。展开后「按轮」区列出每轮一行(T<turn> / live · verdict · I'm doing · TTFT · 吐字时长)。

每轮怎么打分

对这一轮的 reasoning 文本(只算 kind === 'reasoning' 的块,可见 text 一律不算):

信号 · 分 · 说明

I'm doing / I am doing / 粘连 I'mdoing ≥ 1 · +4 · 08-19/20 社区主指纹

本轮最新块首行即 I'm doing… · +2 · 开场比块中出现更强

有 I'm doing 且该轮 let me = 0 · +1 · 灰测常缺 Let me

概要形:列表/标题行占比 ≥ 35%(或 ≥ 15% 且有 I'm doing) · +2 · 列表行 = 行首 - * • 1. 1) #–###

脏 token:Nameeee、antml:thinking、<antml、EDMFunc、everydaycalculation · +2 · 从 reasoning 漏出

后端串 fp_…(如 fp_v4pro_20260812_prod) · +2 · 部署指纹,当细节不是身份

TTFT 异常慢(超过本会话动态线) · +1 · 见下节;受网络影响,封顶 +1

该轮 let me ≥ 2 且无 I'm doing · −3 · 典型 0813 Standard

裸 we ≥ 3、无 I'm doing、非概要形 · −1 · 典型 0813 Minimal

阈值:score ≥ 5 → 命中;score ≥ 2 → 疑似;其余未命中。

TTFT / 吐字节奏(动态线,抗网络干扰)

社区反复强调灰测「首字很慢」「一段一段出」。宿主在 assistant 节点上记录 timing.stepStartTime / firstTokenTime / completedTime,插件据此给出每轮:

  • TTFT = firstToken − stepStart;
  • 吐字时长 stream = completed − firstToken;
  • ms/字符 = TTFT ÷ 该轮推理字符数。

这些时间戳包含排队与网络,固定阈值会在慢链路上误报。所以插件用会话自己的历史轮估网络质量,动态调整命中线:

画像字段 · 含义

ttftBaseline · 已计轮 TTFT 的中位数——这条链路的底噪

ttftSpread · p90 ÷ p50——抖动程度

streamCharsPerSec · 吐字阶段每秒推理字符(慢链路同样拖低它)

slowLineMs · 动态命中线 = max(基线 + 3 s, 基线 × 2 × 抖动),下限 2.5 s、上限 60 s

效果:全程 ~9 s 的慢代理把基线抬到 9.5 s、命中线抬到 ~20 s——自己的每一轮都不会被误报;快链路(~0.7 s 基线)命中线收紧到 ~3.7 s,一次 5 s 的卡顿照样被抓。样本 < 2 轮时退回静态规则(≥ 6 s 或 ≥ 300 ms/字符)。

TTFT 仍只作 +1 弱加分,原始数字与画像始终显示——判断留给用户。流式 partial 没有时间戳,TTFT 列留空。

面板上的数字(命

…(truncated)

Rendered from the README published on npm. Formatted only, not edited.

Versions

Published on npm::11,最后更新 2026-09-25

Links

GitHub · Homepage · npm

Same category