naodeng 可测试性分析（中文版）
何时使用
- 需要评估需求与系统在可控制、可观察、可隔离和可复现方面的测试准备度。
- 需要对现有方案、结果或证据做风险评审，并形成可执行改进项。
- 输入不完整，但仍需先给出带假设和信息缺口的可用初版。
输出格式选项
- 默认输出 Markdown，适合评审、执行和持续补充。
- 用户要求表格、CSV、JSON 或工单格式时，保留同样的风险、证据、优先级和边界字段。
- 若输出会进入自动化流程，先确认字段 schema、枚举值和必填项。
如何使用
- 先阅读并遵循
prompts/testability-analysis.md的输入、执行规则、最低覆盖清单和输出顺序。 - 补充真正影响判断的范围、环境、版本、限制、证据和成功标准。
- 先做输入审计，再区分已确认事实、合理假设和待确认问题。
- 当任务要求
architecture-testability-review或architecture模式时，先从架构制品、依赖拓扑、异步边界、测试接缝、替身策略、故障注入入口和环境复现分析，再保留通用可测试性维度。 - 按风险和证据强度排序，产出可直接执行、评审或验证的结果。
- 信息不足时不要停在提问：先交付受限初版，并说明哪些结论暂不能成立。
参考文件
- 每次执行必须读取
prompts/testability-analysis.md；它是本 Skill 的完整执行规范。 - 需要评测或回归本 Skill 时，读取
evals/eval.yaml与匹配的evals/cases/用例。 - 只有目录实际存在且任务需要时，才读取
references/、examples/、scripts/或output-formats.md，不要假设不存在的资产。 - 需要回归
architecture-testability-review时使用architecture-*Eval 和本地触发数据；仍复用本 Skill 的物理目录，不创建别名目录。
核心约束
- 不要把测试框架选择当测试性本身
- 每项改进说明价值和成本
- 避免为测试暴露不安全后门
architecture模式必须用架构级来源支撑接缝、替身、隔离和故障注入判断；不把框架名称当作可测试性证据。- 不编造输入中不存在的系统行为、字段、数据、指标或根因。
- 关键结论必须关联证据；证据不足时标记为假设并给出验证方法。
- 优先级必须说明业务影响、发生可能性或可探测性依据。
交付前自检
- 已覆盖：可观察性、可控制性、隔离、确定性、数据准备、故障注入、环境一致、自动化接口。
- 已区分事实、假设、缺口和建议。
- 高风险项有明确优先级、证据、负责人或下一步。
- 输出包含可验证的判断标准，而非泛泛而谈。
- 未执行未经授权的生产写操作或破坏性动作。
常见误区
- 只列检查点，不说明输入条件、预期结果或证据。
- 把所有事项都标为高优先级，失去取舍价值。
- 用工具名或通用理论替代领域判断。
- 输入不完整时直接拒绝，或反过来假装结论已经确定。
最佳实践
- 从最可能造成业务损失、安全问题或发布阻塞的路径开始。
- 用最小可验证实验缩小不确定性，并记录复现条件。
- 让输出能够被另一位工程师直接执行和复核。