Tapd Product Discovery

TAPD 产品前置流程

概述

处理 PRD 之前的需求工作：想法记录、需求来源整理、用户调研、竞品分析、业务分析、PRD、页面原型 Spec、BKUI HTML 原型、原型评审和产品评审。流程从产品父单开始，按“想法记录 -> 产品调研 -> PRD -> 页面原型 Spec -> BKUI HTML 原型 -> 原型评审 -> 产品评审 -> 角色拆单”推进；产品方案通过后再按实际需要创建设计、前端、后端子单。

前端和后端子单创建后，继续使用已有研发流程处理；它不替代 tapd-story-clarification、tapd-story-evaluation、tapd-story-pipeline。

适用场景

• 用户只有一个想法、老板需求、用户反馈、竞品观察或业务问题，还没有完整 PRD。
• 用户希望先做用户调研、竞品分析、业务分析或原型，再整理成 PRD。
• PRD 已准备好，需要生成页面原型 Spec、BKUI HTML 原型，供产品、设计、前端评审。
• 已有产品方案通过评审，需要按设计、前端、后端拆 TAPD 子单。
• 需要说明产品、设计、前端、后端分别使用哪些 TAPD 状态。

不适用场景

• PRD、设计稿和接口文档都已确认，只需要研发实现：使用 tapd-story-pipeline。
• 已有标准化需求文档，只需要澄清或补充验收标准：使用 tapd-story-clarification。
• 已有父需求，需要按用户故事拆分和评分：使用 tapd-story-evaluation。
• 只处理代码、构建、发布或 Code Review：使用对应研发 Skill。

前置条件

• TAPD MCP 服务可用。
• 用户提供 workspace_id，或项目根目录 project.json 中存在 workspace_id。
• 创建或更新 TAPD 单据前，先向用户展示计划变更，确认后再调用 MCP。

输入

状态流转

产品父单

backlog -> doing -> for approve -> approved -> done

设计子单

backlog -> todo(已规划) -> designing -> design approved -> done

前端和后端子单

backlog -> for approve -> approved -> todo(已规划) -> doing -> for test -> tested -> for gray -> grayed -> done

前端和后端子单只记录各自研发进度，不再放产品调研和 PRD 评审内容。

执行流程

1. 判断当前入口

先判断用户处于哪一段：

2. 准备产品父单

2.1 确定 workspace_id 和 owner

优先级：

1. 用户显式提供
2. project.json
3. 询问用户

2.2 已有产品父单

用户提供产品父单 ID 时，调用 TAPD MCP stories_get 读取单据：

workspace_id: <workspace_id>
id: <产品父单 ID>
with_v_status: "1"

读取后检查：

• 单据是否存在
• 是否为父单或可作为父单
• 当前状态是否适合继续推进

2.3 没有产品父单

没有父单时，先整理创建计划并请用户确认。确认后调用 stories_create：

workspace_id: <workspace_id>
name: <需求名称>
description: <产品父单初始描述>
with_v_status: "1"
v_status: "backlog"
owner: <owner>
creator: <owner>
priority_label: <High|Middle|Low>
created: <当前时间>

父单初始描述使用 references/product-requirement-template.md。

3. 产品调研与 PRD

执行前读取 references/product-discovery-guide.md，按需求复杂度选择要补的内容：

• 需求来源和触发背景
• 目标用户和使用场景
• 当前问题和业务影响
• 用户调研结论
• 竞品或替代方案分析
• 项目内约束
• 产品目标和衡量指标
• 原型、流程或交互草图
• PRD 范围、验收标准和非目标

如果用户还没有开始调研，先输出调研提纲并推进产品父单到 doing。如果用户已经提供调研材料，直接整理为产品文档。

产品文档保存到：

docs/reqs/product/<产品父单短标题>.md

文件名从需求名称提炼，保留 4-12 个中文字符；重名时追加需求短 ID。

4. 页面原型 Spec 与 HTML 原型

PRD 完成后，先判断是否需要页面原型。

需要页面原型的场景：

• 新增或调整页面、表格、表单、弹窗、抽屉、图表
• 需要产品、设计、前端在拆单前确认页面结构
• PRD 中已有多个页面或复杂交互

可跳过的场景：

• 纯后端能力
• 纯配置或脚本任务
• 只改文案且不影响页面结构
• 已有可复用设计稿或原型链接

需要时读取 references/prototype-spec-template.md，生成页面原型 Spec，保存到：

docs/reqs/product/<产品父单短标题>.prototype.md

用户确认页面原型 Spec 后，读取 references/bkui-html-prototype-guide.md，生成 BKUI HTML 原型，保存到：

docs/reqs/product/prototypes/<产品父单短标题>-preview.html

原型评审通过后，再进入产品评审和角色拆单。跳过页面原型时，要在产品父单中记录原因。

5. 产品评审

当 PRD 已准备好，且原型完成或已记录跳过原因：

1. 向用户展示即将回写的产品文档路径和状态变更。
2. 用户确认后，读取本地产品文档内容，调用 stories_update 回写到产品父单 description。
3. 将产品父单状态推进到 for approve。

评审通过后，用户可以直接说“产品评审通过”或提供评审结论。确认后将产品父单推进到 approved。

6. 角色拆单

产品父单为 approved 后，读取 references/role-ticket-splitting.md，判断需要哪些子单。

简单需求可以跳过某些角色。每个跳过项都要在产品父单中写明原因。

子单创建字段

调用 stories_create 前，先展示子单计划并请用户确认。确认后逐一创建：

workspace_id: <workspace_id>
name: <角色前缀 + 子单名称>
parent_id: <产品父单 19 位 ID>
description: <角色子单说明>
with_v_status: "1"
v_status: "backlog"
owner: <对应负责人，未知则使用 owner 并标注待分配>
creator: <owner>
priority_label: <继承产品父单或用户指定>
created: <当前时间>

角色前缀建议：

• [设计] <需求名称>
• [前端] <需求名称>
• [后端] <需求名称>

7. 回写父单并结束产品侧流程

子单创建完成后，更新产品父单描述，补充：

• 子单列表和链接
• 未创建角色子单的原因
• 研发侧下一步建议

用户确认后，将产品父单推进到 done。

产品父单 done 不代表功能已上线，只代表产品侧工作完成；上线状态由前端/后端子单继续记录。

8. 输出总结

输出格式：

## 产品前置流程完成

| 项目 | 结果 |
|------|------|
| 产品父单 | #xxx，done |
| 产品文档 | docs/reqs/product/xxx.md |
| 页面原型 Spec | docs/reqs/product/xxx.prototype.md / 未生成：原因 |
| HTML 原型 | docs/reqs/product/prototypes/xxx-preview.html / 未生成：原因 |
| 设计子单 | #xxx / 未创建：原因 |
| 前端子单 | #xxx / 未创建：原因 |
| 后端子单 | #xxx / 未创建：原因 |
| 下一步 | 设计进入设计流程；前端/后端进入澄清、评估、规划、实现流程 |

与现有 Skill 的关系

错误处理

参考文件