很多团队都会遇到类似的问题:产品升级后,工单量开始上升,研发、产品经理、技术负责人都想知道问题集中在哪里,但工单系统往往在内网里,需要登录,有权限控制,还没有方便调用的公开接口。
真正麻烦的地方不是“让大模型分析文本”。只要把工单数据整理成结构化 JSON,大模型做分类、归因、提炼共性问题并不难。难点在于:怎么稳定、低成本地把内网系统里的数据拿出来,并且让这个过程可以重复使用。
一个可行的做法是把人工操作沉淀成 Claude Skills。这里的 Skills 指的是 Claude Agent Skills:用 SKILL.md 描述任务流程,再配合脚本、命令和提示词,让 Agent 在需要时调用这套能力。
工单分析特别适合做成 Skill,因为它具备三个特征:
| 特征 | 具体表现 | 自动化价值 |
|---|---|---|
| 数据在内网 | 需要登录,依赖当前用户权限 | 不能绕过权限,但可以复用已登录浏览器里的合法会话 |
| 高频重复 | 每周、每个版本、每个产品都要分析 | 适合沉淀成标准作业流程 SOP(Standard Operating Procedure) |
| 分析视角不同 | 研发看技术问题,产品看共性需求,TL 看横向对比 | 同一份数据可以配不同提示词生成不同报告 |
核心思路可以概括成一句话:不要让 AI 去“点页面”,而是让 AI 执行已经验证过的接口请求。
为什么不直接让 Agent 操作浏览器
最直观的方案是让 Agent 打开浏览器,像人一样点击筛选条件、翻页、导出数据。Playwright、playwright-mcp、agent-browser 都能做这类事情,但在企业后台系统里,这条路通常不够稳定。
问题主要出在两个地方。
| 方案 | 做法 | 问题 |
|---|---|---|
| Playwright / playwright-mcp | 让模型读取页面快照,再点击元素 | 页面快照消耗大量 token,动态页面元素定位容易失效 |
| agent-browser snapshot/click/fill | 用更轻量的浏览器交互命令操作页面 | 比传统 Playwright 更省 token,但仍然依赖页面结构 |
| 固定 selector 脚本 | 写死 CSS selector 或 XPath | 初期稳定,页面一改就要维护脚本 |
例如,用 Playwright 写一个简单点击脚本并不复杂:
const { chromium } = require("playwright");
const browser = await chromium.launch();
const page = await browser.newPage();
await page.goto("https://inner.example.com");
await page.locator(".submit").click();
await browser.close();
但真实后台系统里,页面通常有动态表格、日期选择器、弹窗、分页、异步加载、权限差异和灰度版本。只要 DOM(文档对象模型,Document Object Model)结构发生变化,脚本就可能失效。
让 Agent 通过页面快照自己判断要点哪里,灵活性更强,却带来另一个问题:每次执行都像重新探索页面,输出不够确定,token 成本也高。
所以,更稳的切入点不是 UI,而是接口。
关键观察:SPA 页面只是接口数据的渲染结果
现在很多企业后台都是 SPA(单页应用,Single Page Application)。页面看起来复杂,但本质是前端发送 AJAX(异步 JavaScript 与 XML,Asynchronous JavaScript and XML)请求,从后端拿到 JSON,再把 JSON 渲染成表格、卡片或图表。
只要页面能正常显示工单列表,就说明当前浏览器登录态下,某个接口已经成功返回了这些数据。
在 Chrome DevTools 的 Network 面板里,对这个请求执行 Copy as fetch,浏览器会生成一段可复现的 fetch 代码。把这段代码放回同一个登录态的页面环境里执行,请求就可以再次发出,并返回同样结构的数据。
这个机制带来的变化很关键:
flowchart LR
A[人工打开内网工单系统] --> B[浏览器完成登录态校验]
B --> C[页面发起接口请求]
C --> D[Network 面板复制 fetch 请求]
D --> E[脚本化请求]
E --> F[agent-browser eval 执行脚本]
F --> G[得到 JSON 工单数据]
G --> H[大模型分析并生成报告]
这里没有绕过权限,也不需要破解接口。请求依然运行在用户自己的登录态里,能拿到什么数据取决于当前账号本来具备什么权限。
整体方案:Copy as fetch + agent-browser eval + Skills
方案拆开看非常简单:
- 用带 CDP(Chrome DevTools Protocol,Chrome 开发者工具协议)调试端口的 Chrome 打开内网系统。
- 用户正常登录,并进入工单查询页面。
- 从 Network 面板复制工单查询接口的
fetch请求。 - 把请求整理成
scripts/order-analysis.js。 - 用
agent-browser eval在当前页面上下文执行脚本。 - 将 JSON 结果交给 Claude 分析。
- 把整个流程写进
SKILL.md,形成可复用 Skill。
执行链路如下:
sequenceDiagram
participant User as 用户
participant Chrome as 已登录 Chrome
participant Skill as Claude Skill
participant AgentBrowser as agent-browser
participant API as 内网工单接口
participant LLM as 大模型
User->>Chrome: 登录内网工单系统
User->>Skill: 触发工单分析任务
Skill->>AgentBrowser: open 目标页面
Skill->>AgentBrowser: eval 工单请求脚本
AgentBrowser->>Chrome: 在当前页面上下文执行 fetch
Chrome->>API: 携带当前登录态请求数据
API-->>Chrome: 返回 JSON
Chrome-->>AgentBrowser: 返回执行结果
AgentBrowser-->>Skill: 输出 order.json
Skill->>LLM: 分析 JSON
LLM-->>Skill: 生成 Markdown 报告
这套方案的稳定性来自两个选择:
- 页面交互只负责建立登录态和上下文,不负责复杂操作。
- 数据获取靠接口脚本完成,而不是靠点击、筛选和导出按钮完成。
Skill 目录结构
一个最小可用的工单分析 Skill 可以这样组织:
order-analysis-skill/
├── scripts/
│ ├── check-agent-browser.sh
│ ├── check-cdp.sh
│ └── order-analysis.js
└── SKILL.md
各文件职责如下:
| 文件 | 作用 |
|---|---|
SKILL.md | 描述 Skill 能力、执行流程、分析要求和输出格式 |
scripts/check-cdp.sh | 检查 Chrome 调试端口是否可用 |
scripts/check-agent-browser.sh | 检查 agent-browser 是否已安装 |
scripts/order-analysis.js | 执行工单接口请求,输出结构化 JSON |
前置检查脚本
agent-browser 需要连接一个开启 CDP 调试端口的 Chrome。为了避免执行到一半才发现环境不对,可以先写两个检查脚本。
check-cdp.sh:
#!/usr/bin/env bash
set -euo pipefail
CDP_PORT="${CDP_PORT:-9222}"
if curl -fsS "http://127.0.0.1:${CDP_PORT}/json/version" >/dev/null; then
echo "Chrome CDP is available on port ${CDP_PORT}"
else
echo "Chrome CDP is not available on port ${CDP_PORT}" >&2
echo "Start Chrome with --remote-debugging-port=${CDP_PORT}" >&2
exit 1
fi
check-agent-browser.sh:
#!/usr/bin/env bash
set -euo pipefail
if command -v agent-browser >/dev/null 2>&1; then
agent-browser --version || true
else
echo "agent-browser is not installed or not found in PATH" >&2
exit 1
fi
启动 Chrome 时建议使用单独的用户目录,避免影响日常浏览器环境:
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
--remote-debugging-port=9222 \
--user-data-dir="$HOME/.chrome-cdp-profile"
Linux 环境可以按实际 Chrome 路径调整:
google-chrome \
--remote-debugging-port=9222 \
--user-data-dir="$HOME/.chrome-cdp-profile"
工单请求脚本
从 DevTools 复制出来的 fetch 通常很长,包含很多请求头。落地成脚本时,不建议把它原样塞进仓库,而是做三件事:
- 保留接口必需的 headers。
- 把筛选条件抽成变量。
- 加上分页、异常处理和输出格式。
示例脚本如下:
// scripts/order-analysis.js
(async () => {
const productName = "API 网关"; // 留空表示查询全部产品
const pageSize = 100;
const result = {
fetchedAt: new Date().toISOString(),
productName,
total: 0,
tickets: []
};
let pageNo = 1;
while (true) {
const response = await fetch("https://inner.example.com/api/tickets/search", {
method: "POST",
headers: {
"content-type": "application/json"
},
body: JSON.stringify({
productName,
pageNo,
pageSize,
type: "upgrade",
status: "closed"
}),
credentials: "include"
});
if (!response.ok) {
throw new Error(`Request failed: ${response.status} ${response.statusText}`);
}
const json = await response.json();
const items = json?.data?.items ?? [];
result.tickets.push(...items);
if (items.length < pageSize) {
result.total = result.tickets.length;
break;
}
pageNo += 1;
}
return JSON.stringify(result, null, 2);
})();
credentials: "include" 用来让请求携带当前浏览器上下文中的 Cookie。实际系统可能还需要 CSRF Token、租户 ID、区域参数或其他业务字段,这些都应该从 Copy as fetch 的结果里确认。
用 agent-browser 执行数据采集
进入 Skill 所在目录后,可以按这个顺序执行:
sh scripts/check-cdp.sh
sh scripts/check-agent-browser.sh
打开目标页面:
agent-browser --cdp 9222 open "https://inner.example.com"
用户在浏览器中完成登录,并进入工单系统页面后,创建本次分析的输出目录:
OUTPUT_DIR=".output/order-analysis/$(date +%Y%m%d-%H%M%S)"
mkdir -p "$OUTPUT_DIR"
执行工单采集脚本:
agent-browser --cdp 9222 eval "$(cat scripts/order-analysis.js)" \
> "$OUTPUT_DIR/order.json"
采集完成后,order.json 应该是结构化数据,例如:
{
"fetchedAt": "2026-06-07T10:20:30.000Z",
"productName": "API 网关",
"total": 2,
"tickets": [
{
"id": "TICKET-001",
"title": "升级后路由配置不生效",
"product": "API 网关",
"version": "v2.3.0",
"createdAt": "2026-06-01",
"description": "用户升级后发现部分路由没有按预期转发"
},
{
"id": "TICKET-002",
"title": "控制台升级提示不清晰",
"product": "API 网关",
"version": "v2.3.0",
"createdAt": "2026-06-02",
"description": "用户不理解升级前检查项的含义"
}
]
}
之后让模型读取这个 JSON,生成分析报告即可。
SKILL.md 怎么写
SKILL.md 的价值不是把一段脚本包起来,而是告诉 Agent:什么时候使用这个能力、执行哪些检查、如何采集数据、报告要输出成什么结构。
一个可用模板如下:
---
name: order-analysis
description: 分析产品升级工单,识别共性问题、趋势变化和产品改进机会。通过 agent-browser 访问已登录的内网工单系统,提取工单 JSON 数据,并生成结构化分析报告。
---
# 工单分析 Skill
## 使用条件
当用户要求分析产品升级工单、定位共性问题、比较不同产品工单趋势,或输出产品改进建议时,使用这个 Skill。
## 环境检查
执行以下命令,确认 Chrome CDP 和 agent-browser 可用:
```bash
sh scripts/check-cdp.sh
sh scripts/check-agent-browser.sh
打开工单系统
agent-browser --cdp 9222 open "https://inner.example.com"
如果页面要求登录,等待用户在浏览器里完成登录。不要尝试绕过登录或权限校验。
创建输出目录
OUTPUT_DIR=".output/order-analysis/$(date +%Y%m%d-%H%M%S)"
mkdir -p "$OUTPUT_DIR"
获取工单数据
在同一个工作目录下执行:
agent-browser --cdp 9222 eval "$(cat scripts/order-analysis.js)" \
> "$OUTPUT_DIR/order.json"
分析要求
读取 $OUTPUT_DIR/order.json,生成 $OUTPUT_DIR/order_report.md。
报告必须包含:
- 工单概览:总量、产品分布、版本分布、时间分布。
- 问题分类:按技术缺陷、升级兼容、文档说明、控制台体验、用户误操作等类别归类。
- 共性问题:提炼出现频率高、影响面大的问题。
- 根因判断:区分代码缺陷、产品设计、文档缺失、流程不清晰。
- 改进建议:给出可执行的产品、研发、文档和运营动作。
- 风险优先级:按影响面和紧急程度排序。
输出格式
使用 Markdown 输出,包含表格和条目列表。关键结论放在报告开头。
这样一来,Skill 不只是“运行某个命令”,而是把完整 SOP 写成了 Agent 可以理解和执行的能力说明。
## 报告输出可以标准化
为了让多次分析结果可比较,报告结构最好固定下来。比如:
```markdown
# 工单分析报告
## 关键结论
- 本周期共采集工单 128 条,其中升级兼容类问题占比 36%。
- API 网关、消息队列、对象存储三个产品的升级工单数量最高。
- 共性问题集中在升级前检查不足、控制台提示不清晰、文档缺少异常处理说明。
## 工单概览
| 指标 | 数值 |
|---|---:|
| 工单总数 | 128 |
| 涉及产品数 | 12 |
| 涉及版本数 | 18 |
| 高优先级问题数 | 9 |
## 问题分类
| 分类 | 数量 | 占比 | 典型表现 |
|---|---:|---:|---|
| 升级兼容 | 46 | 36% | 配置迁移后行为变化 |
| 控制台体验 | 28 | 22% | 提示信息无法指导下一步操作 |
| 文档缺失 | 24 | 19% | 缺少升级前检查说明 |
| 代码缺陷 | 18 | 14% | 升级后功能异常 |
| 用户误操作 | 12 | 9% | 未按流程执行前置步骤 |
模型输出越稳定,后续做周报、趋势对比和产品复盘就越容易。
不同角色如何复用同一个 Skill
同一份工单数据,不同角色关心的切面不同。Skill 的好处是数据采集逻辑可以保持不变,只改筛选条件或分析提示词。
| 角色 | 关注点 | 调整位置 |
|---|---|---|
| 研发 | 具体缺陷、复现路径、根因模块 | 修改报告提示词,强调技术分类和根因定位 |
| 前端 | 控制台体验、交互文案、操作路径 | 修改提示词,要求标记体验类问题 |
| 产品经理 | 共性需求、产品化机会、用户认知成本 | 修改提示词,强调需求聚类和产品改进 |
| 技术负责人 | 产品横向对比、风险排序、资源投入 | 修改数据范围和报告维度 |
如果只想分析某个产品,可以改脚本里的变量:
const productName = "API 网关";
如果想做跨产品横向对比,可以留空或传入产品列表:
const productName = "";
也可以把变量从环境参数读入,避免每次改代码:
const productName = globalThis.productName ?? "";
实际执行时再由 Skill 根据用户需求选择不同脚本或动态生成参数。
Skills 和 Workflow 的区别
Workflow 更像一张固定流程图,适合步骤明确、输入输出稳定、节点关系长期不变的任务。Skills 更像一份可执行说明书,适合流程有标准框架,但细节会随场景变化的任务。
| 对比项 | Workflow | Skills |
|---|---|---|
| 表达方式 | 节点、连线、配置项 | Markdown、脚本、自然语言说明 |
| 适合场景 | 固定审批流、固定数据处理链路 | 分析类、诊断类、半结构化 SOP |
| 修改成本 | 依赖平台配置,改动要小心影响节点 | 修改文本和脚本即可 |
| 可移植性 | 容易受平台绑定影响 | 文件夹即可迁移,适合 Git 管理 |
| 灵活性 | 输入变化大时容易分支膨胀 | Agent 可以按说明适配任务变化 |
工单分析这种任务不适合完全写死成流程图,因为每次分析的产品、时间范围、角色视角、输出重点都可能变化。把“稳定部分”写成脚本,把“变化部分”写进提示词,通常更容易维护。
落地时容易踩的坑
不要把敏感信息写进仓库
Copy as fetch 可能包含 Cookie、Token、内部域名、租户 ID 等敏感信息。整理脚本时要删除不必要的敏感 header,不要把真实 Cookie 提交到 Git。
推荐做法:
- Cookie 依赖浏览器登录态,不写进脚本。
- Token 如果必须使用,从页面环境或安全配置读取。
- 示例代码使用脱敏域名,例如
inner.example.com。
CDP 调试端口要控制暴露范围
Chrome CDP 端口可以控制浏览器,不能暴露到不可信网络。启动时使用本机地址,并尽量使用单独浏览器 profile。
--remote-debugging-port=9222
--user-data-dir="$HOME/.chrome-cdp-profile"
不要在共享机器上长期开启调试端口。
接口字段会变化,要给脚本留出容错
后台接口升级后,字段路径可能变化。解析时不要写得过于脆弱:
const items =
json?.data?.items ??
json?.data?.list ??
json?.items ??
[];
同时建议在输出里保留原始响应的关键元信息,方便排查。
分页和限流要处理好
只请求第一页会漏数据。请求过快又可能触发限流。可以在循环里加入轻微等待:
function sleep(ms) {
return new Promise(resolve => setTimeout(resolve, ms));
}
await sleep(300);
如果接口返回总数,也可以按总页数循环,避免依赖 items.length < pageSize 这种判断。
分清确定性任务和分析任务
数据采集应该尽量确定:脚本、参数、分页、输出目录都要稳定。
数据分析可以交给模型:分类、归因、摘要、建议更适合自然语言推理。
一个好的 Skill 不应该让模型临时猜接口怎么调,也不应该把所有分析规则硬编码进脚本。稳定部分工程化,弹性部分交给 Agent,二者边界要清楚。
适合使用这套方法的场景
这种方式不只适合工单分析。只要满足“数据在已登录后台页面里,页面由接口渲染,任务需要反复执行”这几个条件,都可以考虑用类似方案。
| 场景 | 可采集数据 | 可生成结果 |
|---|---|---|
| 工单分析 | 工单列表、问题描述、产品版本 | 共性问题、根因分类、改进建议 |
| 运营后台日报 | 指标接口、活动数据、用户行为 | 日报、异常波动说明 |
| 质量平台分析 | 缺陷列表、测试结果、失败原因 | 缺陷趋势、风险模块 |
| 发布复盘 | 发布单、告警、回滚记录 | 发布质量报告、流程改进点 |
| 客服问题聚类 | 会话记录、问题标签 | 高频问题、知识库补充建议 |
不适合的情况也要明确:
| 不适合场景 | 原因 |
|---|---|
| 没有登录权限的数据 | 不能用自动化绕过权限 |
| 页面数据不是接口返回 | Copy as fetch 复现不了完整数据 |
| 接口强绑定一次性签名 | 需要额外处理签名刷新逻辑 |
| 数据量极大 | 应该接入离线数据仓库或正式 API |
| 强事务写操作 | 自动化写入风险高,必须额外审批和保护 |
一个可复用 Skill 的核心价值
把工单分析做成 Skill,价值不在于“让 AI 帮忙写一份报告”这么简单,而在于把隐藏在人工操作里的步骤显性化:
- 去哪里打开页面。
- 如何确认环境可用。
- 如何获取数据。
- 数据保存在哪里。
- 用什么视角分析。
- 报告按什么结构输出。
- 哪些行为不能做。
这些内容一旦沉淀到 SKILL.md 和脚本里,下一次分析就不需要重新解释流程。研发要看技术根因,改提示词;产品要看共性需求,改报告重点;负责人要看横向对比,改数据范围。
最终形成的是一套可版本管理、可审查、可迁移、可迭代的 SOP 自动化能力。