Day 09 - Agent Skills and Reusable Context

今日目标

能把重复工作流封装成可复用 Skill，写清适用场景、输入、步骤、输出与失败处理。

学习安排

时间	模块	做什么
0-10 分钟	核心概念	通读当天术语表，圈出 3 个你最想在工作里用上的概念。
10-25 分钟	阅读输入	精读当天章节重点，只抓问题、思路、结论。
25-45 分钟	实践任务	动手完成输出模板，必须产出一份可复用产物。
45-55 分钟	追问与反思	回答追问练习，标记卡住的概念。
55-60 分钟	复盘与作业	整理自检清单，定下明天要复习的一点。

核心概念

术语	中文解释	应用场景
skill	技能：把固定工作流（适用场景、输入、步骤、输出、失败处理）封装成可复用单元，模型遇到对应任务时按技能执行。	把性能测试分析流程存成 skill，下次直接调用。
reusable workflow	可复用工作流：把重复出现的任务固化为标准化流程，避免每次重新设计。	每周压测分析都走同一套步骤，输出格式一致。
template	模板：技能中的骨架，用占位符留空，调用时替换为具体内容。	分析报告的章节骨架，填入不同测试数据。
applicable scenario	适用场景：说明技能适合什么任务、什么输入，防止被用到不合适的任务上。	明确「适合容量/稳定性测试分析，不适合压测执行」。
input contract	输入契约：规定技能的输入字段、格式、必填项与取值范围。	约定 TPS、P95、错误率必填，目标值可选。
failure handling	失败处理：定义输入缺失、工具失败、结果异常时的降级行为。	数据为空时标注「无数据」，不推测。
over-generalization	过度泛化：技能试图覆盖太多场景，导致每个场景都做不好。	一个技能又想分析压测、又想设计用例，结果两头都不精。
skill evaluation	技能评估：用评估集检验技能输出质量，判断改动是否真的变好。	拿 10 条历史压测数据跑技能，统计报告准确率。
versioning	版本治理：技能需要版本管理，改动可追溯、可对比、可回滚。	分析步骤改了 v0.2，用 v0.1 与 v0.2 各跑一遍对比。

阅读重点

对应章节：第 2 章中 Agent Skills 与上下文复用相关内容。
关注点：
Skill 与普通 Prompt 的区别：多出的输入契约、失败处理与示例分别解决什么问题。
哪些任务适合做成 Skill：高重复、输入输出明确、流程稳定。
业务规则应该放 Skill 还是放知识库，各有什么优劣。
Skill 如何避免过度泛化：适用场景写得越清楚，越不容易被误用。
补充材料：
Anthropic 关于 Agent skills 的文档：技能的结构、命名与触发方式。
Claude Code 的 skill 目录规范，参考实际项目中技能的目录组织与元信息。

理解检查

Skill 和普通 Prompt 有什么区别？多出来的部分各自解决什么问题？
哪些任务适合做成 Skill？哪些任务不适合？
Skill 中应该包含业务规则吗？放 Skill 和放知识库有什么区别？
Skill 如何避免过度泛化？

实践任务

背景：团队每周都要做性能测试分析，但每次都从头写指令，输出格式不一致，还要反复提醒模型别编造数据。今天把分析流程封装成一个可复用 Skill。

步骤：

写适用场景：明确适合什么测试类型、什么输入、什么输出，并写清不适合的场景。
定义输入契约：每个字段的类型、必填或可选、约束。
写分析步骤：3-5 步固定流程，顺序固定。
写输出模板：固定章节与表格列。
写失败处理：数据缺失、指标为空、无法判定时分别怎么做。
补一个示例：用一组真实压测数据走完整个流程。
保存为 skill-performance-analysis.md。

产出：一份完整的 Skill 定义，后续任务可直接复用。

输出模板

技能名称：[技能名]

适用场景：
- 适合：[任务类型、输入、环境]。
- 不适合：[排除的场景]。

必要输入：
- [字段]：[类型]，[必填/可选]，[约束]。

分析步骤：
- [步骤 1]。
- [步骤 2]。
- [步骤 3]。

输出模板：[章节与表格列]。

失败处理：
- 输入缺失时：[行为]。
- 数据为空时：[行为]。
- 无法判定时：[行为]。

示例：[一个走完全流程的例子]。

示范输出

技能名称：性能测试分析 Skill

适用场景：
- 适合：容量测试、稳定性测试结果的指标分析，输入为压测原始数据与目标值。
- 不适合：压测执行本身、调优方案设计、代码级性能排查。

必要输入：
- 测试类型：字符串，必填，如容量/稳定性。
- 时间窗：字符串，必填，如 2026-08-10 10:00-11:00。
- 并发数：整数，必填。
- TPS、P95、P99、错误率：数值，必填。
- 目标值：数值，可选，缺省时只给对比不给结论。

分析步骤：
- 先判断总体是否达标：核心指标对比目标值。
- 再逐项分析不达标指标：差距、趋势、与时间窗内事件的相关性。
- 最后给出假设与验证方法，区分「已验证」与「待验证」。

输出模板：
- 结论摘要：是否达标 + 一句话原因。
- 指标对比表：指标、实际值、目标值、差距、是否达标。
- 异常分析：每项异常的现象、证据、假设。
- 待验证清单：假设与验证方法。

失败处理：
- 输入缺失：标注「无数据」，跳过该指标，不推测。
- 数据为空：说明空结果的可能原因，标注待验证。
- 无法判定：输出「无法判定」，列出还缺什么信息。

示例：
输入：容量测试，10:00-11:00，并发 200，TPS 1800，P95 450ms，错误率 0.3%，目标 TPS 2000。
输出：总体未达标（TPS 差 10%），P95 超标，假设为数据库连接池不足，标注待验证。

追问练习

Skill 如何被评估？你会用什么指标判断一个 Skill 是变好还是变坏？
两个场景高度相似但规则不同，拆成两个 Skill，还是一个 Skill 加分支？
Skill 里的步骤被模型跳过怎么办？要不要在输出里强制检查步骤完成情况？
业务规则放 Skill 里与放 RAG 知识库里，各有什么优劣？

常见误区

把 Skill 写成大而全的百科全书：场景越宽，误用越多，这就是过度泛化。
只写步骤不写失败处理：输入一变化，技能就崩。
技能没有版本：改坏了无法回滚，也无法对比新旧效果。
认为写了 Skill 就万事大吉：Skill 好不好，必须用评估集验证。

进阶扩展

技能版本治理：目录、版本号、changelog，改动前先跑回归 eval。
技能触发机制：模型自主发现技能，还是由 harness 按任务路由到技能。
技能组合：多个 Skill 按流程串联，形成更复杂的工作流。

今日作业

完成性能测试分析 Skill 定义，保存为可复用文件。
用同一组输入分别跑「无 Skill」和「有 Skill」两次，对比输出。
列出你工作中 3 个适合做成 Skill 的重复任务。

自检清单

我能说出 Skill 比普通 Prompt 多哪些部分。
我能判断一个任务适不适合做成 Skill。
我能写清适用场景与输入契约。
我能为 Skill 设计失败处理。
我能说明 Skill 为什么要版本化。