第1888篇：被用户骂醒的AI产品——那些我们以为"足够好"的功能

做产品最危险的状态，不是明显的失败，而是"看起来还行"。

我们的AI辅助写作功能在内测阶段拿到了4.2分（满分5分）的满意度。我们觉得不错，就上线了。

上线后第三天，用户反馈群里有人说："这功能跟鸡肋一样，有没有比没有，但加了反而碍事。"

我去看了一下具体的用户行为数据，发现这个"4.2分"的功能，80%的用户只用了一次就再也没打开。

那一刻我才意识到，我们在内测阶段测的是"用户第一次体验"，而不是"用户是否真的会持续使用"。

---

功能一：AI辅助写作——"帮倒忙"的智能建议

这是一个给用户在写邮件、报告时提供AI辅助的功能。用户在输入区打字，AI会实时分析并在侧栏给出建议：语气改进、结构优化、用词替换。

我们花了两个月做这个功能，内测时很多用户说"感觉很高端"。

但真实使用数据是：功能打开后，平均使用时长只有47秒，然后用户就关掉了。

我去访谈了十几个"只用了一次就不用了"的用户，得到的反馈让我很不是滋味：

"建议太多了，我写两句话，右边就蹦出来五六条建议，我不知道该看哪条。"

"它的建议改了之后不像我说话的方式，发给同事感觉很奇怪。"

"每次都要停下来看建议，比我自己写还慢。"

核心问题是：我们设计这个功能时，想的是"AI能做什么"，而不是"用户真正需要什么"。用户不需要一个全程指导他写作的AI，用户需要的是在自己卡住的时候得到一个提示。

我们做了一次大改版：

改版前： 实时、持续、主动地在侧栏展示建议。

改版后： 默认收起，只在用户明确触发（点击"获取建议"按钮，或者光标停留超过10秒）时展示。建议数量从5-8条压缩到1-3条最重要的。同时加了"语气偏好"设置，让AI在给建议时参考用户的写作风格。

// 改版后的触发逻辑
@Service
public class WritingAssistantService {
    
    /**
     * 计算是否应该主动推送建议
     * 只在用户明显停滞时才主动出现，而不是持续存在
     */
    public boolean shouldProactivelySuggest(WritingSession session) {
        // 条件1：用户停止输入超过8秒（思考中，可能需要帮助）
        boolean idleLongEnough = session.getIdleDurationMs() > 8000;
        
        // 条件2：最后一段话有语法或逻辑问题的信号词（比如"但是...但是"、"然而...然而"）
        boolean hasStructureIssue = detectStructureIssue(session.getLastParagraph());
        
        // 条件3：用户刚刚按了退格键删了很多字（可能在推倒重来）
        boolean recentlyDeleted = session.getRecentDeleteCount() > 30;
        
        return idleLongEnough && (hasStructureIssue || recentlyDeleted);
    }
    
    /**
     * 生成建议时，考虑用户的写作风格偏好
     */
    public WritingSuggestion generateSuggestion(String text, UserWritingProfile profile) {
        String prompt = buildPersonalizedPrompt(text, profile);
        String rawSuggestion = llmClient.complete(prompt);
        
        // 只返回最重要的1-2条建议，不要一口气给5条
        return parseAndFilter(rawSuggestion, 2);
    }
    
    private String buildPersonalizedPrompt(String text, UserWritingProfile profile) {
        return String.format("""
            请分析以下文字，提供最多2条最重要的改进建议。
            
            用户写作风格偏好：
            - 语气：%s（正式/半正式/口语）
            - 长度倾向：%s（简洁/详细）
            - 用词风格：%s（书面/日常）
            
            文字内容：
            %s
            
            只输出真正重要的建议，如果文字已经很好，可以输出0条建议。
            """,
            profile.getTonePreference(),
            profile.getLengthPreference(),
            profile.getVocabularyStyle(),
            text
        );
    }
}

改版后三个月，功能的次月留存率从12%升到了51%。用户评价从"鸡肋"变成了"用着还挺顺手的"。

---

功能二：AI会议总结——"准确但没用"的摘要

我们给视频会议工具加了一个功能：会议结束后自动生成AI总结，包含主要讨论点、决策事项和待办清单。

技术上这个功能做得还不错，摘要准确率在测试集上有83%。我们觉得很满意。

上线之后，用户反馈一直是"不用这个，还是自己手记靠谱"。

我们有个产品同学做了一次非常有价值的用户研究：她参加了十几次使用了这个功能的会议，会后用AI摘要跟实际会议内容做对比，同时观察用户拿到摘要后的行为。

她发现了一个关键问题：AI总结出来的"决策事项"经常不是真正的决定，而是会议中被提出但还没最终确定的选项。

比如会议中有人说"我们可以考虑A方案或者B方案，下周讨论"，AI会总结成"决策：采用A或B方案"。这不是决策，这是待议事项。

更糟糕的是，这个错误不是每次都有，只是偶发性出现。用户发现摘要有几次不靠谱之后，就不再信任它了。

这个问题的本质是：AI无法区分"正在讨论的选项"和"已经做出的决定"——因为区分这两者需要理解会议的语境和说话者的确认意图，而这是非常细微的语义差别。

我们做了以下改动：

改动一：在摘要里明确区分"已决定"和"待决定"两个类别。

public class MeetingSummary {
    
    private List<String> discussions;         // 讨论点
    private List<DecisionItem> decisions;     // 明确决定的事项
    private List<PendingItem> pendingItems;   // 还在讨论、未最终确定的事项
    private List<ActionItem> actionItems;     // 待办事项（有明确负责人）
    
    // ...
}

public class DecisionItem {
    private String content;
    private String decisionMaker;   // 谁做了这个决定
    private double confidence;      // AI对这是否是明确决定的置信度
    
    // 如果confidence低于0.8，在UI上标记为"待确认"
}

改动二：低置信度的内容显示"待确认"标记，让用户知道哪些地方AI不确定。

改动三：加入"一键确认/修改"按钮，鼓励用户在生成后快速校对。

用户研究发现，用户其实不排斥花30秒校对摘要——他们排斥的是"我不知道哪里需要校对"的模糊感。加了置信度标记之后，用户能快速定位到需要确认的地方，体验好多了。

---

功能三：AI代码注释生成——"太完美"反而不自然

我们给IDE插件加了一个功能：选中代码，右键"生成注释"，AI自动生成JavaDoc格式的注释。

这个功能在内测时评价很高，技术同学都说"省了很多写注释的时间"。

但上线三个月后，有人反映："用AI生成的注释，Code Review时会有人指出'注释和代码不符合'"。

这个问题的来源让我没想到：AI生成的注释太"理想化"了，描述的是函数"理论上应该做的事"，而不是函数"实际上做的事"。

举个例子：

// 代码是这样的
public List<User> findActiveUsers(int page, int size) {
    // 注意：这里有一个历史遗留问题，当size>100时会忽略page参数
    if (size > 100) {
        return userRepository.findByStatus("ACTIVE");  // 全量返回，没有分页
    }
    return userRepository.findByStatusPageable("ACTIVE", PageRequest.of(page, size));
}

// AI生成的注释是这样的
/**
 * 查询所有活跃用户，支持分页
 * @param page 页码，从0开始
 * @param size 每页数量
 * @return 活跃用户列表
 */

注释说"支持分页"，但实际上当size>100时分页失效了。这个历史遗留的"坑"，AI完全忽略了，生成了一个"正确但有误导性"的注释。

这个问题比较难从技术上根本解决，因为要求AI理解代码的隐性行为（比如边界条件下的特殊处理）超出了当前AI的能力范围。

我们的处理方式是降低预期、改变定位：

改版前的定位： "一键生成完整准确的代码注释"

改版后的定位： "生成注释草稿，帮你快速开始，最终由你完善"

UI上加了明显的提示："AI注释是草稿，请在提交前确认其准确性，特别是边界条件和副作用"。

同时我们修改了Prompt，让AI在注释里主动标出它不确定的地方：

private String buildAnnotationPrompt(String code) {
    return String.format("""
        请为以下Java代码生成JavaDoc注释。
        
        要求：
        1. 如果发现代码有特殊的边界条件处理，在注释中明确指出
        2. 如果发现代码行为可能与方法名暗示的不符，在注释末尾加上@implNote说明
        3. 如果你不确定某个参数的含义，在注释中用[待确认]标记
        4. 不要美化代码的实际行为
        
        代码：
        %s
        """,
        code
    );
}

改版后，Code Review中"注释与代码不符"的问题减少了70%，因为AI开始主动暴露它看到的歧义，而不是替用户"补脑"。

---

深层反思：为什么我们一再犯同样的错误

回顾这些案例，我发现我们团队犯的错误有一个共同模式：我们测试的是AI的能力，而不是AI融入用户工作流之后的整体体验。

AI辅助写作功能，我们测试的是"建议质量"——高分。但没有测"用户在写作时看到建议的感受"——打断了写作节奏。

AI会议总结，我们测试的是"摘要准确率"——83%。但没有测"用户拿到摘要后的信任度"——被几次错误打掉了。

AI代码注释，我们测试的是"注释是否完整"——很完整。但没有测"注释在真实工作场景中的准确性"——会误导人。

这是做AI产品的一个陷阱：AI能力的评估（离线指标）和用户价值的评估（在线体验）之间存在巨大的鸿沟。一个离线测试得分很高的功能，在真实用户场景中可能表现很糟糕；反过来，一个离线指标不算出众的功能，在真实场景中也可能因为恰好满足了用户的需求而被高度认可。

我现在的做法是：任何AI功能上线前，必须有至少一周的"影子使用"观察期——让测试用户在真实工作中使用，同时录屏，然后我坐下来看完所有录屏。

看用户在功能旁边皱眉，看用户在用完一次之后再也不点开，看用户用AI输出直接当结果复制走——这些行为比任何满意度问卷都说明问题。

被用户骂醒，比被数据骗着走，结果要好得多。