"经验分享"相关的文章
产品设计
支付结算:付款按钮点下去之后,到底发生了什么?

支付结算:付款按钮点下去之后,到底发生了什么?

这是「电商产品能力拆解」系列的第 7 篇·支付结算的上篇。上一篇讲了订单中心——三层结构、12 步生命周期、异常订单三大来源、逆向流程、超时与编排。支付结算这一关非常沉重,所以拆成上下两篇:上篇聚焦"钱怎么进来"——支付方式、支付链路、支付状态机这三个地基;下篇再聊"钱进来之后怎么不出事"——对账、分账、退款、异常资金池。
别只做“很好用”的产品经理:先判断边界,再解决问题

别只做“很好用”的产品经理:先判断边界,再解决问题

很多产品经理和项目 owner 都有类似经历:越能接住问题,越容易变成所有人的默认负责人。业务催结果、研发等前提、领导追进度、客服反馈客户已经在催,最后都汇总到你这里。本文想讨论的不是“不要解决问题”,而是产品经理在接住问题前,如何先判断目标、边界和下一步,从响应型协作升级为判断型协作。
AI
10多个意图全打架,6个月收敛成2类:我做ToB投研Agent的复盘

10多个意图全打架,6个月收敛成2类:我做ToB投研Agent的复盘

这个ToB端金融投研Agent系统,服务的是B端业务里的普通散户用户。我们用6个月,从一开始十多个意图边界不清,逐步收敛成「4个核心智能体、2类需求范式、4条执行路径」。最后内部测试里,响应时间从10几秒压到7秒内,关键问答准确率做到约95%。但比数据更值得复盘的,是中间踩过的几个坑:意图互相打架、溯源链路不够硬、个股相关能力差点做成黑盒。
货代SRM实战:采购订单协同怎么做,才能让供应商接单不是口头承诺?

货代SRM实战:采购订单协同怎么做,才能让供应商接单不是口头承诺?

很多货代企业对外协同仍停留在电话、微信和邮件层面: 业务发个需求,供应商回一句“能做”,真正的时窗、资源、变更责任和后续证据,却没有形成统一记录。结果是,执行阶段容易失控,变更阶段容易扯皮,结算阶段更难说清。本文从产品设计视角拆解“采购订单协同”模块,讨论为什么PO不是简单的下单动作,而是供应商交付承诺、变更协同和后续结算的起点。
货代SRM实战:合同与价目表怎么做,才能让每一笔买价都有依据?

货代SRM实战:合同与价目表怎么做,才能让每一笔买价都有依据?

在货代行业里,很多成本失控并不是因为没有签合同,而是因为合同只存在于PDF里,真正被业务执行和对账引用的仍是口头约定、邮件补充和临时解释。最终,调度不知道该按哪个价选供应商,财务不知道该按哪个规则核对金额,业务也很难回答“这票为什么会多出一笔附加费”。本文从产品视角拆解“合同与价目表管理”模块,讨论如何把静态文本转化为结构化规则,让合同真正成为执行与结算的依据。
产品设计
建了10个意图全打架,重写3次架构:我做金融多智能体的30天踩坑实录

建了10个意图全打架,重写3次架构:我做金融多智能体的30天踩坑实录

4个人的小团队,30天推翻重来3次。从一开始建了十几个意图互相打架的Workflow,到最后响应时间从28秒干到12秒、准确率从60%拉到85%的ReAct——中间每一步都是被真实问题逼着往前走的。这篇文章没有理论框架的大而全梳理,只有一个AI PM在金融场景里实打实踩过的坑。如果你也在做Agent产品,希望能帮你少走点弯路。
产品设计
工业数字化与行业软件产品,如何从项目交付走向产品成立

工业数字化与行业软件产品,如何从项目交付走向产品成立

这篇文章篇幅会稍微长一些,因为我不想把它写成几句判断式观点,而是希望尽量把背后的逻辑、判断标准,以及产品经理能力变化讲清楚。如果你也在做工业数字化、行业软件或项目型 ToB 产品,并且正在经历“项目做了不少,但产品始终难以沉淀”的困惑,不妨静下来读一读,也许其中有些问题和判断,会对你有所启发。