面对 Poppy 开放协议草案，判断某项能力是硬性要求还是建议，可靠的做法不是看实现方的宣传材料，而是回到草案文本本身：动词和情态词决定措辞强度，交互流程决定缺失后的后果，声明主体决定谁该负责。先把这三件事分开，再决定这项能力要不要接、接了以后怎么降级。

建议按三步判断：先摘出草案里描述该能力的原句，看用的是「必须／应当」还是「可以／建议／可选」；再假设这项能力缺失，看主流程还能不能走完；最后确认这句话是协议本身写的，还是某个实现方自己加的。三者结论不一致时，以草案原文为准，把不确定项写进兼容矩阵，而不是先写进对外承诺。

在 Poppy 草案里找出能力描述的动词和情态词

大部分草案不会用「硬性」「建议」这种标签，而是靠情态词区分强度。可以先按下面的分组粗筛，再逐条读上下文，注意同一句里的条件从句会改变权重，例如「在 X 未提供时，客户端 must 回退」强制的其实是回退动作，不是 X 本身。

• 偏硬性：必须、应当、不得、must、shall、required、must not。通常对应实现方无法合法忽略的行为。
• 偏建议：建议、推荐、宜、should、recommended、expected。多数场景是鼓励实现，但不满足不一定导致流程失败。
• 偏可选：可以、可选、允许、may、can、optional、at the discretion of。通常由实现方自行决定是否提供。
• 需结合环境确认：支持 support、兼容 compatible、遵循 conform。这类词单独看不表强度，要看它后面接的是哪种动词。

# 先定位，再判断；不要把命中结果直接当成结论
grep -nEi "must|shall|required|may|can|should|recommended|optional" poppy-draft.txt
grep -nE "必须|应当|不得|可以|建议|推荐|可选" poppy-draft-zh.txt

如果草案同时有中英版本，建议以其中一版为主版本比对。翻译漂移常见于 should 被译成「应」或「必须」，遇到两边措辞不一致时，先把这条标成待确认，不要直接按更强的一版执行。

把支持、可选、推荐放进交互流程里验证

措辞只能给出第一层判断，第二层判断靠流程：假设这项能力不存在，交互还能不能走完。把正常路径和降级路径用文字写出来，比读十遍草案更有用。

正常路径：
  客户端发起请求 -> 服务端返回基础字段 + 可选能力字段
  -> 客户端按可选能力处理 -> 得到结果

降级路径：
  客户端发起请求 -> 服务端不提供可选能力字段
  -> 客户端回退到基础字段或默认行为 -> 得到结果（字段更少或需二次请求）

写完两条路径后逐点核对：如果去掉该能力，流程卡在某一步且没有替代动作，通常说明它是硬性依赖；如果只是结果字段变少、精度下降、需要额外一次请求或多一段本地处理，一般属于建议项或可选能力。还有一种中间情况：缺失时协议允许对端拒绝整个请求，那它表面是可选、实际是准强制，需要在矩阵里单独标注。这一步只依赖草案文本和日志行为，不需要额外造数据。

区分协议草案要求与实现方附加能力

实现方的文档、公告、示例代码里出现的能力，不等于协议要求的。避免混淆，可以固定问三个问题：

1. 谁声明：这项能力是否出现在草案正文或附录里？只出现在某实现方的 README、变更日志或示例配置里的，先当作实现附加能力。
2. 谁可拒绝：对端能否在不违反协议的前提下忽略或拒绝这项能力？能拒绝的，通常不是协议级硬性项。
3. 谁承担回退：缺失时由哪一侧负责兜底——发起方、接收方，还是双方都要处理？责任写不清的地方，往往是草案留白，需要双方协商后落到自己的实现约定里。

三个问题的答案如果集中在实现方一侧，就把它记为「实现选择」；只有落在草案正文并带硬性情态词的，才记为「协议要求」。中间状态先记为待确认，等看到草案修订或对端明确的配置行为再定。

用兼容矩阵整理建议项取舍

把上面几步的结论落成一张表，比记在脑子里更稳。矩阵维度固定为能力、约束强度、缺失后果、验证方式，结论栏留空，等确认后再填，不要先写预期值。

填表时保持一行一个能力，不要把几个能力合并成一行，否则后续取舍会纠缠在一起。约束强度按草案原句填，验证方式写清是看了哪份文本、哪条日志或哪次配置对比；如果暂时只有一种证据，就注明证据不足。这张表可以随版本更新，但不要用实现方单方面的宣传内容覆盖草案原文的结论。

写出对外沟通时的边界表述

判断清楚之后，还要在沟通里说清楚，避免把建议项讲成强制要求。对外描述时，先分清是协议要求还是实现选择，再用对应句式表达。

协议要求句式：
  按 Poppy 草案相关条款，<能力名> 属于 <必须/应当> 项；
  对端若不提供，流程 <会中断/可被拒绝>，因此对接时需按强制项处理。

实现选择句式：
  <能力名> 目前由 <某实现方/某版本> 额外提供，草案未列为强制项；
  我们在此基础上做了支持，对端是否提供不影响基础流程能否走完。

这两种句式可以并排用在设计说明或对接邮件里，把「协议怎么说」和「我们怎么做」分开陈述。遇到尚未确认的项，用「待确认，需结合草案修订和对端行为核实」收尾，比提前写成承诺更容易在后续保持一致。