前言¶

團隊裏用 AI 寫代碼、寫文檔的流程越來越順，但很容易出現一種情況：AI 第一次給出骨架，人就直接在它上面改，改完看起來是”我寫的”，可真到要自己從頭搭的時候，搭不起來。這個問題在社區裏被叫做認知債——產出是你的，能力形成不是。

yu1842/xianshou-plugin（包名 dsh-plugin-xianshou，維護者 yu1842，社區目錄分類爲工作流）是給 DeepSeek Harness 的一個插件，實現的是《先手協議 · 防認知債的 AI 使用方案》。它不限制你用多少 AI，而是規定 AI 在什麼時點才能介入：在你自己出過手之前，AI 不能替你決定結構。下面介紹這個插件的定位、安裝和具體用法。

需要先說明：DSH 的理念是”一切皆插件”，插件生態由社區維護，本插件與 DeepSeek 官方沒有從屬關係。

一、它解決什麼問題¶

README 引用 MIT 媒體實驗室的一項 EEG 研究，結論是長期依賴 AI 生成會形成認知債。同一條研究裏有一個少被引用的對照細節：先獨立構建框架、再用 AI 增強的組，未見認知損害。

插件據此把”用不用 AI”變成了兩個更細的問題：AI 在哪一步可以進來、進來了多少有沒有留痕。對應關係如下：

插件的落點很明確：不禁止用 AI，而是在你自己出過手之前攔住 AI 替你決定結構。這是設計約束，不是暫未實現。

二、核心功能：十四個工具¶

插件向宿主註冊 14 個工具，覆蓋任務的建檔、執行、留痕、回收和驗收全流程：

1、xianshou_start：建檔並判區，三個判據必須由用戶回答。
2、xianshou_status：查看單個任務或列出全部。
3、xianshou_draft：提交醜版本，不足 80 字且無結構會被拒。
4、xianshou_mark：給段落打 [自]/[AI]/[改] 標籤。
5、xianshou_audit：計算比例，<30% 正常、30–60% 需回收、>60% 打回重做。
6、xianshou_deliver：交付並生成回收閘門。
7、xianshou_recall：提交三問答案，<80% 打回黃區。
8、xianshou_refusal：記錄採納 / 否決 / 部分修改。
9、xianshou_health：四指標一起看，不給總分。
10、xianshou_export：導出週報（markdown）或備份（json）或兩者。
11、xianshou_import：從備份恢復，默認 dry-run，只增不刪。
12、xianshou_camp：四周訓練營，開營 / 看進度 / 驗收。
13、xianshou_probe：記錄裸考，W1 基線、W4 脫離測試。
14、xianshou_guide：使用教程，目錄 / 某一章正文 / 切換學習路徑。

其中最關鍵的閘門是第 3 步到第 6 步：紅區任務必須先用 xianshou_draft 提交一版自己的醜稿，AI 的寫入類工具調用纔會被放行。

三、安裝與啓用¶

插件適配 DSH 版本 >=0.2.1-rc.1 <0.3.0，Node 要求 >=20.11。先從源碼構建並裝進一個隔離的 profile 試跑，不要直接裝進生產 profile：

npm ci && npm run build

# 裝進隔離 profile 試
dsh plugin --profile xs-test add file:/absolute/path/to/xianshou-plugin

# 確認真的生效，而不只是"列表裏有名字"
dsh --profile xs-test --dump-config | grep -A5 xianshou

第一行構建插件，第二行把插件註冊到名爲 xs-test 的隔離 profile，第三行檢查宿主是否真的加載了它。

默認的閘門模式是 gate.mode = ask：紅區任務沒落稿時彈審批，而不是直接拒絕。想先觀察兩週再收緊，改成 advisory；想強約束（比如訓練營場景），改成 deny。零配置也能跑——所有閾值都有默認值，省略即安全。

四、一個例子：走完紅區任務的一輪¶

下面按典型順序調用工具，演示一次紅區任務：

1、建檔定區：

xianshou_start   # 三個判據需要用戶回答

2、先自己寫醜稿，不足 80 字且無結構會被拒：

xianshou_draft

3、過程中給段落打標，區分自己寫的和 AI 寫的：

xianshou_mark

4、交付並生成回收閘門：

xianshou_deliver

5、到期在做回收三問，答不出會被打回：

xianshou_recall   # 三問正確率 <80% 打回黃區

6、用審計工具看 AI 介入比例：

xianshou_audit   # <30% 正常 / 30-60% 需回收 / >60% 打回重做

日常工作中不需要每個命令都敲，面板裏的任務臺賬會按上述狀態推進。xianshou_refusal 用來記錄某條 AI 建議是採納、否決還是部分修改，用來維護拒絕率指標。

五、控制台（Web 端）¶

插件是雙面包：宿主半邊提供工具與閘門，客戶端半邊在 DSH 側邊欄掛一個”先手協議”入口，點開是一個整頁面板，包含九個模塊：概覽 / 任務臺賬 / 先手閘門 / 留痕賬本 / 回收隊列 / 拒絕率 / 健康度 / 教程 / 設置。

面板裏使用 hash 路由（例如 #xianshou/tasks/xs-7f21?zone=red），刷新和前進後退都能成立——之所以用 hash，是因爲 DSH 前端對未知路徑返回 404，不會做 history fallback。面板在 900 px 導航轉橫排，560 px 卡片變兩列。

想看六種寬度下的真實渲染：

npm run preview     # 生成 docs/console-preview.html

裝完沒看到入口，先跑 npm run doctor 自檢，區分是包的問題還是宿主的問題。

六、明確不做的事¶

對應方案原文的”三個不做”，寫在這裏方便評估是否適合你的團隊：

1. 不做時長限制：證據不支持劑量假說，限時只會催生繞過。
2. 不做全面禁用：禁令換來的不是自控，是隱瞞。
3. 不用滿意度 / 打卡率驗收：它們在這個議題上與真實能力負相關。

插件也不假裝能測量你是否真的懂了。回收判分默認走用戶自評（0–2 分），理由是”自己有沒有記住”這件事只有本人能誠實回答。如果需要更硬的判分，換一個 RecallScorer 實現，而不是讓模型打分。

七、兼容性與開發¶

兼容性聲明覆蓋 npm 上真實發布過的 9 個 DSH 版本 × 7 種接縫組合，共 63 個矩陣單元，全部通過：

npm run test:compat    # 只跑矩陣（約 0.5 秒）
npm run test:report    # 重新生成 docs/COMPATIBILITY-REPORT.md

判定分三層：engines.dsh（安裝）→ VersionGate（加載）→ CapabilityProbe（運行期逐接縫降級）。注意矩陣覆蓋不等於真機實測，真機冒煙清單見 docs/COMPATIBILITY.md §6。

常用開發命令：

npm run build        # tsc → dist/
npm test             # 構建 + 生成令牌 + 全量測試（115 個用例）
npm run tokens       # 重新導出設計令牌 CSS
npm run sample       # 重新生成卡片樣例
npm run doctor       # 自檢入口爲什麼不出現

架構上，domain/ 不 import 倉庫其他層，也不 import node: 內置模塊，因此可以脫離宿主單測。加一個工具 = 寫一個 XianshouTool 子類並加進數組；加一條分區判據 = 加一個 ZoneRule；加一條宿主產品線 = 加一個 HarnessAdapter 子類，三者都不需要改已有代碼。

八、適用場景與注意¶

適合的場景：

• 個人或團隊想保持”先自己想、再讓 AI 補”的工作流，需要一個有強制力的閘門，而不是靠自覺。
• 訓練營、教學場景需要觀察和驗收學員在沒有 AI 的情況下能否獨立完成任務。
• 對 AI 介入比例有審計需求，需要留痕和週報。

需要留意的地方：

1. 插件在 DSH 進程內運行，享有當前進程的權限。安裝前應先讀源碼，確認威脅模型和許可證。本插件許可證是 MIT。
2. 閘門攔的是寫入類工具調用，紅區任務的判定標準來自 xianshou_start 的三個問題，需要使用者如實回答，否則分區失去意義。
3. 控制台入口依賴 DSH 側邊欄槽位，裝完沒出現入口先用 npm run doctor 排查。
4. 兼容範圍固定在 >=0.2.1-rc.1 <0.3.0，DSH 升級到 0.3.0 之後需要等待插件適配。

九、小結¶

這個插件的價值不在限制用量，而在把”AI 什麼時候可以介入”變成一條可檢查的規則：紅區任務沒有自己的醜稿，寫入類工具就過不去。配合留痕、回收和審計，它把”我自己想過”這件事從口號變成了可驗證的過程。目錄頁顯示當前星標爲 0，社區目錄分類爲工作流，是一個小規模但設計完整的插件。

• 社區目錄頁：https://www.skillhub.cn/plugins/yu1842/xianshou-plugin
• GitHub：https://github.com/yu1842/xianshou-plugin
• 文檔：docs/UI-INTEGRATION.md（槽位契約、權限判定順序、路由表）、docs/ARCHITECTURE.md（模塊職責、SOLID 落點）、docs/COMPATIBILITY.md（三層判定與真機冒煙清單）