别再手写用例了！DeepSeek Harness + Workbuddy 10分钟生成可评审用例

上个月团队来了个新人，我让他给一个优惠券系统的后端接口写测试用例。这哥们对着PRD文档憋了一下午，交上来28条。我扫了一眼，正常流程全覆盖，异常场景写了两条“参数为空”和“参数格式错误”，边界值一个没有。

我没批评他。三年前我也是这么写用例的。

问题不在于他不行，在于手写用例这件事本身的ROI太低了。一个测试工程师一天能写多少条有效用例？撑死五六十条，还得算上查文档、对接口、确认业务规则的时间。而这五六十条里，有多少是“该写但没时间写”的边界场景？我们自己心里都清楚。

最近把 DeepSeek Harness 和 Workbuddy 串起来跑了一轮，从上传接口文档到生成可评审的用例集，实际耗时不到10分钟。这篇文章把完整流程和踩过的坑都写出来，你照着跑一遍就能用。

先搞清楚这两个工具分别干什么

DeepSeek Harness（DSH） 是DeepSeek在2026年8月开源的Agent运行时，口号是“一切皆插件”。它的核心等式是：Agent = Model + Harness。模型是大脑，负责推理；Harness是手脚，负责让模型真正去读文件、调工具、执行命令。不是又一个聊天窗口，而是一套让AI能动手干活的工程底座。

Workbuddy 是腾讯的AI助手平台，支持自定义Skill开发。你可以把它理解成一个可以封装你测试经验和输出规范的工作台。

为什么要两个一起用？因为DSH给你的是执行能力，Workbuddy给你的是模型调用和Skill封装。单独用DSH也行，但如果你公司已经在用Workbuddy的模型额度（很多团队只采购了Workbuddy的积分），把Workbuddy作为DSH的模型提供方，就不用额外花钱买DeepSeek的API。

说白了：DSH负责“怎么跑”，Workbuddy负责“用谁的模型跑”和“按什么规范跑”。

安装：一行命令，但我在这卡了半小时

前置条件只有一个：Node.js 22或更新版本。

node --version

看到v22.x.x就OK。没有的话去Node.js官网装LTS版。

然后一行命令启动DSH：

npx @deepseek-ai/dsh web

这条命令会自动下载并启动Web UI，默认监听 http://127.0.0.1:3080。

我踩的坑：第一次跑的时候终端提示“node不是内部或外部命令”，但我明明刚装过。关掉终端重新打开就好了，环境变量没刷新。Windows用户大概率会遇到这个。

启动之后浏览器打开 127.0.0.1:3080，能看到DSH的Web界面就算通了。

把Workbuddy的模型接进来

DSH启动之后默认需要配模型。打开 Settings → Models，正常情况填DeepSeek API Key就行。

但如果你手头只有Workbuddy的额度，需要装一个第三方适配器插件：

npx --yes @axiaohungry/dsh-llm-workbuddy@latest install

装完重启DSH，回到 设置 → 模型，能看到多了一个 WorkBuddy 中国区 的选项。

认证方式有两种：API Key模式或者令牌登录。我用的API Key，在插件配置里填进去就行。装完之后DSH会自动从Workbuddy拉取当前账号可用的模型列表。

这一步的意义：你不用为了跑DSH额外买DeepSeek的API额度。公司现有的Workbuddy积分直接复用，Token消耗走的就是Workbuddy那边。

创建一个专属的“用例生成Skill”

这是整套流程里最值得花时间的一步，也是一次性投入、长期复用的东西。

在Workbuddy里新建一个Skill，把你团队对测试用例的规范要求全部写进去。不要只写一句“帮我生成测试用例”，太泛了，生成出来的东西格式五花八门，没法直接导入测试管理工具。

我的Skill配置是这样的：

输入：PRD文档（Word/Markdown/PDF）、接口文档、历史高频BUG列表（可选）

输出格式：固定表格，列头为 用例编号 | 所属模块 | 测试场景 | 用例类型 | 优先级 | 前置条件 | 操作步骤 | 预期结果

覆盖要求：

• 正常流程：主路径全覆盖
• 异常场景：空值、超长、特殊字符、非法枚举、接口幂等性
• 边界值：参数长度上下限、数值临界值
• 多条件组合：涉及多个业务规则交叉的场景单独列出

质量约束：每条用例的“预期结果”必须可验证，禁止写“系统正常处理”这种废话。

把这个Skill保存之后，以后每次生成用例都走同一套规范，不需要每次重新描述要求。团队里其他人也能直接用。

跑起来：上传文档，等结果

回到DSH的Web UI，在对话框里输入任务指令。

我用的提示词长这样：

读取 ./docs 下的接口文档和 ./app 下的代码，提取测试需求。输出用例设计要点：包含等价类划分、边界值和异常场景，逐条列出，每条写清楚前置条件、操作步骤和预期结果。

这条指令看着简单，但每个限定词都有用：

• “读取 ./docs 下的接口文档” → 限定数据来源，不让模型去猜
• “等价类划分、边界值和异常场景” → 强制覆盖三类场景，避免只生成正向用例
• “每条写清楚前置条件、操作步骤和预期结果” → 定义输出结构

然后把PRD和接口文档拖进工作区，点运行。

等待时间取决于文档大小和接口复杂度。我测的是一个库存管理API，三个接口（录入库存、查询库存、出库），实际生成时间大约7分钟，出了52条用例。

覆盖情况：

• 正常流程：18条
• 异常场景：21条（含空值、超长、非法类型、并发冲突）
• 边界值：13条（参数长度边界、库存数量上下限、价格精度边界）

其中我觉得手工写绝对会漏的几条：

• 出库数量等于当前库存时的并发扣减一致性
• 查询接口在分页边界（最后一页只有1条数据）时的返回结构
• 录入库存时商品ID为已删除状态的处理逻辑

复核：这8条你得自己改

DeepSeek Harness生成用例的准确率不低，但不是100%可用。我的体感是50多条里有8条左右需要调整。

常见的需要改的情况：

1. 预期结果写得过于笼统。 比如“系统应返回错误信息”——改成“返回HTTP 400，响应体包含 {"code": "INVALID_PARAM", "message": "库存数量必须为正整数"}”才叫可验证。

2. 业务规则理解偏差。 如果你给的PRD里某条规则写得模糊，模型会按自己的理解生成，可能和实际业务不符。这类必须人工确认。

3. 边界值取错。 比如接口文档写“库存数量范围 1-9999”，模型可能生成“库存数量为0”作为异常场景，但实际上0在业务逻辑里是允许的（表示无库存）。这种要对照代码或跟开发确认。

4. 优先级划分不合理。 模型倾向于把大部分用例标成P1，需要按实际业务风险重新分级。

所以正确的用法是：AI出初稿，人做评审和修正。 10分钟生成+1小时评审，对比原来1-2天纯手工写，效率提升是实打实的。

这套流程适合什么场景，不适合什么场景

适合：

• 接口文档相对完整的后端服务
• 业务规则有明确文字描述的功能模块
• 需要快速产出大量用例初稿的迭代节奏
• 团队新人需要快速上手某个模块的测试设计

不太适合：

• 需求文档极度模糊、全靠口口相传的老系统
• 强依赖领域专家经验的复杂业务（比如金融风控规则、保险精算逻辑）
• 需要精确到UI像素级交互的前端测试

说白了，文档质量决定生成质量。PRD写得越清楚，模型出的用例越能直接用。

一个延伸思路

这套“DSH + Workbuddy Skill”的方案，本质上是用开源Agent框架搭了一套轻量级的AI用例生成流水线。

如果你不想自己维护这套配置，或者团队规模比较大需要更系统的管理能力（知识库、用例版本管理、自动化执行对接），市面上也有企业级的智能测试平台在做同样的事。比如测吧爱测的智能测试平台，核心逻辑类似——需求文档进知识库，知识图谱驱动用例生成，生成结果支持自定义规范。区别在于企业级产品帮你把知识库构建、用例管理、自动化执行串成了一条完整链路，省去了自己搭插件的功夫。

但如果你只是想快速验证“AI能不能帮我写用例”这件事，DSH + Workbuddy这个组合是目前门槛最低的起手方式。一行命令装好，10分钟跑出结果，觉得有用再考虑下一步。

最后说一句实在的。写用例这件事，从来不是测试工程师的核心竞争力。理解业务、发现风险、判断优先级，才是。把手写用例的时间省下来，花在这三件事上，才是这套工具真正该被用的方式。