Speckit Checklist Zh

检查表目的："中文的单元测试"

关键概念：检查表是要求编写的单元测试 - 它们验证特定领域中要求的质量、清晰度和完整性。

不用于验证/测试：

• ❌ 不是"验证按钮正确点击"
• ❌ 不是"测试错误处理是否有效"
• ❌ 不是"确认 API 返回 200"
• ❌ 不是检查代码/实现是否符合规格

用于要求质量验证：

• ✅ "是否为所有卡片类型定义了视觉层次要求？"（完整性）
• ✅ "是否用特定的尺寸/定位量化了'显著显示'？"（清晰度）
• ✅ "所有交互元素的悬停状态要求是否一致？"（一致性）
• ✅ "是否为键盘导航定义了可访问性要求？"（覆盖范围）
• ✅ "规格是否定义了徽标图像加载失败时的情况？"（边缘情况）

比喻：如果您的规格是编写的代码，那么检查表就是它的单元测试套件。您正在测试要求是否编写良好、完整、明确并准备好实施 - 而不是测试实现是否有效。

用户输入

$ARGUMENTS

您必须在继续之前考虑用户输入（如果不为空）。

执行步骤

scripts: sh: .specify/scripts/bash/check-prerequisites.sh --json ps: .specify/scripts/powershell/check-prerequisites.ps1 -Json

1. 设置：从仓库根目录运行 {SCRIPT} 并解析 JSON 以获取 FEATURE_DIR 和 AVAILABLE_DOCS 列表。

• 所有文件路径必须是绝对的。
• 对于参数中的单引号，如 "I'm Groot"，使用转义语法：例如 'I'\''m Groot'（或者如果可能的话使用双引号："I'm Groot"）。

2. 澄清意图（动态）：推导出最多三个初始上下文澄清问题（无预设目录）。它们必须：

• 从用户的措辞 + 从规格/计划/任务中提取的信号生成
• 仅询问会实质性改变检查表内容的信息
• 如果在 $ARGUMENTS 中已经明确，则单独跳过
• 优先考虑精确性而非广度

生成算法：

1. 提取信号：功能领域关键词（例如，auth, latency, UX, API），风险指标（"critical", "must", "compliance"），利益相关者提示（"QA", "review", "security team"）和明确的交付物（"a11y", "rollback", "contracts"）。 2. 将信号聚类到候选关注领域（最多 4 个）按相关性排序。 3. 识别可能的受众和时机（作者、审阅者、QA、发布）如果不明确。 4. 检测缺失的维度：范围广度、深度/严谨性、风险重点、排除边界、可测量的验收标准。 5. 从这些原型中制定问题：

• 范围细化（例如，"这应该包括与 X 和 Y 的集成接触点还是仅限于本地模块正确性？"）
• 风险优先级（例如，"这些潜在风险领域中哪些应该接受强制门控检查？"）
• 深度校准（例如，"这是一个轻量级的预提交健全性列表还是正式的发布门？"）
• 受众框架（例如，"这将仅由作者使用还是在 PR 审阅期间由同行使用？"）
• 边界排除（例如，"我们应该明确排除本轮的性能调优项目吗？"）
• 场景类别差距（例如，"未检测到恢复流程——回滚/部分故障路径是否在范围内？"）

问题格式规则：

• 如果提供选项，生成一个紧凑的表格，列：选项 | 候选 | 重要性原因
• 限制最多 A-E 个选项；如果自由形式答案更清晰则省略表格
• 永远不要要求用户重述他们已经说过的话
• 避免推测性类别（无幻觉）。如果不确定，明确询问："确认 X 是否在范围内。"

无法交互时的默认值：

• 深度：标准
• 受众：如果与代码相关则为审阅者（PR）；否则为作者
• 关注：前 2 个相关性聚类

输出问题（标记 Q1/Q2/Q3）。回答后：如果≥2 个场景类别（替代/异常/恢复/非功能性领域）仍不清楚，您可以要求最多两个更有针对性的后续问题（Q4/Q5），每个问题附带一行理由（例如，"未解决的恢复路径风险"）。不要超过五个总问题。如果用户明确拒绝更多问题则跳过升级。

3. 理解用户请求：结合 $ARGUMENTS + 澄清答案：

• 推导检查表主题（例如，安全、审阅、部署、用户体验）
• 整合用户提到的明确必备项目
• 将焦点选择映射到类别脚手架
• 从规格/计划/任务中推断任何缺失的上下文（不要幻觉）

4. 加载功能上下文：从 FEATURE_DIR 读取：

• spec.md：功能要求和范围
• plan.md（如果存在）：技术细节、依赖关系
• tasks.md（如果存在）：实施任务

上下文加载策略：

• 仅加载与活跃关注领域相关的必要部分（避免完整文件转储）
• 更喜欢将长段落总结为简洁的场景/要求要点
• 使用渐进式披露：仅在检测到差距时添加后续检索
• 如果源文档很大，生成中间摘要项目而不是嵌入原始文本

5. 生成检查表 - 创建"要求的单元测试"：

• 如果不存在则创建 FEATURE_DIR/checklists/ 目录
• 生成唯一的检查表文件名：
• 使用基于领域的简短描述性名称（例如，ux.md, api.md, security.md）
• 格式：[domain].md
• 如果文件存在，则追加到现有文件
• 从 CHK001 开始顺序编号项目
• 每个 speckit-checklist 运行创建一个新文件（从不覆盖现有检查表）

核心原则 - 测试要求，而不是实现： 每个检查表项目必须评估要求本身：

• 完整性：所有必要的要求是否存在？
• 清晰度：要求是否明确且具体？
• 一致性：要求是否相互对齐？
• 可测量性：要求是否可以客观验证？
• 覆盖范围：是否解决了所有场景/边缘情况？

类别结构 - 按要求质量维度分组项目：

• 要求完整性（是否记录了所有必要的要求？）
• 要求清晰度（要求是否具体且明确？）
• 要求一致性（要求是否对齐而无冲突？）
• 验收标准质量（成功标准是否可测量？）
• 场景覆盖（是否解决了所有流程/案例？）
• 边缘情况覆盖（是否定义了边界条件？）
• 非功能性要求（性能、安全性、可访问性等 - 是否指定？）
• 依赖关系和假设（是否记录和验证？）
• 歧义和冲突（需要澄清什么？）

如何编写检查表项目 - "英语的单元测试"：

❌ 错误（测试实现）：

• "验证着陆页显示 3 个剧集卡片"
• "测试桌面端悬停状态是否有效"
• "确认徽标点击导航到主页"

✅ 正确（测试要求质量）：

• "是否明确指定了特色剧集的确切数量和布局？" [完整性]
• "是否用特定的尺寸/定位量化了'显著显示'？" [清晰度]
• "所有交互元素的悬停状态要求是否一致？" [一致性]
• "是否为所有交互式 UI 定义了键盘导航要求？" [覆盖范围]
• "当徽标图像加载失败时是否指定了回退行为？" [边缘情况]
• "是否为异步剧集数据定义了加载状态？" [完整性]
• "规格是否定义了竞争 UI 元素的视觉层次？" [清晰度]

项目结构： 每个项目应遵循此模式：

• 询问要求质量的问题格式
• 关注规格/计划中编写（或未编写）的内容
• 包括质量维度在括号中 [完整性/清晰度/一致性等]
• 检查现有要求时引用规格部分 [Spec §X.Y]
• 使用 [Gap] 标记检查缺失的要求

按质量维度的示例：

完整性：

• "是否为所有 API 故障模式定义了错误处理要求？ [Gap]"
• "是否为所有交互元素指定了可访问性要求？ [完整性]"
• "是否为响应式布局定义了移动断点要求？ [Gap]"

清晰度：

• "是否用特定的时间阈值量化了'快速加载'？ [清晰度, Spec §NFR-2]"
• "是否明确定义了'相关剧集'的选择标准？ [清晰度, Spec §FR-5]"
• "是否用可测量的视觉属性定义了'显著'？ [歧义, Spec §FR-4]"

一致性：

• "所有页面的导航要求是否对齐？ [一致性, Spec §FR-10]"
• "着陆页和详情页的卡片组件要求是否一致？ [一致性]"

覆盖范围：

• "是否为零状态场景（无剧集）定义了要求？ [覆盖范围, 边缘情况]"
• "是否解决了并发用户交互场景？ [覆盖范围, Gap]"
• "是否为部分数据加载失败指定了要求？ [覆盖范围, 异常流程]"

可测量性：

• "视觉层次要求是否可测量/可测试？ [验收标准, Spec §FR-1]"
• "是否可以客观验证'平衡的视觉权重'？ [可测量性, Spec §FR-2]"

场景分类和覆盖（要求质量重点）：

• 检查是否存在要求：主要、替代、异常/错误、恢复、非功能性场景
• 对于每个场景类别，询问："[场景类型] 要求是否完整、清晰且一致？"
• 如果场景类别缺失："[场景类型] 要求是故意排除还是缺失？ [Gap]"
• 包括状态变更时的弹性/回滚："是否为迁移失败定义了回滚要求？ [Gap]"

可追溯性要求：

• 最低要求：≥80% 的项目必须至少包含一个可追溯性引用
• 每个项目应引用：规格部分 [Spec §X.Y]，或使用标记：[Gap]、[Ambiguity]、[Conflict]、[Assumption]
• 如果不存在 ID 系统："是否建立了要求和验收标准 ID 方案？ [可追溯性]"

表面和解决问题（要求质量问题）： 询问有关要求本身的问题：

• 歧义："'快速' 一词是否用具体指标量化？ [歧义, Spec §NFR-1]"
• 冲突："§FR-10 和 §FR-10a 中的导航要求是否冲突？ [冲突]"
• 假设："'始终可用的播客 API' 假设是否已验证？ [假设]"
• 依赖关系："是否记录了外部播客 API 要求？ [依赖关系, Gap]"
• 缺失定义："是否用可测量的标准定义了'视觉层次'？ [Gap]"

内容整合：

• 软上限：如果原始候选项目 > 40，按风险/影响优先排序
• 合并检查相同要求方面的近似重复项
• 如果 >5 个低影响边缘情况，创建一个项目："边缘情况 X、Y、Z 是否在要求中解决？ [覆盖范围]"

🚫 绝对禁止 - 这些使其成为实现测试，而不是要求测试：

• ❌ 任何以"验证"、"测试"、"确认"、"检查" + 实现行为开头的项目
• ❌ 引用代码执行、用户操作、系统行为
• ❌ "正确显示"、"正常工作"、"按预期功能"
• ❌ "点击"、"导航"、"渲染"、"加载"、"执行"
• ❌ 测试用例、测试计划、QA 程序
• ❌ 实现细节（框架、API、算法）

✅ 必需模式 - 这些测试要求质量：

• ✅ "是否为 [场景] 定义/指定/记录了 [要求类型]？"
• ✅ "是否用具体标准量化/澄清了 [模糊术语]？"
• ✅ "[部分 A] 和 [部分 B] 的要求是否一致？"
• ✅ "是否可以客观测量/验证 [要求]？"
• ✅ "要求中是否解决了 [边缘情况/场景]？"
• ✅ "规格是否定义了 [缺失方面]？"

6. 结构参考：按照 .specify/templates/checklist-template.md 中的规范模板生成检查表，包括标题、元部分、类别标题和 ID 格式。如果模板不可用，使用：H1 标题、目的/创建的元行、包含 - [ ] CHK### <要求项目> 行的 ## 类别部分，全局递增 ID 从 CHK001 开始。

7. 报告：输出创建的检查表的完整路径、项目计数，并提醒用户每次运行都会创建一个新文件。总结：

• 选择的关注领域
• 深度级别
• 参与者/时机
• 任何包含的用户明确指定的必备项目

重要：每个 speckit-checklist 命令调用都使用简短的描述性名称创建检查表文件，除非文件已存在。这允许：

• 不同类型的多个检查表（例如，ux.md, test.md, security.md）
• 简单、易记的文件名，指示检查表目的
• 在 checklists/ 文件夹中轻松识别和导航

为避免混乱，使用描述性类型并在完成后清理过时的检查表。

示例检查表类型和示例项目

用户体验要求质量： ux.md

示例项目（测试要求，而不是实现）：

• "是否用可测量的标准定义了视觉层次要求？ [清晰度, Spec §FR-1]"
• "是否明确定义了 UI 元素的数量和定位？ [完整性, Spec §FR-1]"
• "交互状态要求（悬停、焦点、活动）是否一致定义？ [一致性]"
• "是否为所有交互元素指定了可访问性要求？ [覆盖范围, Gap]"
• "图像加载失败时是否定义了回退行为？ [边缘情况, Gap]"
• "是否可以客观测量'显著显示'？ [可测量性, Spec §FR-4]"

API 要求质量： api.md

示例项目：

• "是否为所有故障场景指定了错误响应格式？ [完整性]"
• "是否用具体阈值量化了速率限制要求？ [清晰度]"
• "所有端点的身份验证要求是否一致？ [一致性]"
• "是否为外部依赖关系定义了重试/超时要求？ [覆盖范围, Gap]"
• "版本控制策略是否在要求中记录？ [Gap]"

性能要求质量： performance.md

示例项目：

• "是否用具体指标量化了性能要求？ [清晰度]"
• "是否为所有关键用户旅程定义了性能目标？ [覆盖范围]"
• "是否为不同负载条件指定了性能要求？ [完整性]"
• "是否可以客观测量性能要求？ [可测量性]"
• "是否为高负载场景定义了降级要求？ [边缘情况, Gap]"

安全要求质量： security.md

示例项目：

• "是否为所有受保护资源指定了身份验证要求？ [覆盖范围]"
• "是否为敏感信息定义了数据保护要求？ [完整性]"
• "威胁模型是否记录并与要求对齐？ [可追溯性]"
• "安全要求是否与合规义务一致？ [一致性]"
• "是否定义了安全故障/违规响应要求？ [Gap, 异常流程]"

反例：不要做的事情

❌ 错误 - 这些测试实现，而不是要求：

- [ ] CHK001 - 验证着陆页显示 3 个剧集卡片 [Spec §FR-001]
- [ ] CHK002 - 测试桌面端悬停状态是否正确工作 [Spec §FR-003]
- [ ] CHK003 - 确认徽标点击导航到主页 [Spec §FR-010]
- [ ] CHK004 - 检查相关剧集部分显示 3-5 个项目 [Spec §FR-005]

✅ 正确 - 这些测试要求质量：

- [ ] CHK001 - 是否明确定义了特色剧集的数量和布局？ [完整性, Spec §FR-001]
- [ ] CHK002 - 是否为所有交互元素一致定义了悬停状态要求？ [一致性, Spec §FR-003]
- [ ] CHK003 - 是否为所有可点击品牌元素明确了导航要求？ [清晰度, Spec §FR-010]
- [ ] CHK004 - 是否记录了相关剧集的选择标准？ [Gap, Spec §FR-005]
- [ ] CHK005 - 是否为异步剧集数据定义了加载状态要求？ [Gap]
- [ ] CHK006 - 是否可以客观测量"视觉层次"要求？ [可测量性, Spec §FR-001]

主要区别：

• 错误：测试系统是否正常工作
• 正确：测试要求是否编写正确
• 错误：行为验证
• 正确：要求质量验证
• 错误："它是否做 X？"
• 正确："X 是否明确定义？"

[检查表类型] 检查表：[功能名称]

目的：[此检查表涵盖内容的简要描述] 创建时间：[日期] 功能：[链接到 spec.md 或相关文档]

注意：此检查表由 /speckit.checklist 命令根据功能上下文和要求生成。

<!-- ============================================================================ 重要提示：下面的检查表项目仅为示例项目，仅用于说明。

/speckit.checklist 命令必须根据以下内容替换这些项目：

• 用户的具体检查表请求
• 来自 spec.md 的功能要求
• 来自 plan.md 的技术上下文
• 来自 tasks.md 的实现细节

不要在生成的检查表文件中保留这些示例项目。 ============================================================================ -->

[类别 1]

• [ ] CHK001 第一个检查表项目，带有明确的操作
• [ ] CHK002 第二个检查表项目
• [ ] CHK003 第三个检查表项目

[类别 2]

• [ ] CHK004 另一个类别的项目
• [ ] CHK005 带有特定标准的项目
• [ ] CHK006 此类别中的最后一个项目

备注

• 完成后勾选项目：[x]
• 在线添加评论或发现
• 链接到相关资源或文档
• 项目按顺序编号以便于参考

- [ ] CHK001 - Are the number and layout of featured episodes explicitly specified? [Completeness, Spec §FR-001]
- [ ] CHK002 - Are hover state requirements consistently defined for all interactive elements? [Consistency, Spec §FR-003]
- [ ] CHK003 - Are navigation requirements clear for all clickable brand elements? [Clarity, Spec §FR-010]
- [ ] CHK004 - Is the selection criteria for related episodes documented? [Gap, Spec §FR-005]
- [ ] CHK005 - Are loading state requirements defined for asynchronous episode data? [Gap]
- [ ] CHK006 - Can "visual hierarchy" requirements be objectively measured? [Measurability, Spec §FR-001]

示例代码片段

PowerShell转义语法示例

对于参数中的单引号，使用转义语法：

# 错误：I'm Groot
# 正确：'I'\''m Groot'

# 或者如果可能，使用双引号：
"I'm Groot"

检查清单项目结构示例

正确的项目格式：

- [ ] CHK001 - Are the exact number and layout of featured episodes specified? [Completeness, Spec §FR-001]
- [ ] CHK002 - Are hover state requirements consistently defined for all interactive elements? [Consistency, Spec §FR-003]
- [ ] CHK003 - Is the selection criteria for related episodes documented? [Gap, Spec §FR-005]

项目组成要素：

1. 复选框：- [ ] 2. ID：CHK###（从001开始顺序编号） 3. 问题格式：询问需求质量的问题 4. 质量维度标签：[Completeness/Clarity/Consistency/etc.] 5. 规范引用：[Spec §X.Y]（当检查现有需求时） 6. 缺失标记：[Gap]（当检查缺失需求时）

问题格式化规则

选项表格格式：

| 选项 | 候选项 | 重要性 |
|------|--------|---------|
| A | 轻量级预提交检查 | 快速反馈，低摩擦 |
| B | 正式发布门控 | 高质量保证，正式流程 |
| C | PR审查辅助 | 协作改进，知识共享 |

限制：

• 最多A-E选项
• 如果自由形式答案更清晰，则省略表格
• 绝不要要求用户重述他们已经说过的内容
• 避免推测类别（无幻觉）

默认值设置

当交互不可能时：

• 深度：标准
• 受众：如果与代码相关则为审查者（PR）；否则为作者
• 焦点：前2个相关聚类

$ARGUMENTS

- [ ] CHK001 - Verify landing page displays 3 episode cards [Spec §FR-001]
- [ ] CHK002 - Test hover states work correctly on desktop [Spec §FR-003]
- [ ] CHK003 - Confirm logo click navigates to home page [Spec §FR-010]
- [ ] CHK004 - Check that related episodes section shows 3-5 items [Spec §FR-005]

反示例：什么不应该做

❌ 错误 - 这些测试实施，而非需求：

错误的项目类型：

1. 验证行为：

• "验证登录页面显示3个剧集卡片"
• "测试悬停状态在桌面版上正常工作"
• "确认logo点击导航到主页"

2. 检查实施细节：

• "检查相关剧集部分显示3-5个项目"
• "验证按钮在点击时变蓝"
• "测试API调用返回200状态码"

3. 基于用户操作的项目：

• "点击提交按钮时表单应提交"
• "用户输入无效邮箱时显示错误消息"
• "滚动时导航栏保持固定在顶部"

✅ 正确 - 这些测试需求质量：

正确的项目类型：

1. 完整性检查：

• "是否明确指定了特色剧集的数量和布局？[完整性, Spec §FR-001]"
• "是否为所有异步剧集数据定义了加载状态需求？[Gap]"

2. 清晰度验证：

• "所有可点击品牌元素的导航需求是否清晰？[清晰度, Spec §FR-010]"
• "'视觉层次'需求是否可以客观测量？[可测量性, Spec §FR-001]"

3. 一致性检查：

• "所有交互元素的悬停状态需求是否一致定义？[一致性, Spec §FR-003]"

4. 覆盖度验证：

• "相关剧集的选择标准是否已记录？[Gap, Spec §FR-005]"
• "是否为零状态场景（无剧集）定义了需求？[覆盖度, 边界情况]"

关键差异总结：

识别错误项目的模式

应立即标记的警告词语：

• "Verify" / "验证"
• "Test" / "测试"
• "Confirm" / "确认"
• "Check" / "检查"
• "Displays" / "显示"
• "Works" / "工作"
• "Functions" / "功能"

应避免的动词：

• Click / 点击
• Navigate / 导航
• Render / 渲染
• Load / 加载
• Execute / 执行

正确的提问模式：

• "Are [需求类型] defined/specified/documented for [场景]？"
• "Is [模糊术语] quantified/clarified with specific criteria？"
• "Are requirements consistent between [部分A] and [部分B]？"
• "Can [需求] be objectively measured/verified？"

检查清单类型和示例项目

UX需求质量检查清单：ux.md

示例项目（测试需求，而非实施）：

• "是否使用可测量标准定义了视觉层次需求？[清晰度, Spec §FR-1]"
• "是否明确指定了UI元素的数量和位置？[完整性, Spec §FR-1]"
• "是否一致定义了交互状态需求（悬停、焦点、活动）？[一致性]"
• "是否为所有交互元素指定了可访问性需求？[覆盖度, Gap]"
• "是否在图像加载失败时定义了回退行为？[边界情况, Gap]"
• "'突出显示'是否可以客观测量？[可测量性, Spec §FR-4]"

API需求质量检查清单：api.md

示例项目：

• "是否为所有故障场景指定了错误响应格式？[完整性]"
• "是否使用特定阈值量化了速率限制需求？[清晰度]"
• "所有端点的身份验证需求是否一致？[一致性]"
• "是否为外部依赖项定义了重试/超时需求？[覆盖度, Gap]"
• "版本控制策略是否在需求中记录？[Gap]"

性能需求质量检查清单：performance.md

示例项目：

• "是否使用特定指标量化了性能需求？[清晰度]"
• "是否为所有关键用户旅程定义了性能目标？[覆盖度]"
• "是否指定了不同负载条件下的性能需求？[完整性]"
• "性能需求是否可以客观测量？[可测量性]"
• "是否为高负载场景定义了降级需求？[边界情况, Gap]"

安全需求质量检查清单：security.md

示例项目：

• "是否为所有受保护资源指定了身份验证需求？[覆盖度]"
• "是否为敏感信息定义了数据保护需求？[完整性]"
• "威胁模型是否已记录并且需求与之保持一致？[可追溯性]"
• "安全需求是否与合规义务保持一致？[一致性]"
• "是否定义了安全失败/泄露响应需求？[Gap, 异常流程]"

检查清单命名约定

文件命名原则：

• 使用简短、描述性的名称基于域（例如 ux.md, api.md, security.md）
• 格式：[domain].md
• 如果文件存在，追加到现有文件

避免使用：

• 过于通用的名称（如 checklist.md, review.md）
• 过于具体的名称（如 api-endpoint-v2-security.md）
• 包含日期或版本的名称（这些信息应在文件内容中）

执行指南

完整执行步骤详解

1. 环境设置

运行先决条件检查脚本：

.scripts\check-prerequisites.ps1 -Json

解析输出：

• FEATURE_DIR: 功能根目录的绝对路径
• AVAILABLE_DOCS: 可用文档列表 [spec.md, plan.md, tasks.md]

2. 动态意图澄清算法

信号提取： 1. 功能域关键词：auth, latency, UX, API 2. 风险指标：critical, must, compliance 3. 利益相关者提示：QA, review, security team 4. 明确交付物：a11y, rollback, contracts

问题生成原型：

• 范围细化："这应该包括与X和Y的集成接触点还是仅限于本地模块正确性？"
• 风险优先级："这些潜在风险区域中哪些应该接受强制性门控检查？"
• 深度校准："这是轻量级预提交健全性列表还是正式发布门？"
• 受众框架："这仅供作者使用还是在PR审查期间供同行使用？"
• 边界排除："本轮我们是否应明确排除性能调优项目？"

3. 上下文加载策略

渐进式披露原则：

• 仅加载与活动焦点区域相关的必要部分
• 优先将长部分总结为简洁的场景/需求要点
• 使用渐进式披露：仅在检测到缺失时添加后续检索
• 如果源文档很大，生成临时摘要项目而不是嵌入原始文本

4. 检查清单生成算法

核心原则 - 测试需求而非实施： 每个检查清单项目必须评估需求本身在以下方面的质量：

• 完整性：是否存在所有必要的需求？
• 清晰度：需求是否明确无歧义？
• 一致性：需求是否相互一致？
• 可测量性：需求是否可以客观验证？
• 覆盖度：是否处理了所有场景/边界情况？

可追溯性要求：

• 最低要求：≥80%的项目必须包含至少一个可追溯性引用
• 每个项目应引用：规范章节 [Spec §X.Y]，或使用标记：[Gap], [Ambiguity], [Conflict], [Assumption]
• 如果不存在ID系统："是否建立了需求和验收标准ID方案？[可追溯性]"

5. 内容整合策略

软上限： 如果原始候选项目 > 40，按风险/影响优先排序 合并重复项： 合并检查相同需求方面的近似重复项 边界情况分组： 如果 > 5 个低影响边界情况，创建一个项目："需求中是否解决了边界情况X, Y, Z？[覆盖度]"

质量维度详细说明

九大需求质量维度

1. 需求完整性 (Requirement Completeness)

关注点：是否记录了所有必要的需求？

示例项目：

• "是否为所有API故障模式定义了错误处理需求？[Gap]"
• "是否为所有交互元素指定了可访问性需求？[完整性]"
• "是否为响应式布局定义了移动断点需求？[Gap]"

2. 需求清晰度 (Requirement Clarity)

关注点：需求是否明确无歧义？

示例项目：

• "'快速加载'是否用特定时间阈值量化？[清晰度, Spec §NFR-2]"
• "'相关剧集'选择标准是否明确定义？[清晰度, Spec §FR-5]"
• "'突出'是否用可测量的视觉属性定义？[歧义, Spec §FR-4]"

3. 需求一致性 (Requirement Consistency)

关注点：需求是否在无冲突的情况下保持一致？

示例项目：

• "所有页面的导航需求是否一致？[一致性, Spec §FR-10]"
• "登录页面和详情页面的卡片组件需求是否一致？[一致性]"

4. 验收标准质量 (Acceptance Criteria Quality)

关注点：成功标准是否可测量？

示例项目：

• "视觉层次需求是否可测量/可测试？[验收标准, Spec §FR-1]"
• "'平衡视觉权重'是否可以客观验证？[可测量性, Spec §FR-2]"

5. 场景覆盖度 (Scenario Coverage)

关注点：是否处理了所有流程/案例？

示例项目：

• "是否为零状态场景（无剧集）定义了需求？[覆盖度, 边界情况]"
• "是否解决了并发用户交互场景？[覆盖度, Gap]"
• "是否为部分数据加载故障指定了需求？[覆盖度, 异常流程]"

6. 边界情况覆盖度 (Edge Case Coverage)

关注点：是否定义了边界条件？

示例项目：

• "是否在logo图像加载失败时指定了回退行为？[边界情况]"
• "是否处理了网络连接完全丢失的情况？[边界情况, Gap]"
• "是否定义了最大用户数限制的处理？[边界情况]"

7. 非功能性需求 (Non-Functional Requirements)

关注点：是否指定了性能、安全性、可访问性等？

示例项目：

• "是否用特定指标量化了性能需求？[清晰度]"
• "是否为敏感数据定义了安全要求？[完整性]"
• "是否符合WCAG 2.1 AA级可访问性标准？[覆盖度]"

8. 依赖项和假设 (Dependencies & Assumptions)

关注点：是否记录并验证了依赖项和假设？

示例项目：

• "'始终可用的播客API'假设是否已验证？[假设]"
• "是否记录了外部播客API需求？[依赖项, Gap]"
• "第三方服务级别的可用性要求是什么？[依赖项]"

9. 歧义和冲突 (Ambiguities & Conflicts)

关注点：什么需要澄清？

示例项目：

• "术语'快速'是否用特定指标量化？[歧义, Spec §NFR-1]"
• "§FR-10和§FR-10a之间的导航需求是否冲突？[冲突]"
• "'视觉层次'是否用可测量标准定义？[Gap]"

场景分类和覆盖度

主要场景类型：

1. 主要场景：正常业务流程 2. 备用场景：替代路径和方法 3. 异常/错误场景：故障和错误条件 4. 恢复场景：从故障中恢复 5. 非功能性场景：性能、安全、可访问性等

覆盖度检查模式：

• 对于每种场景类型，询问："[场景类型]需求是否完整、清晰和一致？"
• 如果场景类型缺失："[场景类型]需求是故意排除还是缺失？[Gap]"
• 当发生状态变更时包含弹性/回滚："是否为迁移故障定义了回滚需求？[Gap]"