光说不练假把式。我们给 DeepSeek Harness 设计了一场三关闯关实验：第一关写测试用例，第二关自己执行测试，第三关最狠——丢给它一段埋了雷的代码，让它找 Bug。一关比一关难，也正好能摸出这个 Agent 的能力边界在哪里。实验环境和此前实测一致：Node.js 环境，npx @deepseek-ai/dsh web 启动，标准模式，当前 developer preview 版本。三关围绕同一个背景展开：一个订单计价函数。
第一关：写用例
靶子函数如下：
def calc_order_price(items):
"""items: [{"name": str, "price": float, "count": int}, ...]
返回 (总价, 均价)；总额超过 100 打 8 折"""
total = 0
for item in items:
total += item["price"] item["count"]
if total > 100:
total = 0.8
return round(total, 2), round(total / len(items), 2)
我们只给了这个函数和一句话："为它编写 pytest 用例，覆盖正常流、边界和异常。"几分钟后 dsh 交卷，挑三条：
def test_normal_order_no_discount():
items = [{"name": "a", "price": 30.0, "count": 2}]
total, avg = calc_order_price(items)
assert total == 60.0 # 60 未超过 100，不打折
def test_over_100_gets_discount():
items = [{"name": "a", "price": 60.0, "count": 2}]
total, avg = calc_order_price(items)
assert total == 96.0 # 120 超过 100，打 8 折
def test_empty_items_raises():
# 边界：空列表，当前实现会除零
with pytest.raises(ZeroDivisionError):
calc_order_price([])
值得说的是后两条：折扣用例的期望值 96.0 算得对，说明它真的按规则推演过，不是抄模板；空列表那条，它不光想到了空输入，还在备注里写明"当前实现对空列表会除零"。边界意识在线。第一关，通过——生成快、方向对。
第二关：跑用例
第二关让 dsh 执行自己写的用例。它确实能执行命令、读回输出：
python -m pytest test_price.py -v
结果：跑起来了，失败摘要也给得像样，哪个用例挂在哪条断言上都能说清。但两个老毛病都犯了：一是响应速度偏慢，一轮分析要等一会儿；二是我追加"修正后重跑"的组合动作时，它打了一次转，重复读同一份日志，需要我人工提醒才继续推进。另外这种多轮任务越长，API 成本放大得越明显，短循环跑、跑完即结，更划算。第二关，勉强通过——会跑会看结果，但节奏得人来带。
第三关：找埋雷代码的 Bug
重头戏来了。我们把函数升级了一下，埋进三个雷（注释是标给读者看的，喂给 dsh 的是去掉注释的原码）：
def calc_order_price(items, discount=0.8):
"""订单总额满 100 打 8 折，返回 (总价, 均价)"""
total = 0
for i in range(1, len(items)): # 雷 1：跳过了第一件商品
total += items[i]["price"] items[i]["count"]
if total > 100:
total = total discount # 雷 2：需求其实规定只对超出 100 的部分打折
avg = total / len(items) # 雷 3：空列表时除零
return round(total, 2), round(avg, 2)
提示词只有一句："审查这个函数，指出所有缺陷。"dsh 的体检报告：
雷 1，抓到了。它指出 range(1, len(items)) 会漏掉第一件商品，还给了修正建议。差一错误是它的强项，静态读码的功夫在线；
雷 3，抓到一半。它提到空列表的除零风险，但归在"建议加防御性判断"里，没当成正经缺陷处理；
雷 2，没抓到。它认为打折逻辑"写得没毛病"——单看代码，total * discount 确实语法正确、逻辑自洽。问题出在业务规则上：我们手里的需求写的是"只对超出 100 的部分打折"。这条规则不在代码里，dsh 看到的只有代码，自然判它无错。
为了验证，我们把需求原文补进提示词又跑了一次。这回雷 2 被抓到了：它明确指出"全额打折与'仅超出部分打折'的规则不符"，并给出了分段计价的修正思路。同一个函数，差别只在输入里有没有验收标准——这大概是本次实验最有价值的一个观察。
第三关，部分通过：语法和明显逻辑错误抓得住，业务语义错误只有在规则被明确给出时才抓得到。
边界到底在哪
三关跑完，dsh 找 Bug 的边界很清楚：能抓的是"大家都认的错"——语法问题、差一、除零、明显不合理的控制流；抓不到的是"业务规则分歧"——折扣范围算错、状态码语义不对、字段映射错位，这些的正确答案不在代码里，在需求里。
所以实践建议也很实际：想让它找 Bug，就把验收标准跟代码一起给它，规则写得越具体，命中率越高；只给代码，它只能对"代码写得对不对"负责，没法对"代码做得对不对"负责。
本文整理自霍格沃兹测试开发学社的原创分享，更多测试开发与 AI 测试实战内容，我们下一篇见。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
