夜雨聆风去年我负责一个工业环保监测项目。团队花了三个月，规划了三个令人兴奋的AI功能：与客户MES系统打通获取生产计划、做点位相关性图谱、为正反案例建双库。
每个功能都经过评审，PPT做得漂亮，技术方案写得扎实。
最后全砍了。
砍掉它们的那几天，团队里没人开心。承认自己之前的判断错了，比承认自己不会做更难。但回头看，正是这三刀，把项目从死亡边缘拉了回来。
这让我想明白一件事：B端产品经理最值钱的本事，不是能堆多少功能，而是敢说“不做”。
最初我也掉进过一个坑——死磕技术指标。每天盯着准确率、召回率，看着测试指标涨了几个点就以为项目在进步。
直到一次客户沟通，一个环保管理员跟我说：“你准确率92%还是98%，跟我没关系。我只关心一件事——监管那边收到错告警，我要不要去解释？”
这句话点醒了我。业务方关心从来不是你的模型多准，而是出错那部分会不会让他难堪、出事故、担责任。
所以，落地的目标必须变成业务方敢拍胸脯说“这个数我能扛”的指标。
在我们项目里，目标被拆成了几条线：企业内部派维修工的，误报率高一点没事，多跑一趟而已，放到一两成都行；对环保监管的推送，必须压到极低，因为推错一次就是一次合规事故；对接政府的，干脆别让AI自己拍板，留个活人签字。
这才是PM该定的目标——不是技术参数，是业务承诺。
后来我又踩了另一个坑：把目标定成一个孤零零的数字。“误报率压到5%”听着挺好，可5.1%算不算合格？第一天上线肯定到不了5%，会不会被叫停？
真正好用的目标得带阶段：第一个月能扛住一两成，半年内压到一成以内，稳了再说5%以下。这是一个客户跟得上的目标，不是一个上线第一天就把你打死的数字。
回到开头那三刀。
第一刀：MES系统对接。
想法很美好——让客户接生产计划过来，系统就知道什么时候是计划内停车、什么时候是临时检修，这些时段就不报警。
我让销售去谈，结果没一个客户愿意。
工厂的生产计划是核心商业机密。什么时候开停车、负荷多少，直接对应产能、订单、成本。把数据给一个环保监测系统，等于把经营底牌摊在外人面前。有个厂长当场说：“你装这个不就是应付环保监管吗，怎么连这个也要？”
我们算了笔账：就算谈下来，对接MES是动辄百万级的IT工程，一个监测产品凭什么开这个口？销售周期能被拖死。
砍。
第二刀：点位相关性图谱。
这个是我自己最早想的方案，砍它时最没面子。设想挺漂亮——把厂区里几十个传感器的关系画出来，相邻点位数据一起飙的是真异常，只有一个点位飙多半是传感器坏了。
工艺工程师带我去了趟车间，指着两排排放口说：1号口的除尘器坏了，2号口压根不受影响，这俩是两套独立流程。我又问有没有强相关的点位，他说有，但那种情况一定是同一个污染源出来的，工艺上根本没必要装两个传感器。
我意识到自己犯了什么错——拿学术里的漂亮假设，往一个物理上根本不成立的场景上硬套。
砍。
第三刀：正反例双库。
这招看着无害——把故障案例标对的和标错的分开存，对的加权用，错的当反面教材。我跟算法团队讨论后，都觉得能做。
工单系统那边的产品负责人提醒我：“你去看看现场维修工人怎么填工单。”
我去了。手上沾着油泥的工人，让他在手机界面上选一堆字段，闭着眼睛点几下就不错了，再让他判断“AI之前给的归因方向哪儿不对”——他根本不知道AI之前给的是什么。这超出了他的职责范围。
反例标签永远凑不齐，机制做了也是空着跑。
砍。
这三刀砍下来，我总结出一条铁律：B端产品的设计，但凡需要客户在他本职工作之外再多做点什么事，这件事就要打问号。
客户买你的系统是为了省事，不是添麻烦。每多让他做一件事，销售周期就拉长一点，交付难度就高一截。
砍方案最难的从来不是技术判断，而是政治成本。客户提过需求、销售在合同里写过、自己在评审会上拍过桌子——这种时候说“不做”，要顶住的不是几个工程师的质疑，而是一整条已经在转的车轮。
砍完三件后，我重新数了手里还剩什么。剩下的都是不依赖客户配合、用自己的数据就能跑的招：
进模型前一道纯规则过滤、时间窗口往后挪做去抖、传感器自检状态读一下、单点位自己跟自己历史比、检索回来用Reranker重排、置信度按几个客观信号加权出来、按推送对象不同设不同门槛、工单回填的标注让系统自己学。
每一招单拎出来，都没法把误报压到零。它们各自只能干掉一类问题：纯规则解决脏数据，时间窗口解决瞬间抖动，自检状态解决传感器故障，工单标注解决系统不认识工况。
谁也别想一个人扛下所有事。
后来我跟团队反复讲：分清主菜和配菜。
主菜两个。一个是进模型前的纯规则过滤，性价比最高——纯代码、零成本、能砍掉一大半误报，后面所有AI模块都受益于干净数据。另一个是工单回填驱动的飞轮，这是整套系统唯一能自己进化的发动机——没有它，系统装上去那天就是它最聪明的一天。
配菜是一堆：置信度门控、分级裁决、反例机制、LoRA微调。每一道该不该上、什么时候上，看主菜跑下来还差多少，跟那条业务承诺的线还差多远。够了就不上，差了就补一道。
配菜取舍标准很明确：做这道菜花的钱，能不能换业务那条线再往下压几个点。换不来，就不做。
那套工单回填飞轮是整套系统的命门。我跟工单团队磨了很久才定下来流程。
填工单的是车间维修工人，不是产品经理。这话听着像废话，但太多AI团队一头扎进算法时就忘了这事。
我跟着维修组跑过几次现场。工人的真实场景是这样的：手上沾着油泥，刚从一台跳闸的设备底下爬出来，工单系统在手机上让他填一堆字段。他能怎么填？十有八九闭着眼睛点几下，赶紧关掉去下一台。
这时候你跟他讲“标注规范”、做“培训”、发“激励”，全是空话。培训刚结束他就忘了，激励金额够的客户老板不批，不够的工人看不上。
让标注数据干净，靠的是流程压死，不是道德感化。
我们最后定了几天规矩：工单不完成标注就关不掉，整张单挂在“进行中”，他领不了下一单，KPI还要扣闭单率；关键字段强校验，前后端都堵死，跳过一个字段都提交不了；让他填客观事实，别让他做主观判断——别问“这是不是误报”，问“现场有没有发现传感器异常”“有没有实施维修动作”，他凭眼睛回答，剩下的让系统自己去推导。
我们还加了道反作弊：某个工人90%的工单都点同一个选项，自动标可疑，让班组长复核，复核不一致扣绩效。
这套东西看着粗暴，但符合工业客户的真实场景。让“认真填”比“乱填”省事，让“乱填”的成本比“认真填”高，人就会做正确的事，跟道德感无关。
当然，铺这套机制得有个心理准备：前一两个月会很难受。工人会抱怨，班组长会跟客户老板告状，客户老板可能回头来找你。这时候PM得顶上去，告诉对方这一两个月的不舒服，换的是后面系统自己越跑越省事。
撑过去，飞轮就转起来了。撑不过去，再贵的模型也救不回来。
砍完那三件、把组合搭起来、把飞轮压稳之后，我在团队里立了条规矩：每次评审完一版PRD，让PM同事单独整一页“不做清单”——这次被砍掉的需求是哪些、为什么不做。
一开始团队觉得挺怪，做着做着才反应过来：这页“不做清单”才是项目里最值钱的资产。它告诉所有人项目的边界在哪、力气不该往哪儿使、客户来提新需求时拿什么去挡。
我观察到大部分AI产品经理都在做加法：听到新技术就想往项目里塞，看到一篇论文就想试试，老板提了个想法就想搞个demo。功能列表越来越长，项目越来越重。
可真正让一个B端项目活下来的，往往是减法。
每砍一件事，背后都是一次产品判断：这玩意儿能不能让我们更接近那条业务承诺的线？不能，就砍。
会加方案的产品经理一抓一大把，会砍方案的少得多。因为加方案有“我做了”的存在感，砍方案只有“我没做”的空白。
可那个空白，恰恰是项目能跑下去的空间。
换句话说，所有这些手段——前置规则、时间去抖、置信度分级、人工裁决、数据飞轮——单看哪一个都不能让系统从“会出错”变成“不会出错”。它们能做的，是把出错的概率、代价、场景，一点点挪进业务能扛住的那个区间里。
具体用哪几招、按什么次序上、什么时候添、什么时候砍——那是PM站在业务、成本、客户配合度三个角中间，一遍遍拍出来的事。没有标准答案，也没人能写本教科书让你照着抄。
所以我也不敢说这些一定对，最多是几次踩坑、几个和团队吵架的晚上，琢磨出来的一点偏见。换个场景、换个客户、换个老板，结论可能就不一样。
但有一件事我越来越确定：真正让一个产品经理值钱的，不是他做过多少功能，而是他敢于砍掉多少。
你最近做的最重要的产品决策，是加了什么，还是砍了什么？
✽ · ✽ · ✽
