“工作中需求文档经常写的不全”，这是一个很大的问题，我并不知道您公司的业务和部门的情况，因为我最近在一个初创公司，业务并没有那么复杂，这边的产品是通过几个 skills 去写 prd，在 prd 实现后，会根据 prd 和具体代码实现的功能沉淀额外一份功能模块文档，所以我这边的需求文档质量比较高，在进行 ai 生成测试用例的时候，经过一个比较符合业务的 skills 生成的用例质量比较高，在我看来是直接可用的，只需要自己在一些 case 上做一些探索测试即可覆盖全面。 关于这部分内容，也能看出来不是测试这边调整能做到的，需要产研测一起配合，所以我刚刚提到部门规模和情况，如果是一些发展了很久的部门，业务很复杂文档数量庞大，这确实是一个需要解决的问题，以上只是我个人经验，希望对你有帮助

阿里开源了一个类似的框架，open-code-review，我最近也在尝试接入到公司测试环境，但是这个本身是纯白盒的，关于业务理解方面我也在探索，有搞头是一定的，前提是需要有足够的、高质量的需求文档让大模型做业务理解，通过 diff 的代码和足够的业务需求文档，是可以做到随着代码 push 去生成相关测试用例的

接入 ai 功能不代表适合做这种专项测试，我现在在做 agent 产品测试，就拿这个举例子。一开始我公司在探索阶段写出来的代码，根本没法按照正常的 agent 评测去做，没有上下文管理，没有记忆管理，有工具调用但是很混乱，这就没法进行流程上的评测了，只能通过 prompt - answer 看他能不能按照预期去回答。真正能不能去做这些测试，还是取决于你们那的开发情况怎么样

我是应届生，接触测试一年了，做 agent 测试半年多，最近半年一直在写各种 skills，一直以来我能意识到 skills 是有标准结构的，但是我在写的时候都是 skills 目录下一个 SKILL.md + scripts，这样能用，但是随着用起来，我需要增加一些 few-shot 提高 SKILL.md 的质量，需要写一些 skill 结束后的验证手段保证它真的按照我的 skills 去走，这就导致 SKILL.md 越来越大，反而不会完全遵守我的步骤流程，幻觉越来越严重，只能又删删改改。看完这篇文章我也有一些如何去调整的想法，非常感谢