我这里用 claude code +csv+markdown，可以试试，比起撸代码直接调大模型去实现，从我的经验看，效率、效果不是一个 level 的

理解产品和用例规范

1. 把现有用例（excel）整理为 csv，然后按用例的模块字段拆分为子 csv，这些用例有场景用例、功能用例等
2. 让 claude code 理解下现有用例（可以逐个 csv 理解）。
3. 给 claude code 一个 用例 csv 模板以及 用例规范.md
4. 基本上有这些内容，claude code 就能理解你的产品，并根据需求去编写用例

理解需求并编写用例

1. 把 docx 转为 markdown。这一步试了各种工具，目前微软的 markitdown 转的比较好
2. 把一个整体的 markdow 拆解为 gitbook/obsidian 那种结构化的子 markdown
3. 现在 claude code 可以理解你的需求了
4. 让 claude code 全文需求分析一遍完整需求。我这里是个小型项目，产品需求文档 70 页，大约 10W 个 token，做个业务流程分析、数据流转分析之类的，再生成场景用例（那种 十几个操作步骤），也就 20 个场景。
5. 让 claude code 做个计划，按你提供的用例规范，逐个模块写功能测试用例，避免超过上下文。

效果

1. 上面这些过程，我全程几乎啥也没写，全都是告诉 claude code 如何处理，包括后面的生成技能，
2. 黑盒功能用例人工审核通过率在 80%。因为就是页面那些元素的描述和规则，这里的通过率是比较高的。
3. 场景要差一点，生成的 20 条场景，标题都是正确的，也就是对产品业务流程理解是完全正确的，但是步骤和期望写的不好，原因是这些步骤分散在需求各处，细节基本都是脑补出来的。
4. 问它一些关于业务的知识，或者是操作步骤，他都能分析出来，原理是他会通过搜索关键字，把所有相关的用例都找出来

token 耗费

我用的是 智谱的 coding plan，干上面这些活，400 万左右 token，最开始不太熟，反复了几次。

总结下

现在 claude code 都有百万 token 的上下文了，少说能理解 50 万字的需求文档了，而且也就在分析场景和编写测试要点的时候用一下，写具体模块用例的时候，就需要 grep 相关需求 +grep 相关用例的 csv 就行了，用 rag 过重了，而且 rag 要是文档拆分的不好，用例和需求的上下文都不连贯了，反而效果不好。

我在 windows7 尝试了上诉所有方法后仍无解，在系统目录下 adb version 查看版本为 1.0.29 在 sdk\platform-tools 目录下查看版本为 1.0.31
恼怒之下将 sdk\platform-tools 下的 adb.exe,AdbWinApi.dll,AdbWinUsbApi.dll 复制到 windows\system32 下竟神奇般搞定

这是 windows 下环境变量的生效次序问题，检查下你的%PATH% 变量，可能在多个目录下包含 adb 命令。