在模块化配置体系中，rules（规则）决定了 Claude 的下限（不能搞砸什么），而 skills（技能）则决定了 Claude 的上限（能多快、多准地完成复杂任务）。

高效扩展 Claude 能力的核心秘诀，是把 skills/ 目录里的文件写成**“标准作业程序 (SOP)”。不要把它当成用来阅读的散文，而是要把它写成带触发条件、带执行步骤、带验证标准的状态机**。

针对你们的音视频 SoC 嵌入式开发，以下是高效编写和运用 Skills 的核心策略与模板示例：

1. 技能公式：Trigger + SOP + Validation

一个真正能让 AI 产生“确定性输出”的 Skill 文件，必须包含三个基本要素：

• 触发器 (Trigger)：告诉 Claude 什么时候去挂载这个技能。

• 标准步骤 (SOP)：把复杂任务拆解为可以用 svn 或 shell 命令执行的具体步骤。

• 验证标准 (Validation)：做完之后，怎么检查自己做对了没有。

2. 实战案例：教它一套“连续技”

场景 A：排查内存池泄漏 (Video Buffer Leak)

音视频开发中最怕 VB 泄漏。单纯让大模型“找 Bug”它会看花眼。我们需要写一个技能，教它像老工程师一样使用工具链。

新建文件：skills/trace_vb_leak.md

# 🛠️ Skill: 视频缓存池 (VB) 泄漏排查法

**触发条件**：当用户报告“画面卡死”、“申请 VB 失败”、“VB 耗尽”或明确要求排查内存泄漏时。

## 🎯 排查 SOP (严格按顺序执行终端命令)
1. **定位生产源**：使用 `grep -rn "HI_MPI_VB_GetBlock" src/` 找到所有分配 VB 的源文件和行号。
2. **提取上下文**：使用 `cat` 或 `sed` 打印出上述行号所在函数的完整代码块。
3. **追踪数据流 (Data Flow)**：
   - 寻找获取到的 `VB_BLK` 句柄是如何传递的（是否存入了全局队列？是否发给了其他线程？）。
4. **定位释放源**：在同一个生命周期或消费线程中，搜索对应的 `HI_MPI_VB_ReleaseBlock`。

## ✅ 验证判定树
- 如果函数内存在 `return` 异常分支，但没有在 `return` 前执行 `ReleaseBlock` ➡️ **发现泄漏点**。
- 如果句柄被跨线程传递，请检查消费者线程退出的逻辑中，是否有清空队列并释放残余 VB 的代码。如果没有 ➡️ **发现隐患**。

场景 B：基于厂商 API 模板生成代码

不要指望大模型凭空写出完美的海思/联咏初始化代码。把核心的、正确配置过参数的“骨架代码”作为 Skill 喂给它。

新建文件：skills/venc_init_template.md

# 🛠️ Skill: 视频编码器 (VENC) 标准初始化流程

**触发条件**：要求新建编码通道、初始化 H.264/H.265 编码器时。

## 🎯 代码生成 SOP
当你需要编写 VENC 初始化代码时，必须严格按照以下三步执行，并直接使用提供的模板结构：

**Step 1: 配置编码通道属性 (VENC_CHN_ATTR_S)**
必须处理 `stVencAttr`（宽高、Profile）和 `stRcAttr`（码率控制，强制作 CBR 或 VBR 校验）。

**Step 2: 创建通道**
调用 `HI_MPI_VENC_CreateChn(VeChn, &stAttr)`。
*(必须紧跟 `if (s32Ret != HI_SUCCESS)` 的错误处理与日志打印)*

**Step 3: 接收图像并开始编码**
调用 `HI_MPI_VENC_StartRecvPic(VeChn)`。

## 📝 强制参考代码骨架 (防幻觉)
```c
// [此处贴一段你们团队内部最标准、最精简的 VENC 初始化 C 代码片段]
// 注意：告诉 Claude 只能修改关键参数（如宽高、码率），不能改变函数调用顺序。

### 3. 高效扩展的 3 个系统级技巧

**技巧一：动态索引，节省 Token**
随着 Skills 越来越多，不要在 `CLAUDE.md` 里把所有技能内容全抄一遍（会爆 Token）。
你应该在 `CLAUDE.md` 中做一个**“技能菜单”**：
> "如果遇到内存问题，请主动读取 `skills/trace_vb_leak.md`。"
> "如果需要解析 dmesg 日志，请读取 `skills/parse_kernel_log.md`。"
这样，Claude 只会在遇到特定问题时，才去按需加载（Lazy Load）特定的技能文件。

**技巧二：教它学会用 Shell 工具处理大文本**
嵌入式的日志（如 `cat /proc/umap/vb`）极其冗长。你可以写一个 Skill，教 Claude 先用 Shell 命令过滤数据，再进行分析。
* *Skill 示例*："当你需要分析 `/proc` 节点状态时，不要直接读取整个文件。请先使用 `grep` 提取出当前状态为 `busy` 的块，然后再分析。"

**技巧三：从 Review 中提取 Skill**
这是团队进化的关键。当你花费了 20 分钟纠正了 Claude 关于一个“视频帧时间戳 (PTS) 对齐”的错误后，不要就这么算了。立即对它下发指令：
* *"请将刚才我们讨论的 PTS 对齐规则和正确的代码写法，总结提炼成一个 markdown 文件，保存到 `skills/pts_alignment_rules.md` 中。"*
这样，个人踩过的坑，就顺滑地变成了系统的通用技能。

---

如果把这种 SOP 化的 Skill 思维应用到你们目前最容易出 Bug、最耗费调试时间的一个具体模块（比如 I2C 驱动通信，或者视频推流网络延迟），你觉得哪一个场景最值得优先写成第一个 Skill 模板？