前言¶
在 DSH 裏開一個新會話，常見的第一句是「幫我做一個網頁博客」這類話：任務本身能執行，但站點形態、生成方式、部署位置都沒定。模型往往會先猜一版再改，或者來回多輪確認，token 和注意力都耗在返工上。另一種做法是給智能體註冊專用澄清工具、或把長段 system prompt 常駐每輪請求——功能上可行，但工具表和系統詞會按輪次重複計費。
下面介紹社區插件 dsh-clarify-first（顯示名「澄清優先」），維護者爲 skadery。它掛在 DSH 的 agent/pre-step 鉤子上：僅當本會話第一條真人消息看起來「能做但缺關鍵決策」時，在模型動手前注入一條約 200 token 的一次性提示，讓模型用 DSH 原生的 ask_user_question 一次問清 2～4 個決策點；選項來自本地 JSON 模板庫，不註冊新工具、不常駐 system prompt、也不額外調用 LLM。
這是什麼¶
dsh-clarify-first 是 DeepSeek Harness 生態下的擴展類插件（package.json 中 dsh.category 爲 extension）。當前 npm 包版本爲 0.2.0，許可證 MIT，要求 Node >=22.19.0、DSH >=0.1.7-rc.2（詳見倉庫 engines 與 peerDependencies）。
一句話定位：在寫代碼之前先問清少數關鍵決策，而不是在三十條消息之後才發現方向錯了——README 中的英文 slogan 即 Ask three questions before writing code, not thirty messages after.
核心功能¶
一次性注入與原生提問¶
觸發後，插件用確定性匹配（README 稱 0 延遲）選中模板包，把 notice 注入當前輪上下文。模型應優先調用內置 ask_user_question，每題 2～4 個選項（含推薦項，用戶也可自由作答）。用戶點選後，模型按答案直接開工，README 要求不再複述需求。
典型流程（摘自 README）：
用戶: 幫我做一個網頁博客
↓ 插件（確定性匹配，0 延遲）
模型: [ask_user_question] 站點形態？生成方式？部署方式？
用戶: 點選 → 純靜態 / Hexo / GitHub Pages
模型: 直接按這三條開工（不再複述需求）
三檔提問深度¶
| 檔位 | 第一輪問幾個 | 補問 | 怎麼切 |
|---|---|---|---|
| 精簡 | 2 | 不補問，沒問到的按推薦項定 | 首條消息裏寫「少問點」「只問關鍵」 |
| 標準（默認） | 3 | 不補問 | 不寫，或寫 depth: 2 |
| 深入 | 4 | 拿到答案後，再對仍懸着的關鍵點補一輪（最多 2 問） | 寫「問細一點」「多問幾個」 |
優先級：首條消息裏的措辭 > 檔位文件 > 插件配置。檔位文件可隨時改，約 60 秒內生效，無需重啓 DSH：
// <DSH_HOME>/clarify-first/gear.json (Windows 默認示例路徑見 README: F:\DSHHome\clarify-first\gear.json)
{ "depth": 3 } // 1=精簡 2=標準 3=深入
深入檔並非固定多輪訪談：第一輪給 4 個最影響做法的點；第二輪僅在出現新歧義時補問，最多 2 問。
本地模板庫¶
邏輯集中在 lib/index.js（README 稱約 360 行）。packs/*.json 提供 15 個模板包、89 個決策點、246 個選項（每點帶 lv=1|2|3 影響度）。包按場景劃分，例如 web 覆蓋網頁/博客/官網/落地頁，generic 爲兜底。優先級數字越大越優先；同命中數按優先級取捨。packs/*.json 每 60 秒熱重載，改模板無需重啓 DSH；改 lib/index.js 需重啓 DSH。
成本與實現取捨（README 對照表）¶
插件刻意不註冊 clarify_options 類工具、不用常駐 system 段、不調輔助小模型。README 給出的量級：約 200 token / 會話（深入檔約 320），一次性；對比「一輪返工通常 2k～10k token」，作者認爲返工率略降即可回本。提示是「注入消息」而非系統指令，模型可能忽略——忽略則回到原行爲，屬於用可靠性換零常駐成本的取捨。
安裝與啓用¶
DeepSeek Harness 採用「一切皆插件」的擴展方式；社區目錄頁 skillhub.cn 上的 dsh-clarify-first 與 GitHub 倉庫相互獨立，並非 DeepSeek / 幻方官方應用商店。安裝前請自行查看源碼與 MIT 許可證；插件以當前 DSH 進程權限運行。
市場安裝（README 寫明「已上架後」）：
dsh plugin --profile desktop add dsh-clarify-first
本地開發掛載示例（路徑按本機修改）：
dsh plugin --profile desktop add link:F:\DSHproj\project\2026-10-31-prompt-clarify-plugin
# 然後重啓 DSH（插件在啓動時裝載）
停用或卸載：將 profile 裏 config.enabled 設爲 false，或執行：
dsh plugin --profile desktop remove dsh-clarify-first
配置項¶
在 profile 的 cordis.patch.yml 中，條目 id 爲 clarify-first，名稱 dsh-clarify-first：
- id: clarify-first
name: 'dsh-clarify-first'
config:
enabled: true # 總開關
minScore: 3 # 欠定義閾值：任務詞+2 產物詞+2 含糊詞+1 具體性-3
depth: 'auto' # 默認檔位 1|2|3；'auto' = 標準(2)。消息措辭與檔位文件優先
maxPoints: 0 # >0 時強制收窄第一輪問數（0 = 交給檔位）
gearFile: '' # 檔位文件路徑；空 = <DSH_HOME>/clarify-first/gear.json
packsDir: '' # 自定義模板目錄（絕對路徑；空=用插件內置 packs）
quietDirs: [] # 這些目錄下不觸發
debug: false # 命中原因寫日誌
觸發規則與典型用法¶
先做理解規則，再發第一條消息：
- 只看本會話第一條真人消息（
source.kind === 'user'）。歷史裏已有助手回覆，或已有第二條真人消息，插件不介入。 - 文本超過 120 字不觸發；「繼續 / 好 / 謝謝 / 你好」等不觸發。
- 出現具體性標記（框架名、路徑、
@文件、代碼塊、帶單位數字、「用 X 做」等）會扣 3 分——足夠明確的需求不應被打斷。調研/選型類（如「Hexo 和 Hugo 哪個好」）例外。 - 用戶在首條消息指揮本插件（如「優化一下澄清優先」）→ 不觸發。
- 用戶說「別問了直接做」→ 本會話永久靜音。
- packs 缺失、JSON 損壞、未知鉤子等異常 → 靜默放行，不阻斷對話。
典型用法：新開會話，用短句描述欠定義任務（如「幫我做一個網頁博客」），等待模型彈出 ask_user_question；需要少問時在首條消息寫「少問點」，需要多問寫「問細一點」。需要改默認檔位時編輯 <DSH_HOME>/clarify-first/gear.json 或上述 depth / gearFile。
適用場景與注意¶
適合：經常以模糊一句話開新會話、希望在一輪點選裏定形態/棧/部署/交付物等關鍵分叉的 DSH 桌面 profile 用戶。
注意：
- 只作用於會話首輪，中途改需求不會再次澄清。
- 選項來自模板庫，長尾需求靠推薦項與自由回答兜底，不是完整需求訪談。
- 依賴
agent/pre-step；DSH 大版本升級前，README 建議先跑node tools/smoke.mjs。 - 倉庫提供
tools/smoke.mjs（46 項斷言）與tools/route.mjs（34 條路由迴歸），改詞表或改包後應跑回歸。
結尾¶
dsh-clarify-first 用約 200 token 的一次性注入，把「先問 2～4 個關鍵決策再寫代碼」嵌進 DSH 首輪流程，並複用原生 ask_user_question，避免工具註冊與常駐 prompt 的逐輪成本。進一步瞭解可訪問目錄頁 https://www.skillhub.cn/plugins/skadery/dsh-clarify-first 與源碼倉庫 https://github.com/skadery/dsh-clarify-first。
