我把大模型嵌进产品工作流之后，哪些环节真的变快了

过去两年我在产品工作流里大量使用大模型。这篇文章只讲实测有效的部分，以及那些被过度吹捧、实际反而拖慢效率的部分。

一、需求聚类：从 3 小时到 20 分钟

以前：把 400 条用户反馈做成 Excel，人工打标签、归类、数数。一次大约 3 小时，且不同人分类标准不一致。

现在：把反馈批量丢给模型做初分类，输出结构化 JSON。

{
  "cluster": "结算时效投诉",
  "sentiment": "negative",
  "severity": 4,
  "quote": "上周的款到现在还没到账"
}

然后用脚本聚合。耗时降到 20 分钟，其中 15 分钟是我在复核模型的分类边界。

关键点：模型负责分类，人负责定义分类体系。分类体系设计得好不好，直接决定结果有没有用。

二、竞品研究：从 2 天到 2 小时

以前：人工收集竞品文档、定价页、更新日志，整理成对比表。一个完整竞品分析大约 2 个工作日。

现在：抓取竞品公开页面 → 模型抽取结构化字段 → 生成对比初稿 → 人工修正。

耗时 2 小时，但必须注意：模型会自信地编造不存在的功能。我们的做法是所有事实性结论都必须附带原文出处链接，人工抽检 20%。

三、文档起草：节省 60%，但省不掉思考

看清楚最后一行：涉及价值判断和业务权衡的任务，模型几乎帮不上忙。指标体系怎么设计，取决于你认为什么重要，这不是模型能替你回答的。

四、数据分析：只有在 schema 清晰时才有效

让模型写 SQL 的效果，完全取决于表结构是否自解释。

• 表名 t_ord_02、字段 f_a1 → 模型基本写错
• 表名 payment_attempts、字段 decline_code → 一次就对

结论：为模型优化你的数据模型，顺带也让新人上手更快。

哪些环节反而变慢了

1. 需要极强一致性的对外文档：模型输出必须逐句核对，核对成本高于自己写
2. 高度依赖内部隐知识的判断：模型没有上下文，产出全是正确的废话
3. 需要承担责任的关键决策：可以问，但不能用

我的使用原则

• 能验证的才交给模型：有标准答案的任务优先自动化
• 保留信息来源：所有事实结论必须可追溯
• 人在流程里，不在流程外：模型产出必须经过人的判断节点

大模型不会取代产品经理，但会用大模型的产品经理，会取代不会用的。

小结

真正的收益不在「让模型写东西」，而在把重复的认知劳动变成可校验的流水线。