<!-- 由 BMAD™ Core 驱动 -->

# 故事草稿清单

Scrum Master 应使用此清单来验证每个故事是否包含足够的上下文，以便开发代理成功实施，同时假设开发代理具有合理的能力来解决问题。

[[LLM: 初始化说明 - 故事草稿验证

在开始使用此清单之前，请确保您能访问以下内容：

1.  正在验证的故事文档（通常在 docs/stories/ 中或直接提供）
2.  父级史诗的上下文
3.  任何引用的架构或设计文档
4.  如果此工作建立在先前工作的基础上，则需提供以前的相关故事

重要提示：此清单在实施开始前验证单个故事。

验证原则：

1.  清晰性 - 开发人员应了解要构建什么
2.  上下文 - 为什么要构建它以及它如何融入整体
3.  指导 - 要遵循的关键技术决策和模式
4.  可测试性 - 如何验证实施是否有效
5.  自包含性 - 所需的大部分信息都在故事本身中

请记住：我们假设有能力的开发代理可以：

-   研究文档和代码库
-   做出合理的技术决策
-   遵循既定模式
-   在真正遇到困难时请求澄清

我们正在检查的是足够的指导，而不是详尽的细节。]]

## 1. 目标与上下文清晰度

[[LLM: 没有明确的目标，开发人员会构建错误的东西。验证：

1.  故事说明了要实施什么功能
2.  业务价值或用户利益是明确的
3.  解释了这如何融入更大的史诗/产品
4.  依赖关系是明确的（“需要故事 X 完成”）
5.  成功看起来是具体的，而不是模糊的]]

- [ ] 故事目标/目的陈述清晰
- [ ] 与史诗目标的关系显而易见
- [ ] 解释了故事如何融入整个系统流程
- [ ] 确定了对先前故事的依赖关系（如果适用）
- [ ] 业务背景和价值清晰

## 2. 技术实施指导

[[LLM: 开发人员需要足够的技术背景才能开始编码。检查：

1.  提到了要创建或修改的关键文件/组件
2.  在不明显的地方指定了技术选择
3.  确定了与现有代码的集成点
4.  定义或引用了数据模型或 API 合约
5.  指出了非标准模式或例外情况

注意：我们不需要列出每个文件 - 只需要重要的文件。]]

- [ ] 确定了要创建/修改的关键文件（不一定详尽无遗）
- [ ] 提到了此故事特别需要的技术
- [ ] 充分描述了关键的 API 或接口
- [ ] 引用了必要的数据模型或结构
- [ ] 列出了所需的环境变量（如果适用）
- [ ] 注意到了标准编码模式的任何例外情况

## 3. 参考有效性

[[LLM: 参考应该有帮助，而不是制造寻宝游戏。确保：

1.  参考指向特定部分，而不是整个文档
2.  解释了每个参考的相关性
3.  故事中总结了关键信息
4.  参考是可访问的（不是损坏的链接）
5.  如果需要，总结了先前故事的上下文]]

- [ ] 对外部文档的引用指向特定的相关部分
- [ ] 总结了先前故事中的关键信息（而不仅仅是引用）
- [ ] 提供了为什么参考相关的上下文
- [ ] 参考使用一致的格式（例如，`docs/filename.md#section`）

## 4. 自包含性评估

[[LLM: 故事应尽可能自包含，以避免上下文切换。验证：

1.  核心需求在故事中，而不仅仅是在参考中
2.  领域术语已解释或从上下文中显而易见
3.  明确陈述了假设
4.  提到了边缘情况（即使已推迟）
5.  无需阅读 10 个其他文档即可理解该故事]]

- [ ] 包含了所需的核心信息（不过度依赖外部文档）
- [ ] 明确了隐含的假设
- [ ] 解释了特定领域的术语或概念
- [ ] 解决了边缘情况或错误场景

## 5. 测试指导

[[LLM: 测试确保实施真正有效。检查：

1.  指定了测试方法（单元、集成、端到端）
2.  列出了关键测试场景
3.  成功标准是可衡量的
4.  注意到了特殊的测试注意事项
5.  故事中的验收标准是可测试的]]

- [ ] 概述了所需的测试方法
- [ ] 确定了关键测试场景
- [ ] 定义了成功标准
- [ ] 注意到了特殊的测试注意事项（如果适用）

## 验证结果

[[LLM: 最终故事验证报告

生成一份简洁的验证报告：

1.  快速摘要
    -   故事准备情况：准备就绪 / 需要修订 / 受阻
    -   清晰度得分 (1-10)
    -   识别出的主要差距

2.  填写验证表：
    -   通过：需求明确满足
    -   部分：有些差距但可行
    -   失败：缺少关键信息

3.  具体问题（如有）
    -   列出要修复的具体问题
    -   提出具体的改进建议
    -   确定任何阻塞性依赖关系

4.  开发人员视角
    -   您能按书面形式实施这个故事吗？
    -   您会有什么问题？
    -   什么可能导致延误或返工？

要务实——完美的文档不存在，但必须足以提供开发代理完成工作所需的极端上下文，并且不会造成混乱。]]

| 类别 | 状态 | 问题 |
| --- | --- | --- |
| 1. 目标与上下文清晰度 | _待定_ | |
| 2. 技术实施指导 | _待定_ | |
| 3. 参考有效性 | _待定_ | |
| 4. 自包含性评估 | _待定_ | |
| 5. 测试指导 | _待定_ | |

**最终评估：**

-   **准备就绪**：故事为实施提供了足够的上下文
-   **需要修订**：故事需要更新（见问题）
-   **受阻**：需要外部信息（指明需要什么信息）