企业官网建设流程全解析

你有没有遇到过这种尴尬：问 AI “帮我测一下这个 App 有哪些问题”，它经常给出非常“正确”但完全无法落地的回答。它知道要测安装、启动、交互、异常场景，但它不知道你团队里缺陷单要写什么格式，不知道哪些页面是本轮迭代的核心冒烟路径，更不知道你的测试机上哪个版本才是当前要验证的包。

这背后是一个很现实的问题：通用 AI Agent 很强，但它缺少“专业经验”。而 2025 年以来技术圈里高频出现的 Skill，正是用来解决这件事的。Skill 可以理解为打包好的“岗位经验 + 技能手册”，让 Agent 在一个特定领域里不再泛泛而谈，而是按一套可复用的标准动作去执行。

这篇文章要写的就是：怎么用 90 分钟时间，把一套“APP 测试 Skill”做出来，装进你的 AI Agent 工作流里，让它从“聊天助手”变成“测试搭子”。我不会只讲概念，会直接给你可复制的 Skill 文件内容、使用流程、验证方法和常见坑。

1. 这篇文章真正要解决的问题

先说一个比较直接的判断：**纯粹让 AI 大模型聊天式地回答问题，解决不了工程问题；让 AI 按固定流程、固定规范去执行一个领域的任务，才叫真正把 AI 用起来。**Skill 就是连接这两者的桥梁。

为什么是 APP 测试这个领域？因为 APP 测试有非常明显的“经验化”特征：什么样的功能改动会影响登录流程，什么样的页面需要做弱网测试，缺陷报告里应该包含哪些字段，冒烟用例要覆盖哪几条主路径。这些经验过去要么存在测试负责人脑子里，要么散落在团队的测试文档里，要么根本没沉淀下来。新同学接手项目时，最容易出现的问题就是“不知道从哪测起”。

如果把这份经验写成一个 Skill，交给 AI Agent 去调用，会发生什么？Agent 会按照你定义的执行规范，自动输出一轮适配当前产品的测试计划、测试用例、问题报告框架。它不再是“想到哪里写到哪里”，而是每次都在同一个质量基线上输出结果。这对团队的意义不是“AI 替人干活”，而是“把团队里最靠谱的那套测试打法，复制到每一个需要的人面前”。

这篇文章适合这几类读者：

• 测试开发工程师、QA 工程师：想用 AI 辅助用例设计和问题分析，但不知道从哪里切入。
• 移动端开发工程师：希望提交代码前能快速自查一轮关键功能回归。
• 对 AI Agent 感兴趣但还停留在“聊天”层面的技术人：想理解 Skill 的真实价值，而不只是看各种花哨演示。

读完之后，你会掌握以下技能：Skill 的基本概念和它与 Agent、MCP 的关系；一个 APP 测试 Skill 的完整结构怎么写；如何把 Skill 配置到自己的 AI 编程工具或 Agent 环境中；如何验证 Skill 是否生效；以及真正上线使用时的工程注意项。

2. Skill 是什么，为什么最近大家都在聊

2.1 一句话定义

Skill 是给 AI Agent 使用的一组“可复用的专业能力封装”。它一般是一个包含提示词指令、执行步骤、检查清单、参考示例、甚至可调用脚本的目录或文件集合。

通俗一点讲：Agent 是一个刚毕业、聪明但缺乏经验的实习生，Skill 就是某个岗位的“入职培训手册 + 工作流规范 + 常用工具清单”。这个实习生本来有很强的学习能力和执行能力，但没有手册时它会自由发挥，结果时好时坏；有了手册，它才知道“在这个岗位上，遇到什么情况应该按什么流程走”。

2.2 为什么 Skill 在 2025 年突然变热了

从技术发展的路径看，AI 编程助手和 Agent 已经解决了“能写代码”“能执行任务”的基础能力，但使用过程中暴露出的新问题是：通用模型不够“懂行”。同样一个任务，放在不同行业、不同团队、不同工具链里，正确做法完全不同。比如“修复一个登录 bug”，对电商团队是找回密码逻辑问题，对银行 App 团队可能还涉及设备绑定和安全校验。模型不知道你的团队规范，只能给出通用建议。

Skill 恰好补上这个缺口。它不是让模型重新学习，而是由人类把领域经验结构化地写出来，装进 Agent 的上下文里。这样 Agent 执行任务时就不是“凭感觉”，而是“按你的规则办”。这就是为什么 Skill 相关的搜索、讨论在开发者圈子里越来越密集——因为大家开始意识到，调教一个 AI，关键不是提问技巧，而是给它一套“工作规矩”。

2.3 Skill、Agent、MCP 到底有什么区别

这三个概念经常一起出现，但如果分不清，后面配置 Skill 时容易迷茫。

更直白一点：MCP 解决的是“Agent 怎么连上外部世界”的问题，Skill 解决的是“Agent 连上之后该按什么套路干活”的问题。你可以没有 MCP 也能用 Skill，因为 Skill 本身可以先是一份纯文字规范；但如果你想在测试过程中真正调用 adb、模拟器、自动化测试工具，就需要 MCP 或脚本机制来打通工具链。

新手最容易有的误解是：Skill 只是“一段更长的提示词”。不完全对。它确实基于提示词，但 Skill 更强调“结构化、可复用、可组合”：同一个 Skill 可以反复加载到不同任务中，同一组 Skill 可以组合成一个更复杂的 Agent 工作流。它本质上是在给一个通用模型“补专业上下文”。

3. 为什么 APP 测试特别适合用 Skill 来调教

3.1 APP 测试有天然的“流程化”基因

APP 测试相比纯算法或底层开发，更像一门“经验密集型的手艺”。正经的测试流程大体上可以分为：需求分析、测试计划、用例设计、环境准备、执行测试、缺陷管理、回归验证、测试报告。这套流程在不同公司、不同项目里高度相似，差异只在于具体细节。

这就给 Skill 提供了很好的生长土壤。因为 Skill 本来就是用来沉淀“重复但又有专业门槛”的经验。你不需要让 AI 每次重新发明测试流程，只需要把团队验证过的那套做法写成规范，然后让 Agent 每次按规范执行。

3.2 测试规范可以被显式表达

Skill 的编写非常依赖“能否把隐性知识显式化”。测试领域恰好适合做这件事：用例要覆盖哪些模块、安装启动要验证哪些状态、弱网场景应该关注什么、缺陷单要包含哪些信息。这些内容完全可以写进一个 Markdown 文件里，作为 Agent 的指导文件。

举个例子，一个智能简历工具的智能评分功能正在测试中。团队知道几个关键点：评分的计算逻辑是 5-10 秒内返回、分数区间要正确、特殊情况如超长简历和空简历要单独处理。把这几条写成一份测试重点检查单，放进 Skill 中，Agent 就能在实际测试中主动关注这些高风险区域，而不是等到用例写完了才发现漏了关键场景。

3.3 核心验证可以借助脚本工具完成

Skill 不只是写文字规范，还可以搭配脚本工具。比如在 Agent 的工作目录里放一个 Python 脚本，用 adb 命令检查连接的设备、获取当前 App 的版本号和包名、甚至快速做一个启动耗时统计。Agent 在执行测试任务时，可以调用这个脚本获取真机信息，而不是只靠“想当然”。

这一点很关键：Skill 让 Agent “懂测试流程”，脚本让 Agent “动真机环境”，两者结合起来，AI 才真正能从一个建议者变成干活的搭子。

3.4 见效周期短，90 分钟足够跑通全流程

Skill 的开发门槛其实很低。它不要求你会复杂的 Agent 框架，不要求会写插件，只需要按结构化方式整理一份规范文档，再加上一点简单的脚本能力。这也和标题里的“90 分钟”是吻合的：前三十分钟理解概念、理清结构；中间四十分钟把示例 Skill 改成自己的；最后二十分钟配置进 Agent 并验证一个测试任务。这个速度，刚好处于“学到东西”和“不会太累”之间。

4. 环境准备与前置条件

在动手写 Skill 之前，先明确需要准备什么。因为 Skill 的具体加载方式在不同平台上有差异，这里不强行绑定某个工具，而是给出通用思路。

4.1 你需要准备的软件环境

关于版本，需要提醒一下：不同 AI 工具的 Skill 加载方式和目录结构存在差异，网上流传的安装路径并不完全通用。写文章时不给你编造一个“官方标准路径”，因为目前 Skill 还没有完全统一的跨平台标准。更稳妥的做法是：先确认你用的工具支持哪种 Skill 格式，再按它的文档来放置文件。

4.2 Skill 的目录结构建议

虽然各平台目录结构可能不同，但通用结构一般是：

app-test-skill/ ├── PROMPT.md # Skill 的核心提示词，定义角色、流程、规范 ├── SKILL.md # Skill 的元信息，描述适用场景和启用条件（可选） ├── checklist/ │ └── smoke-test.md # 冒烟测试检查清单 ├── templates/ │ └── bug-report.md # 缺陷报告模板 └── scripts/ └── check_app.py # 辅助脚本，比如获取设备信息、App 信息

这个结构清晰，且可以按实际需要扩充分支。核心是 PROMPT.md，其余的目录都是辅助材料。Skill 目录越小越好，不要一上来就写几十个文件，先跑通再扩展。

4.3 验证你的工具支持 Skill

不同工具对 Skill 的处理方式不同：

• 有些工具是在对话中通过特殊指令加载某个 Skill 目录。
• 有些工具内置了 Skill 市场，直接安装。
• 有些工具其实不支持“Skill”这个词，但支持自定义指令、自定义提示词、项目规则文件，本质上也能实现类似效果。

建议你先做一个最小验证：写一个只有 20 行内容的 Skill 文件，放到工具能读取的位置，然后问一个问题，观察回答是否包含你定义的规范。如果回答有变化，说明 Skill 机制生效了。

5. 核心流程拆解：从零做一个 APP 测试 Skill

5.1 明确这个 Skill 要解决什么

动手前不要急着写内容。你至少要想清楚：你的测试 Skill 是给谁用的，用在什么场合，期望输出什么。是让 AI 帮你生成测试用例？是让 AI 帮你分析 bug 报告？还是让 AI 直接指挥一个自动化测试脚本跑一轮冒烟测试？

不同目标，Skill 的内容完全不同。

我的建议是：第一版 Skill 不要贪大，聚焦一个高频痛点上。比如“冒烟测试用例设计”，或者“缺陷报告规范化”。先把一个场景做到可用，再逐步扩展。

5.2 设计 Skill 的执行流程

APP 测试 Skill 的核心执行流程可以拆成六步：

1. 识别测试目标：明确被测 App 是什么、本轮测试范围是什么。
2. 获取基础信息：调用脚本获取设备信息、应用版本号、包名。
3. 生成测试计划：根据测试范围，按 Skill 中定义的模块优先级生成用例清单。
4. 执行并且输出用例：按模板输出可执行的用例，包含前置条件、步骤、预期结果。
5. 分析缺陷：如果收到 bug 描述，按团队规范分析根因和复现步骤。
6. 输出测试报告：汇总测试结果、风险点、遗留问题。

这六步不是死的，但第一版写死一点其实更好。Agent 拿到一个明确流程时，执行质量会明显高于“你自由发挥”。

5.3 编写 PROMPT.md 的关键原则

PROMPT.md 是整个 Skill 的灵魂。它的质量直接决定 Agent 输出的质量。这里有几个实际经验可以分享：

• 角色要具体。不要写“你是一个测试专家”，要写“你是一个移动端 APP 测试工程师，熟悉 Android 和 iOS 的常规测试方法，擅长在有限时间内设计高覆盖率的冒烟用例”。
• 流程要编号。Agent 对编号步骤的执行力高于对“最好按如下顺序”这类模糊指令。
• 模板要直接给。不要只描述缺陷报告应该包含什么，直接把模板 Markdown 写出来。
• 要有反面约束。明确告诉 Agent“不要做什么”，比如“不要假设某个页面存在，请基于项目实际页面编写”。
• 要留出输出格式。告诉 Agent 最终输出应采用什么格式，减少人工整理成本。

6. 完整示例代码实现

这一节直接给出一套可以运行的 APP 测试 Skill 示例。你可以把它保存到本地目录，然后根据自己工具的加载机制挂载。

6.1 Skill 主文件 PROMPT.md

# 文件：app-test-skill/PROMPT.md # APP 测试 Skill ## 角色定义 你是一名资深的移动端 APP 测试工程师，熟悉 Android 和 iOS 平台的常规测试方法， 擅长基于需求快速设计高覆盖率的测试用例，并且能够按照团队规范输出缺陷报告。 ## 任务目标 根据用户提供的测试范围，完成以下工作： 1. 生成一份结构化的测试计划。 2. 输出可执行的测试用例。 3. 如果用户提供 bug 描述，分析可能原因并给出复现验证思路。 4. 测试完成后按模板输出测试报告。 ## 执行流程 当你收到测试任务时，严格按以下顺序执行： ### 第一步：明确测试范围 - 询问或确认被测 App 的名称、版本号、平台（Android/iOS）。 - 确认本轮测试是全面回归、冒烟测试还是功能专项测试。 - 如果范围不明确，先输出你识别到的测试范围，并请用户确认。 ### 第二步：获取基础信息（如果环境可用） - 优先尝试通过 adb 获取设备信息和 App 信息。 - 如果无法获取真实设备信息，请在测试报告中注明“基于假设环境编写”。 ### 第三步：设计测试用例 - 按模块划分用例，至少覆盖：安装启动、功能主流程、边界条件、异常场景、数据持久化。 - 每个用例必须包含：用例编号、前置条件、操作步骤、预期结果、优先级。 - 优先级用 P0/P1/P2 标识。P0 为阻塞级，P1 为核心功能，P2 为次要功能。 ### 第四步：输出缺陷分析（如果收到 bug 描述） - 提取 bug 的操作步骤、实际结果、预期结果。 - 给出可能的原因范围，不要做无依据的猜测。 - 建议复现步骤和定位方法，比如检查崩溃日志、抓取网络请求。 ### 第五步：输出测试报告 - 汇总用例执行情况、通过率、未通过项。 - 如果没有实际执行，请在报告中明确标注“用例设计未执行”。 ## 输出要求 - 测试用例使用 Markdown 表格，字段：ID、模块、优先级、前置条件、操作步骤、预期结果。 - 缺陷报告使用下面模板，不允许遗漏字段。 - 所有输出使用中文。 ## 团队规范 - 缺陷严重级别定义： - 致命：App 无法启动、数据丢失、闪退。 - 严重：核心功能不可用、无临时绕过方案。 - 一般：功能可用但结果不正确，或与预期不符。 - 轻微：界面显示问题、体验问题。

6.2 冒烟测试检查清单

# 文件：app-test-skill/checklist/smoke-test.md # 冒烟测试核心检查清单 以下场景在每个版本的冒烟测试中必须覆盖，Agent 输出用例时请对照检查： ## 安装与启动 - [ ] App 能否正常安装 - [ ] 冷启动能否在正常时间内进入首页 - [ ] 热启动（从后台切回）是否保持页面状态 - [ ] 首次启动是否有必要的权限引导 ## 核心主流程 - [ ] 登录/注册流程是否通顺（如果涉及） - [ ] 首页数据是否正常加载 - [ ] 列表页滑动是否流畅 - [ ] 详情页能否正常进入并返回 - [ ] 核心操作（下单、提交、播放等）是否完成闭环 ## 数据安全 - [ ] 退出登录后是否清除敏感信息 - [ ] 杀掉进程重启后，未提交的数据是否有适当处理 - [ ] 前后台切换时，页面是否出现数据错乱 ## 异常场景 - [ ] 无网络情况下是否有友好提示 - [ ] 弱网情况下是否出现超时、卡死 - [ ] 接口返回异常时是否有错误提示，而非崩溃

这份检查清单的意义在于：AI 在生成用例时，会自动把网络异常、数据持久化、前后台切换这类容易遗漏的场景考虑进去。这就是“专业经验显式化”最直接的体现。

6.3 调试辅助脚本

# 文件：app-test-skill/scripts/check_app.py # 用途：获取 Android 设备与 App 基础信息 # 注意：执行前请确认已安装 adb 并连接设备或模拟器 import subprocess import sys def run_command(cmd): """执行系统命令并返回输出""" try: result = subprocess.run(cmd, shell=True, capture_output=True, text=True, timeout=15) return result.stdout.strip() except subprocess.TimeoutExpired: return "命令执行超时" except Exception as e: return f"命令执行失败: {e}" def get_devices(): """列出已连接的设备""" output = run_command("adb devices") print("=== ADB 设备列表 ===") print(output) def get_app_version(package_name): """获取指定包名的版本号""" output = run_command(f"adb shell dumpsys package {package_name} | grep versionName") print(f"=== App 版本信息: {package_name} ===") print(output if output else "未获取到版本信息，请检查包名是否正确") def get_current_activity(package_name): """获取当前前台 Activity（依赖设备上已打开当前 App）""" output = run_command(f"adb shell dumpsys window | grep mCurrentFocus") print(f"=== 当前前台窗口 ===") print(output if output else "未获取到前台窗口信息") if __name__ == "__main__": if len(sys.argv) < 2: print("用法: python check_app.py <包名>") print("示例: python check_app.py com.example.demo") sys.exit(1) get_devices() print() get_app_version(sys.argv[1]) print() get_current_activity(sys.argv[1])

这个脚本只是骨架，但它体现了 Skill 的一个重要能力：Agent 不再只靠“猜”，而是可以通过脚本拿到真实的设备列表、版本号、当前页面信息。这些信息在测试用例设计和 bug 分析中非常关键。

6.4 缺陷报告模板

# 文件：app-test-skill/templates/bug-report.md # 缺陷报告 ## 基本信息 - 缺陷标题： - 严重级别：P0/P1/P2 - 优先级：致命/严重/一般/轻微 - 发现版本： - 发现平台：Android/iOS - 设备信息： ## 问题描述 （用一到两句话描述现象） ## 复现步骤 1. 2. 3. ## 实际结果 （实际发生了什么） ## 预期结果 （应该发生什么） ## 日志信息 （如果有崩溃日志、报错日志、截图，请附上） ## 初步分析 （Agent 分析出的可能原因范围、建议排查方向）

有了这个模板，Agent 在收到 bug 描述时，就不会只回复一长段分析，而是能直接生成符合团队协作要求的缺陷单。这是 Skill 相比普通提示词的优势：稳定性和复用性。

7. 运行结果与效果验证

7.1 如何加载这个 Skill

不同工具加载方式有差异，但通常有两种模式：

一种是直接把 Skill 目录放到工具的项目目录下，然后新开一个会话，在对话中要求 Agent 加载 Skill 目录并执行测试任务。另一种是工具支持斜杠命令，例如在对话框中输入类似/app-test-skill来触发。具体以你使用的工具文档为准。

7.2 测试输入示例

假设你已经加载了 Skill，可以在对话中输入：

请为这个 App 设计一次冒烟测试用例。 App 名称：智能简历工具 平台：Android 版本：v2.3.0 测试重点：新增了「简历评分」功能，需要重点关注评分流程、分数展示、异常简历处理。

7.3 预期输出

如果 Skill 生效，Agent 的输出应该具备以下特征：

• 用例采用 Markdown 表格，字段包含 ID、模块、优先级、前置条件、操作步骤、预期结果。
• 用例中自然覆盖“无网络”“弱网”“空数据”等异常场景。
• 围绕“简历评分”这一新增功能，自动给出 P0/P1 级别的核心路径用例。
• 输出结尾不会出现“如果我的回答有帮助，请点赞”这类通用话术，因为 Skill 已经定义了输出要求。

7.4 如何判断 Skill 是否真正生效

最直接的判断标准是：**同一个问题，不挂载 Skill 时和挂载 Skill 时的输出是否有明显差异。**如果挂载前后回答几乎一样，说明 Skill 没有被正确读取，或者你的 PROMPT.md 内容对模型约束不足。

此时排查顺序是：

1. 检查 Skill 文件路径是否正确。
2. 检查 PROMPT.md 是否有语法或编码问题（尽量用 UTF-8）。
3. 检查工具是否正确识别了 Skill 名称。
4. 在当前会话中主动提示“请先读取 app-test-skill 中的规则”，再发起任务。

7.5 脚本运行验证

脚本这一部分可以单独验证：

python check_app.py com.example.demo

如果设备已连接，预期输出包含 ADB 设备列表和 App 版本信息。如果没有连接任何设备，adb 输出会提示未找到设备。此时检查模拟器或真机的开发者选项与 USB 调试是否已经打开。

8. 常见问题与排查思路

9. 最佳实践与工程建议

9.1 Skill 的命名和版本管理

Skill 文件建议使用语义化命名，比如app-test-skill-v1，并将版本号写在 PROMPT.md 的头部。因为 Skill 会随团队规范迭代，如果改了内容但没有版本记录，很难追溯“当前 AI 行为是哪一版规范导致的”。

有条件的话，把 Skill 目录放到 Git 仓库中统一管理。这样每次更新都有 diff 记录，团队成员也能通过 Pull Request 评审 Skill 的内容变更。

9.2 不要让 Skill 变成“巨型文档”

很多人在写 Skill 时容易有一个冲动：把所有测试知识都塞进去。这不是好习惯。Skill 文件越长，模型在上下文窗口里能有效利用的信息密度反而可能下降，而且每次对话的 token 开销也会增加。

一个好的拍板标准是：**Skill 只放“必须按这个规范来”的内容，参考性的知识放文档链接，不要在 Skill 里大段科普。**比如“什么是弱网测试”这种基础解释没必要写进去，但“弱网场景必须纳入冒烟用例”这种团队规范应该写进去。

9.3 区分“规则”和“示例”

规则是必须遵守的，示例是参考理解的。这两者在 Skill 中要写清楚。如果只给示例，Agent 可能只模仿格式而不理解约束；如果只给规则，Agent 又可能缺少具体画面感。推荐写法是“规则 + 表格模板 + 一个示例片段”，而不是“规则 + 十个示例”。

9.4 安全边界与数据合规

这一点需要特别提醒。当 Agent 参与 APP 测试时，可能会接触到测试账号、设备信息、接口数据。在 Skill 的 PROMPT.md 中建议加入这样一条安全规则：

## 安全与合规要求 - 测试过程仅允许在测试环境或已授权的真机设备上进行。 - 不得采集、输出用户个人敏感信息。 - 如果发现疑似敏感数据，请在报告中提示，不要详细记录。 - 禁止绕过任何操作系统的安全限制。

这些规则能减少 AI 在测试过程中“越界”的风险，也提醒使用者注意测试的合法授权边界。

9.5 从“单点 Skill”走向“Skill 库”

当你的第一个 APP 测试 Skill 跑通之后，很自然会产生更多想法：是不是还可以做一个兼容性测试 Skill？做一个性能测试 Skill？做一个关于特定业务线的支付流程测试 Skill？

这个时候就可以考虑把 Skill 组织结构化，形成一个团队的 Skill 库。常见的结构是：

team-skills/ ├── app-test/ # APP 测试基础 Skill │ ├── PROMPT.md │ ├── checklist/ │ └── templates/ ├── api-test/ # 接口测试 Skill（后续扩展） └── performance-test/ # 性能测试 Skill（后续扩展）

Skill 库的价值不只是复用，而是让团队在工具链演进时，能始终保持一套统一的质量基线。这个基线就是团队长期积累的专业资产。

10. 总结与下一步学习方向

这篇文章主要讲了 Skill 是什么、为什么 APP 测试特别适合用 Skill、以及怎么在 90 分钟内搭建一个能用的 APP 测试 Skill。核心收获有三个：Skill 的本质是“把专业经验结构化后交给 AI”；一个可用的 Skill 需要包含角色定义、执行流程、检查清单、输出模板和可选脚本；验证 Skill 是否生效的最简单方法是对比加载前后的输出差异。

接下来可以往两个方向深入。第一个方向是“把你的 Skill 接入真实测试工具链”，比如结合 adb、自动化测试框架、缺陷管理系统的 API，让 Agent 能真正执行用例并提交缺陷单。第二个方向是“提升 Skill 编写能力”，可以去研究主流 Agent 工具里成熟 Skill 的写法，看别人怎么设计执行流程、怎么划分模块、怎么用少量文字产生强约束。

如果你现在正负责某个 App 的测试工作，我建议不要等到把完整 Skill 设计好再动手。先拿一个最小版本，哪怕只有角色定义和冒烟检查清单，丢给你的 AI 编程助手跑一次真实任务。只要这一次输出比你平时问它“帮我写测试用例”得到的结果更贴合你团队的口味，你就已经把这套方法论的价值拿到手了。剩下的，就是在真实使用中不断修正 PROMPT.md、补充检查清单、调整输出模板，让它越来越像你团队里那个最靠谱的测试搭子。