内容节选自我的《AI产品经理转岗特训营》第四章「AI 产品从立项到测评、上线的全流程」的第一节。
如果你正想快速转型进入 AI 大模型领域、或者已经在公司开展 AI 相关业务,欢迎报名学习。
课程早鸟优惠将在 11 月底结束,强烈建议先添加班主任领取优惠券保留早鸟名额。
工程师(包括产品经理和程序员)在设计任何一款产品或者工具时,终极目标其实只有一个:让技术尽可能多地接管原本由人完成的工作。
• 决策规则说不清楚,很难被写成明确的“如果……就……”的程序逻辑,示例再多也覆盖不全
• 输出缺乏统一的客观标准,结果往往只能“看着差不多”,难以用规则自动验证对错
而传统“程序型”任务的特征则刚好相反:输入结构化、规则可严密推导成“是/否”判断、输出可以预期并被自动校验(图一中的“程序”一侧)。
过去软件工程所实现的“提效”,正是通过不断用这种“规则可编码”的程序,去替代重复、稳定的人工操作。
![]()
•AI 能接受非结构化输入—— 借助对自然语言和上下文的理解能力,从杂乱的信息中提取出有用的信号;
•AI 能在规则不完全清晰时给出“合理解”—— 通过少量示例自行归纳出隐含模式,而不必把规则穷尽到每一条 if-else;
•AI 的输出允许存在弹性—— 它不一定给出唯一标准答案,但可以在可控范围内提出建议、备选方案,由人或后续程序来做最终裁决。
在相当一部分过去“只能人工、程序接不了”的环节上,AI 开始具备了可用甚至可观的承担能力。
![]()
因为有了这一层“弹性理解和生成”的能力,我们可以不再只用“能不能写成程序”这一维度来判断任务是否可被技术接管,而是引入一个新的观察框架。
•任务的弹性:输入和输出是否多样、模糊、带有创意空间,还是高度标准化、可严格预期;
•规则的可表达性:决策规则能否被语言化、公式化、写成清晰的指令,还是高度依赖经验直觉、难以说清楚。
![]()
• 规则难以说清但任务又具有较高弹性的区域,更适合由人和 AI 共同完成,由 AI 提供理解和生成能力,人负责判断与拍板
有了这个新的观察视角,“一项业务能否引入 AI 技术来赋能提效”就不再仅凭拍脑门了,而可以被拆解为一套可执行的方法:
对业务进行任务拆解 → 分析每一项工作的输入、处理与输出逻辑 → 据此判断每个环节更适合由人、AI、程序,还是三者的某种组合来承担。
所以业务都是由一个个更细颗粒度的具体工作节点组成的,产品设计最大的忌讳就是“雕刻巨石”。
试图用 AI 赋能整个业务是非常外行的表现,我有总结过 3 个 AI 产品设计的天坑,在这里再次分享:
![]()
因为我们的终极目的是为了考量一项业务能否以及如何引入 AI,所以需要观察每个原子任务在“输入-处理-输出”这三个维度上的表现。
![]()
拆到这里,一项业务的全流程,能否以及在哪些环节引入 AI 其实已经相对清晰了。
但要实现明确、清晰、量化,还需要更多、更细颗粒度的分析维度,我在这里把“输入-处理-输出”扩展成了 6 个:
![]()
2. 但如果任务的规则由不可语言化(不能表达不能标准化),就比如把人类或者AI 引入进来辅助程序
3. 如果同时它的重复度非常高,让人来做很“费”人,那么引入 AI 的价值就非常高了。
回到刚才“撰写调研报告”的示例,在新的 6 维下对每个原子化工作进行打分可以得到:
![]()
基于此,一项包含 6 个子步骤的任务,每一项任务及整个场景都可以得到量化的可行性判断了:
此场景任务可拆解为 6 个关键步骤,其中 5 个节点可引入 AI 来提效或提质,3 个节点可直接被 AI 托管,2 个节点需要人机协作。
![]()
经过这么一轮拆解,再回看开始对场景任务的观察维度,可以用这么两句话来总结:
我的《AI产品经理转岗特训营》课程中,包含一个产品经理必须了解和掌握的 AI 大模型全部信息。
如果你正想快速转型进入 AI 大模型领域、或者已经在公司开展 AI 相关业务,欢迎报名学习。
最后提醒,课程早鸟优惠将在 11 月底结束,强烈建议先添加班主任领取优惠券保留早鸟名额。