dsh-plain-talk 0.1.3 → 0.1.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +12 -0
- package/README.en.md +127 -147
- package/README.md +48 -72
- package/dsh/index.js +480 -473
- package/dsh/rules.js +1 -0
- package/dsh/vocab.js +229 -215
- package/icon.png +0 -0
- package/lib/client.js +2 -6
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
package/README.en.md
CHANGED
|
@@ -1,147 +1,127 @@
|
|
|
1
|
-
# dsh-plain-talk
|
|
2
|
-
|
|
3
|
-
<p align="center">
|
|
4
|
-
<img src="https://raw.githubusercontent.com/lizilong1993/dsh-plain-talk/main/assets/banner.jpg" alt="dsh-plain-talk —
|
|
5
|
-
</p>
|
|
6
|
-
|
|
7
|
-
<p align="center">
|
|
8
|
-
<strong>English</strong> · <a href="README.md">中文</a>
|
|
9
|
-
</p>
|
|
10
|
-
|
|
11
|
-
<p align="center">
|
|
12
|
-
<a href="LICENSE"><img alt="MIT" src="https://img.shields.io/badge/license-MIT-263146?style=flat-square"></a>
|
|
13
|
-
<a href="https://www.npmjs.com/package/dsh-plain-talk"><img alt="npm" src="https://img.shields.io/npm/v/dsh-plain-talk?style=flat-square"></a>
|
|
14
|
-
<img alt="dsh-plugin" src="https://img.shields.io/badge/dsh--plugin-ready-478CBF?style=flat-square&logo=deepseek&logoColor=white">
|
|
15
|
-
</p>
|
|
16
|
-
|
|
17
|
-
A reply-shaping plugin for DeepSeek Harness:
|
|
18
|
-
|
|
19
|
-
## What it does
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
## Results
|
|
28
|
-
|
|
29
|
-
Environment: DeepSeek Harness `desktop` profile
|
|
30
|
-
|
|
31
|
-
###
|
|
32
|
-
|
|
33
|
-
|
|
|
34
|
-
|
|
35
|
-
| A.
|
|
36
|
-
|
|
|
37
|
-
| |
|
|
38
|
-
|
|
|
39
|
-
|
|
|
40
|
-
|
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
##
|
|
115
|
-
|
|
116
|
-
`
|
|
117
|
-
|
|
118
|
-
|
|
119
|
-
|
|
120
|
-
|
|
121
|
-
|
|
122
|
-
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
|
|
126
|
-
|
|
127
|
-
|
|
128
|
-
- Switch and vocabulary are atomic JSON sidecar files; no session events are written.
|
|
129
|
-
|
|
130
|
-
## Data
|
|
131
|
-
|
|
132
|
-
Only `$DSH_HOME/plain-talk.json` and `$DSH_HOME/plain-talk-vocab.json` are written. No network, no upload, no credential access. A corrupt state file reads as "no choice recorded".
|
|
133
|
-
|
|
134
|
-
## Configuration
|
|
135
|
-
|
|
136
|
-
Environment variable `PLAIN_TALK_DEFAULT` (`on` / `off`, default `on`).
|
|
137
|
-
|
|
138
|
-
## Notes
|
|
139
|
-
|
|
140
|
-
- The button position depends on `conversation.input.left`; a host redesign may move it beside other left-side controls.
|
|
141
|
-
- Rules are prompt constraints; `plain_talk_check` warns but never blocks a send.
|
|
142
|
-
- Vocabulary is shared per user, not per project; code detection is heuristic.
|
|
143
|
-
- With the mode on, each request carries about 590 extra input tokens.
|
|
144
|
-
|
|
145
|
-
## License
|
|
146
|
-
|
|
147
|
-
MIT — see [LICENSE](./LICENSE).
|
|
1
|
+
# dsh-plain-talk (Plain Talk)
|
|
2
|
+
|
|
3
|
+
<p align="center">
|
|
4
|
+
<img src="https://raw.githubusercontent.com/lizilong1993/dsh-plain-talk/main/assets/banner.jpg" alt="dsh-plain-talk — plain talk" width="100%">
|
|
5
|
+
</p>
|
|
6
|
+
|
|
7
|
+
<p align="center">
|
|
8
|
+
<strong>English</strong> · <a href="README.md">中文</a>
|
|
9
|
+
</p>
|
|
10
|
+
|
|
11
|
+
<p align="center">
|
|
12
|
+
<a href="LICENSE"><img alt="MIT" src="https://img.shields.io/badge/license-MIT-263146?style=flat-square"></a>
|
|
13
|
+
<a href="https://www.npmjs.com/package/dsh-plain-talk"><img alt="npm" src="https://img.shields.io/npm/v/dsh-plain-talk?style=flat-square"></a>
|
|
14
|
+
<img alt="dsh-plugin" src="https://img.shields.io/badge/dsh--plugin-ready-478CBF?style=flat-square&logo=deepseek&logoColor=white">
|
|
15
|
+
</p>
|
|
16
|
+
|
|
17
|
+
A reply-shaping plugin for DeepSeek Harness: a "Plain talk" switch in the composer. When on, replies lead with the conclusion, stay under 12 lines by default, paste cited text directly, gloss a code with one plain sentence the first time it appears, and remember the words you already know.
|
|
18
|
+
|
|
19
|
+
## What it does
|
|
20
|
+
|
|
21
|
+
* **Conclusion first**: the first line is the answer or the verdict; no restating the question, no "let me take a look".
|
|
22
|
+
* **Short by default**: ≤12 lines / 300 characters; depth only when you ask for it.
|
|
23
|
+
* **Self-contained**: no "as mentioned above / earlier / last round"; a code (EXP-7, DEV-1K, run-3) is written as `EXP-7 (one sentence explaining it)` on first use.
|
|
24
|
+
* **Readable citations**: when giving `file:line`, paste the quoted lines.
|
|
25
|
+
* **Vocabulary**: words you have used, project names and common terms count as known; "research X" still explains X on the first reply, then remembers it. Codes never enter the list.
|
|
26
|
+
|
|
27
|
+
## Results
|
|
28
|
+
|
|
29
|
+
Environment: DeepSeek Harness `desktop` profile, headless run, model `command code/deepseek-v4.1-flash` (high), 2026-11-04. Same prompt, same workspace, only the switch changes.
|
|
30
|
+
|
|
31
|
+
### Output comparison
|
|
32
|
+
|
|
33
|
+
|Case|Off|On|
|
|
34
|
+
|-|-|-|
|
|
35
|
+
|A1 Create and verify files|Task complete; the artifacts are in `bench-demo/`:<br><br>- `a.txt`, `b.txt`, `c.txt` contain A, B, C<br>- `check.mjs`: reads the three files in a→b→c order, strips newlines and joins them<br><br>Run `node check.mjs`; it prints `ABC`, exit code 0.|Done: the four files are in `bench-demo/`, and running the script prints `ABC`.<br><br>- `a.txt`, `b.txt`, `c.txt` each hold a single line `A`, `B`, `C`<br>- `check.mjs` reads a → b → c, joins and prints; measured output: `ABC`<br><br>Check it yourself: run `node check.mjs` in `bench-demo`; you should see one line `ABC`.|
|
|
36
|
+
|A2 Write and read back|Done.<br><br>- Created `hello.txt` with `Hello`<br>- Read back confirms 1 line containing `Hello`<br><br>File path: `<workspace>/hello.txt`|I created hello.txt in the workspace root with `Hello` (the file already existed before my change; this run overwrote it with the same content), then read it back: `1: Hello`.<br><br>Two notes:<br><br>- A hello.txt already existed with the same `Hello`, so this overwrite changed nothing.<br>- The file has one line and no trailing newline; add one if needed.<br><br>File path: `<workspace>/hello.txt`|
|
|
37
|
+
|B1 Why models forget|Most people think this is only "the context window is too short"; even a long window forgets. First, truncation and compression: early turns beyond the window are dropped by the sliding window or summarized by the system, and the detail is gone. Second, attention is soft retrieval with no index guarantee — the more candidates, the more the weights are diluted, and position bias is obvious ("lost in the middle": the start and end stick, the middle is ignored). Third, positional encoding extrapolates worse over very long distances, so the signal linking early tokens to the current one is weaker.<br><br>Deeper down, the training objective never paid for "long-term memory". Pretraining predicts the next token and barely penalizes forgetting what was said earlier, so the model never learns an explicit memory read/write mechanism; early information survives only by being re-encoded through residual streams, which have limited bandwidth and accumulate error. Real products also do KV-cache compression, history summarization and retrieval stitching, so early content reaches the present in lossy form. The workable fix is not "make it remember" but externalize the key facts: retrieval, write them into the system prompt, or restate them when needed.|Put simply, the model has no "memory"; each answer sees only the tokens in the current context window. Once the window fills, earlier turns are truncated or compressed into a summary and the original text is gone. A bigger window is still finite, and the fuller it gets the more attention is diluted: distant information has low weight and is easily buried in the middle (the so-called lost-in-the-middle), so it is "visible but unusable".<br><br>The other cause is the training distribution. Models mostly learn long-range dependencies on short text; at tens of thousands of tokens, linking "the constraint from turn 3" to "the question at turn 80" is naturally weaker than human comprehension and recall. On top of that, systems drop KV cache and keep only recent turns to save compute, so early content is structurally discarded. It is not that the model "forgot" — the content was never continuously retained. Anything that must survive a long conversation needs an external record: write it to a file, retrieve it, or restate the key constraints each turn.|
|
|
38
|
+
|B2 merge vs rebase|`git merge` keeps the full history of both branches and creates a merge commit, so the history is truthful but forked and not linear in time. `git rebase` replays your branch's commits one by one onto the latest commit of the target branch, producing a linear, clean history but rewriting commit hashes. In practice, prefer merge on shared branches so you do not disturb others' history; use rebase to integrate the latest code on a personal branch and keep commits tidy.|**merge keeps the fork and joins it; rebase moves commits onto a new base and rewrites history.** merge creates a new merge commit joining the two branches and leaves existing hashes unchanged; rebase replays your branch's commits onto the target's latest commit, creating new commits (all hashes change) and a straight line. So merge is safer for commits already pushed to a shared branch; rebase is only for local commits not yet pushed, otherwise it breaks references others hold to the old history.|
|
|
39
|
+
|C1 Experiment draft|Conclusion: EXP-7 is not merging this time. With it, CAND's localization accuracy went 61.2% → 63.8%, +2.6 points, short of the 3-point bar. This is a decision after a real run, not "cannot evaluate".<br><br>But the external version has two numbers that contradict each other; check that first.<br><br>First, the opening says "no accuracy gain", which conflicts with +2.6pp later; it should say "a gain, but under the bar".<br><br>Second, 1198/1200 predictions are byte-identical. Only 2 differ, which can move at most 0.17 points — not 2.6pp. At least one of these numbers is wrong, and 2.6pp sits just under the bar; until that contradiction is resolved the conclusion does not hold.<br><br>Three things are also missing: AUROC is only cited as reports/exp7/summary.md:42 with no value, and the file is not here; sharded merging is not a claim-eligible EvalRun and must be labelled a directional comparison; there is no confidence interval — at n=1200, 2.6pp is about 31 samples, so significance is unknown.<br><br>What you can do now: run a full per-item diff to see whether "1198/1200 identical" or "+2.6pp" is right, check why fixing two known defects changed only 2 predictions, and put the AUROC value into the report. If the gain really is 2.6pp, do not start round-2 yet.|Conclusion: EXP-7 (the experiment that adds an "instance verification" step to the inference flow) did not reach the merge bar; do not merge.<br><br>- On DEV-1K (the 1200-sample dev set) localization accuracy went 61.2% → 63.8%, +2.6 points; the merge bar is 3 points.<br>- The comparison run is run-3: BASE (baseline, config name base_v3) vs CAND (BASE plus exp7_verify, keeping the previous two rounds' config). Same manifest (SHA-256 a1b2c3d…), seed 42, code e4f5a6b, 4×GPU in 4 shards of 300 each merged into 1200.<br>- This is a measured comparison, not a failed run: 1198 of 1200 predictions are byte-identical; two known defects are fixed.<br>- Caveat: a sharded merge is not an EvalRun that can enter the record; it only shows the denominator, manifest and seed match.<br>- AUROC has no verifiable value: the draft points at reports/exp7/summary.md, which is not in the repository, so this line is not cited.<br><br>Next step: produce summary.md, or run round-2 as a single full run to re-check CAND.|
|
|
40
|
+
|C2 Release-check draft|**Conclusion**: you cannot issue a "ready to ship" report now. The draft puts "ready to ship" next to "run-7 regression is not finished" without stating the condition, so sending it would read as unconditional approval. The accurate wording is **conditional release: decide after the run-7 regression wraps up**.<br><br>**Confirmed**<br>- The check covers login, payment and export<br>- Export time dropped from 4.2s to 3.1s<br>- The payment callback failed once in run-7; the draft points to logs/run-7.txt:88<br><br>**Two things required before release**<br>- Finish the run-7 regression and state clearly "all green" or "still failing"<br>- Classify that payment failure: a transient timeout, retryable, or reproducible. This decides whether a known problem can ship and is the most important unknown in the report.<br><br>**What the draft does not say**<br>- Who ran it, when, on which version or environment<br>- Whether "covered three paths" means ran or passed<br>- Whether the failure succeeded on retry<br><br>**What I checked**<br>- There is no `logs/` directory here, so `run-7.txt:88` cannot be verified; it is only relayed as the draft's citation<br>- `draft.md` in the same directory is a report from another experiment and unrelated to the release; I did not merge it in<br><br>**One-paragraph version** (ready to paste): The login, payment and export paths of BUILD-42 were checked, and export time dropped from 4.2s to 3.1s; but the run-7 regression is unfinished and the payment callback failed once in run-7. Decide after the regression wraps up and the nature of that failure is confirmed.<br><br>Do you want me to rewrite this as a formal report, or update `draft2.md` to this version first?|Conclusion: do not ship BUILD-42 (the build about to go out) yet. The draft's own conclusion says "ready to ship", but the same draft says run-7 (the 7th regression round) is unfinished and the payment callback failed once in run-7; both point to not releasing, so the conclusion contradicts the draft body.<br><br>- Coverage: login, payment and export.<br>- Payment: the callback failed once in run-7, recorded at line 88 of run-7's log logs/run-7.txt; the file is not in the current directory, so I cannot quote it — provide the path or paste it.<br>- Export: time dropped from 4.2s to 3.1s.<br>- Regression: run-7 is unfinished and the cause of the payment failure is unknown.<br><br>Next step: rerun run-7 first and check whether the payment failure reproduces; if it does, do not ship.|
|
|
41
|
+
|
|
42
|
+
### Characters and token difference
|
|
43
|
+
|
|
44
|
+
|Case|Characters (off / on)|Output tokens (off / on)|
|
|
45
|
+
|-|-|-|
|
|
46
|
+
|A1 Create and verify files|144 ➡ 189|2,333 ➡ 1,344|
|
|
47
|
+
|A2 Write and read back|124➡238|220 ➡398|
|
|
48
|
+
|B1 Why models forget|410 ➡ 350|732 ➡ 326|
|
|
49
|
+
|B2 merge vs rebase|184 ➡ 194|150 ➡ 366|
|
|
50
|
+
|C1 Experiment draft|558 ➡ 496|2,781 ➡ 3,066|
|
|
51
|
+
|C2 Release-check draft|672 ➡ 331|1,636 ➡ 2,092|
|
|
52
|
+
|
|
53
|
+
About +589 input token per step.
|
|
54
|
+
|
|
55
|
+
## Install
|
|
56
|
+
|
|
57
|
+
```sh
|
|
58
|
+
# npm
|
|
59
|
+
dsh plugin --profile desktop add dsh-plain-talk
|
|
60
|
+
|
|
61
|
+
# GitHub
|
|
62
|
+
dsh plugin --profile desktop add github:lizilong1993/dsh-plain-talk
|
|
63
|
+
|
|
64
|
+
# local directory
|
|
65
|
+
dsh plugin --profile desktop add ./dsh-plain-talk
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
Restart DSH after installing.
|
|
69
|
+
|
|
70
|
+
## Use
|
|
71
|
+
|
|
72
|
+
1. Open any session; a smiley speech-bubble icon appears to the right of the permission selector in the composer.
|
|
73
|
+
2. On: the smiley has three sound waves on its right and an open smile; off: the smile version without waves. Click to toggle, affecting only the current session.
|
|
74
|
+
3. State is written to `$DSH_HOME/plain-talk.json` and survives a restart.
|
|
75
|
+
4. To make new sessions start off: set `PLAIN_TALK_DEFAULT=off` in the launch environment.
|
|
76
|
+
|
|
77
|
+
## Vocabulary
|
|
78
|
+
|
|
79
|
+
`$DSH_HOME/plain-talk-vocab.json`, shared across sessions.
|
|
80
|
+
|
|
81
|
+
|Category|Meaning|Examples|
|
|
82
|
+
|-|-|-|
|
|
83
|
+
|common|built in, not explained|arXiv, DOI, API, GPU|
|
|
84
|
+
|domain|field terms you have used|diffusion models, AUROC|
|
|
85
|
+
|project / product name|repositories, products, workspace names|AcmeService_V2, DataHub_V3|
|
|
86
|
+
|unclassified|recorded, not classified|other detected terms|
|
|
87
|
+
|
|
88
|
+
Internal codes (EXP-7, DEV-1K, run-3) never enter the list: every occurrence is treated as unknown so the model explains it again.
|
|
89
|
+
|
|
90
|
+
"Research X" has two steps: X is first marked pending and the first reply explains it as usual; after the reply is delivered it is written into the list. Common terms (such as arXiv) are unaffected; internal codes are never recorded.
|
|
91
|
+
|
|
92
|
+
Maintain it with `plain_talk_vocab`: `list` / `add` / `remove` / `classify`; you can also edit the JSON directly.
|
|
93
|
+
|
|
94
|
+
## Self-check tool
|
|
95
|
+
|
|
96
|
+
`plain_talk_check` takes a draft and returns a list of issues:
|
|
97
|
+
|
|
98
|
+
* Must fix: back-references, session ids / subagents / tool names, pointer-only citations with no quoted text.
|
|
99
|
+
* Suggested fixes: unexplained codes, over 12 lines / 300 characters, lists over 5, opening pleasantries, closing requests for more work, a Chinese user receiving an all-English reply.
|
|
100
|
+
|
|
101
|
+
The rules section asks the model to call it before sending a completion reply or any reply over 12 lines.
|
|
102
|
+
|
|
103
|
+
## How it works
|
|
104
|
+
|
|
105
|
+
* Host (`dsh/index.js`) registers a system-prompt section (`plain-talk`, order 55) that returns the rules only when the current session's switch is on.
|
|
106
|
+
* Browser half (`lib/client.js`) registers into `conversation.input.left` and renders an 18×18 smiley button.
|
|
107
|
+
* The switch is read and written over the loopback route `/plain-talk/state` (127.0.0.1 / ::1 only, body ≤8 KB).
|
|
108
|
+
* State and vocabulary are atomic JSON sidecars; no session events are written.
|
|
109
|
+
|
|
110
|
+
## Data and permissions
|
|
111
|
+
|
|
112
|
+
Only `$DSH_HOME/plain-talk.json` and `$DSH_HOME/plain-talk-vocab.json` are written. No network, no upload, no credential access; a corrupt state file is treated as "no record".
|
|
113
|
+
|
|
114
|
+
## Configuration
|
|
115
|
+
|
|
116
|
+
Only the environment variable `PLAIN_TALK_DEFAULT` (`on` / `off`, default `on`).
|
|
117
|
+
|
|
118
|
+
## Notes
|
|
119
|
+
|
|
120
|
+
* Button position depends on `conversation.input.left`; a host redesign may move it beside other left-side controls.
|
|
121
|
+
* Rules are prompt constraints; `plain_talk_check` only warns and does not block sending.
|
|
122
|
+
* Vocabulary is shared per user, not isolated per project.
|
|
123
|
+
* With the switch on, each request carries about 590 extra input tokens.
|
|
124
|
+
|
|
125
|
+
## License
|
|
126
|
+
|
|
127
|
+
MIT — see [LICENSE](./LICENSE).
|
package/README.md
CHANGED
|
@@ -18,70 +18,44 @@ DeepSeek Harness 的回复优化插件：输入框里一个「说人话」开关
|
|
|
18
18
|
|
|
19
19
|
## 它做什么
|
|
20
20
|
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
21
|
+
* **结论先行**：第一行就是答案或判定，不复述问题，不写"我来看看"。
|
|
22
|
+
* **默认短**：≤12 行 / 300 字；你要求展开时才放开深度。
|
|
23
|
+
* **自包含**：不用"上述 / 前面 / 上一轮"；代号（EXP-7、DEV-1K、run-3）第一次出现写成 `EXP-7（一句话说明）`。
|
|
24
|
+
* **引用可读**：给 `文件:行号` 的同时贴出那几行原文。
|
|
25
|
+
* **词汇清单**：你说过的词、项目名、常见术语默认已知；"调研 X"的第一轮仍会解释 X，回复交付后才记住。代号不进清单。
|
|
26
26
|
|
|
27
27
|
## 效果
|
|
28
28
|
|
|
29
|
-
测试环境：DeepSeek Harness `desktop` profile、headless 运行、模型 `
|
|
29
|
+
测试环境：DeepSeek Harness `desktop` profile、headless 运行、模型 `command code/deepseek-v4.1-flash`（high），2026-11-04。同一提示词、同一工作区，只切换开关。
|
|
30
30
|
|
|
31
|
-
###
|
|
31
|
+
### 输出对比
|
|
32
32
|
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
| A
|
|
36
|
-
|
|
|
37
|
-
|
|
|
38
|
-
|
|
|
39
|
-
|
|
|
40
|
-
|
|
|
41
|
-
| | 回指次数 | 2 | 0 | **−2** |
|
|
42
|
-
| C 报告整理（把草稿改成给用户的汇报） | 最终回复字数 | 558 | 496 | **−11%** |
|
|
43
|
-
| | 输出 token | 2,781 | 3,066 | +10%（多一次自检） |
|
|
44
|
-
| | 未解释代号 | 6 | 0 | **−6** |
|
|
45
|
-
| | 只给指针的引用 | 1 | 0 | **−1** |
|
|
33
|
+
|场景|关闭|开启|
|
|
34
|
+
|-|-|-|
|
|
35
|
+
|A1 建文件并验证|任务完成，产物都在 `bench-demo/` 目录：<br><br>- `a.txt`、`b.txt`、`c.txt`，内容分别是 A、B、C<br>- `check.mjs`：按 a→b→c 顺序读取三个文件，去掉换行后拼接输出<br><br>运行 `node check.mjs`，输出 `ABC`，退出码 0。|已达标：`bench-demo` 下四个文件已就位，运行脚本输出 `ABC`。<br><br>- `a.txt`、`b.txt`、`c.txt` 各只有一行 `A`、`B`、`C`<br>- `check.mjs` 按 a → b → c 顺序读取、拼接并打印，实测输出：`ABC`<br><br>你自己确认：在 `bench-demo` 目录执行 `node check.mjs`，应看到一行 `ABC`。|
|
|
36
|
+
|A2 写入并读回|已完成。<br><br>- 创建了 `hello.txt`，写入内容 `Hello`<br>- 读回确认为 1 行，内容就是 `Hello`<br><br>文件路径：`<工作区>/hello.txt`|我在工作区根目录创建了 hello.txt，写入内容为 `Hello`（该文件在我操作前已存在，这次是把它覆盖为同一内容），随后读回确认：`1: Hello`。<br><br>需要注意两点：<br><br>- 已存在同名的 hello.txt，原本内容也是 `Hello`，所以这次覆盖没有造成实际变化。<br>- 文件只有一行，没有换行符，如需要可补一个行尾换行。<br><br>文件路径：`<工作区>/hello.txt`|
|
|
37
|
+
|B1 为什么模型会忘事|多数人以为这只是“上下文窗口不够长”，其实窗口够长也会忘。一是截断与压缩：超过窗口的早期轮次会被滑窗丢弃，或者被系统摘要掉，原本的细节就没了。二是注意力是软检索，没有索引保证——候选内容越多，权重越被摊薄，而且位置偏差很明显（“lost in the middle”：开头和结尾记得住，中间段最容易被忽略）。三是位置编码在超长距离上外推能力下降，早期 token 与当前 token 的关联信号本来就更弱。<br><br>再往深一层，是训练目标没给“长期记忆”发工资。预训练是逐 token 预测，几乎不惩罚“忘了前面说过什么”，模型因此没学出显式的记忆读写机制；早期信息只能靠每层残差流反复重编码往后传，而这条通道带宽有限，误差逐层累积。加上实际产品还会做 KV cache 压缩、历史摘要、检索式拼接，早期内容往往以有损形式才活到当下。所以真正管用的办法不是“让它记住”，而是把关键事实外置：检索、写进系统提示、或在需要时重述。|简单说，模型没有“记忆”，它每次回答只能看到当前上下文窗口里的全部 token；窗口塞满后，早先的对话要么被截断、要么被压缩成摘要，原文就没了。窗口再大也不是无限，而塞得越满，注意力被稀释得越厉害：远处的信息权重低、容易被中间位置淹没（常说的 lost-in-the-middle），于是“看得见但用不上”。<br><br>另一层原因是训练时的分布。模型主要在短文本上学习长距离依赖，真到几万 token 的跨度，它把“第 3 轮的约束”和“第 80 轮的问题”关联起来的能力，本来就弱于人类的理解记忆；加上系统端为了省算力会做 KV 缓存淘汰、滑动窗口保留最近若干轮，早期内容被结构性丢弃。所以这不是“忘了”，而是从没被持续保留——需要跨长对话保持的信息，得靠外部记录（写入文件、检索、每轮重述关键约束）来补。|
|
|
38
|
+
|B2 merge 与 rebase|`git merge` 会保留两条分支的完整历史，并生成一个合并提交，历史因此真实，但会分叉、按时间而言不够线性。`git rebase` 则把你分支上的提交逐个“移接”到目标分支的最新提交之上，从而得到一条线性、干净的历史，但会重写提交哈希。实践中，在共享分支上优先使用 merge，以免打乱别人的历史；在个人分支上整合最新代码时用 rebase，可以保持提交整洁。|**merge 是保留分叉再合并，rebase 是把提交搬到新基底上重写历史。** merge 会生成一个新的合并提交把两条分支接起来，原有提交的哈希不变；rebase 则把当前分支的提交逐个重放到目标分支最新提交之后，产生全新的提交（哈希全变），历史变成一条直线。所以共享分支上推送过的提交用 merge 更安全，rebase 只适合还没推送的本地提交，否则会打断别人基于旧历史的引用。|
|
|
39
|
+
|C1 实验草稿|结论：EXP-7 这次不合并。加了它的 CAND 定位精度 61.2% → 63.8%，涨 2.6 个百分点，没到 3 个点的门槛。这是跑完实测后的决定，不是"无法评估"。<br><br>但对外的版本里有两个数字打架，得先查。<br><br>一是开头写"没有带来定位精度提升"，和后面的 +2.6pp 冲突，应改成"有提升，但不够门槛"。<br><br>二是 1198/1200 条预测逐字节相同。只剩 2 条不同，最多撬动 0.17 个百分点，凑不出 2.6pp。这两个数至少错一个，而 2.6pp 又刚好卡在门槛下面，不解决这个矛盾，结论就站不住。<br><br>另外缺三样：AUROC 只写了见 reports/exp7/summary.md:42，没给数值，文件也不在当前目录；分片合并的结果本身不是 claim-eligible EvalRun，要注明是方向性对照；没有置信区间，n=1200 时 2.6pp 约等于 31 条样本的差异，是否显著未知。<br><br>你现在就能做的：跑一次全量逐条 diff，确认到底是"1198/1200 相同"还是"+2.6pp"准确，顺带查为什么两个已知缺陷修完预测只变了 2 条；把 AUROC 数值补进报告。如果精度确实只有 2.6pp，round-2 先别跑。|结论：EXP-7（给推理流程加"实例验证"一步的实验）没达到合并门槛，不合并。<br><br>- DEV-1K（1200 条开发集）上定位精度 61.2% → 63.8%，+2.6 个百分点，合并线 3 个百分点。<br>- 对照批次是 run-3：BASE（基线，配置名 base_v3）对 CAND（BASE 加 exp7_verify 这一步，保留前两轮配置）。同 manifest（SHA-256 a1b2c3d…）、seed 42、代码 e4f5a6b，4×GPU 分 4 片各 300 条合并成 1200。<br>- 这是实测对照，不是跑不出来：1200 条里 1198 条预测逐字节相同；两个已知缺陷已修复。<br>- 口径瑕疵：分片合并的结果不算可入库的 EvalRun，只能说明分母、manifest、seed 一致。<br>- AUROC 没有可核对的数值：草稿指向的 reports/exp7/summary.md 不在仓库里，这条不引。<br><br>下一步：补出 summary.md，或开 round-2 用单个全量 run 复核 CAND。|
|
|
40
|
+
|C2 上线检查草稿|**结论**：现在不能出“可以上线”的汇报。草稿把“可以上线”和“run-7 回归还没跑完”并列写着，但没有说明条件，直接发出去会被读成无条件放行。准确说法是**条件放行：等 run-7 回归收尾后，再决定是否上线**。<br><br>**已经确认的**<br>- 检查覆盖登录、支付、导出三条链路<br>- 导出耗时从 4.2s 降到 3.1s<br>- 支付回调在 run-7 中失败过一次，草稿中指到 logs/run-7.txt:88<br><br>**放行前必须完成的两件事**<br>- 补齐 run-7 回归，给出“全绿”或“仍未通过”的明确状态<br>- 给支付回调那次失败定性：是偶发超时、可重试，还是必现问题。这条决定能不能带问题上线，是整份汇报里最关键的未知项。<br><br>**草稿没有交代的信息**<br>- 谁执行的、什么时候、在哪个版本或环境跑的<br>- “覆盖了三个链路”是指跑过还是跑通了<br>- 失败那次有没有重试成功<br><br>**我另外核了一下**<br>- 工作目录里没有 `logs/` 目录，所以 `run-7.txt:88` 无法核对，只能作为原草稿的引用转述<br>- 同目录的 `draft.md` 是另一轮实验报告，和上线无关，我没并进来<br><br>**一句话版本**（可以直接贴给相关方）：BUILD-42 的登录、支付、导出三条链路已检查，导出耗时从 4.2s 降到 3.1s；但 run-7 的回归尚未跑完，且支付回调在 run-7 中失败过一次，待回归收尾并确认该失败的性质后，再给出上线结论。<br><br>是否需要我照这个改写成正式汇报文档，或先把 `draft2.md` 更新成这版？|结论：BUILD-42（这次要上线的构建）先别上线。草稿自己的结论写的是“可以上线”，但同一份草稿又写明 run-7（第 7 轮回归）还没跑完，并且支付回调在 run-7 里失败过一次；这两条都指向不能放行，所以这个结论和草稿正文相互矛盾。<br><br>- 覆盖范围：登录、支付、导出三条链路。<br>- 支付：支付回调在 run-7 里失败过一次，记录在 run-7 的日志 logs/run-7.txt 第 88 行；该文件不在当前目录，我无法贴出原文，需要你提供路径或直接贴出来。<br>- 导出：耗时从 4.2s 降到 3.1s。<br>- 回归：run-7 还没跑完，支付回调失败的原因也还没查清。<br><br>下一步：先补跑 run-7，确认支付回调的失败能否复现；只要能复现，就不上线。|
|
|
46
41
|
|
|
47
|
-
|
|
42
|
+
### 字数与 token差异
|
|
48
43
|
|
|
49
|
-
|
|
44
|
+
|场景|字数（关闭 / 开启）|输出 token（关闭 / 开启）|
|
|
45
|
+
|-|-|-|
|
|
46
|
+
|A1 建文件并验证|144 ➡ 189|2,333 ➡ 1,344|
|
|
47
|
+
|A2 写入并读回|124➡238|220 ➡398|
|
|
48
|
+
|B1 为什么模型会忘事|410 ➡ 350|732 ➡ 326|
|
|
49
|
+
|B2 merge 与 rebase|184 ➡ 194|150 ➡ 366|
|
|
50
|
+
|C1 实验草稿|558 ➡ 496|2,781 ➡ 3,066|
|
|
51
|
+
|C2 上线检查草稿|672 ➡ 331|1,636 ➡ 2,092|
|
|
50
52
|
|
|
51
|
-
|
|
52
|
-
|---|---|---|
|
|
53
|
-
| 首行 | 任务完成，产物都在 `bench-demo/` 目录： | 已达标：`bench-demo` 下四个文件已就位，运行脚本输出 `ABC`。 |
|
|
54
|
-
| 产物说明 | `a.txt`、`b.txt`、`c.txt` 内容分别是 A、B、C；`check.mjs` 按 a→b→c 顺序读取，去掉换行后拼接输出 | `a.txt`、`b.txt`、`c.txt` 各只有一行 `A`、`B`、`C`；`check.mjs` 按 a → b → c 读取、拼接并打印，实测输出：`ABC` |
|
|
55
|
-
| 读者确认 | 运行 `node check.mjs`，输出 `ABC`，退出码 0。 | 你自己确认：在 `bench-demo` 目录执行 `node check.mjs`，应看到一行 `ABC`。 |
|
|
56
|
-
| 字数 / 输出 token | 144 / 2,333 | 189 / 1,344 |
|
|
57
|
-
|
|
58
|
-
### B 解释类：同一问题，两侧输出
|
|
59
|
-
|
|
60
|
-
| 对比点 | 关闭 | 开启 |
|
|
61
|
-
|---|---|---|
|
|
62
|
-
| 第一段 | 多数人以为这只是"上下文窗口不够长"，其实窗口够长也会忘。一是截断与压缩……二是注意力是软检索……三是位置编码在超长距离上外推能力下降。 | 简单说，模型没有"记忆"，它每次回答只能看到当前上下文窗口里的全部 token；窗口塞满后，早先的对话要么被截断、要么被压缩成摘要。 |
|
|
63
|
-
| 第二段 | 再往深一层，是训练目标没给"长期记忆"发工资。预训练是逐 token 预测，几乎不惩罚"忘了前面说过什么"…… | 另一层原因是训练时的分布。模型主要在短文本上学习长距离依赖，真到几万 token 的跨度，关联能力本来就弱…… |
|
|
64
|
-
| 回指 | 2 处（"前面说过"等） | 0 |
|
|
65
|
-
| 字数 / 输出 token | 410 / 732 | 350 / 326 |
|
|
66
|
-
|
|
67
|
-
### C 报告整理：同一份草稿，两侧整理结果
|
|
68
|
-
|
|
69
|
-
草稿里放了代号、回指和只给指针的引用。示例中的项目代号已替换为中性占位符。
|
|
70
|
-
|
|
71
|
-
| 对比点 | 关闭 | 开启 |
|
|
72
|
-
|---|---|---|
|
|
73
|
-
| 结论句 | 结论：EXP-7（新加的实例校验模块）这次不合并。加了它的 CAND 定位精度 61.2% → 63.8%，涨 2.6 个百分点，没到 3 个点的门槛。 | 结论：EXP-7（给推理流程加"实例验证"一步的实验）没达到合并门槛，不合并。 |
|
|
74
|
-
| 代号处理 | EXP-7、CAND 有解释；AUROC、pp、round-2 仍是裸代号 | EXP-7、DEV-1K、run-3、BASE、CAND、round-2 全部就地解释 |
|
|
75
|
-
| 引用 | 只写"见 reports/exp7/summary.md:42"，没有原文 | 说明该文件不在仓库里，这条不引用 |
|
|
76
|
-
| 下一步 | 一段话里给了多个选项 | 只给一个动作 |
|
|
77
|
-
| 字数 / 输出 token | 558 / 2,781 | 496 / 3,066 |
|
|
53
|
+
每步约 +589 input token。
|
|
78
54
|
|
|
79
55
|
## 安装
|
|
80
56
|
|
|
81
|
-
需要带 `conversation.input.left` 插槽的 DeepSeek Harness（0.2.x 线）。
|
|
82
|
-
|
|
83
57
|
```sh
|
|
84
|
-
# npm
|
|
58
|
+
# npm
|
|
85
59
|
dsh plugin --profile desktop add dsh-plain-talk
|
|
86
60
|
|
|
87
61
|
# GitHub
|
|
@@ -95,8 +69,8 @@ dsh plugin --profile desktop add ./dsh-plain-talk
|
|
|
95
69
|
|
|
96
70
|
## 使用
|
|
97
71
|
|
|
98
|
-
1.
|
|
99
|
-
2.
|
|
72
|
+
1. 打开任意会话，输入框权限选择器右侧会多一个笑脸气泡图标。
|
|
73
|
+
2. 开启时笑脸右侧带三道声波、张嘴笑；关闭时是不带声波的微笑版。点一下切换，只影响当前会话。
|
|
100
74
|
3. 状态写在 `$DSH_HOME/plain-talk.json`，重启后保持。
|
|
101
75
|
4. 想让新会话默认关闭：启动环境里设 `PLAIN_TALK_DEFAULT=off`。
|
|
102
76
|
|
|
@@ -104,15 +78,16 @@ dsh plugin --profile desktop add ./dsh-plain-talk
|
|
|
104
78
|
|
|
105
79
|
`$DSH_HOME/plain-talk-vocab.json`，跨会话共享。
|
|
106
80
|
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
| 待归类 | 已记录、未分类 | 其他识别到的代号 |
|
|
81
|
+
|类别|含义|例子|
|
|
82
|
+
|-|-|-|
|
|
83
|
+
|常识词汇|内置，不解释|arXiv、DOI、API、GPU|
|
|
84
|
+
|专业词汇|你用过的领域词|扩散模型、AUROC|
|
|
85
|
+
|项目 / 产品名|仓库、产品、工作区名|AcmeService_V2、DataHub_V3|
|
|
86
|
+
|待归类|已记录、未分类|其他识别到的词|
|
|
114
87
|
|
|
115
|
-
|
|
88
|
+
内部代号（EXP-7、DEV-1K、run-3）不进入词表：每次出现都按未知处理，提醒模型重新解释。
|
|
89
|
+
|
|
90
|
+
"调研 X"分两步：X 先记为待确认，第一轮回复照常解释；回复交付后写入词表。常识词（如 arXiv）和内部代号不受影响。
|
|
116
91
|
|
|
117
92
|
维护用 `plain_talk_vocab`：`list` / `add` / `remove` / `classify`；也可以直接改 JSON。
|
|
118
93
|
|
|
@@ -120,17 +95,17 @@ dsh plugin --profile desktop add ./dsh-plain-talk
|
|
|
120
95
|
|
|
121
96
|
`plain_talk_check` 接收一条草稿，返回问题清单：
|
|
122
97
|
|
|
123
|
-
|
|
124
|
-
|
|
98
|
+
* 必须改：回指词、会话号 / 子代理 / 工具名、只给指针没有原文。
|
|
99
|
+
* 建议改：未解释代号、超过 12 行 / 300 字、列表超过 5 条、开头寒暄、结尾征询、中文用户却整段英文。
|
|
125
100
|
|
|
126
101
|
规则区段要求模型在完成类回复或超过 12 行的回复发送前调用它。
|
|
127
102
|
|
|
128
103
|
## 工作原理
|
|
129
104
|
|
|
130
|
-
|
|
131
|
-
|
|
132
|
-
|
|
133
|
-
|
|
105
|
+
* 宿主端（`dsh/index.js`）注册一个系统提示词段落（`plain-talk`，order 55），只有当前会话开关打开时返回规则正文。
|
|
106
|
+
* 浏览器端（`lib/client.js`）注册进 `conversation.input.left`，渲染 18×18 笑脸按钮。
|
|
107
|
+
* 开关经 loopback 路由 `/plain-talk/state` 读写（仅 127.0.0.1 / ::1，body ≤8 KB）。
|
|
108
|
+
* 状态与词表都是 JSON sidecar，原子写；不写 session 事件。
|
|
134
109
|
|
|
135
110
|
## 数据与权限
|
|
136
111
|
|
|
@@ -142,11 +117,12 @@ dsh plugin --profile desktop add ./dsh-plain-talk
|
|
|
142
117
|
|
|
143
118
|
## 注意
|
|
144
119
|
|
|
145
|
-
|
|
146
|
-
|
|
147
|
-
|
|
148
|
-
|
|
120
|
+
* 按钮位置依赖 `conversation.input.left`，宿主改版后可能移到其它左侧控件旁。
|
|
121
|
+
* 规则是提示词约束，`plain_talk_check` 只提醒、不拦截发送。
|
|
122
|
+
* 词表按用户共享，不按项目隔离。
|
|
123
|
+
* 默认开启时每个请求多约 590 input token。
|
|
149
124
|
|
|
150
125
|
## 许可
|
|
151
126
|
|
|
152
127
|
MIT —— 见 [LICENSE](./LICENSE)。
|
|
128
|
+
|