如果你已经会做功能测试，也偶尔用 ChatGPT 帮忙写用例、改报告，这门课会带你再往前一步：把零散的 AI 用法串起来，变成一套能真正帮你完成工作的测试工作流。
不是写给已经很专业的测试开发，也不是写给想马上转程序员的人。它更适合已经在做功能测试、想把 AI 用进日常工作的人。
你可能会让 ChatGPT 帮忙写几条用例、润色 Bug、改一下报告，但每次都是临时问一句，没有形成稳定方法。
从“问 AI 要答案”，升级成“用 AI 分析、用 Agent 执行、用自己判断验收结果”。
你仍然是功能测试，但手里多了一套 AI 工具链：能提效、能表达、能排错、能沉淀，面对变化没那么慌。
用最直观的方式看结果：不是背很多概念，而是把“聊天 AI、测试经验、Agent 执行”串成一套能反复使用的工作方式。
拿到需求后，先让 AI 生成测试点、边界值、异常场景，再用你的业务经验补充真实坑点。
把口述、截图、录屏里的信息整理成开发愿意看的 Bug 报告，减少来回追问。
需求变更后，让 AI 先列出影响范围、优先级和检查清单，不再靠记忆硬扛。
能把任务说清楚，让 Agent 找文件、读需求、生成脚本、跑测试、看日志、整理结果。
这里不是要求你一下子变成很专业的测试开发，而是把功能测试日常工作拆成一块块技能，逐步接上 AI 和 Agent。
把需求拆成可测试对象。
把测试任务说成 AI 能稳定执行的指令。
让 AI 起草，人负责评审和校准。
让测试不再卡在“没有合适数据”。
把现象变成开发能定位的问题。
从“全点一遍”升级成风险驱动。
把 Agent 当执行副手，而不是聊天对象。
不用先成为开发，但要看懂脚本在做什么。
自动化真正值钱的部分，是失败后能判断原因。
从只看页面，升级到初步定位问题来源。
让测试结果变成清晰的发布建议。
AI 输出是草稿，测试人员负责把关。
把一次成功经验变成长期资产。
这套课分成四个阶段：把 ChatGPT 用顺、把需求变成测试资产、把 Agent 用起来，最后沉淀成自己的 AI-QA 工作台。
先从最熟悉的功能测试工作开始：Prompt、PRD 分析、用例生成、Bug 报告、回归清单、测试总结。
学习怎么给 Agent 下任务：读文件、生成脚本、执行 UI 自动化、分析接口和日志、定位失败原因。
拿真实项目或 Todo Demo 跑一遍完整流程，最后沉淀成 Prompt 库、脚本库、报告库和测试知识库。
商用课程的核心不只是“会问 AI”，而是学会把测试任务交给 Agent，并能检查它做得对不对。
学会说清目标、范围、输入、输出、验收标准，让 Agent 不只是回答，而是按步骤完成任务。
从“打开目录看看有什么”开始，逐步学会让它定位用例、生成报告、运行测试、解释日志。
学会校准：第一次人工复核，第二次半信任，第三次让它承担重复回归，自己专注风险判断。
每周 2-3 次，每次 30-40 分钟。入口不难，但每周都有明确产出：测试资产、Agent 任务、脚本、报告和个人工作台。
每周都设计成“知识点 + 练习任务 + 可交付成果”。学完不是只会聊天，而是能产出用例、报告、脚本和工作流。
从聊天 AI 的“告诉你怎么做”，过渡到 Agent 的“直接帮你做”。重点训练：如何把任务说清楚，如何验收结果。
优先使用她手头正在测的真实项目。没有合适项目时，用 Todo Web 应用演练 Agent 从理解需求到跑测试的完整流程。
可测试：添加、标记完成、删除、筛选、搜索、统计、刷新后持久化。
每张卡都可以直接复制，再把方括号里的内容换成自己的项目。越贴近真实业务，AI 越有用。
你是一个资深软件测试工程师。我要测试的功能是：[功能名称]。
功能背景：[这个功能给谁用，解决什么问题]
主要流程：[按 1、2、3 写出用户怎么操作]
业务规则：[限制条件、次数限制、权限、金额、状态流转等]
已知风险：[之前出过的 bug、容易漏测的地方]
请帮我生成测试用例，覆盖：
1. 正常流程
2. 异常输入
3. 边界值
4. 权限和安全
5. 网络/弱网/重复提交
6. 上游下游影响
输出格式：表格，列包含编号、优先级、场景分类、前置条件、操作步骤、预期结果、备注。
我测试时发现一个 bug，请帮我整理成开发容易理解的标准 Bug 报告。
我做了这些操作：
[步骤 1]
[步骤 2]
[步骤 3]
预期结果：[应该发生什么]
实际结果：[实际发生什么]
测试环境：[设备/系统/浏览器/App 版本/账号角色]
复现频率：[必现/偶现/试了几次成功几次]
附件信息：[截图、录屏、日志、接口返回，如果没有就写无]
请输出：Bug 标题、严重程度建议、前置条件、复现步骤、预期结果、实际结果、影响范围、还需要我补充确认的问题。
注意：不确定的地方不要替我编，先列成待确认问题。
这次需求/代码改动如下：
[粘贴需求变更、接口变更、页面变更或开发说明]
请站在功能测试人员角度，帮我分析回归测试范围。
请输出：
1. 直接受影响的功能
2. 可能被间接影响的功能
3. 必须回归的核心流程
4. 可以抽样验证的低风险流程
5. 需要重点关注的数据、权限、兼容性和异常场景
6. 回归优先级：高/中/低
7. 建议测试顺序
8. 如果时间不够，最小回归集合是什么
输出格式用表格，并说明每一项为什么要测。
我有一个 Web 系统：[网址]。
我想把下面的手工测试用例转成 Playwright 自动化测试脚本：
[粘贴手工用例，包括前置条件、操作步骤、预期结果]
请帮我生成脚本，要求：
1. 每个场景一个独立测试函数
2. 每一步都写注释，说明对应哪条手工步骤
3. 使用稳定的定位方式，优先使用文本、label、role、data-testid
4. 页面加载和接口响应要有合理等待，不要硬等太久
5. 失败时自动截图
6. 最后告诉我怎么运行这个脚本
7. 如果页面元素信息不够，请先列出你需要我补充的选择器或页面截图，不要乱猜。
请根据我的测试记录，帮我生成一份可以发给组长/项目负责人的测试报告。
本次测试功能：[功能名称]
测试时间：[日期]
测试环境：[环境、版本、设备、账号角色]
用例执行情况：[总数、通过数、失败数、阻塞数]
发现的问题：
[问题 1：现象、严重程度、当前状态]
[问题 2：现象、严重程度、当前状态]
请输出：
1. 测试结论：建议发布/有条件发布/不建议发布
2. 测试范围
3. 执行概况
4. 主要风险
5. 未解决问题列表
6. 建议下一步动作
7. 一段适合发到群里的简短总结
语气要求：专业、清楚、不夸大、不甩锅。
我的自动化测试脚本跑失败了，请帮我判断是脚本问题、环境问题，还是业务功能真的有 bug。
失败用例名称：[用例名称]
报错信息：[粘贴完整报错]
失败截图/页面现象：[描述或粘贴截图信息]
最近改动：[如果知道，写需求或代码最近改了什么]
我手工验证的结果：[手工操作是否也失败]
请按这个结构分析：
1. 最可能原因排序
2. 判断依据
3. 我应该先检查哪 3 件事
4. 如果是脚本问题，应该怎么改
5. 如果是业务 bug，Bug 报告应该怎么写
6. 需要我补充哪些信息
注意：先帮我缩小范围，不要一上来就重写全部脚本。
这不是一套简单的 Prompt 模板包，而是一条从 AI 提效到 Agent 实战的完整训练路线，陪你把零散 AI 用法串成真正能工作的能力。
适合刚开始使用在线 AI 工具的功能测试人员，先解决需求拆解、用例设计、Bug 报告和测试总结。
适合想真正把 Agent 用进工作的人，重点训练任务拆解、项目操作、自动化执行和失败排查。
适合需要有人带着做真实项目的人，用自己的业务完成一次从需求到报告的 AI + Agent 测试闭环。