需求模糊
客户反馈平台
/roundtable --prototype pencil --roles product,data,developer,qa“我们做个客户反馈平台吧，最好还能分析一下，业务和产品都能看。”
把“做个平台”这种方向性表达，收敛成 MVP 页面、数据模型、权限边界和验收标准。
从模糊输入到确定性结果
这类问题进入圆桌后，会先把原始表达拆成目标、范围、约束、风险，再生成能真正交付的产物。
原始问题
“我们做个客户反馈平台吧，最好还能分析一下，业务和产品都能看。”
→
圆桌拆解
目标
建立一个 MVP 反馈收集与处理系统，先解决提交、查看、流转和基础统计。
范围
反馈表单 / 后台列表 / 反馈详情
风险
权限边界不清 / 状态历史缺失
→
最终产物
- 页面清单
- 数据模型
- Prototype Handoff
- 任务拆解
产物快照
同一个场景进入圆桌后，通常会同时生成给人看、给执行层看、给外部工具看的三类结果。
Human Report
给人看的结论摘要
- 建立一个 MVP 反馈收集与处理系统，先解决提交、查看、流转和基础统计。
- 权限边界不清
- 状态历史缺失
Execution Method
给执行层的任务、验证计划和 Superpowers 执行方法
- 反馈表单
- 后台列表
- 页面清单
- 数据模型
External Handoff
给 Pencil、Lovable、GitLab 或其他系统的输入
- Public Feedback Form
- Admin Feedback Dashboard
- Task split for MVP pages
- Permission boundary checklist
交付物示例
这些不是完整文件，而是更接近真实输出形态的片段，帮助用户快速理解结果长什么样。
Human Report
markdown
## 核心结论
- 先做提交、后台列表、状态流转、基础统计四条主路径
- 后台必须区分管理员与普通处理人
- 本轮不做复杂报表和多租户Prototype Handoff 示例
markdown
## Product Goal
Build a customer feedback workflow for teams to collect, triage, and track feedback.
## Pages
- Public Feedback Form
- Admin Feedback Dashboard
- Feedback Detail
- Analytics OverviewGitLab Issue 示例
markdown
## Scope
### In Scope
- feedback form
- admin list and detail
- status history
- basic analytics
## Acceptance Criteria
- [ ] AC-001: Admin can update status
- [ ] AC-002: Status history is preserved为什么模糊
反馈平台只是方向，不等于需求。没有说明首期做哪些页面、谁来用、权限怎么分、分析做到什么程度。
建议专家
产品专家数据专家开发工程师QA
目标
建立一个 MVP 反馈收集与处理系统，先解决提交、查看、流转和基础统计。
主要产物
- 页面清单
- 数据模型
- Prototype Handoff
- 任务拆解
- 验收标准
范围
- 反馈表单
- 后台列表
- 反馈详情
- 状态变更
- 基础统计页
约束
- 首期不做复杂 BI
- 不做多租户
- 优先 Web 端
风险
- 权限边界不清
- 状态历史缺失
- 统计口径不一致
执行流程
Gate CheckContext PackExpert SelectionGenerate Handoff