前言¶

团队里用 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（三层判定与真机冒烟清单）