dsh-qa v0.2.0 更新：从测试看板走向可追溯的质量控制工作台
dsh-qa v0.2.0 更新：从测试看板走向可追溯的质量控制工作台
今年 8 月，dsh-qa 从一个运行在 DeepSeek Harness 里的本地 QA 工作台起步：需求、用例、缺陷、里程碑、报告和审批门禁可以留在同一个项目空间里。它解决的第一个问题很朴素——别让测试过程只剩在聊天记录、表格和不同系统之间来回搬运。
从 v0.1.3 到 v0.1.8，项目补齐了双语界面、测试覆盖和 QA Skill 的安装生命周期；9 月 1 日发布的 v0.2.0，把测试过程中的来源、执行和证据放进同一条可追溯链路。
本文梳理这轮更新如何让团队看清质量结论的来源、依据与决策责任。
如果还不了解工作台的基础能力，可以先阅读《质量工作台 dsh-qa：把 AI 测试工作台装进 DeepSeek Harness》；想顺着一个测试项目看完整流程，可以继续看《从需求分析到发布归档：一个测试项目如何用 dsh-qa 走完全流程》。
先把日常工作台做完整：双语、流程和可验证性
早期版本的改进看起来分散，实际上都在为日常使用清障。
v0.1.3 新增中英文即时切换，并把导航、首页、看板、日历、对话区以及抽屉和模态框标题纳入同一套语言体验。对于跨语言协作的测试团队，这不是把菜单翻译一下而已：看板阶段、操作反馈和项目上下文要在切换后仍然对得上，界面才不会成为流程里的第二套术语。
随后，v0.1.4 把 node:test 单元测试、Playwright 端到端测试和 GitHub Actions CI 串起来。质量工作台本身也需要被验证——看板投影、统计、日历提醒、HTTP API 与项目生命周期不能只靠一次人工演示来证明没有回归。
v0.1.5 延续了这一方向，完善 Quality Control Room、QA 分类看板和跨工作区的卡片交互。测试人员可以先看到待处理的风险、门禁和项目状态，再进入具体材料处理问题。
Skill 不再只是“装进去”：从发现到卸载都有状态
v0.1.6 至 v0.1.8 把重点放在 QA Skill 的使用路径上。
工作台新增按语言和分类展示的 QA Skill 安装页，补齐 qa preset 与相关端到端流程；之后的 v0.1.7 会在 Skill 卡片上显示已安装状态，并提供确认后的卸载操作与中英文反馈；v0.1.8 再优化已安装 Skill 的推荐逻辑。
这组更新解决的是一个经常被忽略的问题：可安装能力如果没有状态，就很难维护。用户不该猜某个 Skill 是否已经在 DSH 中可用，也不该为了清理不再需要的能力而手动翻目录。安装、识别、推荐和卸载构成一个完整生命周期，工作台才能把“技能库”变成可控的项目能力，而不是一堆一次性脚本。
这里仍有明确分工。dsh-qa 负责展示和管理本地安装状态；Skill 的内容与适用范围来自配套的 awesome-qa-skills；DSH 仍负责会话、模型、工具与权限。边界清晰，比把所有配置揉进一个界面更容易排查问题。
v0.2.0：把质量结论放回来源与证据里
v0.2.0 的核心是新的 QA 控制工作台。它围绕质量任务建立了几类彼此关联的记录：来源快照、风险、测试范围、测试计划、执行配置、受控本地运行、证据包、故障分析和回归集。
这是一种很重要的变化。过去，团队常常能看到一个“通过”的结论，却很难立即回答三个问题：
- 测试范围来自哪一版需求或代码？
- 这次实际按什么配置执行？
- 失败、跳过或例外留下了什么证据？
有了来源快照，测试范围不必只依赖后来被改写的描述；有了执行配置和受控本地运行，结果可以关联到当时的执行条件；有了证据包和故障分析，失败不再只是一行状态，而是能被复查、归因和纳入回归集的材料。
它把判断所需的上下文带回来。团队可以据此核对结论覆盖了什么、遗漏了什么，以及证据是否充足。
计算型门禁：给决策提供结论，不替人做决策
本次更新还加入了计算型质量门禁、交付报告、趋势和受控例外。门禁可以给出 PASS、WARN 或 BLOCK，用于辅助交付决策。
这三个状态用于风险沟通：
PASS表示当前规则与已记录证据满足通过条件；WARN表示存在需要明确评估或接受的风险、缺口或例外；BLOCK表示关键条件或证据不足，交付不应继续被当作已满足质量要求。
“受控例外”会把例外原因、风险承担人和复查时间写进记录；趋势则让团队看到问题是在收敛，还是同一种证据缺口反复出现。
这延续了 dsh-qa 一开始的权限边界：AI 可以整理材料、申请门禁、辅助分析；最终是否发布、是否接受风险，仍由负责人基于项目上下文作出决定。工具可以提高判断质量，不能替代判断责任。
项目详情升级为工作区
v0.2.0 还把项目详情升级成完整工作区：首页和看板卡片可以直接进入，首页最多展示五个在办项目。这个改动看似是导航调整，背后是信息组织方式的变化。
项目工作区聚合质量任务、范围、执行、证据、风险与交付报告。首页回答“现在需要关注什么”，工作区记录“为什么得出这个结论”。两层分开后，日常跟进更聚焦，需要追溯时也不用重新翻聊天记录和外部文档。
可靠性边界同样是这次更新的一部分
质量控制工作台开始执行本地受控运行后，安全与可靠性不再是可选项。v0.2.0 对来源路径边界、运行授权、最小化执行环境、进程树终止、证据恢复和配额管理做了加强，并修复了延迟持久化首次写入与详情刷新后门禁结果恢复的问题。
这些内容不一定最适合放在产品海报上，却直接决定记录是否可信。一个任务如果可以随意越过来源路径边界，或运行结束后遗留子进程，测试工作台就会反过来给本地环境制造风险；一个刷新后会丢失门禁结果的界面，也无法承担审计和交付沟通的角色。
发布说明记录的验证结果是：98 个单元/API 测试、20 个 Chromium 端到端测试通过，npm 包预检包含 49 个发布文件。它们说明的是该版本已覆盖的验证范围，不是任何具体业务项目的质量保证。
适合怎样开始体验
先选一个正在推进的小范围测试任务：冻结一份来源材料，写清测试范围，配置一次受控执行，把结果与证据包放回任务，再让门禁显示它究竟是 PASS、WARN 还是 BLOCK。
这样做能很快暴露团队真正缺的是什么：也许是范围定义，也许是环境记录，也许是回归证据，而不一定是再多一份 AI 生成的测试用例。
项目可通过 DSH 安装：
dsh plugin --profile web add dsh-qa项目地址：https://github.com/naodeng/dsh-qa
完整版本说明：dsh-qa v0.2.0 Release
dsh-qa 仍处于早期阶段，尤其是与仍在快速演进的 DSH 生态集成时，应从小范围、可复查的项目开始使用。但这次更新已经给出了一个更可持续的方向：AI 可以帮助测试更快地产出和整理信息，质量结论则必须始终连着来源、执行过程、证据与人的决策。