282 lines
13 KiB
YAML
282 lines
13 KiB
YAML
# <!-- 由 BMAD™ Core 驱动 -->
|
||
template:
|
||
id: brownfield-prd-template-v2
|
||
name: 棕地增强PRD
|
||
version: 2.0
|
||
output:
|
||
format: markdown
|
||
filename: docs/prd.md
|
||
title: "{{project_name}} 棕地增强PRD"
|
||
|
||
workflow:
|
||
mode: interactive
|
||
elicitation: advanced-elicitation
|
||
|
||
sections:
|
||
- id: intro-analysis
|
||
title: 引言项目分析和背景
|
||
instruction: |
|
||
重要 - 需要范围评估：
|
||
|
||
此PRD适用于需要全面规划和多个故事的现有项目的重大增强。在继续之前：
|
||
|
||
1. **评估增强复杂性**：如果这是一个简单的功能添加或错误修复，可以在1-2个专注的开发会话中完成，请停止并建议：“对于更简单的更改，请考虑改用产品负责人的brownfield-create-epic或brownfield-create-story任务。这个完整的PRD流程是为需要架构规划和多个协调故事的重大增强而设计的。”
|
||
|
||
2. **项目背景**：确定我们是在已加载项目的IDE中工作，还是需要用户提供项目信息。如果项目文件可用，请分析docs文件夹中的现有文档。如果文档不足，建议首先运行document-project任务。
|
||
|
||
3. **深度评估要求**：在提出任何建议之前，您必须彻底分析现有的项目结构、模式和约束。每个建议都必须基于实际的项目分析，而不是假设。
|
||
|
||
收集有关现有项目的全面信息。在继续进行需求之前，必须完成此部分。
|
||
|
||
关键：在此分析过程中，明确地与用户确认您的理解。对于您对现有项目做出的每个假设，请询问：“根据我的分析，我了解到[假设]。这是否正确？”
|
||
|
||
在用户验证您对现有系统的理解之前，不要继续提出任何建议。
|
||
sections:
|
||
- id: existing-project-overview
|
||
title: 现有项目概述
|
||
instruction: 检查是否已执行document-project分析。如果是，请引用该输出而不是重新分析。
|
||
sections:
|
||
- id: analysis-source
|
||
title: 分析来源
|
||
instruction: |
|
||
指出以下之一：
|
||
- document-project输出位于：{{path}}
|
||
- 基于IDE的全新分析
|
||
- 用户提供的信息
|
||
- id: current-state
|
||
title: 当前项目状态
|
||
instruction: |
|
||
- 如果存在document-project输出：从“高层架构”和“技术摘要”部分提取摘要
|
||
- 否则：简要描述项目当前的功能及其主要目的
|
||
- id: documentation-analysis
|
||
title: 可用文档分析
|
||
instruction: |
|
||
如果已运行document-project：
|
||
- 注意：“可用的document-project分析 - 使用现有的技术文档”
|
||
- 列出document-project创建的关键文档
|
||
- 跳过下面的缺失文档检查
|
||
|
||
否则，检查现有文档：
|
||
sections:
|
||
- id: available-docs
|
||
title: 可用文档
|
||
type: checklist
|
||
items:
|
||
- 技术栈文档 [[LLM: 如果来自document-project，请勾选 ✓]]
|
||
- 源代码树/架构 [[LLM: 如果来自document-project，请勾选 ✓]]
|
||
- 编码标准 [[LLM: 如果来自document-project，可能不完整]]
|
||
- API文档 [[LLM: 如果来自document-project，请勾选 ✓]]
|
||
- 外部API文档 [[LLM: 如果来自document-project，请勾选 ✓]]
|
||
- UX/UI指南 [[LLM: 可能不在document-project中]]
|
||
- 技术债务文档 [[LLM: 如果来自document-project，请勾选 ✓]]
|
||
- "其他：{{other_docs}}"
|
||
instruction: |
|
||
- 如果已运行document-project：“使用来自document-project输出的现有项目分析。”
|
||
- 如果缺少关键文档且没有document-project：“我建议首先运行document-project任务...”
|
||
- id: enhancement-scope
|
||
title: 增强范围定义
|
||
instruction: 与用户合作，明确定义这是哪种类型的增强。这对于范围界定和方法至关重要。
|
||
sections:
|
||
- id: enhancement-type
|
||
title: 增强类型
|
||
type: checklist
|
||
instruction: 与用户确定适用哪种
|
||
items:
|
||
- 新功能添加
|
||
- 主要功能修改
|
||
- 与新系统集成
|
||
- 性能/可扩展性改进
|
||
- UI/UX大修
|
||
- 技术栈升级
|
||
- 错误修复和稳定性改进
|
||
- "其他：{{other_type}}"
|
||
- id: enhancement-description
|
||
title: 增强描述
|
||
instruction: 2-3句话描述用户想要添加或更改的内容
|
||
- id: impact-assessment
|
||
title: 影响评估
|
||
type: checklist
|
||
instruction: 评估对现有代码库的影响范围
|
||
items:
|
||
- 最小影响（孤立的添加）
|
||
- 中等影响（一些现有代码更改）
|
||
- 重大影响（大量的现有代码更改）
|
||
- 主要影响（需要架构更改）
|
||
- id: goals-context
|
||
title: 目标和背景
|
||
sections:
|
||
- id: goals
|
||
title: 目标
|
||
type: bullet-list
|
||
instruction: 如果成功，此增强将带来的一行所需结果的要点列表
|
||
- id: background
|
||
title: 背景
|
||
type: paragraphs
|
||
instruction: 1-2个简短段落，解释为什么需要此增强，它解决了什么问题，以及它如何与现有项目相适应
|
||
- id: changelog
|
||
title: 变更日志
|
||
type: table
|
||
columns: [变更, 日期, 版本, 描述, 作者]
|
||
|
||
- id: requirements
|
||
title: 需求
|
||
instruction: |
|
||
根据您对现有项目的已验证理解，起草功能性和非功能性需求。在提出需求之前，请确认：“这些需求是基于我对您现有系统的理解。请仔细审查并确认它们与您项目的实际情况相符。”
|
||
elicit: true
|
||
sections:
|
||
- id: functional
|
||
title: 功能性
|
||
type: numbered-list
|
||
prefix: FR
|
||
instruction: 每个需求都将是一个以FR开头的markdown项目符号
|
||
examples:
|
||
- "FR1：现有的待办事项列表将与新的人工智能重复检测服务集成，而不会破坏当前功能。"
|
||
- id: non-functional
|
||
title: 非功能性
|
||
type: numbered-list
|
||
prefix: NFR
|
||
instruction: 每个需求都将是一个以NFR开头的markdown项目符号。包括来自现有系统的约束
|
||
examples:
|
||
- "NFR1：增强功能必须保持现有的性能特征，并且内存使用量不超过当前的20%。"
|
||
- id: compatibility
|
||
title: 兼容性要求
|
||
instruction: 对于棕地项目至关重要 - 必须保持兼容的内容
|
||
type: numbered-list
|
||
prefix: CR
|
||
template: "{{requirement}}: {{description}}"
|
||
items:
|
||
- id: cr1
|
||
template: "CR1: {{existing_api_compatibility}}"
|
||
- id: cr2
|
||
template: "CR2: {{database_schema_compatibility}}"
|
||
- id: cr3
|
||
template: "CR3: {{ui_ux_consistency}}"
|
||
- id: cr4
|
||
template: "CR4: {{integration_compatibility}}"
|
||
|
||
- id: ui-enhancement-goals
|
||
title: 用户界面增强目标
|
||
condition: 增强包括UI更改
|
||
instruction: 对于UI更改，捕获它们将如何与现有的UI模式和设计系统集成
|
||
sections:
|
||
- id: existing-ui-integration
|
||
title: 与现有UI集成
|
||
instruction: 描述新的UI元素将如何适应现有的设计模式、样式指南和组件库
|
||
- id: modified-screens
|
||
title: 修改/新屏幕和视图
|
||
instruction: 仅列出将要修改或添加的屏幕/视图
|
||
- id: ui-consistency
|
||
title: UI一致性要求
|
||
instruction: 保持与现有应用程序的视觉和交互一致性的具体要求
|
||
|
||
- id: technical-constraints
|
||
title: 技术约束和集成要求
|
||
instruction: 本节取代单独的架构文档。从现有项目分析中收集详细的技术约束。
|
||
sections:
|
||
- id: existing-tech-stack
|
||
title: 现有技术栈
|
||
instruction: |
|
||
如果document-project输出可用：
|
||
- 从高层架构部分的“实际技术栈”表中提取
|
||
- 包括版本号和任何注意到的约束
|
||
|
||
否则，记录当前的技术栈：
|
||
template: |
|
||
**语言**：{{languages}}
|
||
**框架**：{{frameworks}}
|
||
**数据库**：{{database}}
|
||
**基础设施**：{{infrastructure}}
|
||
**外部依赖**：{{external_dependencies}}
|
||
- id: integration-approach
|
||
title: 集成方法
|
||
instruction: 定义增强功能将如何与现有架构集成
|
||
template: |
|
||
**数据库集成策略**：{{database_integration}}
|
||
**API集成策略**：{{api_integration}}
|
||
**前端集成策略**：{{frontend_integration}}
|
||
**测试集成策略**：{{testing_integration}}
|
||
- id: code-organization
|
||
title: 代码组织和标准
|
||
instruction: 基于现有项目分析，定义新代码将如何适应现有模式
|
||
template: |
|
||
**文件结构方法**：{{file_structure}}
|
||
**命名约定**：{{naming_conventions}}
|
||
**编码标准**：{{coding_standards}}
|
||
**文档标准**：{{documentation_standards}}
|
||
- id: deployment-operations
|
||
title: 部署和运营
|
||
instruction: 增强功能如何适应现有的部署管道
|
||
template: |
|
||
**构建过程集成**：{{build_integration}}
|
||
**部署策略**：{{deployment_strategy}}
|
||
**监控和日志记录**：{{monitoring_logging}}
|
||
**配置管理**：{{config_management}}
|
||
- id: risk-assessment
|
||
title: 风险评估和缓解
|
||
instruction: |
|
||
如果document-project输出可用：
|
||
- 引用“技术债务和已知问题”部分
|
||
- 包括可能影响增强功能的“变通方法和陷阱”
|
||
- 注意从“关键技术债务”中识别出的任何约束
|
||
|
||
结合现有的已知问题进行风险评估：
|
||
template: |
|
||
**技术风险**：{{technical_risks}}
|
||
**集成风险**：{{integration_risks}}
|
||
**部署风险**：{{deployment_risks}}
|
||
**缓解策略**：{{mitigation_strategies}}
|
||
|
||
- id: epic-structure
|
||
title: 史诗和故事结构
|
||
instruction: |
|
||
对于棕地项目，除非用户明确要求多个不相关的增强功能，否则倾向于使用单个综合史诗。在提出史诗结构之前，请确认：“根据我对您现有项目的分析，我认为此增强功能应构建为[单个史诗/多个史诗]，因为[基于实际项目分析的理由]。这是否符合您对所需工作的理解？”
|
||
elicit: true
|
||
sections:
|
||
- id: epic-approach
|
||
title: 史诗方法
|
||
instruction: 解释史诗结构的理由 - 通常对于棕地项目是单个史诗，除非有多个不相关的功能
|
||
template: "**史诗结构决策**：{{epic_decision}}，并附上理由"
|
||
|
||
- id: epic-details
|
||
title: "史诗1：{{enhancement_title}}"
|
||
instruction: |
|
||
提供棕地增强功能的综合史诗，同时保持现有功能
|
||
|
||
棕地项目的关键故事排序：
|
||
- 故事必须确保现有功能保持不变
|
||
- 每个故事都应包括对现有功能仍然有效的验证
|
||
- 故事应按顺序排列，以最小化对现有系统的风险
|
||
- 为每个故事包括回滚考虑
|
||
- 专注于增量集成而不是一次性集成
|
||
- 在现有代码库上下文中为AI代理执行确定故事的大小
|
||
- 强制性：提出完整的故事序列，并询问：“这个故事序列旨在最小化对您现有系统的风险。鉴于您项目的架构和约束，这个顺序是否合理？”
|
||
- 故事必须在逻辑上是连续的，并明确识别出依赖关系
|
||
- 每个故事都必须在保持系统完整性的同时交付价值
|
||
template: |
|
||
**史诗目标**：{{epic_goal}}
|
||
|
||
**集成要求**：{{integration_requirements}}
|
||
sections:
|
||
- id: story
|
||
title: "故事1.{{story_number}} {{story_title}}"
|
||
repeatable: true
|
||
template: |
|
||
作为一个{{user_type}}，
|
||
我想要{{action}}，
|
||
以便{{benefit}}。
|
||
sections:
|
||
- id: acceptance-criteria
|
||
title: 验收标准
|
||
type: numbered-list
|
||
instruction: 定义既包括新功能又包括现有系统完整性的标准
|
||
item_template: "{{criterion_number}}: {{criteria}}"
|
||
- id: integration-verification
|
||
title: 集成验证
|
||
instruction: 确保现有功能保持不变的具体验证步骤
|
||
type: numbered-list
|
||
prefix: IV
|
||
items:
|
||
- template: "IV1: {{existing_functionality_verification}}"
|
||
- template: "IV2: {{integration_point_verification}}"
|
||
- template: "IV3: {{performance_impact_verification}}"
|