邮件里有人催功能，群里有人换一种说法提同一个问题，访谈笔记又记录了另一种使用场景。产品负责人需要的不是再多一份摘要，而是能回答：这些反馈是否在说同一个需求，谁受到影响，为什么要做，以及决定之后怎样回到原始依据？
Busa Feedback 是把用户原话、聚类后的需求和路线图提案放到同一工作台的 Busabase 模板。Agent 整理材料、归并需求、提出建议，负责人在界面里检查证据和取舍，再决定下一步。
可以先从一份自有反馈导出或手工记录开始。无需把所有渠道一次接齐，也不应把演示数据当作真实用户反馈。
安装后先确认产品和来源
打开Busa Feedback 模板页，登录后选择目标 workspace 安装。先确认使用的是哪一个团队空间，再查看模板的工作台与说明；演示界面展示的是示例状态，不是你的采集结果。
初始化需要产品名称与标识、实际渠道和采集方式、评分权重及路线图分栏。来源可以是自有客服邮件、社群、应用商店反馈、调查或访谈；连接、导出或其他 Agent 的交接要分别准备。模板不会仅凭一个来源名称就自动获得平台权限。
若环境缺少模板声明的依赖，先完成对应连接或安装，再执行写入。不要把未接通渠道写成已覆盖。密钥保留在安全配置中，来源表只记录环境变量名称等必要信息。
模板页原始 inbox 界面（英文演示数据，不是真实客户反馈）。 ↗ busabase.com
八张表把证据和决定分开保存
模板源码声明八个 Base：products 管产品，sources 管来源，feedback 留原始反馈，requests 管归并需求，roadmap 管当前路线图，proposals 放待决策提案，sync-log 记录处理运行，settings 保存评分与分栏设置。
最关键的关系是原话到需求、需求到提案、提案到路线图结果。feedback 保留文本、时间、来源入口、用户上下文和 request-id；requests 保存问题陈述、方案摘要和代表反馈。负责人应能从一个需求回到原话，而不只看到 Agent 写的概括。
这让“用户要什么”和“团队决定做什么”可以分别保存。一个清晰的问题可以暂不安排；一条紧急抱怨也可能是需要修复的缺陷，而非新功能需求。
先让同一条反馈只进入一次
准备导入时，source 描述来源，items 保存稳定的 external_id、原文、收到时间、可用的 permalink 与用户信息。ingest_feedback.mjs是原始反馈的统一入口，省略--apply先查看 dry-run，再在已授权范围内应用。
去重键由来源标识和 external_id 构成，形成fb-<source_id>-<external_id>。同一来源重复导入不应多算一条。跨渠道转述仍需要 Agent 检查：不同 external_id 不自动证明是不同用户或独立需求。
只导入自己产品、自己有权使用的渠道材料。保存必要文本和安全来源链接，不把整份平台响应、密钥或无关个人信息堆进需求表。对于缺来源或无法确认的材料，标明缺口后再判断是否纳入。
模板页原始 requests 界面（英文演示数据，不是真实客户反馈）。 ↗ busabase.com
聚类时保留用户真正的问题
可以给 Agent 这份指令：
读取本轮新增反馈，按产品和底层使用问题归并。保留代表原话及来源；相似措辞但目标不同的反馈不要硬合并。为每个需求写问题陈述、建议范围和待确认项，关联原反馈。把缺陷线索、垃圾信息和功能需求分开，给出聚类提案，先展示会修改的记录。
聚类是 Agent 的分析工作，apply_clusters.mjs负责验证和写回分配结果。feedback 的 new、clustered、ignored、insight表示材料整理状态；requests 的 candidate、roadmap、declined、needs_info表示需求处理状态。
频次和 weighted-score由关联 feedback 在读取时动态计算，不能让 Agent 手填一个漂亮分数。按schema，权重分是关联反馈 user-weight 的总和。权重设置体现团队自己的取舍，不能把它当成已经证明的商业收益或天然优先级。
在路线图界面审核建议与草稿
当需求值得采取行动时，Agent 提出 promote、decline、merge 或 changelog 类提案，附理由、证据及可编辑草稿。负责人在 Roadmap 界面读原话、检查合并是否合理、修改草稿，并选择批准、要求修改或阻塞。
模板 proposals 表中的 approved 是业务决定。它与 Busabase 底层 ChangeRequest 是否已合并不同。Change Requests 文档说明实际写入遵循权限：有 write 权限可即时合并，提案专用权限则等待审核。不要把两种状态混为“已完成”。
要求修改时，review-note应指出要改的范围和理由。Agent 据此修订并返回 needs_review。把人工判断保存在需求和提案记录中，下一轮才能沿用决定，而不是从零重新猜测。
模板页原始 roadmap 界面（英文演示数据，不是真实客户反馈）。 ↗ busabase.com
批准不等于已经通知用户
execute_decisions.mjs默认 dry-run，先列出准备执行的计划；确认后加--apply。源码把路线图调整与重复需求合并归为内部操作，对外回复和发布说明只标记为handoff_ready。脚本本身不会发送消息或发布更新日志。
因此，提案 done也不自动证明用户已收到回复。真正的发送、文档更新或公开发布，要交给对应工具，在匹配的明确授权下完成，再记录结果。先看清这次批准的是内部取舍、回复草稿还是实际发送。
用一批真实反馈验收一轮
先验证重复导入不会增加同一反馈、需求详情能回到原话、计数随关联变化、人工修订会保存、批准后的内部动作和外部交接能区分。无需等全渠道覆盖后才开始。
工作台的价值在于让产品判断可解释：当团队说“先做这个”或“暂时不做”，可以展示支持它的反馈、负责人的理由和后续动作。先用一份有权限的导出走通这条链，再逐步增加渠道。
导入真实反馈前，可先核对模板安装与审核边界，确认哪些结构和内容已生效。