业务流深度判则
本判则用于判断一个 Skill 是否真实承载了可执行、可复核、可迭代的业务流程。它补充格式检查，不替代动态 eval。
0. Skill 的本质(审查的根基)
Skill 的价值在于渐进式披露 + 可执行的处理流程 / 工作规范:在有限的 SKILL.md 里给出触发与流程骨架,按需展开 references,让 agent 能照着执行、能验收、能迭代。这是 Skill 区别于"一份文档 / 一个知识库"的根本。
知识库型不是合格的 Skill——把原始文本 / 知识 / 语料 / 法条 / 书稿章节成堆塞进 skill,没有抽成可执行的抽象规范、没有可执行流程、无法渐进式披露。这违反 Skill 的本质,判 Hard Fail(见 §4"知识堆砌")。
要沉淀某类知识,必须抽成抽象规范(可执行的规则 / 判定流程 / 输出模板),而不是塞原文。例:不是把"合同审查要点 100 条"原文塞进 skill,而是抽成"合同审查 N 步流程 + 每步检查项 + 命中后动作"。
审查时不做"类型分类"(不区分业务型 / 知识库型 / 工具型给不同标准)——所有 Skill 都按"渐进式披露 + 可执行流程"这个本质审。不达本质(无可执行流程 / 知识堆砌)即判 Hard Fail,与"它属于哪一类"无关。
1. 适用范围
在审查以下情况时使用本判则：
- 用户要求判断一个 Skill 是否“有用”“够不够深”“能不能发布”
- Skill 已通过基础格式检查，但仍需要判断业务质量
- Skill 面向专业工作流，输出会影响判断、交付或后续决策
- 需要区分“规则罗列型文档”和“可执行业务单元”
不要把本判则用于评判具体任务答案是否正确。具体答案质量应进入 benchmark eval 或人工复核。
2. 总体判断
一个合格的业务型 Skill 至少应回答四个问题：
- 什么时候触发，什么时候不触发
- 输入不足时如何识别缺口
- 处理过程中按什么步骤推进
- 输出如何验收，哪些情况必须判失败
如果一个 Skill 只列出原则、注意事项或写作要求，但没有明确执行路径、输入输出、边界和验收方式，应判为业务流深度不足。
3. 严格度
默认采用中等严格度：
- Hard Fail 条件是硬指标，出现任一项即不能通过质量验收
- Trigger / Intake / Reasoning / Output / Safety 五层是软指标，用于定位薄弱环节
- 所有 Skill 都按"渐进式披露 + 可执行流程"的本质审,不按"类型"给不同标准(不做类型分类)
- 低自由度的纯工具型,Reasoning 可短但不能缺输入输出和验收;高风险专业型,Intake / Reasoning / Safety 要求更严——这是按"任务脆弱性"调严格度,不是按"skill 类型"分类
4. Hard Fail
出现以下任一情况，判为严重问题：
- 编造关键事实、证据、时间、主体或依据
- 未标注信息不足，却给出确定性专业结论
- 将辅助分析、初筛或草稿表述为正式意见
- 引用明显错误或与结论不相关的依据
- 在高风险场景下没有提示人工复核或专业人员介入
- 未按 Skill 自身规则输出必要免责声明、风险提示或升级建议
- 输出会泄露本应脱敏的个人、企业或案件敏感信息
- 公开示例、配置模板或参考文档中出现真实人名、客户名、案件项目、案号或可反查组合信息
- 文档没有可执行流程，只是概念、原则或口号堆叠
- 知识堆砌:把原始文本 / 知识 / 语料 / 法条 / 书稿成堆塞进 skill,未抽成可执行的抽象规范,无可执行流程、无法渐进式披露(知识库型 skill 的典型问题)——skill 不是知识仓库
5. 五层检查
5.1 Trigger
检查问题：
- description 是否清楚说明功能、触发场景和不触发场景
- Skill 是否会误处理本应由其他流程先完成的任务
- 是否区分低风险任务、专业判断任务和正式交付任务
质量不足表现：
- 触发条件泛泛而谈
- 不触发场景缺失
- 把准备工作、材料获取、专业判断混成一个入口
5.2 Intake
检查问题：
- 是否列出必要输入
- 是否说明关键缺失信息会如何影响判断
- 是否要求信息不足时先追问或标注“待补充”
质量不足表现：
- 缺少输入清单
- 缺少追问机制
- 对材料缺口直接跳过并输出结论
5.3 Reasoning
检查问题：
- 是否说明事实提取、归纳、判断之间的边界
- 是否要求结论与材料或依据可回溯
- 是否说明冲突材料、不确定事实、假设条件如何处理
质量不足表现：
- 只要求“专业”“准确”，没有可观察标准
- 没有区分材料原文、模型归纳和判断
- 没有处理冲突信息的规则
5.4 Output
检查问题：
- 是否定义输出结构或合理默认格式
- 是否说明输出给谁看、用于什么后续动作
- 是否有完成标准、验收标准或不可交付条件
质量不足表现：
- 输出样式随意
- 没有下一步建议或交接信息
- 看似完整，但不能进入真实工作流
5.5 Safety
检查问题：
- 是否说明隐私、脱敏、保密和敏感信息处理
- 是否要求示例、配置模板和 benchmark 材料去具体化
- 是否限制过度承诺
- 是否要求高风险情况升级人工复核
质量不足表现：
- 没有安全边界
- 示例配置中出现具名人员、客户、案件项目或真实联系方式
- 缺少免责声明或升级建议
- 对高风险事项使用确定性承诺
6. 可评估性检查
本节判断是否具备评估基础。若 Skill 声称稳定完成、已验证或可交付，不能停在“具备基础”；继续按 harness-reliability-standards.md 检查独立验证、候选绑定证据和故障注入。若还声称多轮不漏项或产出稳定，继续按 instruction-stability-standards.md 检查逐约束追踪、验证模态、产物阶段和重复执行证据。
审查时确认 Skill 是否具备以下评估基础：
| 检查项 | 状态 | 说明 |
|---|---|---|
| 声明评估范围 | ✅/⚠️/❌ | 明确哪些能力可验收，哪些不在本 Skill 范围内 |
| 声明 Hard Fail | ✅/⚠️/❌ | 说明哪些错误一票否决 |
| 提供 benchmark case 或样例 | ✅/⚠️/❌ | 至少说明典型输入、必须包含项和禁止项 |
| 提供输出验收标准 | ✅/⚠️/❌ | 能判断输出是否可交付或可接手 |
| 区分静态检查与动态评估 | ✅/⚠️/❌ | 不把格式合规误当作任务效果通过 |
| 逐约束追踪与模态匹配 | ✅/⚠️/❌ | 硬约束绑定 active checker、正确产物阶段和正反例 |
| 多轮稳定性证据 | ✅/⚠️/❌ | evaluator-signed 候选外硬约束基线/held-out 与 Harness evidence 有效；至少三轮同输入/配置、唯一 nonce/签名 producer log 的真实产物逐约束 measurement 阈值和历史回归未漂移 |
7. 深度分级
| 等级 | 判定 | 说明 |
|---|---|---|
| ❌ 不通过 | 触发 Hard Fail，或没有可执行流程 | 不建议发布或投入使用 |
| ⚠️ 需改进 | 有基本流程，但输入、推理、输出或安全标准不完整 | 可作为草稿，需补齐关键规则 |
| ✅ 可通过 | 流程、边界、验收和安全要求完整 | 可进入发布或进一步动态 eval |
8. 审查输出建议
审查报告应单独列出“业务流深度”部分：
## 业务流深度
| 层级 | 状态 | 说明 |
|------|------|------|
| Trigger | ✅/⚠️/❌ | ... |
| Intake | ✅/⚠️/❌ | ... |
| Reasoning | ✅/⚠️/❌ | ... |
| Output | ✅/⚠️/❌ | ... |
| Safety | ✅/⚠️/❌ | ... |
### Hard Fail
- 未发现 / 发现 N 项
### 结论
- 通过 / 需改进 / 不通过设计理念（为什么这样要求）
业务流与可评估类建议在报告里要带一句话理念，可直接引用以下表述。
- 评估驱动 / Hard Fail 可机判：先在没有 Skill 的状态下跑代表性任务、记录真实失败，据此定义评估场景，再写最小指令去通过——避免写出一堆"想象出来的需求"。同时为质量关键操作定义可机器判定的硬通过条件（如"验证脚本返回 OK""必填字段非空"），让"成功"是客观可判的，而非凭感觉。对应"声明 Hard Fail""提供 benchmark case""提供输出验收标准""区分静态检查与动态评估"。
- 报告话术：「流程缺可机判的 Hard Fail（如"必须经 validate.py 返回 OK 才继续"），"成功"全凭主观。把不可妥协的验收点写成显式门控，并补 2-3 个"应触发/不应触发/功能正确"的 benchmark 用例作为验收基线。」