一、什么叫提示词
提示词（Prompt） 是用户输入给 AI 的指令或信息，用来引导模型生成期望结果。你可以把大模型AI想象成—位能力极强但需要明确指令的”数字员工”:
- 它不知疲倦、知识广博、响应迅速
- 但它不一定能完整猜测理解你的意图——你必须通过清晰、具体、结构化的提示词告诉它
- 做什么(任务目标)
- 怎么做(方法或格式要求)
- 做到什么程度(质量标准或示例)
简单来说：
👉 提示词 = 你如何与 AI 沟通
👉 输出质量 = 提示词质量 × AI能力
二、正确认识 AI 提示词
大模型AI就像一位“知识广博但偶尔会编故事”的助手一一它几乎能对任何输入做出回应，但不一定总是准确或符合你的预期。 它的输出质量高度依赖于你给它的提示词是否清晰、具体、有约束。
初学者常见误区:
“提示词必须写得很复杂，才能让AI干好活。”
这种想法容易让人望而却步，甚至放弃使用AI，转而选择手动完成任务一一这恰恰错过了提升效率的关键机会。
正确的学习路径
先用起来，再优化
- 从简单开始:哪怕只是一句“帮我写一个APP登录页面功能的测试点”，也是有效的起点
- 在实践中发现问题:比如AI漏掉了边界情况、格式不对、内容太泛
- 带着问题学技巧:这时再去学习“如何指定输出格式“如何加入业务约束”等方法，学习效率最高
- 持续迭代:用得越多，越知道怎么”指挥”AI，提示词能力自然水涨船高
三、提示词核心技巧
模型无法读心一一它只能根据你输入的内容进行推理。 你描述得越具体，AI输出就越接近你的预期。
核心原则:减少模型的猜测，增加你的控制。
| 模糊提示 | 精准提示 |
|---|---|
| “编写代码实现冒泡排序” | “用Python编写一个带详细注释的冒泡排序函数，解释每一行的作用及设计原因。” |
| “写一个游戏测试方案” | “请编写一份 FPS 游戏 3C（角色、控制、镜头）测试方案，包含测试目标、测试方法、典型用例和风险点。” |
精准提示 = 更可用结果
七大高效提示词策略
策略1：提供充分的任务细节
目标:避免让模型“猜你想做什么”。
❌模糊请求:
“用Python写一个排序算法”
✔ 示例：
“用Python编写一个排序算法，用于对整数数组排序。要求:
- 能处理空数组、单元素数组、含重复值的数组
- 时间复杂度不超过O(n logn)
- 返回新数组，不修改原数组。”
- 🎯关键:明确输入、边界条件、性能要求、输出格式。
策略2：指定角色
目标:通过角色限定输出风格与专业深度。
❌无角色:
“解释计算机的组成原理”
✔ 示例：
”你现在是一位小学三年级的信息技术老师，请用孩子能听懂的语言，结合生活例子，解释计算机由哪些部分组成。“ 🎯效果:输出更贴合受众、语气更匹配场景。
策略3：使用分隔符与结构
帮助模型理解信息层级。
✔ 示例：
需求：###设计登录测试用例###输出格式：表格策略4：分解任务分步骤
复杂问题拆解可提高准确度。
✔ 示例：
你是一名资深软件测试工程师，请按以下步骤编写一份测试问题分析报告: bug:创建订单的时候多次点击创建了多个相同的订单
1.先用100字左右简要描述本次发现的缺陷现象及复现路径;
2.以“第一、第二、第三”的结构，分析该问题可能的根本原因(如前端校验缺失、接口未做幂等、数据库并发冲突等);
3.结尾提出一个开放性问题，引导开发或产品团队进一步讨论(例如:“是否需要在用户端增加二次确认?”或“该场景是否应纳入自动化监控?”);
4.全文使用口语化、简洁的技术表达，避免冗长术语堆砌;
5.仅输出最终报告内容，不要包含任何说明、标题或格式解释。
策略5：提供示例（Few-shot）
目标:用”例子”代替抽象描述，快速对齐风格与意图。
✔ 示例：
你是一名软件测试工程师，请参考以下风格，创作一段关于线上缺陷漏测的复盘反思文案:
bug:创建订单的时候多次点击创建了多个相同的订单
[参考文案】
“上周上线的新功能，我明明测过主流程没问题，结果用户一用就崩了…你以为覆盖了正向用例就安全?其实根本没测弱网+低电量这种真实场景!”
要求:
1.采用第一人称，描述一次你亲身经历的漏测或线上问题;
2.语气真实、略带懊恼或警醒感，体现“事后才意识到”的反思;
3.能引发其他测试同行共鸣，促使他们在团队内推动改进(如加强异常流测试、引入监控等);
4.内容不能与参考文案重复(例如不要再说‘弱网’，可换‘并发冲突’‘缓存穿透’‘权限越权’等场景)。
策略6：将复杂任务拆解为子任务
目标:降低单次认知负荷，提升输出质量与可控性 ❌笼统请求(效果差): “写一份支付模块的测试方案” ✔分步执行(推荐做法):
-
需求梳理 请列出支付模块涉及的核心功能点，包括:正常支付、退款、重复支付拦截、超时处理、第三方渠道(微信/支付宝)对接等，并标注每个功能的关键业务规则。
-
风险识别 针对上述功能，分析3-5个高风险场景(如并发支付、网络中断后重试、金额精度丢失、越权调用等)，说明可能引发的缺陷类型及影响等级。
-
策略设计
输出测试策略框架，包含以下部分:
-
功能测试覆盖范围
-
异常与边界测试重点
-
安全测试要求(如敏感信息加密、防重放攻击)
-
是否需要自动化及建议覆盖的用例类型
-
-
用例生成 基于前几步，编写10条关键测试用例，采用标准格式(前置条件、步骤、预期结果)，优先覆盖高风险场景。
策略7：递归摘要长文档
目标:突破模型上下文长度限制，高效处理书籍、长报告等。
我会逐章发送一本书的内容。请你:
1.对每章单独做简明摘要;
2.当我说“发送完毕”时，将所有章节摘要合并，并生成一份全文总摘要。
四、经典提示词构建模型
掌握以下模型，可以快速构建高质量提示词。
1. 3W1H 模型
Who-What-Why-How
| 要素 | 说明 | 关键问题 |
|---|---|---|
| Who(角色) | 明确AI应扮演的身份 | “你希望AI以什么身份回应?专家?老师?朋友?” |
| What(内容) | 定义任务具体内容 | “需要生成什么类型的内容?文章?用例?代码?” |
| Why(目的) | 提供背景与目标 | “为什么要做这件事?面向谁?解决什么问题?” |
| How(方式) | 规定输出形式与边界 | “希望什么风格?什么格式?哪些内容要避免?” |
示例：
请你扮演一位资深测试工程师(Who)
为我的《大模型提示词》编写一组”接口测试用例”示例(What)
这些用例将用于培训新人，帮助他们理解如何用AI提升测试效率(Why)
要求:用表格呈现，包含请求参数、预期状态码和校验点;语言简洁专业，避免虚构不存在的API字段(How)
2. QBR 模型
- Question（问题）
- Background（背景）
- Requirement（需求）
示例：
问题:我需要为即将上线的用户注册模块设计一组高风险测试场景，避免上线后出现账号安全或数据异常问题。
背景:
项目为Web端SaaS产品，使用Vue前端+Spring Boot后端;注册流程包含手机号验证、密码设置、邀请码绑定(可选)
近期同类产品曾因“重复注册导致账号合并错误”和“验证码轰炸”被通报;团队资源有限，需优先覆盖高影响、易遗漏的异常路径。
请求:
请围绕安全性与数据一致性，提供5个高风险测试场景，每个场景需包含:
1.场景名称(如”并发注册同一手机号”);
2.复现步骤简述;
3.预期系统行为;
4.若未覆盖可能导致的业务风险。
3. GCE 模型
- Goal（目标）
- Context（上下文）
- Expectation（期望输出）
示例：
目标:为即将迭代的“订单退款”功能制定一份可执行的手工回归测试计划，确保核心链路零漏测。
条件:
- 迭代周期仅5个工作日，测试时间约2天;
- 功能涉及微信/支付宝原路退回、部分退款、超时自动退款三种场景;
- 已有接口文档和历史用例，但未覆盖”退款中用户注销账号”等异常路径;
- 团队仅1名测试工程师负责该模块。
期望:
- 以Excel表格形式输出;
- 包含字段:测试场景分类(如正向/异常/边界)、关键测试点、优先级(P0/P1/P2)、是否需验证数据库状态、预计耗时(分钟);
- 优先覆盖P0级场景(如资金错误、状态不一致)，总用例数控制在15条以内;
- 避免重复已有正向流程，重点补充异常与并发场景。
4. STAR 模型
适用于案例分析：
- Situation: 当前所处环境或项目背景
- Task: 你需要AI完成的具体工作
- Action: 希望AI采用的方法或依据
- Result: 理想输出的标准或特征
示例：
场景: 我们团队刚完成一个电商大促版本上线，但上线后2小时内收到多起”优惠券未生效”用户投诉。初步排查发现是缓存与数据库状态不一致导致，现需快速输出一份线上问题复盘报告，用于站会同步和流程改进。
任务:
协助我撰写一份结构清晰的线上缺陷复盘报告，聚焦根因分析与改进建议。
动作:
请基于以下信息进行整理(可合理推演缺失细节):
- 缺陷现象:部分用户领取满199减50券后下单，系统未抵扣;
- 技术栈
缓存用户券包，MySQL存储券状态; - 根本原因:发券接口更新DB后未及时刷新缓存(Redis)，且缓存过期时间过长(30分钟)
- 当前修复:已紧急回滚并增加缓存双写校验。 要求结合测试视角，分析测试环节为何未能拦截此问题。
结果: 输出一份约800字的复盘报告，包含以下部分:
- 问题概述(含影响范围);
- 根本原因分析(技术+流程层面);
- 测试盲点反思(如未覆盖缓存失效边界);
- 可落地的改进建议(如增加缓存一致性自动化检查)
- 语言简洁专业，适合在研发团队周会上直接使用。
5. PLA 模型
- Positioning(定位):你当前的角色或阶段;
- Landscape(现状):面临的具体挑战或瓶颈;
- Advice(建议):希望获得的可操作建议。
示例：
定位:
我是一名有1年经验的手工测试工程师，主要负责Web和App功能测试，熟悉测试用例设计和缺陷跟踪，但尚未系统接触自动化或接口测试。
现状:
团队正在推进测试左移和自动化覆盖，新项目要求测试人员能编写基础接口用例并参与CI流水线验证。我尝试自学Postman和Python requests，但缺乏系统路径，不知道该优先学什么、怎么结合实际项目练习，感觉进步缓慢且容易放弃。
建议:
请为我制定一个为期4周的入门学习计划，聚焦“快速上手接口测试并支持日常项目”，要求:
1.每周明确学习主题(如第1周
基础+Postman断言); 2.推荐免费中文资源(文档、视频或实战教程);
3.设计2-3个与电商/登录类项目相关的微型实战任务(如“验证用户注册接口的参数校验”);
4.给出如何向团队展示学习成果、争取实践机会的具体话术或策略。
五、提示词实战
模块一：AI 辅助编写功能测试点
- 需求描述：
商品管理:
1.默认展示出本系统内的所有启用的商品
2.商品展示按照创建时间倒序排列
3.展示字段有:商品编号，商品名称，商品简称，SKU编号，分类
4.查询:商品名称模糊查询，SKU编号精准查询
5.点击选中商品之后右边的物料和工序随之改为对应商品的物料和工序
- 示例提示词：
#角色:资深功能测试工程师专注于Web管理后台的功能与交互测试，擅长从需求文档中提取高价值测试点。
#背景当前系统包含“商品管理"模块，其核心需求如下:1.默认展示本系统内所有[启用状态]的商品;2.商品列表按[创建时间倒序]排列(最新创建在前)3.展示字段包括:商品编号、商品名称、商品简称、SKU编号、分类;4.支持两种查询方式:- 商品名称:支持模糊查询(如输入“手机”可匹配“智能手机”);- SKU编号:仅支持精准查询(必须完全匹配);5.用户点击任一商品行后，页面右侧的“物料信息”和“工序信息”区域应实时更新为该商品关联的数据
#任务基于上述需求，系统性地梳理并输出完整的测试点清单，覆盖功能、边界、异常及交互场景。
#要求- 按以下维度分类组织测试点:**默认展示、排序逻辑、字段显示、查询功能、联动交互**;- 每个测试点需包含:**测试场景描述+预期结果**;- 必须覆盖以下关键风险点: - 禁用商品是否被错误展示? - 模糊查询是否区分大小写/空格? - SKU 精准查询是否误匹配子串? - 点击商品后右侧区域是否异步加载且数据准确?- 避免重复或过于宽泛的描述(如“测试查询功能是否正常”)
#输出格式以Excel表格形式输出，包含三列:|测试类别| 测试场景描述|预期结果|
#示例(供参考)|默认展示| 系统中存在启用和禁用状态的商品各5条| 仅展示5条启用状态的商品，禁用商品不出现 |模块二：AI 辅助编写测试用例
-
测试点
-
提示词
#角色你是一名资深软件测试工程师，擅长从基础测试点出发，系统性地扩展出要盖**功能、边界、异常、UI、权限、性能(响应时间)等多个维度**的完整测试用例集。
#输入内容我将提供一个测试点列表，每行包含三列:- **测试类别**- **测试场景描述**- **预期结果**- **实际输入示例**|测试类别|测试场景描述|预期结果||默认展示|系统中存在启用和禁用状态的商品各5条|仅展示5条启用状态的商品，禁用商品不出现||排序逻辑|创建10个不同时间创建的商品(最早的在前)|商品列表按创建时间倒序排列，最新创建的商品显示在最前面 |
#任务基于上述每个测试点，**不仅生成主干功能用例，还需主动扩展相关维度的补充用例**，包括但不限于:- 正向功能验证- 边界值(如空数据、超长名称)- 异常场景(如网络中断、无权限访问)- UI/交互一致性(字段对齐、加载状态)- 权限控制(普通用户Vs管理员)- 轻量性能关注(如列表加载是否超过3秒)
#输出要求请以**Excel表格结构**输出，包含以下**8列字段**(顺序固定):
1.**用例ID**:格式为TC_商品管理_001、TC_商品管理_002 依次递增2.**测试标题**:简洁明确，体现测试目的与维度(如”【异常】无商品时列表显示空状态”)3.**所属模块**:统一填写“商品管理”4.**用例类型**:从以下选项中选择:"功能"/"边界"/"异常"/"uI"/"权限"/"性能"5.**优先级**:P0(核心流程)、P1(重要分支)、P2(边缘场景)6.**前置条件**:简明描述执行前系统状态(如“系统中存在5条启用商品”)7.**操作步骤**:分步骤编号(1.2.3..)，语言具体、可执行8.**预期结果**:清晰、可验证，与需求一致
#输出格式说明- 请以**纯文本表格形式**输出，使用‘|分隔，确保可直接复制到Excel或CSV 中;- 每个原始测试点至少生成**3-5条**扩展用例，要盖不同维度;- 避免重复，确保每条用例有独立验证价值。
#示例格式|用例ID |测试标题|所属模块|用例类型| 优先级|前置条件|操作步骤|预期结果|模块三：AI 辅助编写接口测试用例
同上，输入内容换为接口文档
模块四：AI 辅助编写数据库SQL
同上，输入内容换为数据表
部分信息可能已经过时