IGNITE AI 里如何提交功能建议和问题反馈

产品团队修不了他们复现不了的东西。一星评价写「AI 烂」什么也教不会；一份带设备、步骤、坏估算截图的紧凑问题报告才会。IGNITE AI 提供应用内功能建议和问题反馈路径，好让真实的记录痛点到达正在发版的人。

最好的反馈通常来自工作流正中间的人：暗盘子上相机失败、货架上条码对不上、Friends 分享没发出去。那种上下文是金。在应用里抓住它，胜过指望一条社交评论找到对的收件箱。

本指南讲怎么写能推进的报告、怎么把 bug 和口味偏好分开，以及怎么提功能而不写第二份产品路线图。它不承诺每个想法都会上线。

Bug 对功能：老实贴标签

Bug 是相对预期行为坏掉的东西：崩溃、白屏、存错、同步失败、把你困住的界面。功能建议是新的或改进的东西：另一种导出、更聪明的默认、一条工作流捷径。

贴错标签会拖慢分诊。若你确认编辑后 Snap Track 仍存成了错餐，那是 bug。若你希望编辑器有一键「加一汤匙油」，那是功能建议——哪怕它感觉很急。

一份最低限度有用的问题报告

写清你在做什么、期望什么、实际发生了什么、能不能复现。加上系统版本、能看到的应用版本，以及屏幕名称。隐私允许时附截图或录屏——必须的话把热量模糊掉，但把报错外框留着。

注明时机：刚更新后、Wi-Fi 对蜂窝、长时间后台之后。间歇性 bug 需要频率（「10 次拍照记录里有 3 次」）。没有步骤的含糊愤怒会被搁置；精确报告会进队列。

复现拍照和扫描问题

Snap Track 问题要说清模式：餐食拍照、标签、条码、饮料，或描述/语音式输入。提到光线、确认前有没有改过，以及坏数据是不是只在保存后才出现。

条码请带上品牌和产品名，以及实体标签是否对不上。产品身份清楚时，数据库错配往往可修——报告只写「扫错了」时不行。

写出能过审的功能建议

用一句话说清要完成的工作：「我需要连续五天重记同一盒备餐，而不用重建。」然后描述你现在的绕路，以及它为什么失败。除非你在说明一条真正的死路，否则别讲界面设计课。

用你自己的一周排优先级，不是互联网心愿单。绑在坚持上的请求——更快的编辑、更清楚的份量、教练导出——通常比换皮主题更要紧。

报告里不该放什么

不要粘贴密码、恢复码或完整支付细节。不要带上 Friend 动态里别人的私人餐。不要威胁；它不会加快分诊，还可能让这条线被忽略。

避免把十件无关问题捆成一团。把崩溃和心愿单拆开，好让每一件能独立关掉。

商店评价对应用内通道

商店评价影响下载；它是很差的 bug 数据库。先在应用里提交可复现报告，再用评价表达高层情绪。若你只写评价，工程可能永远看不到你晚上 10 点撞上的那条堆栈路径。

若支持跟进，用同一结构答一次。回声原始步骤，胜过每次重写一部小说。

反馈如何塑造一款拍照优先的应用

视觉记录、标签 OCR 和社交分享，天生会在边角案例失败。真实厨房和健身房的现场报告，比实验室演示教得更多。你那件无聊的边角——镜头上的蒸汽、反光外卖、多包装酸奶——可能就是明天的修复。

这不意味着每个请求下个迭代就上。这意味着高质量信号会累积。低质量噪音拖慢所有人，包括你真正想要的功能。

IGNITE AI 想在哪收到信号

从 Profile 或帮助界面走应用内功能建议和问题反馈流程，好让元数据跟着工单走。等待时继续用 Snap Track 记；描述模式或已存餐这类兜底，往往能在相机路径失常时仍救回当天。

撞上 AI 捕获 bug 的 Premium 用户应该说出来——那些路径算力重，值得精确报告。反馈里对 Premium 门槛也要诚实：「意外被付费墙挡住」和「我付了之后估算仍错」不是一回事。

结论

好报告短、可复现，并标明是 bug 还是建议。截图和模式名称，胜过含糊的一星长文。

记录中途坏了，就带着步骤走 IGNITE AI 应用内通道——然后用一条兜底捕获路径让日记继续动，团队会用上你的信号。