跳转至

Deep Research: [74] RFC 2119：把必须/应该/可以写成团队一致的合同语言

  • Source: https://www.rfc-editor.org/rfc/rfc2119
  • Note: ../notes/ref-074-rfc2119.md
  • Snapshot: ../sources/md/www-rfc-editor-org-rfc-rfc2119-71c19fc9d8e6.md
  • Category: PRD & Specs (prd_spec)
  • Chapters: 03-prd, 07-engineering

TL;DR

RFC 2119 将必须、应该、可以这些模糊的自然语言转化为具备法律效力的技术契约术语（MUST/SHOULD/MAY），在 AI 产品开发中，它是消除 PRD 与工程实现之间语义鸿沟、定义概率性 AI 系统行为边界（Guardrails）的基石。

核心观点

  1. 术语即契约：RFC 2119 定义的关键词不是语气助词，而是严格的验收标准。MUST 意味着违背即故障（Bug），SHOULD 意味着违背需特批（Exception），MAY 意味着完全可选。
  2. MUST 的绝对性：代表产品的核心功能或安全底线。如果一个功能被标记为 MUST 但未实现，该版本不可发布。
  3. SHOULD 的权衡性：表示强烈建议。存在正当理由时可以忽略，但必须经过深思熟虑并在文档中记录原因（Why specifically usually ignored）。
  4. MAY 的互操作性：表示可选。关键在于系统必须具备鲁棒性——无论该选项是否存在，系统都必须能正常工作（Handle implementation/omission）。
  5. 严禁滥用：这些命令性词汇应仅用于确保护互操作性（Interoperability）或限制潜在危害（Limit behavior），而非用于强制非必要的实现细节。
  6. 安全隐患：未实现 MUST 或错误实现 MUST NOT 通常会直接导致安全漏洞，而忽略 SHOULD 的安全后果往往较为隐蔽，需特别评估。
  7. 大小写敏感：在文档中通常使用全大写（MUST, MUST NOT...）以示区别于普通自然语言。

可落地做法

1. 产品经理（PRD 撰写）

  • 显式声明：在 PRD 开头添加 Terminology 章节，声明本文档关键词必须按 RFC 2119 语义解读。
  • Prompt 优化：在让 AI 生成 PRD 时，System Prompt 中加入：使用 RFC 2119 标准（MUST/SHOULD/MAY）描述功能需求，避免使用‘最好’、‘尽量’等模糊词汇。
  • 边界定义：对于 AI 的幻觉或错误，使用否定句式定义围栏（Guardrails），例如：模型输出 MUST NOT 包含用户未提供的个人身份信息（PII）。

2. 研发工程师（架构与编码）

  • 断言映射：将文档中的 MUST 映射为代码中的 assert、强类型检查或核心逻辑判断；将 SHOULD 映射为 Warning 日志或监控告警。
  • 降级策略：针对 MAY 的功能，必须在代码中预留 if feature_enabled: 的分支，并确保 else 分支有完整的兜底逻辑。

3. 测试与评测（QA/Eval）

  • 验收分级：
    • Blocker：违反 MUST 条款。
    • Major/Normal：违反 SHOULD 条款且无文档化理由。
    • Minor：违反 MAY 条款（通常不记为 Bug，除非导致崩溃）。
  • AI 评测集（Judge）：在编写 LLM-as-a-Judge 的 Prompt 时，直接使用 RFC 2119 词汇指导模型打分：如果是 MUST 条款未满足，打 0 分；如果是 SHOULD 条款未满足，扣 2 分。

检查清单：PRD 语义合规性

  • [ ] 前置声明：文档是否引用了 RFC 2119 标准？
  • [ ] 去模糊化：是否已清除了尽量、最好、如果可能的话等模糊词汇？
  • [ ] MUST 滥用检查：是否所有的 MUST 都是 MVP 必不可少的？（如果全是 MUST，等于没有优先级）
  • [ ] SHOULD 理由：对于工程侧决定忽略的 SHOULD 条款，是否记录了忽略的理由？
  • [ ] 互操作性：对于 MAY 的功能，是否定义了不支持该功能时的系统行为？
  • [ ] 否定式围栏：是否明确定义了 MUST NOT（严禁）的行为，特别是在安全和隐私方面？

常见坑与对策

常见误区 实际后果 对策
通篇 MUST 研发无法排期，导致所有需求都被同等对待，实际上失去了优先级。 限制 MUST 的数量，仅用于 MVP 核心路径和安全红线。非核心体验降级为 SHOULD。
混用大小写 团队成员忽略了这是强制要求，以为只是普通描述。 统一规范：在正式文档中严格使用全大写（MUST/SHOULD）。
SHOULD 变 Optional 工程师认为 SHOULD 就是可以不做。 建立机制：忽略 SHOULD 必须提交 Ticket 说明原因，否则视为 Bug。
忽略 MAY 的另一面 实现了可选功能，但未测试关闭该功能时的系统表现。 强制测试用例覆盖 Feature Flag 开启和关闭两种状态。

可用于丰富《AI 辅助软件产品》的写作点

  • 第 3 章（PRD 与工程合同）：
    • 在介绍 PRD 结构时，插入使用标准化语言减少 Token 歧义的小节。
    • 提供一个对比案例：一段模糊的自然语言需求 vs. 使用 RFC 2119 重写后的需求，展示 AI Coding Agent 对后者的执行准确率更高。
  • 第 7 章（工程化与门禁）：
    • 在AI 系统的确定性保障部分，论述如何用 MUST/MUST NOT 锁死概率性系统的下限（如：内容过滤器 MUST 拦截有害信息）。
  • 第 18 章（评估与迭代）：
    • 在设计基于 LLM 的自动化测试时，建议将 RFC 2119 关键词直接作为 Judge Model 的判题依据（Rubric），提高评测的一致性。