企业官网建设流程全解析

1. 从一句“帮我写用例”到一套能复用的Prompt模板

如果你用过几个月的AI大模型，大概率有过这种体验：问它“帮我写几个测试用例”，它给你甩来十条天上地下、毫无重点的东西，甚至把需求和预期结果都编错了。但你让它“基于这份需求文档，针对登录模块的异常场景设计测试用例，覆盖空值、边界值和重复提交，用表格输出，前置条件和预期结果写清楚”，它就能给出像模像样的结果。

差别不在AI变聪明了，而在于提问方式。干软件测试这行，平时最烦的是需求不清、逻辑不全，到了跟AI打交道的时候，反而很多人忘了这茬——随手一句“帮我测一下”“给我写个用例”，换来的自然是AI“基于概率的脑补”。我在自己的团队里折腾了小半年，把常用场景沉淀成一套Prompt模板体系，覆盖需求分析、用例设计、自动化脚本生成、缺陷分析、测试报告、面试刷题这些场景，今天把核心思路和可直接抄走的模板整理出来。

先说清楚这套东西是干什么的。它不是某个具体工具，也不是某个大模型的专属玩法，而是一套“和AI高效协作的提问框架”。适合三类人：一是日常写功能用例、跟需求死磕的测试工程师；二是做自动化、写脚本但经常被重复代码折磨的测试开发；三是准备跳槽、想用AI快速刷面试题但不知道从哪下手的求职者。不管你用ChatGPT、Claude还是国内的大模型，模板的思路都通用，最多在个别指令词上微调一下。

2. 为什么Prompt模板比“随手提问”靠谱：三条底层逻辑

2.1 AI不是测试专家，它只是个“很会接话的实习生”

先说个扎心的事实：大模型看起来什么都懂，其实它更像一个知识面极广、但完全不了解你项目背景的实习生。你说“帮我测登录”，它不知道你的登录是短信验证码还是扫码，不知道密码规则是8位还是16位，不知道失败重试锁定几次，更不知道你的接口返回code是0还是200才算成功。它只能给出一堆通用答案。

所以Prompt模板的第一原则就是补上下文。把需求、业务规则、接口协议、历史案例这些“实习生需要知道的信息”结构化地喂给它，它才能给出贴近实际的内容。我见过很多人抱怨AI写的用例没法用，一翻输入记录，就一句话“写测试用例”，这不叫用AI，叫抽盲盒。

2.2 模板的本质是把“隐性测试经验”显性化

测试用例设计有很多隐性经验：等价类、边界值、场景法、因果图、正交试验，还有针对业务特定规则的判断逻辑。老测试靠脑子里的经验清单，新手靠背书本。Prompt模板能做的，是把这些隐性经验显性化，写进指令里，让AI每次都按这套清单走。

比如我常用的用例设计模板里，强制要求“覆盖正常路径、异常路径、边界值、权限场景、数据依赖场景、并发场景”六类，AI就必须沿着这些维度输出，而不是像没头苍蝇一样乱写。这相当于你给实习生一张检查清单，他照着打勾，质量下限就有了保障。

2.3 可复制的Prompt才是效率利器

很多人跟AI对话是“一次性聊天”，用完就没了，下次再遇到同样场景又重新从零开始问。实际上，测试工作里大量场景是重复的：每个迭代都要设计用例，每个版本都要写测试报告，每个新接口都要补自动化脚本。把这些Prompt固化下来，形成模板库，用的时候就改改项目名和需求描述，效率提升是几何级的。

我在实际项目中，把常见的十余个场景做成了模板，存在一个Markdown文件里，配合一些支持快捷输入的工具，基本能做到“开新迭代五分钟进入工作状态”。而且模板经过多轮实战修正，踩过的坑都写进了约束条件里，比我临时组织的提问质量高太多。

3. 一套好用的Prompt模板，长什么样：公共框架拆解

3.1 六要素框架：角色、上下文、任务、约束、格式、示例

我把一套完整的Prompt模板拆成六个部分，分别是角色设定、上下文输入、任务描述、约束条件、输出格式、示例参考。六个要素不是每次都要凑齐，但你要知道缺了什么会导致什么后果。

先看一个最基础的完整示例（用于生成登录功能测试用例的简化版）：

【角色】你是拥有10年经验的高级测试工程师，精通功能测试、接口测试和自动化测试。 【上下文】项目是一个Web管理后台，用户通过手机号+验证码登录。验证码有效期为5分钟，每天最多发送10次，同一手机号连续错误5次将锁定账号30分钟。系统要求所有接口鉴权统一通过JWT实现。 【任务】请针对“登录功能”设计测试用例，覆盖手机号格式校验、验证码正确性、验证码过期、验证码频繁发送、锁定策略、正常登录成功等场景。 【约束】用例必须有前置条件和明确的预期结果；数据构造方式要写清楚；不要设计重复用例；每条用例都有唯一编号。 【输出格式】使用Markdown表格输出，字段为：用例编号、用例标题、前置条件、测试步骤、测试数据、预期结果、优先级。 【示例】参考风格： | TC-LOGIN-001 | 验证码正确且未过期，登录成功 | 用户已注册手机号 | 1.输入手机号 2.点击发送验证码 3.输入正确验证码 4.点击登录 | 手机号:138****1234; 验证码:123456 | 登录成功，跳转首页，JWT已下发 | P0 |

拆开看每个要素的作用。

角色设定解决的是“AI用谁的视角干活”。你说“你是测试专家”和不说，效果差异很大。角色能让AI自动调用这个领域常用的方法论和术语，输出更对口。但角色别写得太虚，“资深测试工程师”就够，不用“宇宙级测试之神”这种，模型理解不了太浮夸的设定。

上下文输入是六要素里最关键的一环，也是大多数人做的最差的一环。上下文不只是需求描述，还包括业务规则、技术栈、已有的接口文档、环境信息、已知缺陷列表。信息越具体，AI输出的东西越能落地。反过来，你给的信息越模糊，它就越倾向于给“通用废话”。

任务描述要具体到“动词+对象+范围”。对比一下“帮我看看测试怎么弄”和“针对订单退款流程设计覆盖正常与异常路径的测试用例并标注数据构造方法”，后者任务边界清晰，AI知道你到底要什么。

约束条件是把关员。AI默认会追求“数量多、覆盖面广”，但实际工作中，很多时候你要的是“精而不是多”。写清楚“不需要兼容性测试”“只关注接口层，不考虑UI样式”“每条用例必须能独立执行”，能大幅减少返工。

输出格式决定了你拿到的产出能不能直接用。表格、JSON、代码、文本，不同场景适配不同格式。测试用例用表格，接口测试可以用JSON结构，自动化脚本直接给代码，测试报告用结构化分段。不指定格式，AI极大概率会给你一大坨markdown，你还要花时间整理。

示例参考是“给AI打个样”。这个要素最容易被忽略，但效果最明显。大模型非常擅长模仿，你给它一个风格示例，它输出就会往那个方向靠。比如我让AI生成接口自动化脚本，一定会在Prompt末尾附上一段我习惯的代码风格片段，这样生成的代码基本不用大改。

3.2 公共约束池：每个测试Prompt都该带的“通用咒语”

除了场景化的Prompt，我还维护了一批“公共约束池”，不是在每个Prompt里都写，而是按需往里加。这里挑几条最常用的分享一下。

一是“数据构造要明确”。AI很容易写出“准备一条测试数据”这种废话，加了这句约束后，AI会主动告诉你数据在哪里造、怎么造，是走前端页面、直接插库，还是通过接口造数，比默认输出强很多。

二是“需求冲突时给出风险提示”。这个约束很实用。AI在信息不全时，通常会默认假设“合理场景”，但测试工程师的价值恰恰在于发现需求里的模糊点。加上这句，AI会在用例后补充“待确认风险点”，这会逼着你去想需求里可能存在的坑。

三是“输出必须可执行，不要理论说教”。加了这句，AI就不会给你来一段“测试是保证软件质量的重要手段”这种废话。

四是“对于不确定的信息，明确标注‘需人工确认’”。这个能有效对抗AI幻觉。在真实项目中，AI会一本正经地编造接口返回码、响应字段，让它标注“需人工确认”，能显著降低误导风险。

4. 六大测试场景的Prompt模板实战

4.1 需求分析场景：从一段杂乱需求里提取可测点

刚接手一个需求文档，尤其是PRD写得比较潦草时，最容易漏测。我习惯先把需求丢给AI做一轮“需求可测性分析”，把模糊点先抓出来。模板是这样的：

【角色】你是需求分析师和资深测试工程师。 【上下文】这是我从项目文档中摘录的需求原文（见下方）。假设你对该项目的技术背景不了解，不要臆测技术细节。 【任务】请完成以下工作： 1. 提取该需求涉及的功能点，并标注优先级。 2. 识别需求中表述模糊、存在歧义、缺失前置条件的地方。 3. 针对每个模糊点，给出测试角度的“待确认问题清单”。 4. 给出该需求的高风险区域清单（容易引发线上故障的功能点）。 【约束】不要修改需求原文，不要输出完整用例设计，只做需求层分析。 【输出格式】使用列表分类输出：功能点清单、模糊项清单、待确认问题清单、高风险区域。 【需求原文】 （在这里粘贴需求描述）

实测下来，这个Prompt的价值在于“待确认问题清单”。它会把藏在需求里的逻辑冲突挖出来，比如“用户可退单，但已发货订单不可退”这种描述，AI会追问“发货状态如何定义？退款是否支持部分退？”“确认收货后是否还能售后？”这些问题，很多都是业务方当时没写明白的。

4.2 测试用例设计场景：三个步骤快速生成完整用例集

前面给的登录用例示例已经很完整了，这里补充一个“分步生成”的进阶玩法。对于复杂模块，一次提问往往输出不够深，我建议拆成三步走，每步一个Prompt。第一步先让AI理解需求和输出功能点清单；第二步基于功能点清单逐类设计用例，比如“针对订单模块的支付功能设计用例，只覆盖支付成功、支付超时、支付重复回调三种情况”；第三步对AI生成的用例做“反向检查”，让AI自己找漏洞。

这个“反向检查”的Prompt值得多说一句，它是这样的：

【任务】请审查下面这组测试用例，找出遗漏的场景和设计不合理的用例。 【审查维度】1. 是否覆盖正常流程和异常流程；2. 是否覆盖边界值；3. 是否覆盖权限和数据权限场景；4. 用例之间是否存在重复；5. 预期结果是否清晰可验证。 【约束】如果发现遗漏，直接补充新用例；如果发现重复，指出保留哪一条；不要为了凑数添加无意义用例。

这招本质上是“让AI给AI挑刺”。大模型在你给它一份结构化用例后，能比较稳定地找出逻辑层面的薄弱点。我常用它来做用例评审前的自查，能省一大半评审时间。

4.3 自动化脚本生成场景：让AI直接产出可落地的代码

自动化测试开发同学最常问我的就是“AI写的脚本能用吗”。我的回答是：能用，但前提是你把环境、库、规范、数据结构都交代清楚。拿Python+pytest+requests举例，一个模板是这样的：

【角色】你是测试开发专家，精通Python、pytest、requests库。 【上下文】项目使用Python 3.10、pytest 8.x、requests库。接口鉴权方式为：登录接口获取JWT token，放到Authorization请求头中，格式为“Bearer {token}”。测试数据统一放在config.py的字典中。 【任务】请根据以下接口定义，编写pytest接口自动化测试脚本。 接口定义： - 接口路径：POST /api/v1/order/create - 请求参数：product_id（int，必填）、quantity（int，默认1）、coupon_code（string，可空） - 返回结构：{"code": 0, "data": {"order_id": "xxx"}, "message": "success"} - 成功code为0，失败code为非0，message有具体提示。 【约束】请使用pytest的fixture实现token管理；断言使用assert，不引入额外断言库；测试用例不少于5条，覆盖正常下单、缺参、coupon_code非法、quantity边界（0、负数、超上限）、重复下单；代码必须可以被pytest直接运行。 【输出格式】先输出脚本完整代码，再输出运行说明。 【示例风格】参考我现有的代码风格： （附上一段你惯用的代码片段）

关键诀窍在“示例风格”这一栏。你把一两个自己项目里已有的函数贴进去，AI就能模仿出你习惯的命名、注释风格，生成的代码融入现有工程几乎不用改。另外记得在约束里写清楚“可运行”，否则AI会给你带上一堆没定义的依赖或变量。

4.4 缺陷分析与定位场景：把一段报错信息变成定位思路

测试过程中遇到问题，很多人习惯直接甩锅开发或者自己在代码里翻。其实AI在处理“现象到原因”的推理上有独特优势。我的Prompt模板是这样的：

【角色】你是精通后端开发与测试的专家，熟悉Python/Java、常见中间件和数据库。 【上下文】这是一个B/S架构的系统，前端Vue，后端Spring Boot，数据库MySQL，使用Redis缓存。以下是测试过程中遇到的报错信息，以及对应的请求参数、请求头和部分代码。 【任务】请分析可能的原因，按可能性从高到低排列，对每个原因给出验证方法，并给出最终的排查建议。 【约束】不要直接下结论说“一定是xxx”，要给出排查步骤；区分必现和偶现两种情况的处理思路。 【报错信息】 （粘贴日志/报错截图中的文字） 【请求数据】 （粘贴报文/参数） 【相关代码】 （粘贴关键代码片段）

为什么这个Prompt有效？因为它要求AI给出的是“验证方法”而不是“结论”。AI基于大样本训练，对报错信息往往能给出“可能是A，也可能是B”的多分支假设，配合它的“验证方法”，其实相当于白拿了一份排查清单。实测下来，对空指针、参数校验失败、缓存不一致这类问题，成功率相当高。

4.5 测试报告生成场景：把零散执行结果汇总成结构化报告

每个迭代结束写测试报告，也是重复劳动的典型。与其从用例管理平台导出数据后再手动添油加醋，不如让AI帮你起草，你再修数据。模板如下：

【角色】你是资深测试工程师，负责撰写版本测试报告。 【上下文】以下是我从用例管理平台导出的测试执行结果摘要（见下方）。版本范围、开发周期、测试周期见下方数据。 【任务】请生成一份结构化测试报告，包含以下章节：测试概述、测试范围与执行情况、用例执行统计、缺陷分析与趋势、质量风险评估、遗留问题清单、测试结论。 【约束】报告中不能编造任何数据；涉及具体数字的地方，使用我给出的数据；风险和结论部分给出客观表述，不要过度乐观也不要夸大问题。 【输出格式】使用Markdown分层分段输出，数据用表格展示。 【测试数据】 （粘贴用例总数、执行数、通过数、失败数、缺陷数、遗留问题等）

注意约束里那句“不能编造任何数据”，AI有时候会脑补出几个缺陷编号和状态，必须给它按死。数据都给它喂全了，它输出的报告基本就是结构完整、措辞客观的标准件，你只需补充少量业务上下文。

4.6 面试准备场景：AI刷题与自我介绍辅助的正确用法

热词里有一堆面试相关的内容，这里多说几句。面试题刷题是AI最擅长的事之一，但很多人的用法不对——直接问“软件测试面试题”，AI会给你拉一个题库，但你要背下来吗？没意义。更好的用法是“模拟面试官追问”，让AI根据你的回答不断深挖。模板：

【角色】你是资深测试面试官，来自大型互联网公司，面试风格犀利，喜欢深挖候选人简历和项目细节。 【任务】现在模拟一场软件测试工程师面试。你负责提问，我回答，然后你再根据回答继续追问，直到你把我的技术短板问出来。 【约束】一开始不要把所有题目一次性抛出，要一问一答推进；对每个回答，给出一句简短反馈，并继续追问细节；特别关注我在项目实战中的真实参与度。 【第一问】请从“介绍一个你印象最深的测试项目”开始。

实测感受是，这种“一问一答+追问问到底”的方式，能逼着你把项目细节想清楚，比背八股文有用得多。还有人说遇到那种直接让AI生成一段“银行软件测试自我介绍”的情况，我的建议是：AI可以帮你做结构和措辞优化，但项目数据必须是你自己的。可以这样给AI喂信息：“请帮我优化这段自我介绍，突出银行核心系统的测试经验，包括支付结算、存贷款模块，重点强调我对业务规则的测试设计能力”，把自己真实的经历填进去，效率很高。

5. 从单次问答到AI Agent工作流：测试场景的进阶玩法

5.1 把多个Prompt串成一条流水线

单个Prompt做单件事，终究还是“一问一答”。如果你想在测试工作中更进一步，就要学着把这些Prompt当成节点，串成一条工作流。一个我在用的例子：把“需求分析→用例生成→用例评审→自动化脚本生成”串成一条流水线。

具体做法是，先让AI输出需求分析结果和待确认问题清单，你确认后，把上一轮的输出作为下一轮Prompt的上下文输入。这相当于每个节点做了校准，下一轮就不是从零开始，而是在确认过的信息上继续加工。实际操作中，我会把第一轮输出的“功能点清单”直接粘贴进第二轮用例设计Prompt的上下文里，并加一句“请基于以上已确认功能点设计用例，不要再重复分析需求”。这样生成的用例非常贴需求，而且省掉了大量上下文重复描述。

5.2 用AI Agent管理回归测试数据

热词里有“AI Agent”，这里也展开一下。所谓Agent，说白了就是让AI有记忆、能调用外部工具、能自主完成多步骤任务。在测试领域，我目前用Agent做得比较成熟的一件事是“回归测试智能筛查”。

传统做法是每次发版前，测试要从全量用例里挑回归用例，凭经验、拍脑袋。现在我让AI Agent扮演“回归筛选助手”，输入两个核心信息：本次代码变更清单（从Git提交记录里拉出来）和存量用例集。Agent自动从用例集里筛出“受变更影响的用例”，并备注影响原因。跑完筛选后，再让Agent调代码覆盖率工具，核对关键变更点是否都被覆盖到。

这个流程的价值是，它把“凭经验”变成“基于变更影响面分析”。当然，Agent给出的是建议清单，最终是否执行回归，测试负责人还是要拍板。

5.3 提示词工程之外的三个细节

说点容易被忽略的细节。第一，AI的上下文窗口是有限资源，别把所有历史都塞进去。我的做法是每轮对话只保留“上一轮输出的关键结论”，其余全部清掉，从根本上防止模型被一堆无用历史带偏。第二，不同大模型的指令表现有差异，Claude在长文档理解上确实有优势，国内模型在中文业务理解场景也很能打，模板里的“角色”和“约束”两个要素要按模型微调。第三，Prompt模板不是一次成型，而是要像测试用例那样持续迭代，每次发现AI输出不对，先去检查是不是模板约束不够，而不是怀疑AI智商。

6. 新手最容易踩的六个坑：Prompt模板使用避坑清单

6.1 坑一：上下文里堆了100行废话，关键信息一个字没有

这是最早期的典型错误。有些同事喜欢把一整个PRD文档复制进对话，还全是那种几十页的产品描述，AI读起来吃力，输出自然跑偏。正确做法是提炼出关键业务规则、技术约束、字段定义，用最精简的结构化文字写入上下文。如果需求太长，先让AI提炼要点，同步确认后再做用例设计，反而更快。

6.2 坑二：约束条件太软，AI不听指挥

你写“请认真设计用例”和写“用例必须覆盖边界值、空值和重复提交三个维度，不满足则视为无效输出”，效果天差地别。AI对“认真”“尽量”“合理”这类词的理解是模糊的，但你对“必须”“严格”“不允许”的执行程度更高。约束条件要可验证、可度量，别用形容词表达，要用动词和名词表达。

6.3 坑三：输出格式过于自由，整理成本比手写还高

有个同学跟我吐槽AI写用例要花20分钟整理格式。我一看他的Prompt，完全没写输出格式。不给格式，AI大概率会给你一大段markdown叙述文，你要从中往回扒字段，当然累。任何场景的Prompt，一定在模板里固定好输出格式，这是零成本的整理节省手段。

6.4 坑四：让AI编造数据

这里分两种。一种是AI在测试报告里自己编数据，前面提到了，约束里要按死“不能编造任何数字”。另一种更隐蔽，AI生成接口测试脚本时，会默认构造一套“看起来合理”的账号密码、手机号、身份证号，但你的环境根本没有这些数据，脚本一跑就挂。解决思路是在约束里明确“测试数据必须从config.py读取，不得硬编码”，并在上下文里把现有测试数据粘贴进去。

6.5 坑五：不校验AI生成结果

AI幻觉在测试领域很危险。它会一本正经地给一个不存在的接口编写“预期返回”，还会假设“该接口应该返回code=200”，但实际你的项目code约定是0。任何AI输出都必须经过校验，尤其是代码类输出，跑一遍lint、跑一遍冒烟测试是底线。我的习惯是，AI生成的自动化脚本，必须跑通一次最小用例集才能进代码库。

6.6 坑六：把公司数据直接喂给AI

这个必须单独说。很多测试同学手一抖就把内部需求文档、客户信息、线上日志直接粘贴进公共AI工具，这在合规上是大忌。正确做法是脱敏。用假的手机号、去掉真实客户名称、简化内部系统名，只保留业务逻辑。对于有严格数据管控的公司，建议优先用私有化部署的模型或公司统一采购的内部AI工具，不要为了让AI写得准就把敏感数据往外送。

7. 模板之外：我的三点个人体会

用这套Prompt模板体系大概半年多，最大的感受不是“AI帮我省了多少时间”，而是它改变了我的工作起点。以前拿到需求，脑子里的第一反应是“怎么设计用例”，现在变成了“先让AI帮我梳理可测点和风险清单，我再叠加我的业务判断”。AI的价值不是替代人，是把大量低价值的“接线”工作干完，让你把精力花在真正需要经验的“判断”上。

另一点是，模板不是越复杂越好。我见过有些人做Prompt模板，恨不得写满500字约束，最后AI反而被各种规则绑架，输出变得僵硬。我的体会是，模型能处理的信息是有限的，约束写太多了模型会把注意力平分给每条，反而削弱关键约束的效果。现在我每个模板的约束尽量控制在三到五条，每一条都是踩过坑后沉淀下来的关键规则，宁缺毋滥。

最后分享一个小技巧：把模板存成代码片段，配合快捷输入工具使用，用关键字触发。比如输入“!uc”就自动带出用例设计模板，“!bug”就带出缺陷分析模板。这样实操时完全不用记住模板内容，业务流程顺滑得多。这套东西的原理一点都不神秘，本质上就是把测试领域的方法论翻译成AI能听懂的结构化指令，只要按这个思路去做，每个人都能构建出自己的Prompt模板库。

模板是死的，场景是活的。建议你把文章里的模板当成起点，跑到项目里结合实际需求改一版，再把它迭代成你自己的东西，用起来会比任何“拿来即用”的模板都顺手。