prd-update-decisions

移植自 vfarcic/dot-ai shared-prompts/prd-update-decisions.md（MIT，Copyright (c) 2025 Viktor Farcic）。原作者：Viktor Farcic。

PRD 更新决策斜杠命令

说明

根据对话中做出的设计决策、战略调整和架构选择更新 PRD。此命令会记录尚未反映在代码中，但会影响需求、方案或范围的概念性变更。

流程概览

1. 确定目标 PRD - 确定要更新哪个 PRD
2. 分析对话上下文 - 检查讨论中的设计决策和战略调整
3. 确定决策要点 - 找出架构、工作流、需求或范围变更
4. 映射到 PRD 章节 - 确定 PRD 中哪些部分需要更新
5. 提出更新建议 - 建议对需求、方案和约束进行修改
6. 更新决策日志 - 记录新决策及其理由和影响

步骤 1：分析 PRD

询问用户要更新哪个 PRD，然后：

• 从 prds/[issue-id]-[feature-name].md 读取 PRD 文件
• 了解当前的需求、方案和约束
• 找出最可能受设计决策影响的部分

步骤 2：分析对话

检查对话上下文中的决策模式：

设计决策指标

留意表明战略变更的对话内容：

• 工作流变更：“我们把这个简化为……” “如果改成……呢？”
• 架构决策：“我认为我们应该使用……” “更好的方案是……”
• 需求修改：“其实我们不需要……” “我们还应该加入……”
• 范围调整：“我们把这个推迟……” “这比我们想的更复杂……”
• 用户体验转向：“用户会更喜欢……” “这个工作流更合理……”

具体决策类型

• 技术架构：框架选择、设计模式、数据结构
• 用户体验：工作流变更、界面决策、交互模型
• 需求：新增、修改或移除需求
• 范围管理：新增、推迟或取消功能
• 实施策略：阶段调整、优先级调整、方案修改

步骤 3：评估决策影响

针对每项已确定的决策，评估：

影响类别

• 需求影响：需要新增、修改或移除哪些需求？
• 范围影响：项目范围是扩大还是缩小？
• 时间线影响：是否影响项目阶段或交付日期？
• 架构影响：是否改变技术约束或方案？
• 代码示例影响：哪些示例、接口或代码片段会过时？
• 风险影响：是否引入新风险或降低现有风险？

决策记录格式

针对每项决策，记录：

• 决策：决定了什么
• 日期：做出决策的日期
• 理由：选择此方案的原因
• 影响：这会如何影响 PRD 的需求、范围或方案
• 代码影响：哪些代码示例、接口或代码片段需要更新
• 负责人：做出或批准此决策的人

步骤 4：更新 PRD

更新相应的 PRD 章节：

更新决策日志

• 添加已解决的新决策，并注明日期和理由
• 如果已做出决策，将未决问题标记为已解决
• 更新决策对需求和范围的影响

更新需求

• 根据设计变更修改功能需求
• 如果性能或质量标准发生变化，更新非功能需求
• 如果衡量方式或目标发生变化，调整成功标准

更新实施方案

• 如果顺序或优先级发生变化，更新各阶段
• 如果技术方案演进，修改架构决策
• 如果新增、推迟或移除功能，调整范围管理

代码示例验证与更新

• 识别过时示例：扫描 PRD，找出可能受设计决策影响的代码片段
• 接口变更：当函数签名、参数类型或返回值发生变化时，更新示例
• API 修改：当方法名称、类结构或数据格式发生变化时，修订示例
• 工作流更新：当用户交互模式或步骤顺序发生变化时，更新流程示例
• 标记以供验证：标记需要手动测试以确保仍可正常运行的代码示例

任务与里程碑更新

• 创建新任务：当决策引入现有任务未涵盖的工作时（例如，新的集成、迁移步骤或验证要求）
• 添加新里程碑：当决策显著改变项目范围或阶段划分时（例如，为延后实现的功能新增阶段，或增加交付检查点）
• 更新现有任务：当决策改变任务要求或实现方式时
• 移除或推迟任务：当范围变更或需求取消导致任务不再相关时
• 重新排列优先级：当决策改变交付顺序时

风险与依赖项更新

• 添加由设计决策引入的新风险
• 当方案发生变化时，更新缓解策略
• 当架构变更影响集成时，修改依赖项