Flunes问题所在：反馈从来到不了 GitHub
来自 PM、测试和支持的 bug 报告和想法散落在 Slack 会话、邮件、私信和会议里。总得有个人，通常是开发，先注意到它们，弄明白它们，再敲进 GitHub。报告会丢，会重复，或者到手时缺了能动手处理所需的细节。
在移动端 Safari 上点击支付按钮后，加载转圈持续旋转，无法完成下单。
点击支付后，加载转圈出现并持续超过一分钟，没有跳转也没有显示错误信息。
点击支付应跳转到订单确认页面，或显示可恢复的错误状态。
- apps/checkout/mobile/payment-flow.ts
- apps/checkout/components/PayButton.tsx
- src/lib/stripe/confirm-handler.ts
正是为这一段交接打造。
解法：一道入口，直通 GitHub
Flunes 给团队里研发之外的每个人一条链接来报问题或提需求。这次提交会自动变成你仓库里一条干净、带标签的 GitHub issue。AI 会把原始文字理顺，并指出代码里可能相关的位置，它是一个让 issue 保持干净的增强器，而不是主打卖点。
闭环自己合上
你的队友可以在状态页上或通过邮件回复，不用 GitHub 账号，回复会同步回 issue 的讨论里。你关掉 issue 时，他们会收到已解决的通知。没人再来追你要进展。
一条结构化的 issue 长什么样
每一次提交到达你的仓库时都已经可以直接分流。Flunes 会放上清晰的标题和描述，按类型和优先级打好标签，并附上提报人上传的截图。一条链接指回原始提交以及提交它的那位队友，于是你不用离开 GitHub、也不用在 Slack 里翻找，就能追问一句。最终的结果读起来就像一位细心的队友亲手写的 issue，带着你动手所需的细节，没有任何需要你先重新排版的东西。这种一致性，正是把反馈变成 GitHub issue 的全部意义。
GitHub 仍是唯一事实来源
Flunes 是一个收集层，不是你跟踪工具的替代品。它往 GitHub 里填东西，并不打算变成第二个让工作落脚的地方。分流、分配、里程碑和交付，都发生在你的团队本来就待着的地方，也就是你早已在用的 issue 和 pull request 里。没有要保持同步的单独看板，也没有要对账的并行待办。你不用换工具，也不用迁移任何历史记录。你只是在你早已信任的仓库前面，加上一道干净的入口，让反馈默认就落到正确的地方。
AI 做什么，不做什么
AI 接过一段啰里啰嗦的纯文字报告，把它重写成一条干净的 issue，配上合适的标题、结构和标签。它能指出你代码里可能要先看的那块区域。这就是它的边界。它不读你的源代码，也不编造细节、复现步骤或提报人从没给过的事实。如果一份报告很含糊，那条 issue 就如实保留这种含糊，而不是用猜测去填补空白。你得到的是一个可以信赖的干净起点，而不是包装成 bug 报告的虚构内容。
常见问题
不需要。你的 PM、QA、设计师和支持通过一条私密的魔法链接提反馈，不用 GitHub 账号，不用登录，也不用装任何东西。只有你（仓库所有者）用 GitHub 登录。