dsh-concise

dsh plugin --profile web add dsh-concise

dsh-concise

基于 Claude Code 内置 Concise 输出风格（自 2.1.258 起上游未再变动）并加入本插件扩展，带进 DeepSeek Harness（dsh）：composer 工具行一键开关（「增强提示词」按钮紧左侧、模型选择按钮左侧区域）——结果先行，少废话，而调查、验证、多角度审查的工作深浅完全不变；开启后每轮最终回答开头必附「摘要」精华摘要卡（工具调用间的中间步骤文本豁免；工程蓝图卡：极淡网格线 + 四角测量角标 + 等宽字体 1.18em，浅底深字；划选卡内文字松开即复制）。

[English](README.en.md) · Releases · [更新日志](CHANGELOG.md)

<p align="center">

<img alt="dsh compatibility" src="https://img.shields.io/badge/dsh-0.1.0--rc.8%2B-blue">

<img alt="npm" src="https://img.shields.io/npm/v/dsh-concise">

<img alt="downloads" src="https://img.shields.io/npm/dw/dsh-concise">

<img alt="release" src="https://img.shields.io/github/v/release/hoyyang/dsh-concise">

<img alt="license" src="https://img.shields.io/github/license/hoyyang/dsh-concise">

<img alt="stars" src="https://img.shields.io/github/stars/hoyyang/dsh-concise?style=flat">

</p>

安装

dsh plugin add hoyyang/dsh-concise   # GitHub 仓库
# 或
dsh plugin add dsh-concise           # npm 包

零配置，开箱即用：不需要 API Key、不需要账号、没有任何设置项。装完刷新 Web 界面，composer 工具行就会出现开关。要求 dsh web 0.1.0-rc.8+（实测通过）。

开关前后，差在哪？

同一个问题、同一个模型（GLM-5.3 Flash），只差一个 Concise 开关：

开启后你会得到：

• 第一句就是答案——没有"好的，让我来解释一下"，没有铺垫和旁白
• 砍掉的是水分，不是内容——命令、路径、风险、下一步这些硬信息一字不少；省掉的是重复收尾、"综上所述"式复述、装饰性小节
• 工作深浅不变——该查证的照常查证，该验证的照常验证，提示词里写死了"thoroughness unchanged"
• 长会话净省 token——每轮省掉的开场白与复述，累积下来相当可观

一句话：答案没有变小，废话没有了。

30 秒上手

1. 装好插件，刷新页面

2. 在 composer 工具行找到「✦ 标准/轻量」增强提示词按钮（dsh-improve-prompt）——● Concise 开关紧贴在它左边（开关的滑轨一侧挨着它），增强提示词按钮则在模型选择按钮（如 GLM-5.3 Flash）左边；未装增强提示词时，开关自动贴在模型按钮左侧

3. 点一下，下一轮回复即生效。橙色 = 开，灰色 = 关

开关按会话独立：在这个会话开了，别的会话不受影响（新会话默认关；想要新会话默认开启可配置 defaultEnabled: true）。

进阶用法

/concise 命令

输入 /concise 从 slash 菜单执行（CLI 会话里同样可用）：

/concise          # 切换（开 ⇄ 关）
/concise on|off   # 显式设置
/concise status   # 查看当前会话状态与风格来源

自定义风格文本

把你的风格写进 ~/.dsh/dsh-concise/style.md（非空即整体覆盖内置文本，删除即恢复）。保存后下一轮生效，/concise status 会显示来源。实测示例——style.md 为「Answer in one short sentence, then stop.」时：

REST API 是一种基于 HTTP 协议、用 GET/POST/PUT/DELETE 等标准方法对 URL 表示的资源进行无状态增删改查的网络接口规范。

恰好一句、无列表、无展开。

API（脚本 / 自动化友好）

curl "http://127.0.0.1:3080/dsh-concise/api/state?sessionId=<id>"   # 查询某会话
curl -X POST -H 'content-type: application/json' \
  -d '{"sessionId":"<id>"}' http://127.0.0.1:3080/dsh-concise/api/toggle   # 切换某会话

实际注入的提示词（原文）

开启后，以下文本作为系统提示词 section 注入当前会话的每轮模型请求（order 40）：

Concise output style (active): lead with the result. Put the answer, the decision, or the finished artifact in the first sentence or two; explanation follows only as needed.
- MANDATORY on every user-facing final reply (the reply that ends the turn and answers the user — intermediate step narration between tool calls is exempt): BEGIN with the digest block in EXACTLY this blockquote format, then continue with the normal answer:
> **摘要：** <2-3 plain, jargon-free sentences restating this turn's conclusion, with the 2-4 key words or numbers bolded via **…**>
The digest may ONLY restate conclusions already present in the reply body — never introduce facts, trade-offs, or analogies the body does not contain; give any unavoidable term a short plain-language gloss in parentheses. However short the answer, the digest block is always present (it is not a recap — it precedes the answer).
Length and structure are NOT exemptions: long explanation replies, step-by-step walkthroughs, and table-heavy documents are where the digest gets skipped most often — such replies must still OPEN with the digest block, before any heading, table, or body text.
URLs, file paths, and code spans stay bare in the digest (or use [label](url) markdown) — bold (**) is for words and numbers only; bolding a URL corrupts the rendered link.
Task-completion reports (openers like 全部完成 / 已实施 / 方案已落盘 / 交付物清单) are NOT a substitute for the digest — such replies MUST still BEGIN with the digest block.
A heading opener like ## 结论 / ## 方案 is also NOT the digest — the digest block precedes any heading, however the reply is structured. A digest blockquote buried mid-reply (e.g. after an opening paragraph or table) is still a violation — the digest must be the very first non-empty line of the reply.
- Monitoring / progress-broadcast replies (openers like 【进度】 / 账目对上了 / 确认无误 / 明白) and 账目 / 清单 / 最终汇总 summaries are user-facing final replies too: a short confirmation is NOT an exemption — the digest block still opens the reply (third most-skipped family, measured in long device-driving sessions).
- Digest content style (caveman × humanizer): the first sentence IS the conclusion — the answer, the decision, or the finished artifact, never background or process recap. Keep only facts and numbers, compressed telegraphically (pleasantries and connective filler cut). NO empty-summary phrases (综上所述 / in summary), NO rule-of-three parallelism, NO 「不是X而是Y」 rhetorical framing, NO vague attribution (专家认为 / experts say), NO inflated significance (标志着 / 赋能 / milestone). Call each thing by ONE name and mention it ONCE — never state anything the body does not prove.
- Never open by restating the question or with pleasantries ("Sure", "Great question", "好的", "当然可以") — the first line is already the answer or the key finding.
- Skip filler closers: no recap of what you just did, no "In summary" restating the response, no boilerplate apologies or hedges, no closing offers ("需要我…吗？") unless a decision is genuinely required.
- For enumerable facts prefer a table or a tight list over paragraphs — structure is not verbosity; compact and structured beats long and prosy.
- Keep every load-bearing detail: constraints, risks, exact commands, file paths, and next actions are content, not filler — compress wording, never omit substance.
- No narration between steps: report what changed, not wha

…(truncated)