看到 Poppy 开放协议草案，最容易踩的坑是把「某个实现目前怎么做」当成「协议要求必须怎么做」。可操作的判断顺序是：先按措辞强度把草案里的要求分层，再回到目录确认哪些段落属于能力声明、哪些属于实现说明，最后用一条最小交互流程检查协议层是否闭合。这三步做完，再讨论兼容性才有共同前提；跳过分层直接比对某个实现的配置，很容易把实现细节误读成协议义务。
读 Poppy 开放协议草案时，建议先按措辞强度把要求分成硬约束、建议项和可选扩展，再回到目录确认能力声明与实现说明的边界；凡是草案没写死、又随实现变化的部分，先记为待确认项，不要直接当成兼容性结论。
在 Poppy 草案目录里定位能力声明与实现说明的分界
草案通常会在一份文档里混放两类内容：一类是协议对端点或角色的行为要求，另一类是作者对如何落地给出的建议。判断信号可以先看句式——描述「谁在什么条件下必须观察到什么」的，偏能力声明；描述「建议用某种队列、某种重试节奏、某种存储结构」的，偏实现说明。目录层面通常会出现下面几类章节，具体名称各草案不同，但功能大体相近。
| 章节类型 | 常见内容 | 判别信号 | 读的时候要做什么 |
| 术语与角色定义 | 参与者、端点、会话的角色划分 | 只给名词和边界，不给做法 | 确认后文出现的角色名与这里一致，不一致的记为疑问 |
| 交互流程或时序 | 谁先发起、谁应答、何时结束 | 用步骤或时序描述顺序 | 对照最小流程检查是否有环节缺失 |
| 消息承载与编码 | 交换内容的组织方式 | 规定格式、必填项、扩展位 | 区分「格式必须是什么」和「建议怎么生成」 |
| 错误与终止 | 失败分类、终止条件 | 定义对端可观察的结果 | 确认错误在会话中途和会话建立前是否分别定义 |
| 安全与信任假设 | 认证、密钥来源、信任边界 | 说明前提而非实现手段 | 确认前提未满足时的行为是否定义 |
| 部署与实现建议 | 缓存、重试、并发、容量 | 出现「建议、通常、可以」 | 默认当作实现选择，不计入协议兼容性 |
| 附录与示例 | 示意片段、走查样例 | 内容常带占位符 | 不把示例里的取值当成协议规定值 |
一个实用办法是先把草案文本留存到本地，按措辞扫一遍，再逐条归位，避免只凭记忆判断某句话是约束还是建议。
# 在本地保存的草案文本里定位约束措辞，便于逐条归类
grep -n -E '\b(MUST|MUST NOT|SHALL|SHOULD|SHOULD NOT|MAY|REQUIRED|OPTIONAL|RECOMMENDED)\b' poppy-draft.txt扫出来的结果不要直接当结论，只作为索引：每命中一条，回到上下文确认它约束的是协议行为，还是某个实现的部署方式。
把 MUST、SHOULD、MAY 这类措辞按约束强度归类
措辞强度决定了偏离之后会发生什么，也决定了你需要追问到什么程度。建议按下表归类，读完一种措辞就顺手写下待确认项。
| 措辞 | 约束强度 | 读到时继续追问什么 |
| MUST / SHALL / REQUIRED / MUST NOT | 硬性要求，偏离即不符合草案 | 不满足时对端会观察到什么？草案是否定义了失败反馈？能否用配置、日志或一次最小交互复现？ |
| SHOULD / RECOMMENDED | 建议项，偏离需要给出理由 | 偏离后对端是否仍然接受？互操作的边界停在哪一步？ |
| MAY / OPTIONAL | 可选扩展 | 怎么协商启用？未启用时对端行为是否明确定义？ |
| 普通陈述句、示例片段 | 通常不构成约束 | 这是在描述现状还是提出要求？同一主题在别处是否另有明确要求？ |
需要留意措辞出现在什么语境里。同样是 MUST，用在消息格式上和用在部署方式上，对兼容性的影响完全不同：前者是协议层义务，后者往往只是作者对典型场景的强制假设。这类位置建议单独标记，留到最后一步再判断。
用一条最小交互流程检查协议层是否闭合
把草案里的交互按下面这条文字流程走一遍，看每一环是否都有定义。这里不涉及具体字段名，只检查协议层是否首尾闭合。
- 发起方决定开始一次交互，此时需要什么前提（版本、能力、凭据）？
- 对端接受或拒绝，拒绝时是否给出可区分的理由？
- 双方就本次交互的共同条件达成一致，条件不一致时谁让步？
- 内容或状态开始交换，中途出现异常如何被感知？
- 正常结束，结束动作是否需要对端确认？
- 异常终止（超时、取消、错误），已建立的状态如何收尾？
可能出现的缺口通常集中在四处：一是前提条件在流程章节没写，只在安全章节一笔带过；二是拒绝与错误被合并成同一种结果，导致调用方无法区分重试和放弃；三是终止环节只写了正常路径，超时后的收尾没有定义；四是重试与幂等没有交代，使得同一次交互重复到达时行为不确定。命中任何一处，都建议先记为待确认，而不是默认对端会按自己实现的方式处理。
记录实现方可替换的环节与验证方式
协议草案里通常只有一部分是必须一致的，其余是各家可以换的实现选择。把可替换点单独列出来，能有效避免把某一家实现当成协议本身。
- 传输承载方式：草案只要求语义时，用什么通道承载属于实现选择。
- 内容编码与序列化：只要对端能解析出草案定义的语义，具体编码方式可以替换。
- 存储、队列与并发模型：草案一般不会规定内部结构。
- 重试节奏、超时阈值、退避策略：多数草案给的是建议区间甚至不给。
- 凭据来源与配置下发方式：文件、环境变量还是外部服务，通常由实现决定。
- 日志、指标、追踪的导出方式：属于运维选择，不是协议义务。
验证方式以「可观察」为准，不要靠推断。改一处配置后跑一次最小交互，观察日志里该环节的标识是否随之变化，以及对端响应是否仍落在草案定义的语义范围内。可以用下面的模板逐条记录，方便后续比对两个实现。
环节：传输承载
草案位置：交互流程章节
措辞强度：SHOULD
替换动作：改配置后重跑一次最小交互
观察点：本地日志中该环节的标识、对端返回的结果类别
未确认项：偏离该建议后，对端是否仍然接受如果日志里看不出该环节，通常说明验证点选得太粗，可以先在测试环境打开更细的日志级别再重复一次，而不是直接下结论说「不影响」。替换后的行为是否符合协议，需要结合部署环境和具体版本来确认。
形成读 Poppy 草案的兼容问题清单
把上面的判断沉淀成一份可复用的清单，评估任何实现时都按同样的问题过一遍。下面是可以直接抄走的模板，答案根据实际草案文本和实测行为填写，不要预设结论。
- 这条要求出现在哪一节，属于能力声明还是实现说明？
- 它用的是哪种措辞，硬约束、建议项、可选扩展还是普通陈述？
- 如果是硬约束，不满足时对端可观察到什么？
- 如果是建议项，偏离的代价是什么，是否影响互操作？
- 如果是可选扩展，协商方式与未启用时的默认行为是否定义？
- 最小交互的六个环节中，哪几个在草案里没有明确对应？
- 版本或能力不一致时，由哪一方决定降级或拒绝？
- 哪些环节属于实现可替换点，替换后用什么配置或日志确认行为没变？
- 两次交互重复到达时，草案是否交代了幂等边界？
- 当前实现与草案文本不一致的地方，是偏离了约束，还是只是选了不同的实现路径？
清单填完之后，区分「协议不允许」和「这家实现暂时没做」就容易多了。前者的分歧必须解决，后者通常只是对接时需要额外约定的事项，不宜写进兼容性结论里。