把"询问模型能力是否完整"这个任务放大看，常见痛点：
| 痛点 | 具体表现 |
|---|---|
| 重复解释 | 每次评估都要重新写 prompt，描述背景和目标 |
| 遗漏项 | 想到哪问到哪，容易漏掉关键能力点 |
| 无沉淀 | 评估完了没有标准输出，下次从零开始 |
不是"模型能不能答"，而是在这个场景下能不能稳定、可预期地交付。
| 维度 | 检查点 |
|---|---|
| 任务理解 | 能正确理解用户意图，不跑偏 |
| 知识覆盖 | 不幻觉、不遗漏关键信息 |
| 推理能力 | 复杂问题能拆解，逻辑不跳步 |
| 工具调用 | 能按需正确使用外部能力 / Skill |
| 输出稳定性 | 每次结果结构一致，可复现 |
| 安全边界 | 知道什么不能说、什么不能做 |
| 一次性提问 | 系统化评估 | |
|---|---|---|
| 输入 | "你能做数据分析吗？" | 数据类型 + 分析目标 + 输出格式 |
| 输出 | 泛泛回答 | 多维度结论 + 边界说明 |
| 可复现 | 无法复现 | 可重复、可对比 |
把你和 WorkBuddy 对话中积累的经验，经过参数化、规则化、结构化后，封装成可持久复用的个人工具。
| 适合 | 不适合 |
|---|---|
| 反复做的任务（周报、审计） | 一次性任务（查个数据） |
| 纠正了 AI 多次的行为模式 | AI 本来就知道的知识 |
| 有通用价值、别人也能用 | 纯项目配置/约定 |
| 需要固定输出格式 | 纯聊天/问答场景 |
| 多步骤复杂流程 | 一句话能说清的事 |
SKILL.md 是 Skill 的灵魂，决定 AI 什么时候调用、怎么执行、输出什么。
Frontmatter（头部元数据）：
Markdown 正文（工作手册）：
以腾讯会议 Skill 的 description 为例：
作用：这段描述让 AI 精准判断"什么情况下该调用这个 Skill"，而不是随便一句话就触发。
三者的定位：
可执行代码。AI 负责运行，比如调用会议 API、处理鉴权。
供 AI 阅读的文档。比如 error_dictionary.md 让 AI 遇到错误时不乱猜，而是查字典给出规范回答。
静态资源。_icon.png 是显示在 Skill 列表里的图标。
流水线 —— 任务拆成原子步骤，一步一验证
用户说"帮我查会议号 123456789 的录制"，执行顺序：
get_meeting_by_code → 9 位会议号转 meeting_idget_records_list → 查录制列表get_record_addresses → 获取下载地址每一步完成才能进下一步，SKILL.md 明确写："先通过 get_meeting_by_code 查询 meeting_id，再调用目标工具"。
环境适配
utils.py 里的 get_os_name() 自动探测操作系统（macOS / Windows / Linux），通过 _client_info 参数传给 API，确保返回结果跟用户环境匹配。
安全性
error_dictionary.md 按规范告知（如"鉴权失败，请重新配置 Token"）自进化（雏形）
API 返回 401 鉴权失败 → AI 自动查阅 error_dictionary.md → 字典给出修复建议 → AI 告知用户"请重新配置 Token" → 用户配置好后再次执行成功。即"遇到错误 → 诊断 → 给出方案"的闭环。
以"模型能力评估"为例，演示从一段对话到封装 Skill 的完整流程：
skill-creator："帮我创建一个模型能力评估 Skill"| 类型 | 示例 |
|---|---|
| 应该触发 | "检查这个模型的写作能力" / "帮我做一次模型能力评估" |
| 不应该触发 | "推荐一个好用的 AI 模型" / "今天天气怎么样" |
| 边界情况 | "这个模型还行吧？你帮我看看"（模糊表述，测试是否误触发） |