
工具实践,产品观察,
还有动手之后的真实感受。
先看清问题,再决定下一步。
从每天反复盯商品数据的工作切入,用财务与运营看板帮助用户查看经营情况、发现商品机会与异常。
日常工作的负担
用户每天需要花大量时间反复查看商品数据。这类重复劳动占用注意力,也让发现潜在机会和异常成为一件需要持续盯守的事情。
为什么从这里开始
首期没有一次性复制常见 Agent 的全部功能,例如自动化上下架。产品先帮助用户快速查看数据、定位潜在爆品机会和商品数据异常,让 AI 进入已经存在的工作流程。
先把发现问题的环节做起来
数据查看、机会发现和异常定位组成首期的主要价值。对产品方向的判断在于:哪一段工作发生得足够频繁、占用了足够多时间,值得先投入资源解决。
迭代顺序与产品边界
首期投入放在高频任务上:先让用户更快看到需要关注的问题,再判断下一步该做什么。自动化上下架没有纳入第一步,数据查看、机会发现与异常定位是首期的重点。
把行业知识,变成可用的服务。
面向酒店投资咨询,围绕高频问题设计意图澄清、知识检索与专家衔接。
先理解用户在问什么
酒店投资咨询往往带着不完整的背景。服务需要先识别问题与意图,补充必要信息,再进入检索和回答,避免在问题尚未清楚时直接给结论。
让回答能够找到依据
项目采用问题改写与知识检索,结合关键词和向量方式寻找相关材料。技术选择服务于具体目标:让行业问题能够找到适合的内容,而不是把回答长度当作服务质量。
为专业判断保留位置
基础概念与常见流程适合标准化服务。深度项目判断继续由专家承接,产品需要区分两者,并为模糊问题安排澄清。
以任务理解产品能力
这项实践把 AI 能力放回具体的咨询任务里考察:能否问清楚问题、找到相关知识,并让需要专家参与的判断得到合适的承接。
从自己的需要,做一个可用的产品。
把岗位、简历和求职准备放在一个工作台里。从自己和朋友的需要出发,亲手设计、验证并上线。
从自己的需要出发
求职时,岗位信息、简历材料和沟通准备往往分散在不同地方。这个项目先服务我和朋友的实际需要,让一次求职的相关材料能够放在同一个工作上下文里。
围绕一次求职组织任务
工作台围绕岗位串起 JD 理解、公司调研、定向简历与面试复盘。这些任务共用岗位与材料的上下文,减少在不同工具之间反复整理信息的工作。
把 AI 任务做成可检查的过程
我关注的不只是让模型返回一段文字,也包括任务如何发起、过程如何被观察、结果如何被审阅和保存。已有任务链路设计稿记录了这些环节,以及异常时的处理思路。
产品判断由我负责
需求来自实际使用,我负责确定要做什么、怎样组织任务与界面,再用 AI 辅助完成实现和验证。这个项目展示的是把需要做成产品的过程,目前没有规模化使用的结论。
从商品事实,到可以复用的话术。
AI 帮忙起稿,人继续编辑。把可用内容保存到商品话术库,让每次创作留下可复用的资产。
先有事实,再开始生成
产品先维护商品事实,再选择话术类型、语气和参考时长。它给创作提供明确的输入,减少每次从空白聊天框重新交代背景的重复工作。
生成之后,人继续修改
AI 的输出先作为创作结果。使用者可以逐段修改,确认内容适合实际场景后,再保存到目标商品的话术库。生成和正式保存是两个不同动作。
让可用的内容留下来
商品话术与可复用资产分别承接两种需要:一份稿件服务当前商品,好的表达可以继续用于后续创作。产品把生成、使用和沉淀串在同一条流程里。
用真实任务检验完整性
我和朋友的实际需要决定了这个项目的起点。这里展示输入、人工确认与保存之间能否形成完整任务,不将上线状态等同于用户增长或商业验证。
继续下滑,阅读文章
实践之后,
写下我的思考。
以 AI.菜的名字,记录对工具、产品与工作的观察。
理解问题,
也愿意亲手验证。
高涵 · 杭州 / 上海
我关心 AI 怎样进入具体的工作,也会亲手做一个能运行的版本,检验自己的想法。
工作中做过经营决策、行业知识服务与业务平台。自己的需要,也会变成可以上线的小产品。设计与实现让我更具体地理解成本、边界和取舍。
如果你正在招聘 AI 产品经理,或有一个需要梳理和验证的产品问题,可以从这里的案例开始了解我。
查看完整简历 ↗









