34 篇博文 含有标签「product」

一家中型项目管理公司的产品副总裁，花了三个季度的工程团队路线图来构建 AI 助手。上线六个月后，每周活跃使用率只有 4%。问她为什么要做：「竞争对手发布了一个，董事会问我们什么时候跟上。」这是一个用产品战略包装起来的恐慌决策——而且这种情况现在到处都是。

4% 不是个例。一个客户成功平台在四个月后，AI 生成通话摘要的采用率是 6%。一个物流 SaaS 添加了 AI 路线优化建议，点击率 11%，实际操作率 2%。一个 HR 平台推出了 AI 政策问答机器人，火了两周，然后跌落至 3% 后趋于平稳。这个规律已经稳定到可以命名了：发布 AI 功能，眼看它被忽视，十八个月后悄悄下线。

默认的解释是 AI 不够好。有时确实如此。但更多时候，模型没有问题——用户压根就没找到这个功能。

你的团队在六个月前发布了一项由 AI 驱动的摘要功能。采用率停滞在 8% 的用户。模型调用每月耗资 4,000 美元。构建该功能的工程师已经调到了另一个团队。现在，模型提供商正在涨价。

所有的直觉都在告诉你：砍掉它。但事实证明，停掉一个 AI 功能要比停掉任何其他类型的功能都难得多——大多数团队都是在退役过程中，当合规问题开始出现、核心用户开始反抗时，才以惨痛的方式意识到这一点的。

这是一份在发布功能之前就应该存在的指南，但在你盯着那些明显指向退出的使用率图表时，它最为有用。

大多数 AI 产品团队都会遇到这样一种场景：某位领导层成员询问新的文案生成模型是否比旧的好。团队运行了评估套件，准确率数据看起来不错，于是发布了模型。三周后，营销团队悄悄换回了旧模型，因为新模型“听起来不对劲”。准确率指标是真实的，只是他们衡量错了对象。

这就是 AI 品味问题。只要你的输出是主观的——文案创作、设计建议、创意内容、语气调整、风格推荐——它就会出现。当没有客观的基准事实（Ground Truth）时，传统的机器学习评估框架会给你一种虚假的自信。而大多数团队对于该如何应对并没有系统性的方案。

大多数工程团队把系统提示词当作配置文件对待——需要快速迭代的技术字符串，存储在环境变量中，部署时的仪式感和修改一个超时值差不多。系统提示词有内联注释。错误提示一条也没有。能力披露就是产品经理在上线当天往 Notion 文档里打的那段话。

这正是整整一类 AI 产品故障的根源——这类问题不会出现在你的评估套件里。模型回答了问题，延迟没有问题，JSON 验证通过了。但用户在三次会话之后就停止信任这款产品，周活跃用户曲线再也没能回升。

缺失的那门学科叫对话设计。它影响输出质量的方式，大多数工程监控在架构上是盲目的。

大多数个性化系统是围绕一个飞轮构建的：用户进行互动，你学习他们的偏好，你展示更好的推荐，他们从而进行更多互动。随着数据的积累，飞轮转得越来越快。问题在于，飞轮需要速度才能产生升力——而新用户完全没有速度。

这就是冷启动问题。而且它比大多数团队在首次发布个性化功能时所认识到的更为危险。一个新用户在到达时没有任何历史记录，没有信号，通常还带着怀疑的先验预期：“AI 并不了解我。”你大约有 5 到 15 分钟的时间来证明并非如此，否则他们就会形成一种定论，决定他们是否会留得足够久，以产生那些能让你真正帮助到他们的数据。如果这个窗口期表现糟糕，高达 75% 的新用户会在第一周弃用产品。

冷启动问题不是数据问题，而是初始化问题。工程上的问题是：在缺乏历史记录的情况下，你应该注入什么？

你发布了一个 AI 功能。模型在你的留出集（holdout set）上达到了 92% 的准确率。你把这个结果展示给产品 VP、法务团队和客户成功主管。每个人都点头表示认可。功能上线了。

三个月后，一个你没有专门测试过的客户群体正面临 40% 的错误率。法务部门在提问。客户成功团队正在处理升级投诉。产品 VP 想知道为什么没有人预警。

92% 这个数字在技术上是正确的。但在作为决策输入时，它几乎是毫无用处的 —— 因为整体准确率恰恰掩盖了那些最重要的信息。

你的工程团队已经开发文档摘要生成器三个月了。规范要求：“摘要生成器应返回准确的摘要。”你发布了它。用户抱怨摘要有一半时间是错误的。事后分析显示，在发布前没有人能以可测试的方式定义“准确”的含义。

这是 AI 功能开发的标准轨迹，之所以会发生，是因为团队将为确定性软件构建的验收标准模式，套用到了本质上是概率性的系统上。由 LLM 驱动的摘要生成器没有单一的“正确”输出 —— 它有一系列的输出分布，其中一些是可以接受的，另一些则不然。二元的通过/失败规范无法映射到分布上。

这个问题不仅是哲学上的，它还会导致切实的痛苦：功能发布时质量门槛模糊，回归测试在用户发现之前难以察觉，产品和工程团队在功能是否“完成”上无法达成一致，因为没有人规定对于随机系统来说，“完成”意味着什么。这篇文章将介绍真正有效的模式。

你的高级用户就是你的金丝雀。当你发布新的模型版本或更新系统提示词时，整体评估指标会向上走——任务完成率提升，幻觉评分下降，A/B 测试宣告胜利。随后，你最老练的用户开始提交 bug 报告："以前它就直接做 X，现在先给我说一堆。""格式变了，导致我的下游解析器报错了。""我没法让它保持角色了。"他们不是在臆想。你发布了一次回归，只是仪表盘里没有显示出来。

这正是 AI 产品开发的核心悖论：受行为漂移伤害最深的用户，恰恰是那些在理解系统特性上投入最多的人。他们围绕特定的输出模式构建了工作流，他们学会了哪些提示词能可靠地触发哪些行为。当你更换模型时，不只是发布了更新——你悄悄地让他们数月的校准工作失效了。

在传统软件中，发布功能以合并代码（merge）告终。单元测试通过。集成测试通过。QA 签字认可。你切换标志（flag），除非在生产环境中出现 bug，否则你就可以继续接下来的工作。这个功能就“完成”了。对于 AI 驱动的功能，那个时刻并不存在 —— 如果你假装它存在，你就是在累积稳定性债务，这最终会演变成用户信任问题。

原因很简单，但很少有人围绕它进行设计：确定性软件对于相同的输入每次都会产生相同的输出。AI 功能则不然。这并非因为 bug，而是因为其行为由一个存在于代码库之外的模型定义，该模型基于反映不断变化的世界的数据进行训练，并由那些随着看到更多可能性而不断提高期望的用户使用。

有一种特定的失败会在 AI 功能有机会证明自己之前就将其扼杀。这看起来不像是技术故障——模型架构是合理的，评估分数也不错，功能也发布了。但采用率停滞不前，用户流失，六个月后团队悄悄降低了该功能的优先级。复盘时的诊断是：“数据不足”。

这就是冷启动陷阱。AI 功能随着参与数据的增加而改进，但用户在功能好到足以产生用处之前不会参与。这种循环依赖不是一个可以解决的数学问题——它是一个伪装成工程问题的产品设计挑战。大多数团队都带着同样的错误计划跳了进去：先收集数据，后发布机器学习。

几乎每一个全球部署的 AI 产品中都潜伏着一种隐蔽的失败模式。工程师本地化了 UI 字符串，通过翻译 API 运行模型输出，让母语者抽查几个回复，然后就发布了。该产品在技术上是多语言的，但在文化上并不称职。东京、利雅得和成都的用户收到的输出在语法上是正确的，但在文化上是错误的——这些回复表现出的不尊重、困惑或不信任，是团队在汇总指标中永远无法看到的。

研究结果是明确的：测试的每一个主要大语言模型（LLM）都反映了讲英语的新教欧洲社会的价值观。针对来自 107 个国家的代表性数据进行模型测试的研究发现，没有任何一个模型与非洲、拉丁美洲或中东地区人们建立信任、表达尊重或解决冲突的方式相契合。翻译修补了表面，但底层的校准仍然是西方化的。

Slack 发现，交换了 2,000 条消息的团队以 93% 的比率转化为付费用户。这一洞见回头看似乎显而易见——活跃团队会留下来——但不那么显而易见的是工程层面的后果：Slack 围绕让团队达到这一消息数量来构建整个引导流程，而不是围绕功能演示或能力说明。他们通过使用 Slack 来教会用户 Slack。

AI 功能面临同样的问题，但更难。不存在"发送第一条消息"这样的等价物，因为能力层面是不可见的。面对空白提示框的用户对可能性没有任何直觉。这就是魔法时刻问题：你的产品拥有变革性能力，但用户在亲眼见到之前无法想象，而除非你设计好路径，否则他们永远看不到。

数据让这个问题变得紧迫。2024 年，17% 的公司放弃了大部分 AI 计划。2025 年，这个数字跳升至 42%——单年增长 147%。技术在进步；引导没有。