AI

Agent AI 深度分享 · 案例篇

两个真实 Skill 的
实战拆解

前面我们讲了 Skill 的"为什么"和"什么时候"。现在用两个正在运行的 Skill，拆解它们的运行逻辑、解决的问题、以及"该固定的固定，该智能的智能"。

YY-spr-analysis work-diary-reader 痛点分析流程拆解

01

■ 案例一：YY-spr-analysis

用友 SPR 性能报告分析的痛点

用友 NCC/NC 系统遇到性能问题或报错时，会生成 SPR（Server Performance Report）报告。运维人员拿到这份 HTML 格式的报告后，需要人工完成以下工作：

1

打开 HTML，肉眼找报错信息 SPR 报告通常几百 KB，混杂数千行框架日志，真正的错误信息淹没在噪音里

2

区分"真报错"和"正常行为" NCC 框架有很多看起来像报错的正常日志（如"属性名为空"、"锁定ID失败"），新手容易误判

3

从堆栈中提取类名，去源码里翻文件 InvocationTargetException 包了三层 Caused by，必须找到最内层根因；然后手动在项目中搜索对应的 Java 文件

4

分析 SQL、计算时间占比、写报告 统计 NC/DB/Web 时间占比、找出慢查询、异常 INSERT，最后写一份结构化分析报告

✕ 没有 Skill 时

每次人工分析 30+ 分钟

需要用友 NCC 领域专家经验

容易遗漏真正的 P0 错误

~30 min / 次

✓ 有了 Skill 后

AI 自动完成全流程

直接输出带源码片段的报告

新人也能产出专家级分析

~2 min / 次

↻ 触发信号 1：重复执行（高频运维场景） ☰ 触发信号 2：6 步长流程

02

■ 案例一：YY-spr-analysis

6 步自动化流程

Skill 将专家经验固化为 6 步流水线，用户提供 HTML 文件后自动完成全部分析：

Step 0

自动检测
是不是 SPR

↓

Step 1

HTML →
Markdown

↓

Step 2

定位
关键章节

↓

Step 3

分析报错
过滤正常行为

↓

Step 4

VS Code
源码定位

↓

Step 5

SQL
异常分析

↓

Step 6：生成分析报告

带源码片段 + 修复建议 + P0/P1/P2 标记

亮点：Step 0 是"智能门卫"——不是 SPR 的 HTML 直接放行，不会浪费分析资源。12 个特征信号加权评分，confidence ≥ 30 才触发后续流程。

yy-spr-analysis/
  ├── SKILL.md  # 主技能文件（流程定义 + 输出模板）
  ├── scripts/
  │   ├── detect_spr.mjs  # Node.js 自动识别
  │   ├── html_to_markdown.py  # Python 纯标准库转换
  │   └── find_source_code.py  # VS Code 源码定位
  └── references/
      ├── spr-field-guide.md  # 字段解读 + 常见错误模式
      └── profiles.md  # 性能阈值 + 优先级定义

03

■ 案例一：YY-spr-analysis

该固定的固定，该智能的智能

这个 Skill 最精彩的设计在于：哪些东西写死在规则里，哪些交给 AI 自主判断——边界划得非常清晰。

■ 固定的部分（写死在规则里）

6 步执行顺序——检测、转换、分析、定位、生成，不可跳过
报错分类规则——ClassNotFoundException 是 P0，属性名为空是正常行为
忽略清单——哪些"报错"是 NCC 框架正常日志，不需要报告
性能阈值——NC 时间 >80% 是严重，单条 SQL >100ms 需关注
报告模板——基本信息 + 问题代码 + 修复建议 + 性能摘要

◆ 智能的部分（交给 AI 判断）

输入检测——自动判断任意 HTML 是否为 SPR 报告
堆栈解读——从三层 InvocationTargetException 剥到真正 Caused by
SQL 异常判断——识别 INSERT null、慢查询、执行失败
源码上下文理解——结合 ±15 行代码生成针对性修复建议
自然语言输出——根据分析结果生成人类可读的报告

核心理念：领域专家知识（报错分类、忽略清单、阈值）写死在 Skill 里，确保稳定可靠；
代码理解、堆栈解读、修复建议交给 AI 的推理能力，确保灵活智能。

Step 4 的源码定位过程（自动化亮点）：

        # AI 从报错堆栈中提取的 Java 类名

        InvocationTargetException

          → NullPointerException

            at nc.bs.foo.BarService.commit(BarService.java:123)

        # Skill 自动完成：

        1. 提取类名 nc.bs.foo.BarService → 转为文件路径

        2. 在 VS Code 工作区递归搜索 nc/bs/foo/BarService.java

        3. 提取第 108-138 行代码（出错行 ±15 行上下文）

        4. 如果 VS Code 在运行，自动跳转到出错行

04

■ 案例二：work-diary-reader

工作记录查询的痛点

写日报、周报、月报时，需要回顾这段时间做了什么。但工作记录分散在远程系统里，AI 无法直接获取。

1

数据不在本地——AI 根本看不到 工作记录存在远程 API（work-diary-site-kc.pages.dev），没有 Skill 的 AI 只能说"请把数据发给我"

2

认证门槛——API Token + Bearer 认证 每次调 API 要带 Token，Token 存在本地配置文件里。AI 不知道去哪找、怎么带

3

参数组合复杂——个人/项目 × 今天/本周/自定义 type 有 personal/project，period 有 today/week/custom，还要传 start_date/end_date/project_id

✕ 没有 Skill 时

AI："请把你的工作记录复制给我"

用户：手动打开系统 → 截图/复制 → 粘贴

或者：AI 不知道参数怎么拼，反复试错

手动操作 5-10 min

✓ 有了 Skill 后

用户："查一下我今天做了什么"

AI：自动读 Token → 构造请求 → 查询 → 格式化输出

全程零手动操作

一句话搞定

🔗 触发信号 3：需要集成外部系统（远程 API + 认证）

05

■ 案例二：work-diary-reader

从"请发给我"到"我自己查"

这个 Skill 的核心价值是封装了外部系统的全部复杂性。用户只需要用自然语言描述需求：

用户说一句话

"查查我这周做了什么"

↓

Step 1

读取配置
获取 API Token

↓

Step 2

识别意图
personal + week

↓

Step 3

查项目列表
（如需要）

↓

Step 4

构造 GET 请求
拼接参数

↓

Step 5

curl GET
带 Bearer Token

↓

Step 6：整理输出

解析 JSON → 按标签/日期/人员分组 → 输出日报/周报/月报

参数映射示例——AI 自动理解自然语言：

用户说的话	type	period	额外参数
"今天做了什么"	personal	today	无
"我这周的工作"	personal	week	无
"太极项目上周进展"	project	custom	project_id + 日期范围
"5月份月报"	personal	custom	start_date=05-01, end_date=05-31

这个 Skill 只有 1 个文件（SKILL.md），没有辅助脚本。因为核心逻辑就是"读配置 + 构造 URL + 发请求 + 解析结果"，不需要复杂的脚本支撑。这也说明：Skill 的价值不在于文件多少，而在于封装了正确的外部系统知识。

06

■ 案例二：work-diary-reader

该固定的固定，该智能的智能

■ 固定的部分（写死在规则里）

API 基地址：work-diary-site-kc.pages.dev
认证方式：从配置文件读 Token，请求头加 Bearer
参数规范：type/period/project_id 的合法值和组合规则
响应 JSON 结构：byTag/byDate/byUser 等字段含义
Windows 编码处理：GET 请求不受影响，但需注意终端编码

◆ 智能的部分（交给 AI 判断）

自然语言 → 参数映射："上周" → 算出周一和周日日期
项目名模糊匹配："太极项目" → 从项目列表找到对应 ID
输出格式自适应：日报精简、周报按天汇总、月报详细
多维度整理：按标签分类、按日期分组、按人员统计
摘要生成：从原始记录中提炼"关键成果"和"进展总结"

对比案例一：YY-spr-analysis 需要 3 个脚本 + 2 个参考文档（领域复杂度高），
work-diary-reader 只需 1 个 SKILL.md（通用 API 调用）。
Skill 的复杂度取决于业务场景，不取决于 Skill 本身。

07

两个案例的对比总结

维度	YY-spr-analysis	work-diary-reader
解决的信号	①重复执行 + ②长流程	③外部系统集成
复杂度	高：6步 + 3脚本 + 2参考文档	中：6步但无脚本，纯 API
固定的	执行步骤、报错分类、忽略清单、阈值	API地址、认证方式、参数规范
智能的	输入检测、堆栈解读、SQL分析、修复建议	自然语言映射、模糊匹配、格式化输出
文件结构	SKILL.md + scripts/ + references/	仅 SKILL.md
领域门槛	高（用友 NCC 专业知识）	低（通用 API 调用）
核心价值	领域专家知识的固化与传承	外部系统的封装与打通

两个 Skill 验证了同一个设计哲学：
把人类专家的判断标准写死（确保稳定），把需要理解上下文的决策交给 AI（保持灵活）。
不管是复杂的用友 SPR 分析，还是简单的 API 查询，"该固定的固定，该智能的智能"这个原则都成立。

记住：Skill 的价值不在于文件多少、脚本多复杂。
而在于它把正确的知识固化下来，让 AI 每次都能稳定地执行到最佳路径。

08

从"我会做"，
到"它会做"

两个真实的 Skill，两种不同的痛点，同一个设计哲学

YY-spr-analysis

6步自动化 · 领域专家知识固化 · 30min → 2min

work-diary-reader

外部API封装 · 认证+查询+格式化 · 手动5min → 一句话

设计哲学

该固定的固定（流程/规则/阈值） · 该智能的智能（理解/判断/生成）

制作时机

第三次重复 / 步骤超5步 / 需要集成外部系统

查看理论篇 → agent-skill-sharing.pages.dev

两个真实 Skill 的实战拆解

用友 SPR 性能报告分析的痛点

✕ 没有 Skill 时

✓ 有了 Skill 后

6 步自动化流程

Step 0

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6：生成分析报告

该固定的固定，该智能的智能

■ 固定的部分（写死在规则里）

◆ 智能的部分（交给 AI 判断）

Step 4 的源码定位过程（自动化亮点）：

工作记录查询的痛点

✕ 没有 Skill 时

✓ 有了 Skill 后

从"请发给我"到"我自己查"

用户说一句话

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6：整理输出

参数映射示例——AI 自动理解自然语言：

该固定的固定，该智能的智能

■ 固定的部分（写死在规则里）

◆ 智能的部分（交给 AI 判断）

两个案例的对比总结

从"我会做"，到"它会做"

两个真实 Skill 的
实战拆解

从"我会做"，
到"它会做"