好的 Spec 应当像业务文档一样可读，同时像代码一样可执行。请遵循以下三大法则：
核心： Spec 描述的是业务规则（What），而非操作步骤（How）。避免陷入UI细节，如“点击”、“输入”等，这会让测试变得脆弱。
核心： 标题必须揭示业务价值。不要让读者猜测测试的目的。必须使用开发和业务都能懂的通用语言（Domain Language）。
核心： 不要穷举所有数据，那是机器做的事。人写的Spec应该包含最具代表性的关键实例（Key Examples），通常包括基础路径和核心边界。
不要只听客户说"要什么"
要问"为什么"
理解目标： 客户提出的通常是解决方案，而非真正的问题。团队需要挖掘背后的商业目标。
以始为终： 范围应由目标决定。这是 Spec 的起点。
协作定义： 只有理解了目标，开发人员才能提出更优的技术解法。
Three Amigos 会议
(BA + 开发 + 测试)
避免筒仓： 需求不应由BA独自写完扔给开发。必须三方共同参与。
建立共享理解： 面对面的讨论比文档流转效率高得多。
提前发现Bug： 测试人员在需求阶段的提问（“如果数据为空怎么办？”）是成本最低的Bug修复方式。
抽象是歧义的根源
具体的例子才是真理
具体化： 不要说“系统应计算折扣”，要说“VIP用户购买满100元，折扣为10%”。
人类友好： 人类大脑更擅长处理具体实例，而非抽象逻辑。
边界探索： 通过具体的极端例子（如0，负数），快速对齐对业务规则的理解。
胶水代码层
(Automation Layer)
分离关注点： Spec 保持业务语言（人类可读），自动化代码负责翻译和执行。
避免UI测试： 尽量在业务逻辑层（API/Service）验证，UI测试脆且慢，维护成本极高。
单一事实： 自动化确保 Spec 永远不说谎。
这是 Spec 生命周期的起点。通过“举例说明”讨论需求。此时发现的逻辑漏洞，修复成本几乎为零。如果你等到代码写完才写Spec，你就错过了SBE 80%的价值。
将讨论中杂乱的草稿提炼为清晰、干净的 Spec。去除噪音，保留关键实例。这个文档将直接作为开发的验收标准。
开发人员编写胶水代码，将 Spec 变为可执行的测试。Spec 从红（失败）变绿（通过），标志着功能的完成。Spec 指导开发，而非仅仅验证开发。
Spec 进入 CI/CD 流水线，成为回归测试网。它不仅保护系统不被破坏，更是新加入成员了解业务逻辑的最佳活说明书。