工业环保监测项目中，三个看似光鲜的AI模块最终被果断砍掉，揭示了B端AI产品的生存法则。从误报率指标设定到MES系统对接的失败，再到正反例双库的无效设计，本文深度拆解如何通过‘不做清单’实现产品突围。真正值钱的不是堆砌功能，而是敢于在业务承诺线与客户需求间做减法决策的勇气。

我之前做的那个工业环保监测项目，曾经规划过三个挺有面子的 AI 模块：跟客户的 MES 系统打通拿生产计划、做点位之间的相关性图谱、给检索知识库搞正反例双库。

最后全砍了。

砍的过程一点都不痛快。每一个方案在 PPT 上都趴过、在评审会上都点过头，砍它就是承认自己之前判断错了。但回头看，这三刀要是没下下来，项目大概率早就死在交付半道上。

慢慢摸出来一句话：AI 产品经理真正值钱的本事，不在他能堆出多少功能，在他敢不敢说”不做”。

一、先把那条业务能扛的线定死

这事儿我也走过弯路。

一开始我是技术派那一挂——盯准确率、调召回、上 Reranker，每天看测试指标涨了几个点。直到有一次跟客户那头的环保管理员聊，他说了一句话我记到现在：”你这准确率 92% 还是 95%，跟我没关系。我就关心一件事，监管那头收到错的告警，我要不要去解释。”

那一刻我反应过来——业务方关心的从来不是模型有多准，是错的那部分会不会让他难堪、会不会出事故、会不会担责任。

落地的目标，得是业务方敢拍胸脯说”这个数我能扛”的指标。

我们项目里的目标后来被拆成了几条线：企业内部派维修工那头，误报率高一点没事，多跑一趟而已，放到一两成都行；对环保监管那头的推送，必须压到极低，因为推一次错的就是一次合规事故；对接政府那头的，干脆别让 AI 自己拍板，留个活人签字。

这才是 PM 该定的目标。

它不是技术参数，是业务承诺——是你拿着这条线出去跟客户、跟自己老板拍胸脯保过的数。

线一旦定死，下面所有动作的取舍标准就有了。哪条措施贵但能把对外误报压低两个点？做。哪条措施贵但只是把企业内误报从一成八压到一成五？多半不值。

后来还踩过另一个错——把目标定成一个孤零零的数，而不是一段会动的范围。”误报率压到 5%” 听着挺好，可 5.1% 算不算合格？第一天上线肯定到不了 5%，要不要把项目中止？真要写进 PRD，目标得带阶段：上线第一个月扛得住一两成，半年内压进一成以内，稳了再说 5% 以下。这才是客户跟得上的目标，不是一个上线第一天就把你打死的数字。

二、B 端 AI 有条铁律：别让客户配合你

回到开头那三刀。

MES 对接的想法挺好。让客户把生产计划接过来，系统就知道什么时候是计划内开停车、什么时候是临时检修，遇上这些时段就把异常压一压，不报警。

我让销售去试过。没一个客户愿意。

工厂的生产计划是核心商业机密。什么时候开停车、负荷多少，直接对应产能、订单、成本。这些数据给一个环保监测系统看，等于把经营底牌摊在外人面前。有一个客户的厂长当着销售面说：”你装这玩意儿不就是应付环保监管吗，怎么连这个也要？”

后来我们自己评估了一下：就算谈得下来，对接 MES 是动辄百万级的 IT 工程，一个监测产品凭什么开这个口？销售周期能被拖死。

砍。

点位相关性图谱是我自己最早想的方案，砍它的时候最没面子。设想挺漂亮——把厂区里几十个传感器的关系画出来，相邻点位数据一起飙的，是真异常；只有一个点位飙，多半是这个传感器坏了。

是工艺工程师把我说醒的。他带我去车间走了一圈，指着两排排放口跟我说：1 号口的除尘器坏了，2 号口压根不受影响，这俩在工艺上就是两套独立流程。我又问他：”那有没有强相关的两个点位？”他说有，但那种情况一定是同一个污染源出来的，工艺上根本就没必要装两个传感器。

那一刻我意识到自己犯的错——拿学术里那种漂亮假设，往一个物理上根本不成立的场景上硬套。

砍。

正反例双库这事看着无害。既然有标对的归因案例，也有标错的，分开存，对的加权用，错的当反面教材。我跟算法那头讨论的时候，大家都觉得能做。

是工单系统那边的产品负责人提醒我的，他说你去现场看一眼维修工人怎么填工单。我去了。手上沾着油泥的工人，让他在一个手机界面上选一堆字段，闭着眼睛点几下就不错了，再让他判断”AI 之前给的归因方向哪儿不对”——他根本不知道 AI 之前给的归因是什么、错在哪儿。这超出了他的活儿范围。

反例标签永远凑不齐，机制做了也是空着跑。

砍。

这三刀下来，我捞出一条用得上的判断：B 端 AI 产品的设计，但凡需要客户在他本职工作之外再多做点什么，这件事就要打个大问号。

客户买你的系统是来省事的，不是来添麻烦的。每多让他做一件事，销售周期就拖长一点，交付难度就高一截。能不靠客户的就别靠客户，能用自己手里数据解决的，绝对别去外面要。

砍方案最难的也不是技术判断，是政治成本。客户提过需求、销售在合同里写过、我自己在评审会上拍过桌子——这种时候说”不做”，要顶住的不是几个工程师的质疑，是一整条已经在转的车轮。点位相关性图谱是我自己最难下手砍的，因为它是我提出来的，砍它等于打自己的脸。

(这事儿我也不敢说每次都做得对。能硬着头皮砍下来的我砍，砍不动的我认。这两者之间那条线到底在哪儿，到现在我也没完全摸清楚。)

三、真正能撑场的是组合，不是哪一招

砍完那三件之后，我重新数了一遍手里还剩什么。剩下的全是不依赖客户配合、用自己手里数据就能跑的招——进模型前一道纯规则的过滤、时间窗口往后挪做去抖、传感器自检状态读一下、单点位自己跟自己历史比、检索回来用 Reranker 重排、置信度按几个客观信号加权出来、按推送对象不同设不同门槛、工单回填的标注让系统自己学。

每一招单拎出来，都没法把误报压到零。

它们各自能干掉一类问题：纯规则解决数据本身脏的，时间窗口解决瞬间抖动的，自检状态解决传感器自己坏的，工单标注解决系统不认识工况的。谁也别想一个人扛下所有事。

我后来跟团队反复讲的就一条：分清主菜和配菜。

主菜两个。一个是进模型之前那道纯规则过滤，性价比最高：纯代码、零成本、能砍掉一大半误报，后面所有 AI 模块都受益于一份干净数据。另一个是工单回填驱动的飞轮，整套系统里唯一能自己进化的发动机。没有它，系统装上去那天就是它最聪明的一天，往后只会越跑越糙。

配菜是一堆：置信度门控、分级裁决、反例机制、LoRA 微调。每一道该不该上、什么时候上，看主菜跑下来还差多少、跟那条业务承诺的线还差多远。够了就不上，差了就补一道。

配菜的取舍标准我后来定得很白：做这道菜花的钱，能不能换业务那条线再往下压几个点。换不来，就不做。

四、飞轮要转起来，标注不能靠工人自觉

主菜里那道工单回填的飞轮，是整套系统的命门。这块我跟工单团队磨了挺久才把流程定下来。

填工单的是车间维修工人，不是产品经理。这话听着像废话，但太多 AI 团队一头扎进算法的时候就忘了这件事。

那段时间我跟着维修组跑过几次现场。工人那头是啥景象？手上沾着油泥，刚从一台跳闸的设备底下爬出来，工单系统在手机上让他填一堆字段。他能怎么填？十有八九闭着眼睛点几下，赶紧关掉去下一台。

这时候你跟他讲”标注规范”、做”培训”、发”激励”，全是空话。培训刚结束他就忘了。激励金额给得起的客户老板不批，给不起的工人压根看不上。

要让标注数据干净，靠的是流程压死，不是道德感化。

我们最后定下来的几条规矩，加在一起其实不复杂。工单不完成标注就关不掉，整张单挂在”进行中”，他领不了下一单，KPI 还要扣闭单率，他自然就填了。关键字段强校验，前端后端都堵死，跳过一个字段都提交不了。再有一招挺管用：让他填客观事实、别让他做主观判断。别问”这是不是误报”，问”现场有没有发现传感器异常””有没有实施维修动作”，他凭眼睛看到的事实回答，剩下的让系统自己去推导真假。客观陈述的作弊难度，比主观判断高得多。我们还加了一道反作弊——某个工人 90% 的工单都点同一个选项，自动标可疑，让班组长复核，复核不一致就扣绩效。

这套东西看着粗暴，但符合工业客户的真实场景。让”认真填”比”乱填”省事，让”乱填”的成本比”认真填”高，人就会做正确的选择，跟道德感无关。

铺这套机制还得有个心理准备：前一两个月会很难受。工人会抱怨多了事儿，班组长会跟客户老板告状，客户老板可能又回头来找你。这时候 PM 得顶上去，告诉对方这一两个月的不舒服换的是后面系统自己越跑越省事。撑过那一两个月，标注质量上来了，飞轮转起来了，抱怨自然就少了。

撑不过去的话，飞轮转不起来，整套系统就变成一个静态工具，再贵的模型也救不回来。

(顺嘴说一句，这套思路不光适用于工业。任何 B 端产品，凡是需要一线员工配合提供数据的场景，靠流程压都比靠培训强。)

砍完那三件、把组合搭起来、把飞轮压稳之后，我自己在团队里立了一个规矩：每次评审完一版 PRD，让 PM 同事单独整一页”不做清单”——这次被砍掉的需求是哪些、为什么不做。一开始团队觉得这事儿挺怪，做着做着才反应过来，这页”不做清单”才是项目里最值钱的资产。它告诉所有人这个项目的边界在哪、力气不该往哪儿使、客户来提新需求的时候拿什么去挡。

我观察到的大部分 AI 产品经理做的都是加法。听到一个新技术就想往项目里塞，看到一篇 paper 就想试试，老板提了个想法就想搞个 demo。功能列表越来越长，PRD 越来越厚，项目越来越重。

可真正让一个 B 端 AI 项目活下来的，往往是减法。

每砍一件事，背后都是一次产品判断：这玩意儿能不能让我们更接近那条业务承诺的线？不能，就砍。

会加方案的产品经理一抓一大把，会砍方案的产品经理少得多。因为加方案有”我做了”的存在感，砍方案只有”我没做”的空白。可那个空白，恰恰是项目能跑下去的空间。

所有这些手段——前置规则、时间去抖、置信度分级、人工裁决、数据飞轮、反例标签、LoRA 微调——单看哪一个都不能让 AI 项目从”会出错”变成”不会出错”。它们能做的，是把出错的概率、出错的代价、出错的场景，一点点挪进业务能扛住的那个区间里。

目标就这一个：拉进可接受范围，让它自己越跑越稳。

具体用哪几招、按什么次序上、什么时候添、什么时候砍——那是 PM 站在业务、成本、客户配合度三个角中间，一遍遍拍出来的事。没有标准答案，也没人能写本教科书让你照着抄。

我也不敢说上面这些就一定对，最多是这个项目里、几次踩坑里、和团队吵过的几个晚上里，琢磨出来的一点偏见。换个场景、换个客户、换个老板，结论可能就不一样。

你最近做的最重要的产品决策，是加了什么，还是砍了什么？要是只想得起来加了什么——这个项目，可能就还没真正开始。