芥末
发布于 2026-03-03 / 0 阅读
0
0

用 Claude Skills 把内网工单分析 SOP 固化为可复用自动化能力

很多团队都会遇到类似的问题:产品升级后,工单量开始上升,研发、产品经理、技术负责人都想知道问题集中在哪里,但工单系统往往在内网里,需要登录,有权限控制,还没有方便调用的公开接口。

真正麻烦的地方不是“让大模型分析文本”。只要把工单数据整理成结构化 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

方案拆开看非常简单:

  1. 用带 CDP(Chrome DevTools Protocol,Chrome 开发者工具协议)调试端口的 Chrome 打开内网系统。
  2. 用户正常登录,并进入工单查询页面。
  3. 从 Network 面板复制工单查询接口的 fetch 请求。
  4. 把请求整理成 scripts/order-analysis.js
  5. agent-browser eval 在当前页面上下文执行脚本。
  6. 将 JSON 结果交给 Claude 分析。
  7. 把整个流程写进 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

报告必须包含:

  1. 工单概览:总量、产品分布、版本分布、时间分布。
  2. 问题分类:按技术缺陷、升级兼容、文档说明、控制台体验、用户误操作等类别归类。
  3. 共性问题:提炼出现频率高、影响面大的问题。
  4. 根因判断:区分代码缺陷、产品设计、文档缺失、流程不清晰。
  5. 改进建议:给出可执行的产品、研发、文档和运营动作。
  6. 风险优先级:按影响面和紧急程度排序。

输出格式

使用 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 更像一份可执行说明书,适合流程有标准框架,但细节会随场景变化的任务。

对比项WorkflowSkills
表达方式节点、连线、配置项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 自动化能力。


评论