Concept：如何理解 evidence_level
在 Treeify 的部分生成结果中，你会看到一个字段：evidence_level。
这个字段用于标记：当前这条内容，和原始输入需求之间的依据强度是什么。
它不是质量评分，也不是优先级标记，而是帮助你判断：这条内容到底是直接来自需求、由需求推导出来，还是基于测试设计常识补充出的内容。
当前支持的取值包括：
explicitimpliedinferred_typedomain_common
为什么 Treeify 要提供 evidence_level
在测试设计中，并不是所有内容都来自同一种“依据”。
有些内容在需求里写得非常明确；有些内容虽然没有逐字写出，但根据上下文可以合理推出；还有一些内容，是为了让测试设计更完整，结合类型判断或通用领域常识补充出来的。
如果不区分这些来源，用户很容易遇到两个问题：
- 不知道哪些内容是需求明确要求的
- 不知道哪些内容需要进一步确认或评审
因此，Treeify 用 evidence_level 来帮助你区分每条内容的依据来源，让你在评审和使用结果时有更强的判断依据。
四种 evidence_level 分别表示什么
explicit
表示这条内容在输入需求中被明确写出，或者可以直接从原文中定位到对应表达。
这类内容通常是最直接、最稳定的需求依据。
例如，需求中明确写了：
连续 5 次登录失败后锁定账号。
那么与“5 次失败后锁定账号”相关的测试设计内容，就可以标记为 explicit。
你可以将 explicit 理解为：
- 有明确原文依据
- 可直接追溯到输入内容
- 通常优先作为稳定需求进行采纳
implied
表示这条内容虽然没有被逐字写出，但可以根据已有需求上下文合理推导出来。
它仍然建立在输入需求之上，但不是原文直接出现的句子，而是对已有逻辑的自然延伸。
例如，需求中写了：
用户提交成功后跳转到订单确认页。
虽然需求没有明确写“提交失败时应有失败反馈”，但如果已有上下文表明系统需要处理失败分支，那么某些相关测试关注点可能会被标记为 implied。
你可以将 implied 理解为：
- 不是原文直接陈述
- 但和现有需求逻辑有较强关联
- 通常值得纳入评审，但必要时应人工确认
inferred_type
表示这条内容不是直接来自某一句需求，而是根据当前需求所属类型、任务目标或结构特征推断出来的内容。
这种情况通常出现在：需求本身没有把测试关注点完整展开，但从“这类需求通常需要覆盖什么”可以推断出某类测试设计内容。
例如，一段明显属于 API 输入校验类需求的内容，虽然没有逐项列出所有字段验证逻辑，但 Treeify 可能会基于“这是 API 契约型需求”的判断，推断某些测试关注点，并标记为 inferred_type。
你可以将 inferred_type 理解为：
- 来自对需求类型的判断
- 更偏向结构化推断，而不是直接文本依据
- 适合帮助补齐测试设计，但更建议人工审查后采纳
domain_common
表示这条内容来自该领域中较常见、较通用的测试关注点或业务常识，而不是当前需求中明确写出的内容。
它的作用通常不是断言“需求一定如此”，而是提示：从该领域经验看，这里往往存在值得关注或值得确认的测试点。
例如，在支付、权限、安全、合规等场景中，某些输入校验、权限隔离、异常处理、审计留痕等内容，即使需求中没有明确展开，也可能被 Treeify 作为 domain_common 标记出来。
你可以将 domain_common 理解为：
- 更偏向领域共识或通用测试经验
- 不等同于需求已经明确规定
- 更适合作为补充提醒、评审提示或待确认项
在实际使用中，应该如何理解这四类标记
你不需要把 evidence_level 当作“对错判断”，而应该把它当作“依据来源说明”。
一个更实用的理解方式是：
explicit：需求中明确写了，可以优先信任和追溯implied：需求里能推出来，建议结合上下文审查inferred_type：基于需求类型推断出的补充，建议重点复核domain_common：来自领域常见经验的提醒，适合作为补充和确认项
换句话说，evidence_level 越靠后，并不代表“越差”，而是代表它越需要你结合项目背景、团队标准和真实需求去判断是否采纳。
Treeify 为什么不只输出 explicit
如果 Treeify 只输出 explicit 内容，结果会更保守，也更容易遗漏很多测试设计中真正重要的部分。
因为真实需求文档通常并不完整。很多关键逻辑并不会被写得足够细，尤其是边界条件、异常分支、角色差异和领域常见风险。如果 AI 完全不去补充，最终结果虽然“安全”，但很可能不够实用。
因此，Treeify 不仅保留对明确需求的追溯能力，也会通过 implied、inferred_type 和 domain_common 帮助你看到：
- 哪些内容是需求已经明确提出的
- 哪些内容是从上下文中自然延伸出来的
- 哪些内容是为了让测试设计更完整而补充出来的
这也是 Treeify 在“减少幻觉”和“保证可用性”之间采取的一种平衡方式。
使用建议
在查看带有 evidence_level 的结果时，建议你这样使用：
- 优先确认
explicit内容，确保与原始需求一致 - 对
implied内容，结合上下文判断是否符合真实业务逻辑 - 对
inferred_type内容，确认它是否符合当前需求类型下的测试设计目标 - 对
domain_common内容，将其视为高价值补充提示，而不是默认已经被需求确认的事实
如果你的团队对测试设计的可追溯性要求较高，这个字段会特别有帮助。它能让你更清楚地区分“需求依据”和“设计补充”，从而提高评审效率，也降低误采纳风险。
总结
evidence_level 用于说明：Treeify 生成的某条内容，与原始需求之间的依据强度和来源类型。
它帮助你回答的不是“这条内容写得好不好”，而是：
- 它是不是需求明确写出的？
- 它是不是根据上下文推出来的？
- 它是不是基于需求类型补充出来的？
- 它是不是来自领域通用经验？
通过这个字段，Treeify 希望让测试设计结果不仅更完整，也更透明、更可追溯、更便于评审。