rd-specification git:20260726.db4ec36A

Immutable. This exact content never changes and is served at /api/v1/blob/72209d47127f82ad.

---
name: rd-specification
description: >-
  起草或修订国家、行业、企业、内部或项目标准、规范、指南和规范性条款。
  当需要建立或修改效力依据、范围、术语、引用、符合性判据或规范性表述时使用。
  需要独立结论时使用 rd-review；不用于实现或执行。
---

# rd-specification

以条款级严谨性、证据纪律和规范性用语控制，支撑**标准规范制定、修订和评审**。

## 交付物

- 标准/规范草案大纲或条款草案
- 条款级问题与修订表
- 规范性替换文本建议
- 术语与引用一致性检查表
- 需专家、法务、标准主管或领域负责人确认的开放问题

## 执行步骤

### 1. 范围与效力确认

- 识别标准类型：国家标准、行业标准、企业标准、内部规范、项目规范
- 确认文档状态：草案、征求意见稿、送审稿、已发布基线或修订稿
- 明确目标读者和预期效力
- 确认任务类型：起草、修订、条款分析、对比或差距分析
- 识别目标标准化组织或机构适用的起草规则和规范性用语，不假定存在统一的 shall/should 约定
- 效力相关时确认适用法域、版本、实施日期、替代状态和适用边界

### 2. 证据来源层级

优先级如下：

1. 当前被处理文档正文和条款编号
2. 有约束力的法律、法规、标准或官方规范
3. 被引用标准和规范性文件
4. 已批准的上游项目文档或组织规则
5. 专家判断，必须标注为判断而非事实

证据缺失时标注“依据不足，需人工核实”，不得编造依据。

### 3. 条款级分析

每条问题或建议至少包含：

- 明确被讨论的条款、表、图或术语
- 问题类型：正确性、一致性、可执行性、歧义、范围、术语、引用、格式
- 证据和推理链条
- 尽量给出可替换的规范性文本
- 区分强制性要求、推荐性要求和资料性说明

### 4. 规范性用语控制

- 要求性条款使用清晰的强制用语，避免未定义的“支持”“优化”“提升”
- 避免“先进”“安全”“快速”“可靠”等无判据形容词
- 术语与术语表、引用标准保持一致
- 除非标准明确约束实现方式，否则不写过细的实现细节

### 5. 一致性与可追溯检查

- 交叉检查术语、缩略语、符号、表、图、引用
- 检查条款之间或与引用文件之间是否冲突
- 确认每条要求可测试、可检查或可审计
- 条款要求证明符合性时，定义或定位符合性评价方法、证据、抽样边界和责任方
- 列出未决冲突和所需决策责任人

## 规范注入检查

执行前检查：

- 标准模板、编号规则和起草规则
- 术语表和规范性引用文件
- 既有评审意见表格式
- 领域特定的合规、安全、网络安全或行业要求

## 工具选择

- 当前标准状态、法规、官方解释或外部技术事实使用 `rd-research`
- 优先标准化组织、监管机构、官方规范和已检查的规范性来源
- 只有条款依赖当前软件、协议、SDK 或 API 行为时才使用 Context7 或同类文档检索能力
- 权威文本不可访问时只核实元数据，并把条款内容标记为需要人工确认

## 质量门禁

交付前核查：

- [ ] 每条条款问题或建议引用具体条款、表、图或术语
- [ ] 证据层级明确，依据不足处已标注人工核实
- [ ] 规范性文本清晰、可验证、范围明确
- [ ] 术语和引用一致
- [ ] 重大问题尽量给出替换文本
- [ ] 强制性、推荐性、资料性内容未混淆
- [ ] 重要的法域、版本、适用范围和符合性方法已经明确
- [ ] 未编造标准条款、文档状态或来源结论

## 不做

- 不编造标准文本、发布日期、状态或法律效力
- 未核实内容不可表述为已知标准条款
- 不把专家偏好直接写成强制性要求
- 不执行代码实现、测试、部署或运行验证