质量工作台 dsh-qa：把 AI 测试工作台装进 DeepSeek Harness

在进入 dsh-qa 之前，先说明它所依托的平台。DeepSeek Harness，通常简称 dsh，是 DeepSeek AI 开源的 agent harness，核心架构是插件化——Everything is a Plugin。它提供本地 Web UI，让插件复用宿主的智能体能力，底层使用 Cordis 作为可组合运行时。

这个项目在很短时间内吸引了大量关注。截至 2026 年 8 月 20 日，官方 GitHub 仓库页面显示约 16.73 万 stars、1.79 万 forks。所谓“火爆”在这里有一个更具体的含义：大量开发者正在试用、扩展插件，也在快速暴露平台的边界。它不等于所有集成现在都已经稳定。

DeepSeek Harness 目前仍处于 developer preview（开发者预览） 阶段，官方仓库明确提醒后续会出现不兼容变更。这对 dsh-qa 很重要：工作台依赖宿主的插件和会话 API，平台快速演进时，用户需要把两个项目放在一起更新和验证。

对测试工程师来说，插件化的实际意义是：测试流程可以和驱动它的智能体对话处在同一个环境里。dsh-qa 就是从这里切入的。它先面对的是一个普通但很麻烦的问题——测试团队的日常工作，散落得太开了。

需求在文档里，用例在表格里，缺陷在系统里，里程碑在日历里，测试报告在邮件里。
AI 对话又是另一套：聊完的方案没人记，AI 登记的东西没人看，项目要的“过程资产”始终沉淀不下来。

dsh-qa（质量工作台）就是冲着这个问题来的。
它是 DeepSeek Harness 的一个本地测试工作台插件：把待办提醒、日历排期、项目概览、六列看板和 AI 协作放在同一屏，每个测试项目绑定一个独立的 DSH 会话，自动使用「测试模式」（preset id: qa）。

这里有一个边界需要先说清楚。dsh-qa 不是 SaaS 测试管理系统，也没有在界面后面藏一套独立的模型网关。它是围绕 DSH 的本地项目工作区：工作台保存测试材料，DSH 负责对话、模型目录、凭据、技能、命令、工具和权限策略。项目档案靠近代码，模型配置留在 DSH 里，各管各的，反而更容易维护。

从高层看，整个闭环是：

测试首页 → 项目 DSH 会话 → AI 工具调用 → 材料 / 看板更新 → 人工审批门禁

真正有用的是中间这段。对话可以产出需求、用例、缺陷或报告草稿，登记后的材料会进入项目，而不是随着聊天变长一起消失。

一张屏，装下测试项目的全部日常

打开工作台，第一屏就是测试首页：

• 在办项目、临期/逾期里程碑、待审批门禁、未关闭缺陷、最近动态，全部实时同屏
• 日历支持年/月/日跳转，点击日期即可登记里程碑或日程
• 逾期红标、7 日内临期黄标、待批门禁紫标，顶栏实时统计

项目管理层面，提供项目与迭代双形态：迭代可挂靠父项目，两者都绑定独立 DSH 会话，筛选栏分开查看。

测试首页是用来处理工作的，不是用来摆装饰的。它把在办项目、逾期里程碑、等待审批的门禁、未关闭缺陷和最近动态放在一起——否则测试人员很快就会重新打开五个标签页。日程和里程碑是两类记录，提醒事项不需要伪装成发布承诺。

六列看板，拖拽即更新

看板是标准的六列流水线：

需求分析 → 用例设计 → 用例评审 → 执行中 → 缺陷回归 → 已发布

卡片支持拖拽换列，SSE 实时推送，多窗口同步。
AI 每登记一条需求、用例、缺陷或里程碑，都会实时出现在看板卡片与材料流里——不用你手动搬家。

这也解决了 AI 测试里很常见的一件事：聊天里说“已经考虑过了”，项目里却没有任何记录。在 dsh-qa 里，登记后的材料有项目归属、有阶段，也有进入档案的位置。对话是工作台，看板和材料流是项目记忆。

AI 协作：可全流程、可按需、可关闭

dsh-qa 的 AI 协作是“可控”的，每个项目三种模式任选：

• 全流程辅助：AI 自动提取对话内容并登记上板
• 按需协作：你明确要求时才登记
• 完全关闭：只用工作台的项目管理能力

自动提取与首页提醒也可以分别开关。
AI 登记的需求可关联用例与验证目的；测试用例带优先级、需求追踪 trace 与风险标签；缺陷按业务影响定严重级别，并记录复现频率与影响范围；里程碑自动算截止日；测试报告带版本链。还支持直接导入 Playwright / Pytest 的自动化结果。

三种模式在实际项目里各有用途。全流程辅助适合拿着一份较大的需求文档开始建项目；按需协作适合先讨论方案、确认后再登记；完全关闭则保留一个没有 AI 自动提取的本地项目工作台。项目负责人可以切换模式，不需要搬迁项目。

门禁治理：AI 申请，人来批

需求评审、策略评审、用例评审、报告评审、发布、结项——这些门禁由 AI 提交申请，测试负责人人工审批。
质量决策权始终在人手上，AI 负责把流程跑顺。

这不是一句口号。门禁有待审批状态、审批决定和决定时间；被驳回的申请回到工作流里，不会悄悄把看板往前推进。测试负责人可以明确说“证据还不够”，这比一个看起来很聪明的绿色勾号有用得多。

每个项目，都是独立的 DSH 会话

dsh-qa 不维护第二套 API Key 或模型配置：

• 每个测试项目绑定一个以项目文件夹为工作目录的 DSH 原生会话
• 自动使用「测试模式」（preset id: qa），模型列表、模型切换、技能、命令、工具与权限策略全部来自 DSH
• 对话区输入 / 出现即时建议，技能与命令面板支持分类、搜索、点击插入

浏览器端也保持得很小：前端使用原生 JavaScript，不需要构建步骤；服务端使用 Node 原生 HTTP 和 SSE；DSH 集成通过同源路由挂载。它更像宿主里的一个工作区，而不是又造一套应用平台。

安装与快速开始

# 作为 DSH 插件安装（推荐）
dsh plugin --profile web add github:naodeng/dsh-qa

安装后重启 dsh web，GUI 侧边栏就会出现「质量工作台」入口。
首次使用前先安装测试模式 preset：

scripts/install-qa-preset.sh

不想装插件？直接独立体验：

git clone https://github.com/naodeng/dsh-qa.git
cd dsh-qa
npm start        # → http://127.0.0.1:8899

首次启动会自动创建两个示例（一个测试项目 + 一个迭代），带需求、用例、缺陷、里程碑、报告和待审批门禁，可以直接上手点。

建议先打开示例，再接入真实项目。它能直观看到项目与迭代的关系、待审批门禁如何出现在首页，以及同一批记录如何同时出现在看板、日历和项目详情里。

配套生态

• awesome-qa-skills：92 个中英测试技能，一键安装到 DSH 技能目录
• awesome-qa-prompt：多角色 QA 工作流
• 界面支持中英文一键切换、四套 QA 主题、可调工作区布局，以及复用 DSH Remote 的手机端配对

配套仓库各自负责不同事情：awesome-qa-skills 提供可安装的任务型技能，awesome-qa-prompt 提供角色与工作流提示词，dsh-qa 负责项目状态、材料记录、看板、门禁和本地档案。技能可以更新，工作台不需要跟着重写。

数据完全本机

插件模式数据存放在 ~/.dsh/dsh-qa/，独立模式存放在项目内 data/。
零 npm 依赖、无构建步骤，工作台与 DSH 都只监听 127.0.0.1。
测试项目的业务数据、对话历史，都在你自己的机器上。

本机边界也要理解准确：如果通过 DSH 使用模型，模型交互仍然遵循你在 DSH 中选择的服务商和配置。dsh-qa 不会把项目再上传到自己的服务，但“本地工作台”不等于“模型什么都看不到”。凭据与服务商选择始终由 DSH 设置明确管理。

适合谁

• 想给测试工作配一个统一入口的一线测试工程师
• 要在多个项目里统一测试流程与输出口径的测试负责人
• 正在把 AI 引入测试、又不想被“黑盒 AI”牵着走的团队
• 使用 DeepSeek Harness、想扩展现有能力边界的开发者

如果你已经在用 DeepSeek Harness，装一个 dsh-qa 只需要一行命令。
项目地址：https://github.com/naodeng/dsh-qa

最快的验证路径是：安装插件，安装 qa preset，打开示例项目，让项目会话登记一条需求，再检查看板卡片、材料流和门禁状态。这个小闭环比继续读功能清单更能说明工作台是否适合你的团队。

如果想继续看每条记录如何流转，可以阅读《从需求分析到发布归档：一个测试项目如何用 dsh-qa 走完全流程》。

项目现状与参与方式

dsh-qa 还处在早期阶段。核心闭环已经可以使用，但项目仍然会通过真实试用持续调整——会有粗糙的地方、缺少的便利功能，也会有一些随着团队反馈而变化的设计决定。

欢迎先拿一个小项目试用。如果工作台在哪个测试流程里表现得不够好，请提交 Issue，写清复现步骤、预期行为，必要时附上截图或日志。也欢迎提交 PR：文档、缺陷修复、测试覆盖、无障碍改进和小型流程优化都很有价值。提交代码前请先阅读仓库里的贡献说明和许可证。