AI 能读完所有 VOC，不等于它能稳定判断“哪个问题最大”。如果每次分析都让模型临时发明标签，同一个问题会被拆成多个近义词，问题排名也可能随提问方式改变。更可靠的做法是双轨：用稳定、可审计的 Feedback Taxonomy（反馈分类体系）负责计数，同时让 AI 在“未归类区”发现新问题；分类变更必须经过验证、版本记录和历史重算，才有资格进入增长决策。
用户反馈天然是散的：应用商店写“连不上”，客服里说“总在转圈”，VOC 里可能记录成“配网失败”，设备日志又显示超时。人能感觉这些话有关，但要回答“这个问题本周到底有多少、集中在哪个版本、修复后是否下降”，就需要一套稳定的分类语言。
Feedback Taxonomy（反馈分类体系），大白话是：先规定产品问题有哪些“抽屉”、每个抽屉收什么和不收什么，再让人或 AI 把每条反馈放进去。它不是一串随手打的标签，而是一套有层级、有边界、有版本的共同语言。
生活类比是超市盘点。店员当然能看懂苹果、红富士和切片苹果，但如果有人记“水果”、有人记“苹果”、有人记“红色水果”，月底就无法知道苹果到底卖了多少。AI 自由总结也会出现同样问题：单条解释很聪明，合起来却重复、漏算、不可比较。
Momcozy APP 的待验证例子是设备连接反馈。“首次发现不到设备”“权限未开”“连接中断”“已连接但无法稳定使用”可能都被粗略归为“连接问题”；反过来，同一个“连接超时”也可能被拆成“配网慢”“绑定卡住”“设备离线”。分类太粗，找不到可行动节点；分类太碎，真实问题被稀释。分类体系要回答的不是“这句话听起来像什么”，而是“它在用户旅程哪个节点、属于哪类失败、什么证据可以区分”。
真正难点是稳定与变化同时存在：分类永远不变，会漏掉新版本、新设备和用户新说法；分类随模型每次自由变化，又无法做趋势。因此最小可靠结构应有两个区域：受控分类区负责稳定计数，发现队列接住无法归类和新兴主题。新主题先积累证据，再由人批准新增、合并或拆分，并保留旧标签到新标签的映射。
Enterpret：同一问题被四个近义标签拆开，问题规模就会凭空缩水
大模型自由抽取主题适合探索，不适合直接支撑优先级；要做趋势和排序，必须先有固定标签空间。
关键事实
Enterpret 在 2026 年 7 月的复盘中称，其曾遇到客户只能把平台数字当作实际问题量的 30%–40% 来参考。文章解释了一个核心故障：模型可能把同一问题分别写成“login issues”“problems logging in”“sign-in failures”“can’t access account”，每个标签单看都合理，但问题量被拆散。它用 653,456 条公开 Duolingo 反馈构造演示分类，采用受控层级：产品区域、功能、具体能力，再接用户表达的主题与意图；模型只能从已有路径中选择，而不是每条反馈重新发明类别。
文章还提出“两层、两种语言、两个变化速度”：产品结构来自帮助文档和产品表面，变化较慢；用户主题来自真实反馈，变化更快。无法稳定归类的内容进入 Miscellaneous（暂未归类区），只有当数量和证据足够时才“毕业”为正式主题。
编辑视角它证明了什么： 这证明稳定分类可以把自由文本变成可重复计数，也给 Agent 一个有限、可审计的动作空间。但这是 Enterpret 对自家方法的复盘和公开数据演示，不是独立实验；固定分类能提高一致性，不等于分类语义一定正确，更不能证明排第一的问题修完就会带来留存增长。分类回答“用户在说什么、多少人在说”，因果和资源优先级仍需行为数据、版本证据与实验验证。
Enterpret Adaptive Taxonomy：分类也会漂移，所以改动要像产品发布一样治理
“让分类自动进化”不能等于 AI 自己改完自己生效；安全机制应是先发现、再校验、可预览、可回滚、最后重算历史。
关键事实
Enterpret 的 Adaptive Taxonomy 会读取产品表面、帮助文档、更新记录、缩写和客户语言，持续发现新主题。其编辑机制允许重命名、合并、拆分、移动和删除节点，但改动先进入草稿；系统在提交前检查近义重复、命名冲突、语义重叠与结构问题，复杂合并会先建议调整父节点。只有人保存后才进入生产，草稿可以回滚，受影响记录会重新分类。
另一家 CX 平台 Chattermill 在 2026 年 7 月的指南中也强调，分类体系需要明确所有者、定期审查并合并重叠类别；同时提醒静态分类会因新功能、故障和用户新语言而过时。两家供应商的方法细节不同，但共同指向一个现实：分类不是一次性清洗项目，而是一套持续治理的测量基础设施。
编辑视角它证明了什么： 这证明“发现漂移—提出改动—提交前检查—人工批准—历史重算”已经能被做成产品流程。它没有证明自动发现的新主题都值得进入正式分类，也没有公开分类变更前后的精确率、召回率或业务增量。尤其在母婴、儿童、健康和设备语境中，少量高风险问题不能因为数量不足而永远留在杂项；严重度和频次必须是两条独立轴。
先认识这个人
Asha Sharma 负责微软 AI 平台产品战略，此前担任 Instacart COO，也负责过 Meta Messenger 等产品。她能看到大量企业怎样落地 AI。2025 年 8 月的 Lenny 访谈里，她提出 Product as Organism（产品如生命体）：AI 产品不再只是发布后偶尔优化的静态成品，而会持续吸收互动、评测和结果，再调整模型与产品行为。
核心机制：产品的 KPI 变成“消化反馈并形成结果的速度”
访谈约 4:45–7:43，Asha 把关键能力称为 product metabolism（产品代谢）：系统能否吸收数据、理解奖励信号、产生结果，再通过严格 A/B test 验证。她明确说，现实里不是一个万能闭环，而是多条并行的“装配线”：不同任务需要不同数据、奖励和验证。
她举了微软医疗听写产品 Dragon 的例子：在专家标注约 60 万次医患互动后，持续优化使其所述字符接受率从不同运行中的约 30%–60% 提升到约 83%。这说明高质量、任务相关的反馈，可能比只增加通用模型能力更有价值。但“字符被接受”仍是代理指标，不等于医疗质量或患者结果；这组数字也来自访谈中的公司自述，不能直接外推。
过去怎么做，AI 改变了哪一步
过去 VOC 流程常是：月底汇总标签、人工做报告、开会决定要不要修。AI 可以持续读取多渠道反馈，发现无法归类的新说法，检查旧分类是否重叠，并生成带原文证据的变更候选。变化不只是“报告更快”，而是测量体系能随着产品和客户语言更新。
但这里最容易误解的是：更多互动不会自动让产品变好。若奖励信号是点击、会话结束或五星评价，系统会学习放大这些活动指标；若分类本身把多个问题混在一起，反馈越多，错误计数越稳定。Asha 的“生命体”隐含了三个前提：反馈可解释、目标可验证、系统有评测与观察能力。缺少这些，只是一个会快速吸收噪声的系统。
我们能借什么
最值得借的不是“让 Agent 自己维护全部 VOC”，而是把 VOC 分类当作产品学习回路的一部分：稳定分类负责观察趋势，新主题队列负责适应变化，人工负责语义、严重度与边界，修复或实验结果再回来验证“这个分类是否真的对应一个可改变的用户问题”。这才是“loop，不是 lane”：不是客服打标签、产品看报告、数据画图各做一段，而是同一条证据链对最终结果负责。
以“VOC 分类治理 Agent”为例，完整链路如下。
系统读取什么：公开商店评价、经授权并脱敏的客服与 VOC 文本、APP / 设备 / 固件版本、产品帮助文档、现有分类定义与反例、人工严重度判断、历史修复和实验结果。母婴、儿童、健康与设备数据只按当前问题最小化使用，不默认跨场景拼接成营销画像。
形成什么判断：先把反馈放入受控分类，并给出原文证据与置信度；无法明确归类时进入发现队列。系统再判断某个新主题是近义重复、旧分类边界不清、新版本问题、真正的新问题，还是样本不足。频次与严重度分开：低频高风险不能被数量排序淹没。
能做什么：自动分类、发现近义重复、监测“杂项”增长、提出新增/合并/拆分候选、展示变更会影响哪些历史趋势，并在批准后重算受影响记录。它可以生成调查卡，但不能仅凭反馈量自动改路线图、触达用户或修改生产策略。
如何看结果并更新策略：看人工抽检的一致性、无法归类率、分类漂移、跨渠道重复、版本关联，以及修复后同类反馈和真实任务结果是否共同改善。如果标签量下降但稳定连接没有改善，可能只是分类或渠道变化；如果新主题持续增长且集中于同一版本，才提高调查优先级。已证伪的主题合并和无效实验也要进入记忆。
何时交给人：新分类定义、严重度边界、健康或儿童语境、设备安全、隐私授权不清、少量高风险反馈、跨渠道身份关联、资源优先级与所有生产动作，都交给人。AI 自动打标签属于 AI-assisted Operations（AI 辅助运营）；系统持续发现分类漂移、提出可审计变更、在权限内重算，并用后续结果更新问题与策略，才接近 AI-native Growth System（AI 原生增长系统）。
场景一：设备绑定与稳定使用。 待验证假设是，“无法连接”可能混合权限、发现、绑定、连接中断和稳定性问题。可以先建立窄分类：旅程节点 × 失败类型 × 证据状态，再把无法判断的反馈留在“连接问题—未定位”，而不是强行猜。不能把客户端一句“失败”直接归因于设备，也不能只按数量排序；涉及安全的少量反馈必须单独升级。最先需要的证据，是 15–20 条公开或脱敏样本能否被两个人按同一规则稳定归类。
场景二：AI 助手与 BBM/VOC。 待验证假设是，“答案不满意”可能来自知识错误、没有理解任务、工具失败、表达不清或本应转人工。可以让 Agent 提候选分类和引用，但“高风险必须接管”“结果未知不能算解决”等边界由人定义。不能把敏感会话复用为个性化营销画像。最先验证的不是自动分类率，而是不同类别是否对应不同可行动方案：修知识、修工具、补产品能力、优化表达或加强接管。
场景三：商店评价与产品趋势。 公开评价适合发现跨版本的新说法，但评论者不是全体用户的随机样本，平台星级也容易受非产品因素影响。可以用统一分类比较问题结构与版本线索，不能由评论占比直接推断总体发生率，更不能把五星比例当核心增长判断。最值得看的是：低星问题的绝对量、严重度、产品线结构和可验证版本线索，是否与行为或客服证据互相支持。
可以借什么、不能照抄什么：可以借固定标签空间、杂项发现队列、草稿审核、版本映射和历史重算；不能照抄“分类越自动越好”。Momcozy 的用户语言、设备组合和风险结构更复杂，分类体系首先要服务可行动判断，而不是追求漂亮的自动化覆盖率。
- Feedback Taxonomy｜反馈分类体系：一套稳定、有层级、有边界的反馈“抽屉”。Momcozy 例子：把连接问题按发现、绑定、连接、稳定使用分开，而不是都叫“连不上”。
- Controlled Vocabulary｜受控词表：模型只能从批准的标签中选，不能每次临时造词。Momcozy 例子：“配网失败”和“绑定卡住”若指同一节点，必须归到同一正式标签。
- Taxonomy Drift｜分类漂移：产品和用户语言变化后，旧分类开始漏掉或误装新问题。Momcozy 例子：新设备上线后出现旧体系没有的故障表达，持续堆进“其他”。
- Discovery Queue｜发现队列：暂时无法可靠归类、等待积累证据的新主题池。Momcozy 例子：少量新版本异常先保留原文和版本，不急着创建正式大类。
- Backfill / Reclassification｜历史回算 / 重新分类：分类规则改变后，用新旧映射重算历史，避免趋势断裂。Momcozy 例子：把一个重叠的“连接慢”标签拆开后，历史反馈也按新规则重算并标明版本。
做一次“VOC 分类能不能稳定计数”的小测试，不改生产、不触达用户：
- 选 15 条公开商店低星评价，隐藏用户名，只保留产品、版本线索和原文；
- 先写 5–8 个窄标签，每个标签补一句“收什么”和“明确不收什么”；
- 把 15 条评价归类，允许选择“未定位”，不要强行填满；
- 找出两个最容易让同一条反馈来回摇摆的标签，决定合并、重写边界，还是补一个旅程节点；
- 产出一页“标签—边界—反例—未定位—高风险升级”分类卡。
完成后能更新的判断是：我们现在拥有的是一批看起来整齐的标签，还是一套能稳定计数、发现新问题并支撑行动的测量语言？最后只回答一个具体问题：Momcozy APP 当前哪两个 VOC 标签最可能只是同一个用户问题的近义词，正在把真实问题量拆小？