上次我们发了 DeepSeek Harness（dsh）的实测文章，评论区被问得最多的就是这一句：它到底能替测试开发干多少活？这个问题听着简单，其实没法一句话回答——测试开发这条线很长，从读需求到定位缺陷，每一段的"含金量"并不一样。所以这次不给感觉，给账本：我们把日常工作拆成五个环节，逐项交给 dsh 做一遍，再逐项打分，最后算一笔综合替代度的账。
环境准备
启动方式两种。求快的一行流（需要 Node.js 环境）：
npx @deepseek-ai/dsh web
# 默认 Web UI：http://127.0.0.1:3080
想跟着源码跑的：
git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web
模型接入需要配置 API Key，走环境变量即可：
export DEEPSEEK_API_KEY=sk-xxxx # Linux/macOS
$env:DEEPSEEK_API_KEY="sk-xxxx" # Windows PowerShell
dsh 原生接 DeepSeek 模型，也可以通过 LLM 适配器接其他模型。运行模式有标准、PTC、极简、创造四种，本次打分全程用标准模式。再提醒一次：官方明确说当前是 developer preview，会有破坏性变更，下面的分数只对当前版本有效。
任务怎么下发
为了口径统一，五个环节用同一个背景项目：一个库存管理 API（录入、查询、出库三个接口），文档和代码都放在本地目录里。每个环节单独下发一次任务，避免长链路互相干扰。用例设计环节的提示词样例长这样：
阅读 ./docs 下的接口文档和 ./app 下的代码，提取测试需求，
输出用例设计要点：包含等价类划分、边界值和异常场景，逐条列出，
每条写清楚前置条件、操作步骤和预期结果。
分项打分
| 环节 | 评级 | 一句话结论 |
|---|---|---|
| 需求解析 | 可用偏上 | 能从文档和代码里提取输入输出与规则；隐性规则会漏，需要人补 |
| 用例设计 | 强 | 等价类、边界、异常覆盖较全，是全链路里最出彩的一环 |
| 脚本编写 | 可用偏上 | pytest 形态良好、断言明确；偶有臆造接口，必须评审 |
| 执行调度 | 弱 | 能执行命令，但响应偏慢、长任务稳定性不足，偶发循环打转 |
| 缺陷定位 | 可用 | 能从日志里圈出可疑点并给假设；确认还得靠人 |
下面逐项说理由。
需求解析。 文档写得清楚，它提取得就齐：入参、出参、错误码都能列出来。但"库存为零不允许出库"这类没写进文档、只存在于业务方脑子里的规则，它不会凭空知道。解析的本质是翻译，翻译离不开原文——这一项的分数，其实有一半是给"文档和代码写得够不够清楚"的。
用例设计。 最省人的一环。它给的是具体可执行的用例描述，不是"测试正常流程"这种正确的废话；边界值会主动凑成对（刚好等于阈值、刚过阈值各一条），异常场景也知道往负数、超长字符串、缺字段上想。
脚本编写。 形态不错，会用 fixture、会参数化，断言具体到状态码。但它偶尔会编出不存在的接口，或者假设错返回结构，每一条都要人看。我们的做法是：生成完先跑一遍，红的先人工分类——是代码错还是用例错——再决定改哪边。
执行调度。 短板很明显：响应速度偏慢；任务链一长就容易不稳，实测中我们遇到过循环打转，反复读同一份日志不往前走；另外 API 成本随任务长度放大，长任务跑下来账单感受明显。建议拆段下发，每段有明确产出物，人守在旁边。
缺陷定位。 算是"好参谋"：给它失败日志，它能圈出可疑行、给出几种可能原因的排序。但从"可疑"到"确认"，中间隔着人工复现和验证，这一步它替不了。
打分背后：三件影响结论的事
分数之外，有三件事值得单独说，因为它们直接影响你怎么理解上面那张表。
其一，输入质量决定输出质量。需求解析得分高，前提是文档和代码写得清楚；我们把同一任务换到一份只有口头转述、没有文档的项目上重测，解析质量明显下滑。所以与其问"它有多聪明"，不如先问"我喂进去的东西够不够清楚"。
其二，速度是体感的一部分。dsh 响应偏慢，单个环节等几分钟很正常，五个环节串下来，等待时间相当可观。它更适合"挂着跑、人干别的"，而不适合坐在屏幕前盯着它一步步出结果。
其三，成本会随任务长度放大。环节越多、打转越多，API 账单越明显。我们实测中一次打转就多烧了一截 token。这提醒我们：把任务拆短、一次说清，不只是为稳定，也是为省钱。
算一笔综合替代度的账
最后做个加权粗算（权重按我们团队的日常工时占比估，仅供参考）：
| 环节 | 权重 | 可替代度 |
|---|---|---|
| 需求解析 | 15% | 约五成 |
| 用例设计 | 25% | 约七成 |
| 脚本编写 | 25% | 约六成 |
| 执行调度 | 20% | 约三成 |
| 缺陷定位 | 15% | 约四成 |
加权下来，综合替代度大约一半到三分之二。注意两个口径：其一，这个数指省下的是重复劳动的时间，还没扣评审耗时，把评审算进去，净收益还要打折；其二，替代度高的恰好是重复性强的环节，替代度低的恰好是需要判断的环节——这不是巧合。
所以结论很干脆：AI 替代的是重复劳动，不是判断力。铺用例量、写脚本骨架、跑命令、翻日志，这些 dsh 接得住；定测试策略、定验收标准、拍板风险，依然是人的事。它是强力助手，不是无人值守的替代者。
本文整理自霍格沃兹测试开发学社的原创分享，更多测试开发与 AI 测试实战内容，我们下一篇见。
