# doc-brd-自动驾驶仪 ## 目的自动 **业务需求文档 (BRD)** 生成管道，用于处理参考文档（“docs/00_REF/”或“REF/”）、用户提示或实施计划（“IPLAN-*”），以生成具有类型确定、准备情况验证、主索引管理和并行执行支持的全面 BRD。 **层**：1（入口点 - 无上游文档依赖项） **下游工件**：PRD（第 2 层）、EARS（第 3 层）、BDD（第 4 层）、ADR（第 5 层） ** ** ## MVP → PROD → 新的 MVP 生命周期自动驾驶仪支持迭代 **MVP → PROD → NEW MVP** 生命周期： BRD-01 → 生产 v1 → 反馈 → BRD-02 → 生产 v2 → BRD-03 → ... 相|自动驾驶角色 ---|--- **MVP** |生成具有 5-15 个核心特征的 BRD-NN **产品** |不适用（生产运营） **新 MVP** |为下一个特征生成新的 BRD-NN+1 **生命周期规则**： * 每次调用都会为一个周期创建一个 BRD * 新功能 = 为 NEW BRD 调用自动驾驶仪 * 通过第 16.2 节中的“@depends: BRD-NN”进行链接循环 * 不要为新功能修改现有的生产 BRD ** ** ## 技能依赖该自动驾驶仪协调以下技能：技能|目的|阶段 ---|---|--- `文档命名` |元素 ID 格式 (BRD.NN.TT.SS)、阈值标签、遗留模式检测 |所有阶段 `doc-brd` | BRD 创建规则、模板、部分结构、平台与功能指南 |第三阶段：BRD 生成 `质量顾问` | BRD 生成过程中的实时质量反馈 |第三阶段：BRD 生成 `doc-brd-审计` | **统一质量门**：结构验证+内容审查+PRD-Ready评分|第 4-5 阶段：审核 `doc-brd-修复程序` |应用审计报告中的修复，创建丢失的文件 |第五阶段：修复 **2-技能模型**：“doc-brd-validator”和“doc-brd-reviewer”已弃用并合并到“doc-brd-audit”中。 **委托原则**：自动驾驶仪编排工作流程，但委托： * BRD 结构/内容规则 → `doc-brd` 技巧 * 实时质量反馈→“质量顾问”技能 * 所有验证和审查 → `doc-brd-audit` 技能（统一质量门） * 问题解决和修复 → `doc-brd-fixer` 技能 * 元素ID标准→`文档命名`技巧 ## BRD 合规合同模板所有生成/审查/修复编排必须符合： * `ai_dev_ssd_flow/01_BRD/BRD-MVP-TEMPLATE.md`（人类可读的事实来源） * `ai_dev_ssd_flow/01_BRD/BRD-MVP-TEMPLATE.yaml` （自动驾驶仪模板） * `ai_dev_ssd_flow/01_BRD/BRD_MVP_SCHEMA.yaml` （共享验证合约） **强制对齐区域**： * 18 节结构和小节编号 * MVP 关键锚点（`2.1`、`3.2`、`9.1`、`14.5`、`15.3`、`16.1-16.4`、`17.1-17.6`） * 术语表和附录的模板命名（`17.5 交叉引用`、`17.6 外部标准`、`18.1-18.5`）审核者/修复者输出中发现的任何偏差都必须在通过之前触发修复周期。 ** ** ## 文档元数据合约（强制）生成 BRD 文档实例时，自动驾驶仪必须： ### 1\.文件类型 **从模板中读取** `instance_document_type`： * 来源：`ai_dev_ssd_flow/01_BRD/BRD-MVP-TEMPLATE.yaml` * 字段: `metadata.instance_document_type: "brd-document"` **在生成的文档 frontmatter 中设置** `document_type`：自定义字段： document_type: brd-document # NOT “模板” 工件类型：BRD 层数：1 **验证**：生成的文档必须具有 `document_type: brd-document` * 模板有 `document_type: template` * 实例具有 `document_type: brd-document` * 模式验证这两个值 **错误处理**：如果模板中缺少“instance_document_type”，则默认为“brd-document”。 ** ** ### 2\.交付类型 **从模板中读取** `deliverable_type`： * 来源：`ai_dev_ssd_flow/01_BRD/BRD-MVP-TEMPLATE.md` * 字段：`custom_fields.deliverable_type：“代码”` * 有效值：`code`、`document`、`ux`、`risk`、`process` **在生成的文档 frontmatter 中设置** `deliverable_type`：自定义字段： document_type: brd-文档工件类型：BRD 层数：1 Deliverable_type: code # 来自模板或输入分析 **自动检测**（如果模板中没有）：当模板或输入源中缺少“deliverable_type”时，会从 BRD 内容中自动检测： def detector_deliverable_type(brd_content: str, input_sources: dict) -> str: """从 BRD 内容和输入中自动检测 Deliverable_type。""" content_lower = brd_content.lower() # 检查UX指标如果有（kw in content_lower for kw in [ '线框'，'模型'，'用户界面'，'ui/ux'， ‘设计系统’、‘用户体验’、‘原型’ ]): 返回'ux' # 检查文档指标如果有（kw in content_lower for kw in [ '用户指南', 'api文档', '技术手册', “帮助内容”、“文档”、“知识库” ]): 返回“文档” # 检查风险/合规指标如果有（kw in content_lower for kw in [ “风险评估”、“合规框架”、“审计追踪”、 ‘安全审计’、‘风险管理’、‘合规性’ ]): 返回“风险” # 检查进程指标如果有（kw in content_lower for kw in [ “工作流程自动化”、“流程改进”、 “业务流程”、“操作程序”、“工作流程” ]): 返回“进程” # 默认为代码返回“代码” **验证**：生成的文档必须具有有效的“deliverable_type” * 值：`代码`、`文档`、`ux`、`风险`、`流程` * 默认值：`代码` * 确定下游 SPEC 子类型生成 **错误处理**：如果“deliverable_type”无效，则默认为“code”并记录警告。 ** ** ## 输入合约（规范+向后兼容）规范调用格式： /doc-brd-autopilot --ref <路径> /doc-brd-autopilot --prompt "<业务目标和范围>" /doc-brd-autopilot --iplan <路径|IPLAN-NNN> 向后兼容性： * 仍然支持位置调用（`/doc-brd-autopilot BRD-01`、`/doc-brd-autopilot docs/00_REF/...`）。 * 如果同时提供了标志式输入和位置输入，则**标志式输入具有权威性**。 * 仅位置生成模式应发出建议规范标志的兼容性说明。输入优先级（从最高到最低）： 1. `--iplan` 2. `--ref` 3. `--提示` 如果提供多个输入，则最高优先级的输入将成为**主要源**，而其他输入将被视为**补充上下文**。补充合并语义： * 补充来源可能仅填补缺失的上下文。 * 补充来源不得超越主要来源的目标/范围/限制。 * 目标/范围的冲突会造成阻碍，需要用户澄清。 IPLAN解析顺序： 1. 如果 `--iplan` 是现有文件路径，则使用它。 2. 如果 `--iplan` 值与 `IPLAN-NNN` 匹配（无路径），则按顺序解析： * `work_plans/IPLAN-NNN*.md` * `治理/计划/IPLAN-NNN*.md` 3. 如果找到多个匹配项，则失败并显示列出候选文件的消歧输出。 ** ** ## 智能文档检测自动驾驶仪根据输入文档类型自动确定操作。 ### 输入类型识别（无上游 - 第 1 层） BRD 没有上游文档类型。智能检测的工作方式有所不同：输入 |检测为 |行动 ---|---|--- `BRD-NN`（存在）|自型|审查并修复现有的 BRD `BRD-NN`（缺失）|自型 |搜索参考 → 生成 BRD `BRD-NN BRD-MM ...` |多个 BRD |处理每个（按 3 分块） `文档/00_REF/...` |参考文档 |从参考生成 BRD `--ref <路径>` |参考文档 |从参考生成 BRD `参考/...` |参考文档 |从参考生成 BRD `--提示“...”` |用户提示|根据提示生成 BRD `--iplan <路径| IPLAN-NNN>` |实施方案 ### 检测算法 1. 将输入解析到存储桶中：BRD ID、引用路径、提示、实施计划 2. 使用优先级解析规范主要来源： - `--iplan` > `--ref` > `--prompt` 3. 如果主要来源是 `--iplan`： - 解析 IPLAN 路径（直接路径或“IPLAN-NNN”查找） - 验证所需的 IPLAN 字段：标题、范围、阶段/步骤、约束、依赖性、验证/测试方法 - 将 IPLAN 内容转换为 BRD 部分 (1,2,3,8,9,10,11,12,15) - **强制 ID 转换**（根据“文档命名”技能）： a.检测 IPLAN 内容中的所有旧版/源 ID 模式： - 简单模式：`FR-XXX`、`AC-XXX`、`BO-XXX`、`NFR-XXX` - 复合模式：“FR-{DOMAIN}-XXX”（例如“FR-CICD-001”、“FR-AUTH-002”） - 任何模式匹配： `(FR|AC|BO|NFR|QA|BC)(-[A-Za-z0-9]+)*-[0-9]+` b.将所有检测到的 ID 转换为 BRD.NN.TT.SS 格式： - `FR-*` → `BRD.NN.01.SS`（功能要求） - `NFR-*` → `BRD.NN.02.SS`（质量属性） - `AC-*` → `BRD.NN.06.SS`（验收标准） - `BO-*` → `BRD.NN.23.SS`（业务目标） c.在写入之前根据“文档命名”模式验证所有元素 ID d.如果转换后仍有遗留模式，则生成块 - 运行生成模式（阶段 1-5） 4. 如果主要来源是参考路径（`--ref` 或位置 docs/00_REF|REF 路径）： - 检测小引用模式（<=3 个文件且总计 <=100KB，仅限 markdown/text/reStructuredText） - Small-ref 模式：运行提取表（目标、范围、约束、假设、验收标准） - 标准参考模式：运行完整的源分析管道 - 运行生成模式（阶段 1-5） 5. 如果主要来源是 `--prompt`： - 验证提示质量（目标+范围+至少一个约束或成功信号） - 如果信息提示较少，请请求丰富引导提示 - 运行生成模式（阶段 1-5） 6. IF 输入与“BRD-NN”模式匹配（单个或多个）并且未提供生成源： - 以 3 块为一组进行处理（最大并行） - 对于每个 BRD-NN： a.检查：docs/01_BRD/ 中是否存在 BRD-{NN}？ b.如果存在： - 运行审查和修复周期（第 5 阶段）： 1.运行doc-brd-audit（验证者→审阅者）→生成合并报告 2. 如果状态失败：运行 doc-brd-fixer 3. 重新运行审核，直到状态 PASS 或 max_iterations (3) 4. 强制执行信任门：没有未解决的“需要手动”修复 5. 规范化生成的评论/修复 Markdown 工件 6. 生成最终的 PRD-Ready 报告 c.如果不存在： - 搜索参考文档： 1. 检查 BRD-00_index.md 模块映射 2. 搜索 docs/00_REF/ 匹配的规格 3. 按模块ID（F1-F10、D1-D7）或主题名称匹配 - 如果找到参考： - 运行生成模式（阶段 1-5） - 其他： - 提示用户：“未找到 BRD-NN 的参考。提供 --ref、--prompt 或 --iplan” 7. 为所有已处理的 BRD 生成摘要报告 ### 文件存在性检查 # 检查嵌套文件夹结构（强制） ls 文档/01_BRD/BRD-{NN}_*/ ### 示例 # 单个 BRD - 检查并修复（如果存在）或生成（如果缺失） /doc-brd-autopilot BRD-01 # 审查现有 BRD-01，运行修复周期 /doc-brd-autopilot BRD-99 # BRD-99 缺失 → 搜索参考 → 生成 # 多个 BRD - 以 3 块为一组进行处理 /doc-brd-autopilot BRD-46 BRD-47 BRD-48 BRD-49 BRD-50 # 块 1：46-48，块 2：49-50 # 生成模式（显式参考输入） /doc-brd-自动驾驶仪文档/00_REF/foundation/F1_IAM_Technical_Specification.md /doc-brd-autopilot all # 处理所有参考文档 # 生成模式（提示输入） /doc-brd-autopilot --prompt "为用户身份验证系统创建 BRD" # 生成模式（执行计划输入） /doc-brd-autopilot --iplan work_plans/IPLAN-002_brd_skill_input_expansion.md /doc-brd-autopilot --iplan IPLAN-002 # 混合输入（主要+补充） /doc-brd-autopilot --iplan IPLAN-002 --ref docs/00_REF/foundation/ ### 行动确定输出输入：BRD-01 ├── 检测类型：BRD（自身） ├── BRD 存在：是→ docs/01_BRD/BRD-01_f1_iam/ ├── 行动：审核和修复周期 │ ├── 第1步：运行doc-brd-audit → 得分：85% │ ├── 第 2 步：分数 < 90% → 运行 doc-brd-fixer │ ├── 第三步：重新审核→得分：94% │ └── 第四步：通过 - PRD 就绪 └── 输出：BRD-01.A_audit_report_v002.md、BRD-01.F_fix_report_v001.md 输入：BRD-15 ├── 检测类型：BRD（自身） ├── BRD是否存在：无 ├── 参考搜索：找到 docs/00_REF/domain/D5_Reporting_Technical_Specification.md ├── 行动：生成模式 - 根据参考创建 BRD-15 │ ├── 第1-3阶段：生成BRD │ ├── 第 4 阶段：验证 → PRD 就绪：88% │ └── 第五阶段：审查和修复 → 最终：92% └── 输出：docs/01_BRD/BRD-15_reporting/ 输入：BRD-99 ├── 检测类型：BRD（自身） ├── BRD是否存在：无 ├── 参考文献搜索：未找到匹配的参考文献 └── 操作：提示用户 - “为 BRD-99 提供 --ref、--prompt 或 --iplan” 输入： BRD-46 BRD-47 BRD-48 BRD-49 BRD-50 ├── 检测类型：多个BRD（5） ├── 分块：分块 1 (BRD-46, 47, 48)，分块 2 (BRD-49, 50) └── 加工： ├── 第 1 块：全部存在 → 审核和修复周期（并行） ├── 第 1 块完成：总结 + 暂停 └── 大块2：全部存在→审查和修复周期（并行）输入：docs/00_REF/foundation/F1_IAM_Technical_Specification.md ├── 检测类型：参考文档 └── 行动：生成模式 - 根据参考规范创建 BRD 输入：--iplan IPLAN-002 ├── 检测类型：实施计划 ├── 解析路径：work_plans/IPLAN-002_brd_skill_input_expansion.md ├── 验证：必填字段存在 ├── 行动：生成模式 - 根据实施计划创建 BRD └── 映射：IPLAN 部分 -> BRD 部分（1,2,3,8,9,10,11,12,15） ** ** ## 何时使用此技能 **在以下情况下使用`doc-brd-autopilot`： * 启动一个新项目，需要创建初始的BRD * 将业务需求、战略文档或实施计划转换为正式的 BRD 格式 * 为一个项目创建多个BRD（平台+功能BRD） * 在 CI/CD 管道中自动生成 BRD * 确保团队成员的 BRD 质量保持一致 **请勿在以下情况下使用**： * 手动审查现有的 BRD（使用“doc-brd-audit”） * 创建一个简单的单节 BRD（直接使用 `doc-brd`） * 编辑特定的 BRD 部分（使用“doc-brd”作为指导） ** ** ## 工作流程概述流程图TD 子图 Phase1[“第 1 阶段：输入分析”] A[开始] --> B[阅读策略文件] B --> C[确定利益相关者要求] C --> D[提取业务上下文] D --> E[目录输入源] E --> E1[验证@ref 目标] E1 --> E2{所有参考有效吗？} E2 -->|否| E3[标记缺失文档] E3 --> E4{需要文件吗？} E4 -->|是| E5[中止：首先创建缺失的文档] E4 -->|否| E6[继续注释] E2 -->|是| E6 结束子图 Phase2[“阶段 2：BRD 类型确定”] E6 --> F[运行平台与功能问卷] F --> G{平台 BRD？} G -->|是| H【配置平台BRD模式】 G -->|否| I【配置功能BRD模式】 H --> J[检查平台 BRD 依赖关系] I --> K[验证平台 BRD 是否存在] K -->|失踪| L[队列平台 BRD First] L --> J K -->|存在| J 结束子图 Phase3["第 3 阶段：BRD 生成"] J --> M[加载 BRD 模板] M --> N[生成文档控制] N --> O[生成核心部分 1-9] O --> O2[生成第 7.2 节：ADR 主题] O2 --> P[质量顾问：实时反馈] P --> Q[生成第 10-18 节] Q --> Q2[句柄大师术语表] Q2 --> Q3{词汇表存在吗？} Q3 -->|否| Q4[创建 BRD-00_GLOSSARY.md] Q3 -->|是| Q5【更新路径参考】 Q4 --> Q5 Q5 --> R[添加可追溯性参考] R --> S[写入 BRD 文件] 结束子图阶段 4[“阶段 4-5：审核和修复周期”] S --> T[运行 doc-brd-audit] T --> U{PRD 就绪 >= 90?} U -->|否| V[运行 doc-brd-fixer] V --> W[重新运行 doc-brd-audit] W-->U U -->|是| X[针对 BRD-MVP-TEMPLATE 运行模板一致性检查] X --> X2{模板对齐？} X2 -->|否| V X2 -->|是| X3[标记 BRD 验证] 结束子图 Phase6[“第 6 阶段：最终审查”] X3 --> Y[验证质量检查] Y --> Y2{所有检查均通过？} Y2 -->|否| Y3【旗帜手册审核】 Y3 --> Y3a[语义 MVP 标头标准化] Y3a --> Y3b[安全分段重新编号] Y3b --> Y3c[应用修复置信度标签] Y3c --> Y3d[标准化生成的降价报告] Y3d --> Y4{迭代 < 最大值？} Y4 -->|是|是 Y4 -->|否| Y5【旗帜手册评测】 Y2 -->|是| Z[验证质量检查] Y5 --> Z Z --> AA[生成 PRD 就绪报告] AA --> AB[更新追踪矩阵] 结束 AB --> AC[完成] ** ** ## 详细工作流程 ### 第 1 阶段：输入分析分析可用的输入源以提取业务需求。 **输入源**（优先顺序）：优先|来源 |地点 |内容类型 ---|---|---|--- 1 |实施计划| `work_plans/` 或 `governance/plans/` |计划范围、约束、依赖性、验证方法 2 |参考文件| `文档/00_REF/` |技术规格、差距分析、架构 3 |参考文档（替代）| `参考/` |参考文档的替代位置 4 |现有文档 | `docs/` 或 `README.md` |项目背景、范围 5 |用户提示|互动|业务背景、目标、约束 #### 0.1 小参考模式（确定性）当所有条件都成立时使用小引用模式： * 源集包含 <=3 个文件 * 总大小<=100KB * 所有文件都是 `.md`、`.txt` 或 `.rst` 小参考提取表（必填）：提取领域|输出目标 ---|--- 目标| BRD 第 1-2 节范围 |商业发展计划第 3 部分限制|商业发展计划第 8 节假设|商业发展计划第 8 节验收标准|商业发展计划第 9 节如果超过任何阈值，则路由至标准参考处理模式。 #### 0.2 IPLAN 验证严重性矩阵检查 |严重性 |行为 ---|---|--- 缺少 IPLAN 标题 |错误 |中止生成缺少 IPLAN 范围 |错误 |中止生成缺少阶段/步骤 |错误 |中止生成缺少约束/依赖|警告|继续明确的 BRD 假设缺少验证/测试方法 |警告|继续并标记 BRD QA 差距不明确的 IPLAN 标识符 |错误 |中止并请求消歧 #### 1.0 确定上行模式（第一步） **检查参考文件**： 1. 扫描 `docs/00_REF/` 2. 如果找到，请列出可用的子文件夹： ls -la 文档/00_REF/ 3. 如果用户指定 REF 文件夹中的源文档： - 设置 `upstream_mode: "ref"` - 将 `upstream_ref_path` 设置为指定的子文件夹 4. 如果主要来源是 `--iplan` 并且没有主要参考文档： - 设置 `upstream_mode: "none"` - 仅当使用补充“--ref”上下文时才可选择附加“upstream_ref_path” 5. 如果未找到或用户从头开始创建： - 设置`upstream_mode：“none”`（默认） - 设置 `upstream_ref_path: null` **提示用户 REF 文件夹是否存在**：在 docs/00_REF/ 中找到的参考文档： * source_docs/（15 个文件） * 基础/（10个文件） *内部操作/（8个文件）这个 BRD 是从参考文档中得出的吗？ 1. 否 - 从头开始创建（默认） 2. 是 - 选择参考文件夹 **基于模式生成YAML**： ````yaml # 如果从 REF 文档生成：自定义字段：上游模式：“参考” 上游参考路径：“../../00_REF/source_docs/” # 如果仅根据用户提示生成：自定义字段：上游模式：“无” **分析过程**： # 检查参考文档（主要位置） ls -la 文档/00_REF/ # 替代位置 ls -la 参考/ # 预期结构： # 文档/00_REF/ # ├── Foundation/ # Foundation 模块规格 (F1-F7) # │ ├── F1_IAM_Technical_Specification.md # │ ├── F2_Session_Technical_Specification.md # │ └── GAP_Foundation_Module_Gap_Analysis.md # ├── domain/ # 域模块规格（D1-D7） # │ ├── D1_Agent_Technical_Specification.md # │ └── 架构/ # 架构文档 # └── external/ # 外部引用 **输出**：包含提取的需求、目标和约束的输入目录。 #### 1.1 源文档链接验证（v2.3 中的新增功能） **目的**：在继续生成之前验证所有引用的源文档是否存在。这可以防止生成的 BRD 中损坏的“@ref:”链接。 **验证检查**：检查 |行动|严重性 ---|---|--- 存在参考文档（仅限参考模式）|验证 `docs/00_REF/` 或 `REF/` 中的文件 |错误 - 引用模式下的块生成源文档中的“@ref:”目标 |验证引用的文件是否存在 |错误 - 块生成差距分析文件|验证“GAP_*.md”文件（如果引用）|注意 - 创建标志交叉引用文件 |验证上游文档是否存在 |注意-文档依赖 **验证过程**： # 检查参考文档 grep -h "@ref:" docs/00_REF/**/*.md REF/**/*.md 2>/dev/null | \ grep -oP '\[.*?\]$([^)]+)$' | \ 阅读链接时；做 file=$(echo "$link" | grep -oP '$([^)]+)$' | tr -d '()') 如果[！ -f“$文件”];然后 echo“注意：未找到引用的文件：$file” 菲完成 **错误处理**：场景|行动 ---|--- 缺少所需的源文档 |中止并显示明确的错误消息可选参考缺失 |记录注释，继续占位符注释差距分析文档缺失 |提示用户：创建文档或更新引用 **输出示例**：第一阶段：输入分析 ======================= 找到的参考文件：5 ✅ docs/00_REF/foundation/F1_IAM_Technical_Specification.md ✅ docs/00_REF/foundation/F2_Session_Technical_Specification.md ✅ docs/00_REF/foundation/F3_Observability_Technical_Specification.md ✅ docs/00_REF/domain/D1_Agent_Technical_Specification.md ✅ docs/00_REF/GLOSSARY_Master.md 参考验证： ✅ docs/00_REF/foundation/F1_IAM_Technical_Specification.md ❌ docs/00_REF/foundation/GAP_Foundation_Module_Gap_Analysis.md（未找到）所需操作：创建缺失的参考文档或更新源参考。 ### 第 2 阶段：BRD 类型确定确定是创建平台 BRD 还是功能 BRD。 > **技能委派**：此阶段遵循“doc-brd”技能中定义的规则。请参阅：“.claude/skills/doc-brd/SKILL.md”部分“BRD 分类：平台与功能” **调查问卷**（自动）：问题 |平台指标|特性指标 ---|---|--- 定义基础设施/技术堆栈？ |是的 |否描述特定的面向用户的工作流程？ |没有 |是的其他 BRD 会依赖于此吗？ |是的 |否为多种功能建立模式/标准？ |是的 |否在现有平台上实现功能？ |没有 |是的 **自动检测逻辑**： def确定_brd_type（标题：str，内容：str）-> str： platform_keywords = ["平台","架构","基础设施","集成","基础"] feature_keywords = ["B2C"、"B2B"、"工作流程"、"用户"、"功能"、"模块"] 如果有的话（标题中的 kw 对应平台关键字中的 kw）：返回“平台” 如果有的话（标题中的 kw 为 feature_keywords 中的 kw）：返回“功能” 如果引用_平台_brd（内容）：返回“功能” return "PLATFORM" # 新项目的默认平台 **功能 BRD 依赖性检查**： # 在创建功能 BRD 之前验证平台 BRD 是否存在 ls 文档/01_BRD/BRD-01_* 2>/dev/null || echo“错误：需要平台 BRD-01” ### 第三阶段：BRD 生成生成带有实时质量反馈的 BRD 文档。 > **技能委派**：此阶段遵循“doc-brd”技能中定义的规则。请参阅：`.claude/skills/doc-brd/SKILL.md` 以获取完整的 BRD 创建指南。 > > **质量指导**：使用“质量顾问”技能在生成过程中进行实时反馈。请参阅：“.claude/skills/quality-advisor/SKILL.md”以进行质量监控。 **生成过程**： 1. **预留BRD ID** : # 检查下一个可用的 ID ls 文档/01_BRD/BRD-*.md 文档/01_BRD/BRD-*/BRD-*.0_*.md 2>/dev/null | \ grep -oP 'BRD-\K\d+' |排序 -n |尾部-1 # 新 BRD 增量 2. **加载 BRD 模板**： * 主要：`ai_dev_ssd_flow/01_BRD/BRD-MVP-TEMPLATE.md` * 综合：`ai_dev_ssd_flow/01_BRD/BRD-MVP-TEMPLATE.md` 3. **生成文档控制部分**：领域|价值 ---|--- 项目名称 |从输入分析文档版本 | 0.1.0 创建日期 |当前日期 (YYYY-MM-DD) 最后更新 |当前日期 (YYYY-MM-DD) 文档所有者 |来自利益相关者的意见准备者 |人工智能助手状态 |吃水 PRD 就绪分数 |生成后计算 3a. **设置元数据字段**：自定义字段： document_type: brd-document # 来自instance_document_type 工件类型：BRD 层数：1 Deliverable_type: code # 来自模板或自动检测 **deliverable_type 选择过程**： 1. 检查模板 (`BRD-MVP-TEMPLATE.md`) 中的 `deliverable_type` 字段 2. 如果缺少，则对生成的内容运行自动检测 3.如果还是不清楚，默认为`code` 4. 记录审核跟踪的选择原因 5. **生成核心部分 (1-9)** : * 第 1 部分：执行摘要 * 第 2 部分：业务背景 * 第 3 部分：利益相关者分析 * 第 4 部分：业务要求（使用 BRD.NN.01.SS 格式） * 第 5 部分：成功标准 * 第 6 节：约束和假设 * 第 7 节：架构决策要求 * 第 8 节：风险评估 * 第 9 部分：可追溯性 6. **生成第 7.2 节：架构决策要求**： **7 个强制 ADR 主题类别**（根据“doc-brd”技能）：＃|类别 |元素 ID |必填字段 ---|---|---|--- 1 |基础设施| BRD.NN.32.01 |状态、业务驱动因素、限制、替代方案、云比较 2 |数据架构| BRD.NN.32.02 |状态、业务驱动因素、限制、替代方案、云比较 3 |整合 | BRD.NN.32.03 |状态、业务驱动因素、限制、替代方案、云比较 4 |安全| BRD.NN.32.04 |状态、业务驱动因素、限制、替代方案、云比较 5 |可观察性| BRD.NN.32.05 |状态、业务驱动因素、限制、替代方案、云比较 6 |人工智能/机器学习 | BRD.NN.32.06 |状态、业务驱动因素、限制、替代方案、云比较 7 |技术选型| BRD.NN.32.07 |状态、业务驱动因素、限制、替代方案、云比较 **状态值**：`已选择`、`待处理`、`N/A` **必需的表**（状态=已选择）： * 替代方案概览表（选项 | 功能 | 预计每月成本 | 选择理由） * 云提供商比较表（标准 | GCP | Azure | AWS） 7. **实时质量反馈**（通过“质量顾问”技能）： * 生成内容时监控部分完成情况 * 在创建过程中检测反模式（AP-001 到 AP-017） * 验证元素 ID 格式合规性 (BRD.NN.TT.SS) * 检查占位符文本（[TBD]、TODO、XXX） * 尽早标记问题以减少生成后的返工 8. **生成第 10-18 节**： * 第 10 节：市场背景 * 第 11 节：监管合规性 * 第 12 节：集成要求 * 第 13 节：数据要求 * 第 14 节：性能要求 * 第 15 节：安全要求 * 第 16 节：操作要求 * 第 17 节：术语表 * 第 18 节：附录 9. **平台与功能部分处理**： BRD型 |第 3.6 节 |第3.7节 ---|---|--- 平台|必须填充技术细节|必须填充条件特色| “不适用 - 请参阅平台 BRD-NN 第 3.6 节”| “不适用 - 请参阅平台 BRD-NN 第 3.7 节” 10. **可追溯性参考**： ## 9. 可追溯性 ### 上游来源 |来源 |类型 |参考| |--------|------|------------| | docs/00_REF/foundation/F1_Technical_Specification.md |参考文档|技术规格| | docs/00_REF/foundation/GAP_Analysis.md |参考文档|差距分析| | [利益相关者] |业务投入|初始要求 | ### 下游工件 |神器|类型 |状态 | |----------|------|--------| | PRD-NN |产品要求|待定 | | ADR-NN |架构决策 |待定 | 11. **主词汇表处理**（v2.3 中的新增功能）： BRD 模板引用主术语表。自动驾驶仪必须正确处理该参考值。 **词汇表检查过程**：场景|行动 ---|--- `docs/BRD-00_GLOSSARY.md` 存在 |在第 14 节中使用正确的相对路径词汇表缺失，第一个 BRD |使用模板创建 `docs/01_BRD/BRD-00_GLOSSARY.md` 词汇表缺失，后续 BRD |参考现有术语表或创建（如果缺少） **词汇表创建模板**： --- 标题：“BRD-00：词汇表大师” 标签： - BRD - 词汇表 - 参考自定义字段： document_type：术语表 artifact_type：BRD-REFERENCE 层数：1 --- # BRD-00：主术语表所有业务需求文档中使用的通用术语。 ## 商业术语 |术语 |定义 |背景 | |------|------------|---------| | MVP |最小可行产品|范围定义 | |服务水平协议 |服务水平协议|质量要求| ## 技术术语 |术语 |定义 |背景 | |------|------------|---------| |应用程序接口 |应用程序编程接口|整合 | |智威汤逊 | JSON 网络令牌 |认证| ## 域名术语 [在此处添加项目特定术语] **第 14 节术语表参考格式**： ## 14. 术语表 📚 **主词汇表**：常用术语请参阅`BRD-00_GLOSSARY.md` ### {BRD-NN}-特定条款 |术语 |定义 |背景 | |------|------------|---------| | [第 1 学期] | [定义] | [使用地点] | **路径解析**：宝达位置 |词汇表路径 ---|--- `docs/01_BRD/BRD-01.md`（整体）| `BRD-00_GLOSSARY.md` `docs/01_BRD/BRD-01_slug/BRD-01.3_*.md`（分段）| `../BRD-00_GLOSSARY.md` 12. **BRD 索引处理**（v2.4 中的新增功能）：自动驾驶仪必须创建或更新“BRD-00_index.md”以作为所有 BRD 文档的主索引。 **索引检查过程**：场景|行动 ---|--- `docs/01_BRD/BRD-00_index.md` 存在 |使用新的 BRD 条目进行更新索引缺失 |使用模板创建 `docs/01_BRD/BRD-00_index.md` **BRD-00_index.md 创建模板**： --- 标题：“BRD-00：业务需求文档索引” 标签： - BRD - 索引 - 第 1 层神器自定义字段：文档类型：brd 索引工件类型：BRD-INDEX 层数：1 最后更新：“YYYY-MM-DDTHH：MM：SS” --- # BRD-00：业务需求文档索引项目所有业务需求文档的主索引。 --- ## 文件登记处 | BRD ID |模块|类型 |状态 | PRD 就绪 |地点 | |--------|--------|------|--------|------------|----------| | BRD-01 | F1 IAM |基金会|草稿| 97% | 'BRD-01' | --- ## 模块类别 ### 基础模块 (F1-F7) 与领域无关的、可重用的基础设施模块。 |身份证 |模块名称 | BRD |状态 | |----|-------------|-----|--------| | F1 |身份和访问管理 | 'BRD-01' |草稿| | F2|会话管理 |待定 | - | | F3 |可观察性|待定 | - | | F4|安全运营 |待定 | - | | F5|活动 |待定 | - | | F6|基础设施|待定 | - | | F7|配置|待定 | - | ### 域模块 (D1-D7) 用于成本监控的业务特定模块。 |身份证 |模块名称 | BRD |状态 | |----|-------------|-----|--------| | D1 |代理编排|待定 | - | | D2 |云账户|待定 | - | | D3 |成本分析|待定 | - | | D4 |推荐 |待定 | - | | D5 |报告|待定 | - | | D6 |警报 |待定 | - | | D7 |预算|待定 | - | --- ## 快速链接 - **术语表**：`BRD-00_GLOSSARY.md` - **参考文档**：`00_REF/` - **PRD 层**：`02_PRD/` --- ## 统计数据 |公制|价值| |--------|--------| | BRD 总数 | 1 | |基础模块| 1/7 | 1/7 |域模块 | 0/7 | | PRD 就绪平均分数 | 97% | --- *最后更新：YYYY-MM-DDTHH:MM:SS* **索引更新逻辑**：生成每个 BRD 后： 1. 读取现有的`BRD-00_index.md` 2.解析文档注册表 3. 添加或更新新 BRD 条目 4.更新统计部分 5. 更新“last_updated”时间戳 6.写入更新索引 **条目格式**： | BRD-NN | {模块名称} | {基础/领域} | {状态} | {分数}% | `BRD-NN` | 13. **文件输出**（始终使用嵌套文件夹）： * **单体**（<20k 令牌）：`docs/01_BRD/BRD-NN_{slug}/BRD-NN_{slug}.md` * **分段**（>=20k 标记）：`docs/01_BRD/BRD-NN_{slug}/BRD-NN.0_index.md`、`BRD-NN.1_core.md` 等。 * **主索引**（始终）：`docs/01_BRD/BRD-00_index.md`（创建或更新） **嵌套文件夹规则**：所有 BRD 都使用嵌套文件夹 (`BRD-NN_{slug}/`)，无论大小如何。这可以使伴随文件（审阅报告、修复报告、偏差缓存）与其父文档一起组织起来。 ### 第 4 阶段：BRD 验证 BRD 生成后，验证结构和 PRD-Ready 分数。 > **技能委托**：此阶段使用“doc-brd-audit”技能（统一质量门）中的验证规则。请参阅：`.claude/skills/doc-brd-audit/SKILL.md` 了解完整的验证和审核规则。 **验证命令**： # 统一 BRD 核心验证（主要） bash ai_dev_ssd_flow/01_BRD/scripts/validate_brd_wrapper.sh docs/01_BRD --skip-advisory # 可选的完整分层验证（包括咨询检查） bash ai_dev_ssd_flow/01_BRD/scripts/validate_brd_wrapper.sh 文档/01_BRD **验证检查**：检查 |要求 |错误代码 ---|---|--- YAML 前沿 |有效的元数据字段 | BRD-E001 至 BRD-E005 剖面结构| 18 个必填部分 | BRD-E006 至 BRD-E008 文件控制 |所有必填字段 | BRD-E009 业务目标| BRD.NN.23.SS 格式 | BRD-W001 业务需求| BRD.NN.01.SS 格式 | BRD-W002 第 7.2 节 ADR 主题 |全部 7 个类别均已呈现 | BRD-E013 至 BRD-E018 元素 ID 格式 | BRD.NN.TT.SS（4 段）| BRD-E019 至 BRD-E021 PRD 就绪分数 | >= 90% | BRD-W004 **自动修复操作**：问题 |自动修复操作 ---|--- 元素 ID 格式无效 |转换为 BRD.NN.TT.SS 格式缺少追溯部分 |从模板插入缺少文档控制字段 |添加占位符字段已弃用的 ID 模式（BO-XXX、FR-XXX）|转换为统一格式缺少 PRD-Ready 分数 |计算并插入 **验证循环**：循环（最多 3 次迭代）： 1.运行doc-brd-audit（统一质量门） 2. 如果发现错误：通过 doc-brd-fixer 应用自动修复 3. 如果发现非阻塞问题：审查并解决关键问题 4. 如果 PRD-Ready 分数 < 90%：增强部分 5. 如果干净：标记为“已验证”，继续 6. IF 最大迭代次数：记录问题、手动审核标记 ### 第 5 阶段：审核和修复周期（v2.4 - 2 技能模型）迭代审核和修复周期，以确保完成前的 BRD 质量。 **注意**：此阶段使用“doc-brd-audit”（统一质量门）和“doc-brd-fixer”。已弃用的“doc-brd-validator”和“doc-brd-reviewer”技能已合并到“doc-brd-audit”中。流程图TD A[第 5 阶段开始] --> B[运行 doc-brd-audit] B --> C[生成审计报告] C --> V{验证.drift_cache.json} V -->|失踪| W[创建漂移缓存] 西--> 德 V -->|存在| D{PRD-Ready 分数 >= 90?} D -->|是| E[PASS - 运行输出检查表] D -->|否| F{迭代 < 最大值？} F -->|是| G[运行 doc-brd-fixer] G --> H[应用修复] H --> I[生成修复报告] I --> J[增量迭代] J --> B F -->|否| K[手动审核标志] K --> L[生成包含剩余问题的最终报告] 左--> 右 E --> X[验证第 5 阶段输出清单] X --> Y[进入第 6 阶段] #### 5.1 初步审核运行“doc-brd-audit”来识别问题（统一质量门）。 /doc-brd-audit BRD-NN **输出**：`BRD-NN.A_audit_report_v001.md` #### 5.2 修复周期如果评论分数 < 90%，则调用“doc-brd-fixer”。 /doc-brd-fixer BRD-NN --revalidate **修复类别**：类别 |已应用的修复 ---|--- 丢失文件 |创建术语表、GAP 占位符、参考文档失效链接 |更新路径，创建目标元素 ID |转换遗留模式，修复无效的类型代码内容 |替换模板占位符、日期参考文献 |更新追溯标签 **输出**：`BRD-NN.F_fix_report_v001.md` #### 5.3 重新审核修复后，自动重新运行审核（根据新审核策略从头开始）。 /doc-brd-audit BRD-NN **输出**：`BRD-NN.A_audit_report_v002.md` #### 5.4 迭代控制参数|默认 |描述 ---|---|--- `最大迭代次数` | 3 |最大修复审查周期 `目标分数` | 90 | 90最低及格分数 `停止_手动` |假 |如果仅存在手动问题，请停止 **迭代示例**：迭代 1：评论 v001：得分 85（2 个错误，4 个非阻塞问题）修复 v001：修复了 5 个问题，创建了 2 个文件迭代 2：评论 v002：得分 94（0 个错误，2 个非阻塞问题）状态：通过（分数 >= 90） #### 5.5 质量检查（修复后）经过修复周期后： 1. **部分完整性**： * 所有 18 个部分均已存在并已填充 * 没有剩余占位符文本（[TBD]、TODO、XXX） * 每节的最小内容长度 2. **ADR 主题覆盖范围**： * 解决所有 7 个强制类别 * 所选主题有替代方案概述表 * 所选主题有云提供商比较表 * N/A 主题有明确的原因 3. **元素 ID 合规性**（根据“文档命名”技能）： * 所有ID均使用BRD.NN.TT.SS格式 * 对 BRD 有效的元素类型代码 (01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 22, 23, 24, 32) * 无旧模式（BO-XXX、FR-XXX、AC-XXX、BC-XXX） 4. **PRD 就绪报告** : # PRD-Ready 分数计算公式：100 - 总扣除额按类别扣除： * PRD 级污染（最多 50）：-0 * FR 完整性（最多 30）：-0 * 结构/质量（最多 20）：-0 ** ** 扣除总额：0 PRD 就绪总分：100/100（目标：>= 90）状态：PRD 生成就绪 5. **可追溯性矩阵更新**： ````bash # 更新 BRD-00_TRACEABILITY_MATRIX.md python ai_dev_ssd_flow/scripts/validate_all.py ai_dev_ssd_flow --layer BRD #### 5.6 漂移缓存验证（强制） **每个审核周期后**，验证漂移缓存文件是否存在并已更新。验证算法： ======================= 1. 检查：BRD文件夹中是否存在.drift_cache.json？ - 路径：docs/01_BRD/BRD-NN_{slug}/.drift_cache.json 2. 如果不存在： - 使用当前评论数据创建漂移缓存 - 架构版本：1.1 - 包括：document_id、last_reviewed、reviewer_version、review_history 3.如果存在： - 使用 review_history 数组中的新评论条目进行更新 - 更新last_reviewed时间戳 4. 验证缓存包含： - [ ] schema_version: "1.2" - [ ] document_id 匹配文件夹 (BRD-NN) - [ ] last_reviewed 是当前时间戳 - [ ] review_history 包括此评论的分数和报告版本 **漂移缓存架构**（最少必填字段）： { “schema_version”：“1.1”， "document_id": "BRD-NN", “文档版本”：“1.0”， "upstream_mode": "无", “drift_detection_skipped”：真， "skip_reason": "upstream_mode 设置为 none（默认）", "last_reviewed": "YYYY-MM-DDTHH:MM:SS", “reviewer_version”：“2.8”， “upstream_documents”：{}， “评论历史”：[ { "日期": "YYYY-MM-DDTHH:MM:SS", “分数”：NN， “drift_Detected”：假， "report_version": "vNNN", “状态”：“通过|失败|NEEDS_ATTENTION” } ], “修复历史记录”：[] } #### 5.6.1 哈希计算合约（强制）创建或更新“.drift_cache.json”时，自动驾驶仪必须计算实际的 SHA-256 哈希值。 ##### 在初始 BRD 生成时（第 3-4 阶段）如果设置了 `upstream_mode: "ref"`： 1. **使用 bash 立即计算每个上游文档的哈希值**： sha256sum <上游文件路径> |切-d''-f1 2. **存储在漂移缓存中**，格式为： “upstream_documents”：{ “<文件名>”：{ "路径": "<相对路径>", "哈希": "sha256:<64_hex_characters>", "last_modified": "", “文件大小”：<字节> } } 3. **切勿使用占位符** \- 以下内容无效，不得写入： * `sha256:verified_no_drift` * `sha256：待验证` * `待验证` * `sha256：待定` ##### 审核时（第 5 阶段） 1. **通过 bash 重新计算每个上游文档的哈希值** 2. **与存储的哈希值比较** 3. **使用新哈希更新缓存** 4. **如果哈希值不同则标记漂移** ##### 验证要求检查 |要求 ---|--- 格式|哈希必须匹配正则表达式 `^[0-9a-f]{64}$` 前缀 |存储为 `sha256:` 拒绝 |任何占位符值 #####验证步骤写入漂移缓存后，验证所有哈希值是否有效： # 计算有效的哈希值 grep -oP '"哈希":\s*"sha256:[0-9a-f]{64}"' .drift_cache.json |厕所-l # 跟踪的上游文档数量必须相等 # 检查占位符值（必须返回空） grep -E 'pending_verification|verified_no_drift' .drift_cache.json **失败模式**：如果任何哈希验证失败，则第 5 阶段周期不完整。在继续之前重新运行“sha256sum”并更新缓存。 ** ** #### 5.7 第 5 阶段输出检查表（强制）在进入第 6 阶段之前，请验证所有输出是否存在：第 5 阶段输出清单 ======================= BRD 文件夹：docs/01_BRD/BRD-NN_{slug}/ 所需文件： [ ] BRD-NN.R_review_report_v001.md（初步审查） [ ] BRD-NN.R_review_report_vNNN.md（最终审查，如果迭代 > 1） [ ] BRD-NN.F_fix_report_vNNN.md（如果应用了修复） [ ] .drift_cache.json（强制 - 漂移检测缓存）漂移缓存验证： [ ] 文件存在 [ ] schema_version 为“1.1” [ ] document_id 匹配“BRD-NN” [ ] last_reviewed 是当前时间戳 [ ] review_history 包含此评论的条目质量门： [ ] 最终审核分数 >= 90 [ ] 没有剩余严重错误 [ ] 图合约通行证（`@diagram: c4-l1`、`@diagram: dfd-l0`；如果使用序列图，则序列标记） [ ] PRD-Ready 状态已确认 **失败模式**：如果审核后缺少 `.drift_cache.json`，则第 5 阶段周期不完整。在继续之前创建漂移缓存。 ** ** ## 执行模式 ### 单 BRD 模式从输入源生成一个 BRD。 # 示例：从参考文档生成平台 BRD /doc-brd-自动驾驶仪 \ --ref 文档/00_REF/ \ --类型平台\ --输出文档/01_BRD/ \ --id 01 \ --slug 平台架构 # 替代方案：从 REF/ 目录生成 /doc-brd-自动驾驶仪 \ --ref 参考/ \ --类型平台\ --输出文档/01_BRD/ \ --id 01 \ --slug 平台架构 ### 批处理模式具有依赖性感知的顺序生成多个 BRD。 # 示例：生成平台 BRD，然后生成功能 BRD /doc-brd-自动驾驶仪 \ --batch config/brd_batch.yaml \ --输出文档/01_BRD/ **批量配置** (`config/brd_batch.yaml`)：品牌： - ID：“01” 段头：“f1_iam” 类型：“平台” 优先级：1 来源： - 文档/00_REF/foundation/F1_IAM_Technical_Specification.md - 文档/00_REF/foundation/GAP_Foundation_Module_Gap_Analysis.md - ID：“02” 子集：“f2_会话” 类型：“平台” 优先级：1 来源： - 文档/00_REF/foundation/F2_Session_Technical_Specification.md - ID：“03” slug：“f3_可观察性” 类型：“平台” 优先级：1 来源： - docs/00_REF/foundation/F3_Observability_Technical_Specification.md 执行：平行：真实 max_parallel: 3 # 硬限制 - 不要超过 chunk_size: 3 # 每个块的文档块间暂停：true 最大工人数：2 快速失败：假 ### 试运行模式预览执行计划而不生成文件。 /doc-brd-自动驾驶仪 \ --ref 文档/00_REF/ \ --输出文档/01_BRD/ \ --试运行 ### 审阅模式 (v2.1) 验证现有的 BRD 文件并生成未经修改的质量报告。 **目的**：审核现有 BRD 文件的合规性、质量评分并发现问题。 **命令**： # 查看单个 BRD /doc-brd-自动驾驶仪 \ --brd 文档/01_BRD/BRD-01_platform.md \ --模式回顾 # 查看所有 BRD /doc-brd-自动驾驶仪 \ --brd 文档/01_BRD/ \ --模式审查\ --输出报告 tmp/brd_review_report.md **审核流程**：流程图TD A[输入：现有 BRD] --> B[加载 BRD 文档] B --> C[运行验证检查] C --> D[运行图表合同检查] D --> E[计算 PRD-Ready 分数] E --> F[检查第 7.2 节 ADR 主题] F --> G[验证平台与功能] G --> H[确定问题] H --> I{生成报告} I --> J[可修复问题列表] I --> K[手动审核项目] I --> L[分数细分] J --> M[输出：审查报告] K --> M 左->中 **审查报告结构**： # BRD 审核报告：BRD-01_platform ## 总结 - **PRD 就绪分数**：87% 🟡 - **总问题**：14 - **可自动修复**：10 - **手动审核**：4 ## 分数计算（基于扣除） |类别 |扣除 |最大|状态 | |----------|------------|-----|--------| |珠三角级污染| -6 | 50 | 50 🟡 | | FR 完整性 | -5 | 30| 🟡 | |结构/质量 | -2 | 20 | 🟡 | | **总扣除额** | **-13** | **100** | - | | **最终得分** | **87/100** | **目标 >= 90** | 🟡 | ## 合约检查图 |检查 |状态 |详情 | |--------|--------|---------| | `@diagram: c4-l1` | ✅ |现在 | | `@diagram: dfd-l0` | ✅ |现在 | |序列合约标签 | 🟡 |仅当序列图存在时才需要 | |图表意图标头字段 | ✅ |呈现强制性图表块 | ## 第 7.2 节 ADR 主题检查 |类别 |状态 |详情 | |----------|--------|---------| |基础设施| ✅ |桌子齐全 | |数据架构| ✅ |桌子齐全 | |整合| 🟡 |缺少云比较| |安全| ✅ |桌子齐全| |可观察性| ❌ |缺少替代品表 | |人工智能/机器学习 | ✅ |桌子齐全 | |技术选型| ✅ |桌子齐全 | ## 平台与功能检查 |检查 |状态 |详情 | |--------|--------|---------| | BRD型 |平台|正确识别 | |第 3.6 节 | ✅ |技术细节呈现 | |第 3.7 节 | ✅ |满足条件 | |交叉引用| ✅ |有效参考文献| ## 自动修复问题 | ＃|问题 |地点 |修复行动| |---|--------|----------|------------| | 1 |旧元素 ID |第 4 节：L45 |将 BO-001 转换为 BRD.01.23.01 | | 2 |缺少 PRD-Ready 分数 |文件控制 |计算并插入 | | 3 | ID 格式无效 |第 5 节：L78 |将 FR-001 转换为 BRD.01.01.01 | | ... | ... | ... | ... | ## 需要人工审核 | ＃|问题 |地点 |原因 | |---|--------|----------|--------| | 1 |不完整的风险评估|第 8 节：L102 |所需领域知识 | | 2 |缺少可观测性表 | | 第 7.2.5 节需要架构决策 | | ... | ... | ... | ... | ## 建议 1. 运行修复模式以解决 10 个可自动修复的问题 2. 完整的可观察性ADR主题表 3. 审查并完成风险评估部分 **查看配置**：审查模式：启用：真检查： - Structure_validation # 18 个部分，文档控制 - element_id_compliance # BRD.NN.TT.SS 格式 - adr_topics_validation #7.2 节中的 ADR 类别 - platform_feature_check # 正确的部分处理 -cumulative_tags # 可追溯性参考 - Score_calculation # PRD-Ready 分数输出：格式：markdown # markdown, json, html include_line_numbers: true include_fix_suggestions：true 阈值：通过：90 失败：90 ### 修复模式 (v2.1) 自动修复现有 BRD 文档，同时保留手动内容。 **目的**：对 BRD 文档应用自动修复，以提高质量分数和合规性。 **命令**： # 修复单个 BRD /doc-brd-自动驾驶仪 \ --brd 文档/01_BRD/BRD-01_platform.md \ --模式修复 # 通过备份修复 /doc-brd-自动驾驶仪 \ --brd 文档/01_BRD/BRD-01_platform.md \ --模式修复\ --备份 # 仅修复特定问题类型 /doc-brd-自动驾驶仪 \ --brd 文档/01_BRD/BRD-01_platform.md \ --模式修复\ --fix-types "element_ids,sections,adr_topics" # 试运行修复（预览更改） /doc-brd-自动驾驶仪 \ --brd 文档/01_BRD/BRD-01_platform.md \ --模式修复\ --试运行 **修复过程**：流程图TD A[输入：现有 BRD] --> B[运行查看模式] B --> C[确定可修复的问题] C --> D{备份已启用？} D -->|是| E[创建备份] D -->|否| F[跳过备份] E --> G[按类别应用修复] F-->G 子图 FixCategories["修复类别"] G --> H[元素 ID 修复] G --> I[部分修复] G --> J[ADR 主题修复] G --> K[可追溯性修复] G --> L[分数修正] 结束 H --> M[保留手册内容] 我--> 中号 J --> M K --> M 左->中 M --> N[重新验证] N --> O{分数提高了？} 哦-->|是| P[生成修复报告] 哦-->|否| Q[记录非阻塞问题] 问--> P P --> R[输出：固定 BRD + 报告] **修复类别和操作**：类别 |问题 |自动修复操作 |保留内容 ---|---|---|--- **元素 ID** |旧版 BO-XXX 格式 |转换为 BRD.NN.23.SS | ✅ **元素 ID** |旧版 FR-XXX 格式 |转换为 BRD.NN.01.SS | ✅ **元素 ID** |旧版 AC-XXX 格式 |转换为 BRD.NN.06.SS | ✅ **元素 ID** |旧版 BC-XXX 格式 |转换为 BRD.NN.03.SS | ✅ **元素 ID** | BRD 的类型代码无效 |建议上下文适当的有效 BRD 代码（如果不明确则手动分类）| ✅ **章节** |缺少文档控制字段 |从模板添加| ✅ **章节** |缺少追溯部分 |从模板插入 | ✅ **章节** |缺少 PRD-Ready 分数 |计算并插入 | ✅ **ADR 主题** |缺少类别 |添加模板条目 | ✅ **ADR 主题** |缺少替代品表 |添加表格模板 | ✅ **ADR 主题** |缺少云比较表|添加表格模板 | ✅ **可追溯性** |缺少上游来源|添加模板结构 | ✅ **可追溯性** |缺少下游工件|添加模板结构 | ✅ **分数** |缺少 PRD-Ready 故障 |计算并相加 | ✅ **断开的链接** |缺少词汇表文件 |创建 BRD-00_GLOSSARY.md | ✅ **断开的链接** |缺少参考文档 |提示创建或更新链接 | ⚠️ **断开的链接** |相对路径无效 |基于 BRD 位置修复路径 | ✅ **内容保存规则**： 1. **永远不要删除**现有的业务需求 2. **切勿修改**执行摘要内容 3. **永不改变**利益相关者分析细节 4. **仅添加**缺少的部分和元数据 5. **仅用统一格式替换**旧元素ID 6. **首先备份** 如果设置了 `--backup` 标志 **元素 ID 迁移**：传统模式|新格式 |示例 ---|---|--- `BO-XXX` | `BRD.NN.23.SS` | BO-001 → BRD.01.23.01 `FR-XXX` | `BRD.NN.01.SS` | FR-001 → BRD.01.01.01 'AC-XXX' | `BRD.NN.06.SS` | AC-001 → BRD.01.06.01 `BC-XXX` | `BRD.NN.03.SS` | BC-001 → BRD.01.03.01 `ADR-T-XXX` | `BRD.NN.32.SS` | ADR-T-001 → BRD.01.32.01 **元素类型代码迁移** (v2.3)：无效代码 |正确的行动|背景 |示例 ---|---|---|--- 25 在 BRD |手动重新分类为适合上下文的有效 BRD 代码（`23`、`24`、`22`、`08` 等）|业务内容版块| BRD.01.25.01 → BRD.01.23.01（如果业务目标） **注意**：代码 25 仅对 EARS 文件（EARS 声明）有效。在 BRD 中，标准化 BRD 验证器不接受代码 33；使用适合上下文的有效 BRD 代码。 **损坏的链接修复** (v2.3)：问题 |修复行动|创建文件 ---|---|--- 缺少`BRD-00_GLOSSARY.md` |从模板创建 | ✅ 是的缺少参考文档（GAP、REF）|提示用户选项：(1) 创建占位符，(2) 更新链接，(3) 删除引用 | ⚠️可选错误的相对路径 |根据 BRD 位置重新计算路径 | ❌ 没有跨 BRD 引用不存在的 BRD |日志注释，建议创建BRD | ❌ 没有 **修复报告结构**： # BRD 修复报告：BRD-01_platform ## 总结 - **PRD-Ready 分数之前**：87% 🟡 - **PRD-Ready 分数之后**：94% ✅ - **已修复的问题**：10 - **剩余问题**：4（需要手动审核） ## 应用的修复 | ＃|问题 |地点 |修复已应用 | |---|--------|----------|-------------| | 1 |旧元素 ID |第 4 节：L45 |转换 BO-001 → BRD.01.23.01 | | 2 |缺少 PRD-Ready 分数 |文件控制|添加了 94% 并有故障 | | 3 |缺少云比较| | 第 7.2.3 节添加模板表 | | ... | ... | ... | ... | ## 文件修改 - 文档/01_BRD/BRD-01_platform.md ## 备份位置 -tmp/备份/BRD-01_platform_20260209_143022.md ## 剩余问题（手动审核） | ＃|问题 |地点 |原因 | |---|--------|----------|--------| | 1 |不完整的风险评估|第 8 节：L102 |所需领域知识 | | 2 |缺少可观测性表 | | 第 7.2.5 节需要架构决策 | | ... | ... | ... | ... | ## 扣除影响 |类别 |之前 |之后|达美航空 | |----------|--------|--------|--------| |珠三角级污染扣除| -12 | -6 | +6 | | FR完整性扣除| -8 | -5 | +3 | |结构/质量推导| -4 | -2 | +2 | | **总扣除额** | **-24** | **-13** | **+11** | ## 后续步骤 1. 检查手动标记的项目 2.完整的可观察性ADR主题 3. 重新运行验证以确认分数 **修复配置**：修复模式：启用：真备份：启用：真位置：“tmp/备份/” 保留天数：7 修复类别： element_ids: true # 旧版 ID 转换 sections: true # 缺少的部分 adr_topics: true # 第 7.2 节 ADR 主题 Traceability: true # 上游/下游参考分数: true # PRD-Ready 分数保存： Executive_summary: true # 永不修改 business_requirements: true # 永不修改内容 takeholder_analysis: true # 永不修改 comments: true # 保留用户评论验证： re_validate_after_fix: true 要求分数改进：假最大修复迭代次数：3 元素 ID 迁移： BO_XXX_to_BRD_NN_23_SS：真 # BO-001 → BRD.01.23.01 FR_XXX_to_BRD_NN_01_SS：真 # FR-001 → BRD.01.01.01 AC_XXX_to_BRD_NN_06_SS: true # AC-001 → BRD.01.06.01 BC_XXX_to_BRD_NN_03_SS：真 # BC-001 → BRD.01.03.01 **命令行选项（检查/修复）**：选项|模式|默认 |描述 ---|---|---|--- `--模式审查` |评论 | - |仅运行审阅模式 `--模式修复` |修复 | - |运行修复模式 `--输出报告` |两者 |汽车 |报告输出路径 `--备份` |修复 |真实 |修复前创建备份 `--修复类型` |修复 |全部 |以逗号分隔的修复类别 `--试运行` |修复 |假 |预览修复而不应用 `--保留全部` |修复 |假 |格外谨慎保存 ### 并行执行在 Platform BRD 之后同时执行独立的 BRD。流程图LR A[平台 BRD-01] --> B[功能 BRD-02] A --> C[功能 BRD-03] A --> D[功能 BRD-04] B --> E[所有 BRD 已完成] C-->E D-->E **依赖规则**： * 平台 BRD (BRD-01) 必须首先完成 * 功能 BRD 可以在平台 BRD 之后并行执行 * 交叉依赖的功能 BRD 按顺序执行 ** ** ## 输出工件 ### 生成的文件 **所有 BRD 都使用嵌套文件夹** (`BRD-NN_{slug}/`)，无论大小如何。文档分段（整体与分段）仅取决于文档大小（>20k 标记 = 分段）。文件 |目的|地点 ---|---|--- BRD-00_index.md |主 BRD 索引（创建/更新）| `文档/01_BRD/` BRD-00_GLOSSARY.md |主词汇表（如果丢失则创建）| `文档/01_BRD/` BRD-NN_{slug}/| BRD 文件夹（始终创建）| `文档/01_BRD/` BRD-NN_{slug}.md |主要 BRD 文档（单一 <20k 代币）| `docs/01_BRD/BRD-NN_{slug}/` BRD-NN.0_index.md |分段索引（分段≥20k 标记）| `docs/01_BRD/BRD-NN_{slug}/` BRD-NN.S_{部分}.md |分段文件（分段≥20k 标记）| `docs/01_BRD/BRD-NN_{slug}/` ### 审核报告 (v2.3) **重要**：审核报告是项目文档，必须与已审核的文档一起存储在嵌套文件夹中，而不是临时文件夹中。报告类型 |文件名 |地点 ---|---|--- BRD审计报告| `BRD-NN.A_audit_report_v{VVV}.md` | `docs/01_BRD/BRD-NN_{slug}/` BRD 修复报告 | `BRD-NN.F_fix_report_v{VVV}.md` | `docs/01_BRD/BRD-NN_{slug}/` 漂移缓存| `.drift_cache.json` | `docs/01_BRD/BRD-NN_{slug}/` **注意**：所有 BRD（整体式和分段式）都使用嵌套文件夹，因此所有配套文件都位于同一位置。 ### 报告清理政策（强制性） **生成新报告后，删除该报告类型的所有先前版本。** 此策略适用于审核报告和修复报告。旧报告没有任何作用，因为： * 新的审计政策意味着旧的审计报告永远不会被重复使用 * 每个修复周期都会生成一份完整的新报告 * 仅最新报告反映当前文档状态 * 多个旧报告使 BRD 文件夹变得混乱 **清理规则**：文件模式|行动|原因 ---|---|--- `BRD-NN.A_audit_report_v*.md`（旧版）| **删除** |由新审计取代 `BRD-NN.R_review_report_v*.md`（旧版）| **删除** |已弃用的格式 `BRD-NN.F_fix_report_v*.md`（旧版）| **删除** |由新的修复报告取代 `.drift_cache.json` | **保留** |跟踪审查/修复历史元数据 **清理执行**（每次报告生成后）： # 在 BRD 文件夹中 BRD_FOLDER="$1" NEW_REPORT="$2" # 确定报告类型并清理旧版本 if [[ "$NEW_REPORT" == *".A_audit_report_"* ]];然后 # 删除旧的审计报告（只保留新的）找到“${BRD_FOLDER}”-名称“BRD-*.A_audit_report_v*.md”！ -名称“$(基本名称${NEW_REPORT})”-删除 # 删除旧版审核报告（已弃用）查找“${BRD_FOLDER}”-名称“BRD-*.R_review_report_v*.md”-删除 elif [[ "$NEW_REPORT" == *".F_fix_report_"* ]];然后 # 删除旧的修复报告（仅保留新的）找到“${BRD_FOLDER}”-名称“BRD-*.F_fix_report_v*.md”！ -名称“$(基本名称${NEW_REPORT})”-删除菲 **清理后，BRD 文件夹包含**：文档/01_BRD/BRD-NN_{slug}/ ├── BRD-NN_{slug}.md # BRD 主文档 ├── BRD-NN.A_audit_report_vNNN.md # 最新审计报告（只有一份） ├── BRD-NN.F_fix_report_vNNN.md # 最新修复报告（只有一份） └── .drift_cache.json # 漂移检测缓存 **报告中的清理摘要**：每个报告应包括清理摘要部分： ## 清理总结 - 删除：3 份旧审计报告（v009、v010、v011） - 删除：4份遗留审查报告 **审查文件要求**：审查报告是正式的项目文件，必须符合所有项目文件标准： 1. **YAML Frontmatter**（强制）： --- 标题：“BRD-NN.R：{模块名称} - 审查报告” 标签： - BRD - {模块类型} - 第 1 层神器 - 审查报告 - 质量保证自定义字段： document_type：审查报告工件类型：BRD-REVIEW 层数：1 父文档：BRD-NN 审阅的_文档：BRD-NN_{slug} 模块 ID：{模块 ID} 模块名称：{模块名称} 审核日期：“年-月-日” review_tool：doc-brd-autopilot 评论版本：“{版本}” review_mode：只读 prd_ready_score_claimed：{已声明} prd_ready_score_validated：{已验证} 验证状态：通过|失败错误计数：{n} 非阻塞计数：{n} 信息计数：{n} 自动修复计数：{n} --- 2. **父文件参考**（强制）： * 导航链接到父文档索引 * 可追溯性部分中的“@parent-brd: BRD-NN”标签 * 使用相对路径的交叉引用 3. **部分结构**（强制）：部分|内容 ---|--- 0\.文件控制 |报告元数据、审核日期、工具版本 1\.执行摘要|分数、状态、问题计数 2\.文档概述 |审查了文档详细信息，审查了文件 | 3. 分数计算 |扣分公式、类别扣分、最终分数 | | 4-N。验证详情 |特定部分的验证结果 | | N+1。问题总结 |错误、非阻塞问题、信息分类 | | N+2。推荐 |按优先顺序排列的修复建议 | | N+3。溯源 |父文档参考| 4. **文件命名约定**： * 模式：`{ARTIFACT}-NN.R_review_report.md` * `R` 后缀表示审查文档类型 * 示例：`BRD-03.R_review_report.md` **文件夹结构示例**： # 整体 BRD（文档 <20k 代币）文档/01_BRD/ ├── BRD-07_f7_config/ │ ├── BRD-07_f7_config.md # ← 整体文档 │ ├── BRD-07.R_review_report_v001.md # ← 审核报告 │ ├── BRD-07.F_fix_report_v001.md # ← 修复报告 │ └── .drift_cache.json # ← 漂移缓存 # 分段 BRD（文档 ≥20k 标记）文档/01_BRD/ ├── BRD-01_f1_iam/ │ ├── BRD-01.0_index.md # ← 章节索引 │ ├── BRD-01.1_core.md # ← 第 1 节 │ ├── BRD-01.2_requirements.md # ← 第 2 节 │ ├── BRD-01.3_quality_ops.md # ← 第三节 │ ├── BRD-01.R_review_report_v001.md # ← 审核报告 │ ├── BRD-01.F_fix_report_v001.md # ← 修复报告 │ └── .drift_cache.json # ← 漂移缓存 ### 临时文件报告|目的|地点 ---|---|--- brd_validation_report.json |机器可读的验证数据| `tmp/` prd_ready_score.json | PRD-Ready 分数计算 | `tmp/` autopilot_log.md |执行日志| `tmp/` **注意**：“tmp/”中的 JSON 报告用于编程访问。人类可读的审核报告必须与已审核的文档一起存储。 ** ** ## 错误处理 ### 错误类别类别 |处理|示例 ---|---|--- 输入缺失 |中止并显示消息 |未找到策略文件验证失败 |自动修复，重试 |缺少必填部分 PRD 就绪率低于 90% |增强部分，重试 |得分为 85% 平台 BRD 缺失 |队列平台BRD优先|具有 BRD 功能，不含 BRD-01 超过最大重试次数 |手动审核标记|持续的验证错误 ### 恢复行动 def handle_error(error_type: str, context: dict) -> 操作：匹配错误类型：案例“INPUT_MISSING”：返回 Action.ABORT_WITH_MESSAGE 案例“VALIDATION_FAILURE”：如果上下文[“重试次数”] < 3：返回 Action.AUTO_FIX_RETRY 返回 Action.FLAG_MANUAL_REVIEW 案例“PRD_READY_LOW”：返回 Action.ENHANCE_SECTIONS 案例“PLATFORM_BRD_MISSING”：返回 Action.QUEUE_PLATFORM_FIRST 案例_：返回 Action.FLAG_MANUAL_REVIEW ** ** ## 上下文管理 ### 分块并行执行（强制） **关键**：为了防止对话上下文溢出错误（“提示太长”、“对话太长”），所有自动驾驶仪操作必须遵循分块执行规则： **块大小限制**：每个块最多 3 个文档 **分块规则**： 1. **Chunk Formation** ：将文档分成最多 3 个块 2. **顺序块处理**：一次处理一个块，在开始下一个块之前完成一个块中的所有文档 3. **上下文暂停**：完成每个块后，提供摘要并暂停以供用户确认 4. **进度跟踪** ：显示块进度（例如，“块 2/5：处理 BRD-04、BRD-05、BRD-06...”） **为什么需要分块**： * 防止批处理期间出现“对话太长”错误 * 允许块之间的上下文压缩 * 能够从故障中恢复而不丢失所有进度 * 为用户审查提供自然检查点 **执行模式**：对于 N 份文件的 BRD 批次：第 1 块：BRD-01、BRD-02、BRD-03 → 完整 → 摘要 [上下文压缩机会] 第 2 块：BRD-04、BRD-05、BRD-06 → 完整 → 摘要 [上下文压缩机会] ...继续直到处理完所有文件 **块完成模板**： ## 块 N/M 已完成生成： - BRD-XX：PRD 就绪分数 94% - BRD-YY：PRD 就绪分数 92% - BRD-ZZ：PRD 就绪分数 95% 继续下一个块... ** ** ## 集成点 ### 预执行挂钩 # 挂钩：pre_brd_ Generation # 在 BRD 生成开始之前运行 ./hooks/pre_brd_ Generation.sh # 示例：验证输入源是否存在如果[-z“$BRD_INPUT_MODE”];然后 echo“错误：需要一种输入模式（--ref、--prompt、--iplan 或 BRD-NN 审阅模式）” 1号出口菲 if [ "$BRD_INPUT_MODE" = "ref" ] && [ ! -d "docs/00_REF/" ] && [ ! -d“参考/”]；然后 echo“错误：引用模式需要 docs/00_REF/ 或 REF/ 目录” 1号出口菲 ### 执行后挂钩 # 挂钩：post_brd_ Generation # BRD 生成完成后运行 ./hooks/post_brd_ Generation.sh # 示例：触发 PRD 自动驾驶仪以验证 BRD 如果[“$BRD_VALIDATED”=“真”];然后 /doc-prd-自动驾驶仪 \ --brd“$BRD_PATH”\ --输出文档/02_PRD/ 菲 ### CI/CD 集成 # .github/workflows/brd_autopilot.yml 名称：BRD自动驾驶仪于：推：路径： - '文档/00_REF/**' - '参考/**' 职位：生成 brd：运行：ubuntu-latest 步骤： - 使用：actions/checkout@v4 - 名称：运行 BRD 自动驾驶仪运行： | /doc-brd-自动驾驶仪 \ --ref 文档/00_REF/ \ --输出文档/01_BRD/ \ --验证 - 名称：上传验证报告使用：actions/upload-artifact@v4 与：名称： brd 验证路径：tmp/brd_validation_report.json ** ** ## 质量门 ### 相位门相|门 |标准 ---|---|--- 第一阶段 |输入门|通过 `--iplan`、`--ref`、`--prompt` 或 BRD-ID 审核模式提供的有效输入第二阶段 |类型门| BRD 类型已确定（平台/功能）第三阶段|一代门|生成所有 18 个部分第四阶段 |验证门 | PRD-Ready 分数 >= 90% + 模板一致性通过第五阶段 |评论门 |没有剩余的阻塞问题+没有未解决的“需要手动”修复项目 ### 阻塞与非阻塞问题类型 |封锁|行动 ---|---|--- 缺少必填部分 |是的 |在继续之前必须修复 PRD 就绪分数 < 90% |是的 |必须加强部分元素 ID 格式无效 |是的 |必须转换为统一格式未解决的“需要手动”修复信心 |是的 |在通过之前必须转至人工审核缺少可选部分 |没有 |记录注释，继续生成的报告中的样式/格式问题 |没有 |自动标准化降价，继续 ** ** ## 相关资源 * **BRD 创建技能** : `.claude/skills/doc-brd/SKILL.md` * **BRD 审核技能**：`.claude/skills/doc-brd-audit/SKILL.md`（统一质量门） * **质量顾问技能**：`.claude/skills/quality-advisor/SKILL.md` * **命名标准技能** : `.claude/skills/doc-naming/SKILL.md` * **BRD 模板** : `ai_dev_ssd_flow/01_BRD/BRD-MVP-TEMPLATE.md` * **BRD 创建规则** : `ai_dev_ssd_flow/01_BRD/BRD_MVP_CREATION_RULES.md` * **BRD 验证规则** : `ai_dev_ssd_flow/01_BRD/BRD_MVP_VALIDATION_RULES.md` * **平台与功能指南** : `ai_dev_flow/PLATFORM_VS_FEATURE_BRD.md` * **PRD 自动驾驶仪技能** : `.claude/skills/doc-prd-autopilot/SKILL.md` ** ** ## 版本历史版本 |日期 |变化 ---|---|--- 3.8 | 2026-03-05 | **可交付类型实现**：添加了可交付类型元数据处理；从模板读取，自动检测内容，或默认为“代码”；有效值：代码、文档、ux、风险、流程；确定下游 SPEC 子类型；更新了文档类型合同 → 文档元数据合同，包含 2 个小节；添加了用于元数据字段生成的第 3 阶段步骤 3a 3.7 | 3.7 2026-03-05 | **报告清理策略**：在生成新报告后添加了对旧审计/修复报告的强制清理；删除以前的“BRD-NN.A_audit_report_v*.md”、“BRD-NN.R_review_report_v*.md”（旧版）和“BRD-NN.F_fix_report_v*.md”文件；仅保留每种类型的最新报告；在报告中添加了清理摘要部分 3.6 | 2026-03-01 | **2-Skill 模型** ：从已弃用的 `doc-brd-validator`/`doc-brd-reviewer` 迁移到统一的 `doc-brd-audit`；更新了技能依赖性、流程图、第 5 阶段 → 审核和修复周期；所有参考现在都使用“doc-brd-audit”作为单一质量门 3.5 | 3.5 2026-02-28 | **标准化验证器奇偶校验**：从有效代码列表中删除了 BRD 代码“33”，并使用基于上下文的手动重新映射到有效 BRD 代码替换了旧版“25→33”指南，与“validate_standardized_element_codes.py”对齐。 3.4 | 3.4 2026-02-27 | **强制 IPLAN ID 转换**：为源自 IPLAN 的生成添加了显式 ID 转换步骤；检测简单模式（`FR-XXX`）和复合模式（`FR-CICD-XXX`、`NFR-PERF-XXX`）；如果转换后遗留模式仍然存在，则阻止生成；在写入 BRD 文件之前强制执行“文档命名”合规性 3.3 | 2026-02-27 | **输入契约扩展**：添加规范语法和兼容性（`--ref`、`--prompt`、`--iplan`）；实现了确定性优先级和补充合并语义；添加IPLAN解析顺序和验证矩阵；添加小参考模式阈值/提取表；更新了实施计划驱动生成的输入门和示例，同时保留了 BRD-ID 审核流程。 3.2 | 2026-02-27 | **哈希计算合约**：添加了第 5.6.1 节，在生成和审核时强制执行 bash `sha256sum`；哈希格式验证；占位符拒绝（verified_no_drift，pending_verification）；确认漂移缓存中有效哈希值的验证步骤 3.1| 2026-02-26 | **模板合规性实施**：向“BRD-MVP-TEMPLATE.md/.yaml”和架构添加了显式 BRD 模板合同；在验证通过之前插入第 4 阶段模板一致性门；所需的审查/修复循环闭合现在包括模板命名和分段对齐检查。 3.0 | 2026-02-26 | **修复循环强化**：增强了第 5 阶段的编排，包括语义 MVP 标题规范化、安全分段重新编号、修复置信度标记以及生成的审核/修复报告的降价规范化；添加了控制规则，要求在通过之前没有未解决的“需要手动”修复项目。 2.9 | 2.9 2026-02-25 | **模板对齐**：更新为 18 节结构，其中包括第 12 节（支持）、第 14 节（治理/批准）、第 15 节（质量保证）、第 16 节（可追溯性 16.1-16.4）、第 17 节（术语表 17.1-17.6）；与 BRD-MVP-TEMPLATE.md v1.1 同步 2.8 | 2.8 2026-02-25T11:50:00 | **漂移缓存验证**：在每个审核周期后添加强制漂移缓存验证（第 5.6 节）；添加了带有显式“.drift_cache.json”验证的第 5 阶段输出清单（第 5.7 节）；更新了流程图以包括验证步骤；添加了关于丢失漂移缓存的故障模式文档。 2.7 | 2.7 2026-02-25T08:30:00 | **检测算法修复**：修复了 3 个关键缺陷：(1) 未找到 BRD 现在触发参考搜索 + 生成而不是错误； (2) 审核模式现在包括完整的审核和修复周期（审核者 → 修复者 → 重新审核直到分数 >= 90%）； (3) 添加了具有分块功能的多 BRD 输入处理（最多 3 个并行）。更新了输入类型识别表、示例和操作确定输出以反映正确的行为。 2.6 | 2.6 2026-02-24T21:30:00 | **上游模式检测**：添加了阶段1.0来检测并提示upstream_mode；自动检测REF文件夹并提示用户选择路径；生成upstream_mode和upstream_ref_path字段；当没有 REF 文件夹或从头开始创建时，默认为 upload_mode：“none” 2.5 | 2.5 2026-02-11 | **智能文档检测**：新增文档类型自动识别；自类型输入（BRD-NN）触发审阅模式；参考文档和提示触发器生成；对第 1 层的特殊处理（无上游文档） 2.4 | 2.4 2026-02-10 | **源目录更新**：将输入源从“strategy/”、“docs/inputs/”更改为“docs/00_REF/”（主要）、“REF/”（替代）、用户提示（后备）； **BRD 索引** ：添加了“BRD-00_index.md”主索引的自动创建/更新，包括文档注册表、模块类别、统计信息；更新了所有示例和 CI/CD 配置 2.3 | 2.3 2026-02-10 | **审核和修复周期**：用迭代审核替换第 5 阶段 → 使用 `doc-brd-reviewer` 和 `doc-brd-fixer` 修复周期；添加了`doc-brd-fixer`技能依赖； **链接验证**：添加了阶段 1.1 源文档链接验证以验证生成前是否存在“@ref:”目标； **术语表处理**：添加了具有自动创建/路径解析功能的第 3 阶段第 10 步主术语表处理； **元素 ID 修复**：添加了类型代码修复和损坏的链接修复类别（旧版“25→33”指南在 3.5 中被取代） 2.2 | 2.2 2026-02-10 |添加了审核文档标准：审核报告与审核文档一起存储（不在 tmp/ 中）；审查报告需要 YAML frontmatter、父文档参考和结构化部分；文件命名约定 `{ARTIFACT}-NN.R_review_report.md` 2.1 | 2.1 2026-02-09 |添加了审核模式，用于验证现有 BRD 文件而不进行修改；添加修复模式，用于自动修复 BRD 文档，同时保留手动内容；添加了修复类别（element_ids、sections、adr_topics、traceability、score）；新增内容保存规则；增加了备份功能；添加元素ID迁移（BO_XXX、FR_XXX、AC_XXX、BC_XXX统一格式） 1.0 | 2026-02-08 |通过 5 阶段工作流程创建初始技能；集成的文档命名、doc-brd、doc-brd-validator、质量顾问技能；添加了平台与功能 BRD 处理；添加了第 7.2 节 ADR 主题生成

Doc Brd 自动驾驶仪

包含技能