Skills 如何高效地扩展 Claude 的能力
在模块化配置体系中，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 模板？