企业官网建设流程全解析

目标：把散落在个人的"AI 使用小技巧"沉淀成团队级资产。
使用方式：复制 Prompt → 替换 {{占位符}} → 粘贴到 Cursor / Claude / DeepSeek / ChatGPT 使用。
分类：需求转用例（7 条）· Bug 分析（6 条）· 脚本生成（7 条）。
版本：v1.0

📖 使用总则

每条 Prompt 都遵循 6 元素结构：

1. 角色（Role）：你是什么专家
2. 背景（Context）：项目/业务/技术栈
3. 任务（Task）：具体要做什么
4. 约束（Constraint）：格式、边界、禁止项
5. 输入（Input）：需求文档、日志、代码片段
6. 输出（Output）：期望的格式和结构

⚠️ 通用注意事项：

• 敏感数据（用户手机号、金额、身份证）在贴给公有 AI 之前必须脱敏
• AI 输出必须人工审核后再作为交付物
• 每次使用后有明显改进空间的，反馈给 Prompt 库维护人

一、需求转测试用例（7 条）

P-01 · 从 PRD 生成完整测试用例大纲

你是一名10年经验的资深测试专家，熟悉互联网 B/C 端产品的测试用例设计方法（等价类、边界值、场景法、判定表、状态迁移）。 【背景】 - 产品：{{产品名称}}- 端：{{APP / Web / 小程序}}- 业务模块：{{模块名，如"订单支付"}}- 相关依赖：{{下游服务/第三方}}【任务】 基于以下需求文档，输出一份结构化的测试用例大纲。 【约束】 - 每条用例包含：编号、标题、优先级(P0/P1/P2)、前置条件、操作步骤、预期结果 - 分组：正向流程 / 异常流程 / 边界值 / 兼容性 / 安全 / 性能相关 - 每个字段必须具体，不允许"其他情况"这种含糊表述 - 边界值和异常场景占比 ≥40% - 明确指出你判断存在歧义、需要产品澄清的需求点 【输入】{{粘贴 PRD 原文，或核心业务规则}}【输出格式】 先给一个用例数量分布表（正向 X / 异常 Y / 边界 Z /...）， 再按分组用excel表格输出每条用例，并且格式符合metersphere格式要求 最后单独列一节【需求澄清项】。

P-02 · 从接口文档生成接口测试用例

你是一名接口测试专家，熟悉 REST API 设计和 HTTP 协议边界。 【任务】 基于以下 Swagger/OpenAPI 接口定义，生成完整的接口测试用例，包括正向、参数校验、鉴权、边界、并发。 【约束】 - 至少覆盖：1)正向：所有必填字段合法值2)参数校验：每个字段的必填、类型、长度、格式、枚举3)鉴权：无 token / 过期 token / 越权 token4)边界：字段最大最小长度、极值、特殊字符、SQL 注入类5)幂等性：重复调用是否有副作用6)并发：同一资源并发操作 - 每条用例给出：入参 payload、预期响应码、预期业务码、断言点 - 用 YAML 或 JSON 输出，方便后续导入自动化框架 【输入】{{粘贴 OpenAPI 或接口文档片段}}【输出】 - 用例总数 - 分类列表 - 每条用例的可执行 payload

P-03 · 补齐边界值和异常场景

你是测试边界思维专家。以下是我已经写好的正向流程测试用例，请专门帮我补齐"我可能想漏"的边界值和异常场景。 【约束】 - 只输出"我遗漏的"，已有的不要重复列 - 覆盖维度：数值边界、字符串边界、集合边界、时间边界、并发边界、网络边界、权限边界、状态迁移边界 - 每条用例注明"补漏"的原因（你是基于什么规则想到的） 【输入】{{粘贴已有用例}}【输出】 表格：用例|补漏原因|优先级

P-04 · 从交互稿/截图生成 UI 用例

你是移动端 UI 测试专家。 【任务】 基于上传的交互稿/截图，输出针对该页面的 UI 测试用例。 【约束】 - 覆盖：视觉一致性、交互行为、状态展示、异常态、空数据态、加载态、网络异常态、多语言、暗黑模式、无障碍 - 每个交互元素单独列一条用例 - 明确列出"设计稿中没交代但产品会追问"的问题 【输入】{{附交互稿图片，或以文字描述界面元素}}【输出】 按元素/交互分组的用例表

P-05 · 从用户故事拆分测试场景

你是敏捷测试教练。基于用户故事和验收标准（AC），拆分出所有测试场景。 【约束】 - 每条 AC 至少对应一个正向和一个反向场景 - 使用 Given-When-Then 结构 - 场景颗粒度："可以直接落成用例"级别 【输入】 User Story:{{As a... I want... So that...}}AC:{{验收标准列表}}【输出】|场景编号|Given|When|Then|关联 AC|

P-06 · 用例评审前的"自检 Checklist"

你是测试用例评审专家。请对以下用例做一次"自检 Review"，找出以下类型的问题：1)用例语义不清（换个人看不懂）2)预期结果模糊（如"正常显示"）3)步骤缺失关键动作4)边界/异常覆盖不足5)与需求描述不一致6)重复用例7)优先级判断不合理 【输入】{{粘贴用例集合}}【输出】 按用例编号列问题清单，附修改建议

P-07 · 用例转 MeterSphere/Zentao 导入格式

你是测试管理平台使用专家。请把以下用例转成可直接导入 MeterSphere 的 Excel 表格结构。 【约束】 - 列名固定：名称|所属模块|标签|前置条件|步骤描述|预期结果|编辑模式|用例等级 - 步骤描述用"[1] xxx [2] yyy"的编号格式 - 所属模块用 / 分层 - 编辑模式统一填 STEP 【输入】{{粘贴原始用例}}【输出】 Markdown 表格，第一行是列名，之后每行一条用例

二、Bug 分析与定位（6 条）

P-08 · 从错误日志推断根因

你是资深后端问题排查专家，熟悉 Java/Spring 技术栈。 【任务】 基于以下错误日志，推断可能的根因，并按可能性从高到低排序。 【约束】 - 每个根因给出：证据（日志里的哪一行）+ 排查方法 + 修复方向 - 明确标注哪些是"推测"，哪些是"高置信"- 如果日志信息不足，明确说"需要补充哪些信息才能确诊"【输入】 业务背景：{{做什么操作时报错}}时间：{{}}环境：{{生产/预发/测试}}错误日志：{{粘贴 stacktrace 及上下文日志}}【输出】1. 高置信根因（Top3）2. 待补充信息3. 建议下一步排查动作

P-09 · Bug 单去重与聚类

你是缺陷管理专家。以下是最近一周新报的 Bug 单列表，请：1)判断哪些是同一根因（去重）2)按现象/模块聚类3)找出最容易忽视的"低频但高危"Bug 【输入】{{粘贴 Bug 列表，每行含 ID、标题、模块、报告人、简述}}【输出】 - 疑似重复组：[BUG-1, BUG-3]因为 xxx - 聚类分组：模块 / 现象 / 触发条件 - 高危 Bug 提醒

P-10 · 从截图/录屏推断问题

你是资深前端/移动端问题分析专家。 【任务】 用户反馈了以下截图/录屏，请：1)描述你观察到的现象（视觉层面）2)推断可能的技术原因3)给出建议的排查方向 【约束】 - 不要编造用户没提供的信息 - 明确标注"看不清"或"信息不足"的部分 【输入】 用户描述：{{用户原话}}{{附截图/录屏截取的关键帧}}【输出】 - 现象描述 - - 可能原因 Top3- 需要用户补充的信息

P-11 · Bug 单质量 Review

你是资深 QA 主管，负责把关 Bug 单质量。请对以下 Bug 单做 Review，检查：1)标题是否包含"模块 + 现象"2)复现步骤是否可换人复现3)预期 vs 实际是否清晰4)环境信息是否完整5)是否有证据（截图/日志）6)严重程度 / 优先级 是否合理7)影响范围是否评估 【输入】{{粘贴 Bug 单原文}}【输出】 - 问题清单 - 修改建议（可以直接拿去改） - 严重程度/优先级 是否需要调整

P-12 · 生成 Bug 复盘报告

你是缺陷复盘专家。以下是本次迭代产生的 Bug 数据，请生成一份复盘报告，包含：1)Bug 类型分布（功能/性能/兼容/安全）2)模块分布 Top33)严重程度分布4)高频根因归纳（比如"边界值处理不当"、"接口未鉴权"）5)遗漏原因分析（用例未覆盖 / 需求边界不清 / 环境差异 / 其他）6)改进建议（下一迭代重点关注哪些方向） 【输入】{{粘贴 Bug 列表和分类字段}}【输出】 按1-6 结构生成 Markdown 报告

P-13 · 定位是前端还是后端问题

你是全栈问题定位专家。用户报了问题，你需要基于现象判断锅在前端还是后端。 【任务】 - 分析问题现象 - 给出定位方法（用什么手段确认） - 输出结论 + 置信度 【输入】 现象：{{描述用户看到的现象}}接口调用：{{如果有 network trace}}控制台报错：{{如果有}}后端日志：{{如果有}}【输出】 - 前端可能性：X%（依据：...） - 后端可能性：Y%（依据：...） - 确诊方法：{{具体动作}}

三、脚本生成（7 条）

P-14 · 生成 pytest 接口自动化脚本

你是接口自动化专家，精通 Python + Requests + pytest + pytest-html。 【任务】 基于以下接口定义，生成完整可运行的 pytest 测试脚本。 【约束】 - 使用 pytest 的 fixture 管理 token 和公共数据 - 每个用例独立，不依赖执行顺序 - 断言至少3层：HTTP 状态码 + 业务 code + data 字段 - 用 parametrize 处理多个测试数据 - 加中文注释说明每个断言意图 - 不要虚构不存在的 SDK 或 API 【输入】 接口路径：{{}}方法：{{}}入参：{{}}返回结构：{{}}测试场景：{{正向 + 至少3个反向}}【输出】 完整 .py 文件内容

P-15 · 生成 Selenium/Playwright UI 自动化

你是 UI 自动化专家。 【任务】 基于以下操作场景，用 Playwright（Python）生成自动化脚本。 【约束】 - 使用 Page Object 模式 - 元素定位优先用 role/text，避免脆弱的 XPath - 显式等待，不使用sleep- 每个断言前加中文注释说明检查点 - 失败时自动截图并附加到报告 【输入】 测试场景：{{分步描述用户操作}}目标 URL：{{}}测试账号：{{已脱敏}}【输出】 - pages/xxx_page.py - tests/test_xxx.py - 简要说明如何运行

P-16 · 生成 JMeter 性能测试脚本

你是性能测试专家。 【任务】 基于以下性能测试场景，生成 JMeter 测试计划（.jmx）的 XML 内容。 【约束】 - 使用线程组模拟{{并发数}}用户，Ramp-Up{{X}}秒 - 加合适的 Timer 模拟真实用户思考时间 - 每个请求加断言（状态码 + 关键字） - 加聚合报告和响应时间图 Listener - 参数化：从 CSV 读取用户数据 【输入】 被测接口：{{}}并发目标：{{}}运行时长：{{}}断言点：{{}}【输出】 - 完整 .jmx XML 内容 - 说明如何在命令行运行：jmeter-n-txxx.jmx-lresult.jtl-e-oreport/

P-17 · 生成测试数据构造脚本

你是测试数据工程师。 【任务】 生成一份 Python 脚本，用于批量构造{{数据量}}条{{业务对象}}测试数据。 【约束】 - 使用 Faker 生成真实感数据（中文姓名、手机、身份证脱敏、地址） - 覆盖多种维度：正常数据 X% / 边界数据 Y% / 异常数据 Z% - 数据落库方式：{{直接 SQL / 调用接口 / 写 CSV}}- 支持通过参数控制生成规模 - 生成前先输出一份"数据分布报告"【输入】 业务对象字段：{{}}业务约束规则：{{}}数据分布要求：{{}}【输出】 完整 Python 脚本

P-18 · Postman Collection 转 pytest 脚本

你是自动化框架迁移专家。 【任务】 把以下 Postman Collection JSON 转换为 pytest + requests 的自动化脚本。 【约束】 - 保留原有的环境变量和鉴权逻辑 - 断言迁移：Postman 的 pm.test 转成 assert - 结构：conftest.py 管理 fixture，每个 folder 对应一个测试文件 - 保留原用例名，加中文注释说明含义 【输入】{{Postman Collection JSON}}【输出】 - conftest.py - 各 test_xxx.py 文件 - requirements.txt - README 运行说明

P-19 · 生成 ADB / Monkey 稳定性测试脚本

你是 Android 测试专家。 【任务】 生成一份 shell 脚本，用于对 APP 做稳定性压测和数据采集。 【约束】 - 使用 adb shell monkey 做随机事件流 - 参数化：包名、事件次数、随机种子、日志目录 - 同时采集：CPU/内存（top）、logcat crash 日志、ANR - 每 X 分钟采集一次快照 - 输出简要报告：崩溃次数、ANR 次数、性能峰值 【输入】 APP 包名：{{}}测试时长：{{}}关注点：{{Crash / ANR / 内存泄漏 / CPU 尖峰}}【输出】 完整 shell 脚本 + 说明

P-20 · Code Review：AI 自动化代码质量审查

你是自动化测试代码审查专家。请对以下测试脚本做 Review，检查：1)是否引用了不存在的方法/库（AI 幻觉）2)是否有硬编码敏感信息3)是否有 sleep、依赖执行顺序等坏味道4)断言是否充分（不只是断状态码）5)是否有资源泄漏（连接未关、文件未关）6)是否有并发安全问题7)命名和结构是否符合团队规范 【输入】{{粘贴脚本}}【输出】 - 阻断性问题（必须改） - 建议性问题（应该改） - 加分项（值得推广的写法） - 修复后的示例代码

📌 Prompt 库使用规范

版本管理

• 每条 Prompt 都有编号（P-01 ~ P-20），后续新增按序编号
• Prompt 修改需在 Wiki 里记录 change log，包括修改人、修改时间、修改原因
• 每季度做一次 Prompt Review，淘汰用得少或效果差的

效果度量
每次使用后填写反馈（可选）：

• 用途：{{做什么任务}}
• 输出质量：优 / 良 / 差
• 是否需要多轮追问：是 / 否
• 是否需要人工大幅修改：是 / 否
• 改进建议：{{}}

敏感数据处理
以下内容贴 Prompt 前必须处理：

• 用户手机号、身份证、银行卡：脱敏为 139****1234
• 生产数据库表名/字段名：抽象化描述
• API 内网地址：替换为 https://api.example.com
• 员工姓名/花名：替换为角色名（如 “运营 A”）

团队协作

• Prompt 库放在 Confluence / Notion / Feishu Wiki，全员可读
• 谁写谁维护，署名 owner
• 每月团队周会花 15 分钟做 Prompt 分享，好的用法及时沉淀

🎯 首批 Prompt 推荐使用顺序

新人上手推荐按这个顺序试用：

1. P-08 从错误日志推断根因（最容易看到效果，10 分钟见效）
2. P-14 生成 pytest 接口自动化（能立刻用起来）
3. P-01 从 PRD 生成用例大纲（体会 AI 的用例思路）
4. P-03 补齐边界值和异常场景（体会 AI 的边界思维）
5. P-11 Bug 单质量 Review（体会 AI 的挑错能力）

跑完这 5 条，基本对 AI 在测试岗的能力边界有了实感。