--- name: doubao-agentic-service-skill-quality-review description: 审核豆包智能服务的运行态 SKILL.md 并给出质量准出结论。当用户要求“审核/检查/review/验收/准出”现有豆包智能服务 Skill，或提供其 SKILL.md、Skill 目录、zip 包、粘贴内容并期望评估触发质量、逻辑、格式、安全、可用性或 Skill/Tool 边界时使用；不用于创建或改写 Skill。 --- # 豆包智能服务 Skill 质量审核 对豆包智能服务的运行态 `SKILL.md` 做系统化质量审核，并基于证据给出准出结论。审核覆盖 12 个维度： 1. 命名规范 2. 粒度治理 3. description 触发质量 4. 描述清晰度 5. 逻辑一致性 6. 表意不明与自相矛盾 7. 格式规范 8. 命名安全与合规 9. 内容安全与合规 10. 代码与数据安全 11. 功能可用性 12. Skill 与 Tool 关系治理 逐项检查并给出 `PASS`、`WARN`、`FAIL` 或 `SKIP`。发现问题时提供原文证据和可执行修改建议；信息不足时说明缺少什么，不把未知项判为通过。 ## 适用边界 在以下情况使用本 Skill： - 用户要求审核、检查、review、验收或准出一个现有豆包智能服务运行态 Skill。 - 用户提供 `SKILL.md`、Skill 目录、项目目录、zip 包或粘贴的 Skill 内容，希望得到质量评估。 - 用户要检查触发边界、正文逻辑、工具调用、出卡规则、安全合规或 Skill/Tool 边界。 不要在以下情况使用本 Skill： - 用户要创建或改写 Skill；使用对应的开发或 Skill 创建流程。 - 用户只问规范含义，没有提供或指定待审核对象；直接解释规范。 - 用户要做端到端评测、AB 实验、上传或发布，而不是审核 Skill 内容。 默认只输出审核报告，不修改被审核文件。用户明确要求修复时，先完成审核并指出变更范围，再交给对应的创建或开发流程修改。 ## 确定审核对象 1. 接受文件路径、目录路径、zip 解压目录或用户粘贴的 `SKILL.md` 全文。 2. 用户提供豆包智能服务项目目录时，优先审核项目的运行态 Skill；默认位置通常是 `skill/SKILL.md`，不要误把开发指南、仓库级 `AGENTS.md` 或其它通用 Skill 当成目标。 3. 找到多份候选运行态 Skill 且无法从用户意图唯一确定时，只询问用户要审核哪一份。 4. 提取 frontmatter、正文章节、工具声明、参数 schema、示例、输入输出、出卡规则和引用文件。 5. 如项目内同时提供 MCP schema、工具实现、Manifest、前端配置或返回样例，用它们核对能力契约；没有这些材料时，只审核 `SKILL.md` 本地可判定的内容，并将跨文件契约项标记为 `SKIP` 或 `WARN`。 ## 审核流程 1. 解析基础信息：`name`、`description`、正文 token 估算、章节结构、工具列表和引用文件。 2. 逐项审核 12 个维度，每个维度给出结论、证据、问题和修改建议。 3. 专项扫描表意不明与自相矛盾的规则，逐字引用原文证据。 4. 根据 `description` 和正文构造 2-3 个 should-trigger query、1-2 个 should-not-trigger query 和至少 1 个边界输入。 5. 汇总阻塞项，按安全、能力契约、逻辑、可用性、格式和非阻塞优化的顺序给出修复优先级。 6. 按准出规则给出“准出”“有条件准出”或“不建议准出”。 ## 维度 1：命名规范 检查： - `name` 存在且非空。 - 只使用小写字母、数字和连字符，长度不超过 64 个字符。 - 名称能体现能力域，使用简短动词短语或业务关键词。 - 没有拼写错误、无意义命名或容易引起误解的命名。 ## 维度 2：粒度治理 检查： - 正文建议不超过 5000 tokens。 - 覆盖同一轮或连续同一业务对话可完成的任务集，没有塞入无关能力。 - 没有过度拆分成无法独立完成用户任务的碎片。 - Skill 相比单个 Tool 提供了意图路由、参数收集、多步编排、卡片选择或失败降级价值，而非无附加价值的薄封装。 ## 维度 3：description 触发质量 检查： - 使用第三人称或客观陈述，不写“我可以”“你可以”。 - 同时包含 what（做什么）和 when（何时触发）。 - 包含关键触发词和高频用户表达。 - 写明重要排除项，清楚说明不处理什么。 - 长度不超过 300 字符。 - 不包含执行步骤、内部工具链、实现细节或宣传语。 - 不使用“各种”“所有”“相关”“等”这类没有边界的扩张性措辞。 - 触发范围与正文实际能力和工具集一致，不过度承诺。 ## 维度 4：描述清晰度 检查： - 正文章节结构清晰、层次分明。 - 通用边界、意图路由、工具说明、出卡、回复和失败处理都有明确规则。 - 每个工具的参数 schema 包含字段类型、必填或可选、取值范围、格式、默认值、互斥关系和数据来源；不存在的约束没有被编造。 - 场景路由覆盖主要意图，并明确关联工具、工具链、追问、不调用或不支持分支。 - 多步链路写清顺序、依赖字段和字段来源。 - 出卡和不出卡条件、卡片引用方式与文本回复职责明确。 - 工具失败、业务未达成和成功空结果分别说明处理方式。 ## 维度 5：逻辑一致性 检查： - 同一规则只保留一个权威版本，没有重复且不一致的表述。 - 路由与工具章节对同一意图的处理一致。 - 示例与规则、schema、确认条件和失败分支一致。 - 追问条件与自动继续条件没有交集。 - 正向指令与禁止指令可以同时满足。 - 同一参数在不同位置的必填性、默认值、枚举和来源一致。 - 回复结论与工具业务状态一致，不把搜索、试算或空结果说成创建成功。 ## 维度 6：表意不明与自相矛盾 只报告真正无法客观执行或在相同条件下冲突的规则。朴素但明确的规则不算缺陷；不确定时不列。 ### 6a. 表意不明 识别： - 使用“适当”“合理”“必要时”“视情况”等术语，却没有判定标准或阈值。 - 使用“类似”“相关”“等”等开放词语，却没有穷举范围或判断规则。 - 触发条件、适用范围、参数来源或默认策略无法唯一判断。 - 指令自身有多种互不相同的可执行解释。 每项必须逐字引用原文： ```yaml - quote: "原文片段" reason: 为何无法唯一判定或执行 suggestion: 如何改成可判定规则 ``` ### 6b. 自相矛盾 只在两条规则对相同条件给出互斥要求时判为矛盾。针对不同条件的不同规则不算矛盾。 每项必须逐字引用两处原文： ```yaml - quote_a: "原文片段 A" quote_b: "原文片段 B" reason: 两条规则为何不能同时满足 suggestion: 应保留哪条或如何统一 ``` ## 维度 7：格式规范 检查： - frontmatter 使用 `---` 包裹，且只包含非空的 `name` 和 `description`。 - Markdown 标题层级、列表缩进、代码块、表格和链接语法正确。 - 没有乱码、异常不可见字符或编码问题。 - 主线保持“通用边界 → 意图识别与工具选择 → 工具逐项说明 → 出卡与不出卡工具 → 回复与卡片 → 工具失败、业务未达成和空结果”。 - 每个工具章节依次包含“工具说明与使用场景”“注意事项”“工具调用格式”。 ## 维度 8：命名安全与合规 检查： - `name` 不含无法确认授权的品牌、商标或第三方平台名。 - 不使用冒犯性、歧视性或可能引起误解的词汇。 - 无法确认品牌归属或授权时标记 `WARN`，不要推断已授权。 ## 维度 9：内容安全与合规 检查： - 没有复制外部受版权保护的模板、课程、报告或其它内容而未标注来源和授权边界。 - 没有绕过系统指令、越狱或 prompt injection 指令。 - 没有引导生成违法、有害或歧视性内容。 - 外部素材、URL 和数据源的来源、可用性与授权范围有证据；无法核实时标记 `WARN` 或 `SKIP`。 - 涉及不可逆操作、交易、权限和敏感数据时，确认条件与最小必要原则明确。 ## 维度 10：代码与数据安全 检查： - 没有硬编码密钥、Token、密码、Bearer token、AK/SK 或私钥。 - 没有不受控的 `eval`、`exec`、`shell=True`、`pickle.load`、无 SafeLoader 的 `yaml.load`、`sudo` 或反弹 shell。 - 示例没有硬编码可识别个人的手机号、身份证号、邮箱或其它隐私数据。 - 没有绕过反爬、审计或风控的规则或暗示。 - 外部数据源有合法来源和授权边界；无法核实时标记 `WARN` 或 `SKIP`。 - 数据进入 MCP Server、后端、模型上下文、卡片、日志或第三方服务时，只要求完成当前任务所需的最小字段。 证据中只保留脱敏片段，不复制或输出完整疑似密钥。 ## 维度 11：功能可用性 检查： - 所有工具名与 MCP 实际暴露名称一致；没有 MCP 材料时明确标记无法核验。 - 每个工具都有使用场景、禁止调用的相邻场景、注意事项和完整调用格式。 - 每个 required 字段都有可靠来源，缺参时知道追问什么。 - 路由中出现的工具都有定义，定义的工具都有使用场景。 - 多步链路的前序返回能够提供后序工具所需字段。 - 出卡规则与 Manifest `tools.output`、`entities`、`tool_card_binding` 一致；没有 Manifest 时明确标记无法核验。 - 工具失败、业务未达成和空结果都有“如实回复 + 可执行下一步”，且不输出虚假成功结论或卡片。 - 没有把 mock 数据、工程结构、内部实现缺陷或端上渲染 `_meta` 写成模型运行规则。 ## 维度 12：Skill 与 Tool 关系治理 检查： - Skill 不是对某个 Tool 的无附加价值薄封装。 - 多个工具的使用场景没有重叠或冲突。 - Skill 的触发范围与声明工具集匹配，不过度承诺，也不遗漏正文使用的工具。 - 有同场景其它 Skill/Tool 清单时，检查触发条件是否重叠、能力是否遗漏。 - 没有完整 Skill/Tool 清单时，只做本地可判定的检查，将全局比较项标记为 `SKIP`。 ## 冒烟用例 根据被审核 Skill 的 `description` 和正文构造： - 2-3 个 should-trigger query，覆盖核心能力和高频用户表达。 - 1-2 个 should-not-trigger query，覆盖主要排除项和相邻能力。 - 至少 1 个边界输入，验证缺参、歧义、多意图、敏感数据、不可逆操作或空结果中的一类。 说明每条 query 的预期路由、是否调用工具、需要追问的字段和预期出卡行为。无法实际运行时，把它们标为建议用例，不声称已经执行。 ## 报告格式 输出完整 Markdown 报告，不省略任何维度： ```markdown # Skill 审核报告 ## 基础信息 - 审核对象: ... - name: ... - description 长度: ... - 正文预估 token 数: ... - 章节结构: ... - 可用于交叉核验的材料: ... ## 总览表 | 维度 | 结论 | 阻塞项 | |------|------|--------| | 1. 命名规范 | PASS/WARN/FAIL/SKIP | 简述 | | ... | ... | ... | ## 阻塞项汇总 按修复优先级列出所有 FAIL；没有时写“无”。 ## 分维度详细发现 ### 维度 X：维度名 - **结论**：PASS/WARN/FAIL/SKIP - **证据**：逐字原文、文件位置或核验材料 - **问题**：问题或信息缺口 - **修改建议**：可执行修改方式 ### 维度 6：表意不明与自相矛盾 #### 6a. 表意不明 ... #### 6b. 自相矛盾 ... ## 冒烟用例 ### Should-trigger 1. ... ### Should-not-trigger 1. ... ### 边界输入 1. ... ## 准出结论 - **结论**：准出 / 有条件准出 / 不建议准出 - **理由**：... - **修复优先级**：... ``` 每个 `FAIL` 或 `WARN` 都必须包含证据和修改建议。没有发现时明确写“未发现”，不要省略章节。 ## 准出规则 - 任一安全、格式、逻辑或可用性维度出现 `FAIL`：判定“不建议准出”。 - 维度 6 的自相矛盾默认记为 `FAIL`。 - 维度 6 的表意不明通常记为 `WARN`；影响核心路由、安全、权限或不可逆操作时记为 `FAIL`。 - 没有 `FAIL`，但存在 `WARN` 或 `SKIP`：判定“有条件准出”，列出需修复或补证项。 - 至少 5 个非重复 `WARN`：建议修复后重新审核。 - 12 个维度全部 `PASS`，且冒烟用例的预期路由自洽：判定“准出”。 ## 审核约束 - 12 个维度必须全部出现在报告中。 - 不只给总分；逐项给出证据。 - 不做主观审美评价，只评规范、逻辑、安全、可用性和边界。 - 不把信息不足判为 `PASS`；使用 `SKIP` 并说明需要补充什么。 - 维度 6 的引用必须逐字摘录，不改写或概括。 - 维度 6 宁缺毋滥，不把朴素但明确的规则当缺陷。 - 不输出完整疑似密钥或个人信息；证据必须脱敏。 - 不在报告中添加无关营销话术。 - 不把审核规则、检查清单或 `PASS/WARN/FAIL` 报告要求反向要求写进被审核的运行态 `SKILL.md`；这些是审核过程约束，不是目标文件必须包含的内容。