BRD 逐段评审流水线

要解决什么问题

BRD 往往在段落层面留下未决实现选择：角色边界不清、验收标准缺失、异常与依赖一笔带过。若评审只停留在对话里，产品、研发与测试很难在同一份文档上对齐「问什么、改什么」。本技能把评审结果落到 Word 原生交付物：批注 balloon 承载澄清问题，修订痕迹承载可直接采纳的改写建议，而不是聊天摘要。

如何工作

流程围绕源 BRD 的 .docx 路径展开，先初始化段落级评审 JSON，再逐段读取文档并填充结构化字段：保留 paragraph_index、style_id、heading_path、source_text 不变；当段落含糊、不完整、内部矛盾或缺少验收标准、数据定义、归属、依赖、假设与边界情况时，将 needs_comment 设为 true，并写入简短可执行的 comment_question；当段落需要为精确性、完整性、语法或可测性重写时，将 needs_revision 设为 true，并给出完整句式的 proposed_replacement（非片段）。issue_tags 用于标明原因，例如 ambiguity、scope、acceptance-criteria、exception 等。

随后通过捆绑流水线 物化 最终文档：在与源 BRD 同一目录 生成 .review.json 与 .reviewed.docx。交付前需确认批注出现在对应段落、修订对 needs_revision=true 的段落可见；若 BRD 大量依赖表格或特殊版式，应结合 $doc 类工作流渲染后目视检查。

适用边界与注意点

评审标准强调：不要静默编造业务规则——关键细节缺失时，用批注提问而非猜测。批注宜短且可行动；改写建议应专业、可直接贴回正文。聊天里的分析仅作补充，.docx 才是主交付物。