多数团队声称自己在写规格，实际上只是在代码合并后补一份说明。这种”事后规格”的用途只有一个：应付审计。真正的问题——需求边界不清、验收标准模糊、实现先于共识——全部留到了生产环境才暴露。回归测试不是为了验证意图，而是为了固化已经写好的行为；规格文档在第一次发布后就开始与代码脱节。

HotelByte 的做法是把规格驱动开发当成一道工程门禁，而不是文档任务。这道门禁有四个卡扣：提案、规格、实现、归档。任何变更想穿过这道门，必须携带可验证的验收场景、经过独立评审的设计文档，以及部署后不可篡改的完整记录。听起来慢，但比起返工，它更快。

工具的幻觉与系统的真相

行业常见的错误是装了一个规格工具就以为治理会自动发生。Confluence 页面、Jira 工单、Gherkin 文件都只是 artifacts，真正决定规格有没有用的是围绕它的工作流：谁有权推进变更、”完成”的定义是什么、当实现发现规格错误时怎么办。

HotelByte 的工作流把这些规则显式化了。提案必须回答 Why、What、Impact 三个问题，才能拿到一个稳定的编号；规格层要求每个需求都附带 Gherkin 风格的 WHEN/THEN 场景，”提升性能”这类模糊表述会被打回，直到翻译成可测量的声明；实现层不允许偏离已批准的规格，如果实现中发现规格有误，必须先修订规格并重新审批，再改代码——这直接阻止了”代码即规格”的常见反模式；部署后，完整的变更记录被快照到归档层，形成从业务意图到验证行为的不可篡改链条。

边界条件同样重要。文档错别字、现有边界内的配置值更新可以走轻量路径，但任何影响外部可观测行为的变更仍然需要显式场景覆盖。没有”太小而不需要规格”的绿色通道，因为小变更恰恰是假设泄漏的温床。

HotelByte 放弃的选项

代价是项目早期的”编码爽感”。习惯第一天就写代码的团队会觉得提案和规格层令人烦躁。HotelByte 接受这种摩擦，因为在酒店分销平台里，一次搜索请求可能穿越数十个供应商集成，一个预订状态机的理解偏差就可能导致资金损失——事后发现的代价远高于前置的规格成本。

MECE 文档架构和 7±2 规则也带来认知税：工程师在写规格前必须先想清楚它该放在哪里。回报是，即使在一个拥有数千个集成的系统中，任何工程师都能在三次导航内找到某个能力的权威规格。

阅读路径

如果只看一章，读“架构机制”中的三阶段门禁（proposal → implementation → archive）。这是理解门禁如何在实际中运转的最清晰描述。

关注治理视角的读者可以重点看“验证路径”：外部评审如何检查提案是否包含目标、非目标和验收标准，Gherkin 场景是否映射到测试，archive 是否在实现后更新。

想了解这套纪律的执行成本，看“核心设计原则”中对模糊表述的处理：每一个”应该”、”可能”、”适当”都会被标记出来要求澄清。从这里你能判断这套纪律是真实的，还是表演性的。

交叉引用