Back to Details

evidence-driven-validation

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Evidence-Driven Validation

基于实证的验证

Use this skill when the user wants more than a quick test and explicitly cares about showing that programmed behavior is correct.
Typical triggers:
  • "prove it works"
  • "don't just eyeball it"
  • "show me why this is correct"
  • "I want a real validation plan"
  • "this transition / workflow / interaction must be exact"
  • "I want measurable correctness, not vibes"
当用户不满足于快速测试，且明确希望证明程序行为正确时，可使用此技能。
典型触发场景：
  • "证明它可行"
  • "别只凭目测判断"
  • "告诉我为什么这是正确的"
  • "我需要一个真正的验证计划"
  • "这个转换/工作流/交互必须完全准确"
  • "我想要可衡量的正确性，而非主观感觉"

Goal

目标

Turn the programmed system into an observable model and then check:
  1. what the valid states are
  2. which transitions are allowed
  3. which invariants must hold during and after every transition
  4. which artifacts prove the result
将编程系统转换为可观测模型，然后检查：
  1. 哪些是有效状态
  2. 允许哪些状态转换
  3. 在每次转换期间及之后必须保持哪些不变量
  4. 哪些工件可证明结果

Workflow

工作流程

  1. Define the state model
  • inputs
  • internal state
  • outputs
  • persisted state
  • task-specific runtime state such as queue progress, active step, or selected entity
  1. Define validation obligations
Write them in an if-then form:
  • If preconditions hold,
  • and transition 
    T
    is applied,
  • then invariant set 
    I
    must still hold,
  • and the resulting observable state must match the expected state.
  1. Add diagnostics
Add the smallest observability layer that makes the obligations checkable.
Expose at least:
  • current state values
  • transition phase
  • counters
  • derived outputs
  • persisted snapshot checksum when persistence matters
  • error count or failure signals
  1. Add deterministic runs
Use automation to run repeatable cases such as:
  • idle stability
  • transition sequences
  • persistence roundtrip
  • boundary conditions
  • failure handling
  • regression cases for bugs that were already found
  1. Save artifacts
For every validation case, save:
  • JSON state snapshot
  • pass/fail verdicts
  • log output
  • screenshot or trace when visuals matter
  • optional video when motion or timing matters
  1. Keep one manual protocol
If a critical behavior cannot be simulated reliably, write a short manual protocol with exact pass rules and required evidence.
  1. 定义状态模型
  • 输入
  • 内部状态
  • 输出
  • 持久化状态
  • 任务特定的运行时状态，如队列进度、当前步骤或选定实体
  1. 定义验证义务
以“如果-那么”的形式编写：
  • 如果前置条件成立，
  • 且应用了转换
    T
    ，
  • 那么不变量集合
    I
    必须仍然成立，
  • 且最终的可观测状态必须与预期状态匹配。
  1. 添加诊断机制
添加最小化的可观测性层，使验证义务可被检查。
至少需暴露：
  • 当前状态值
  • 转换阶段
  • 计数器
  • 派生输出
  • 当持久化很重要时的持久化快照校验和
  • 错误计数或失败信号
  1. 添加确定性运行
使用自动化执行可重复的测试用例，例如：
  • 空闲稳定性
  • 转换序列
  • 持久化往返测试
  • 边界条件
  • 故障处理
  • 已发现bug的回归测试用例
  1. 保存工件
为每个验证用例保存：
  • JSON状态快照
  • 测试通过/失败判定结果
  • 日志输出
  • 当视觉效果重要时的截图或追踪信息
  • 当动态效果或时序重要时的可选视频
  1. 保留一份手动流程文档
如果某个关键行为无法可靠模拟，编写一份简短的手动流程文档，包含明确的通过规则和所需证据。

Output Standard

输出标准

The result is only complete when all of these exist:
  • diagnostics mode or equivalent observability hook
  • deterministic validation runner
  • artifact directory
  • readable report
  • clear list of currently passing vs failing validation cases
只有当以下所有内容都存在时，结果才视为完整：
  • 诊断模式或等效的可观测性钩子
  • 确定性验证运行器
  • 工件目录
  • 易读的报告
  • 当前通过与失败验证用例的清晰列表

Important Rule

重要规则

Do not claim success from appearance alone.
If the validation runner says a case fails, report it as failing even if the feature looks mostly right.
不要仅根据外观宣称成功。
如果验证运行器显示某个用例失败，即使功能看起来大致正常，也要将其报告为失败。