企业AI产品的落地过程中，决定AI不做哪些事往往比让它变聪明更难。本文作者通过三年实战经验，复盘八个AI应用场景中两个失败案例的致命缺陷——投标方案辅助因无法捕捉隐性知识而沦为鸡肋，会议纪要提取因过度自动化而触及组织敏感神经。而存活下来的六个场景，都遵循着严格的边界法则：AI的能力范围必须被精确锁定在可验证、可兜底、用户明确预期的小闭环内。这不仅关乎技术可行性，更是产品定位与用户信任的底层逻辑。

三年前开始做企业AI产品的时候，我觉得这行最难的事是让AI变聪明。三年后我发现最难的事是——决定不做什么。

2023年到2025年，我在一家软件公司的智慧能源事业部做AI产品经理。三年里服务了四家能源和政企客户，前前后后做了八个AI应用场景。合同智能审核、可研报告生成、设备台账解析、政策文件比对、投标方案辅助、技术问答知识库、会议纪要提取、运维工单分类——八个场景全部立了项，投入了资源。

最后活下来六个，砍掉两个。

“砍掉”这个词在甲方面前是不能说的。我们说的是”该场景已完成阶段性验证，后续视业务优先级调整”。翻译成人话就是：做不下去了，别再花钱了。

先说那两个死掉的。

第一个死掉的是投标方案辅助。甲方的想法是让AI根据招标文件自动生成投标方案的初稿。听起来特别美好对吧——投标团队每次写方案至少一周，如果AI能出初稿省掉三四天，那效率提升太明显了。我当时也觉得这个场景简直是为AI量身定做的。

POC阶段跑了三份招标文件，AI输出了三份方案初稿。单看每一份，格式工整、章节齐全、技术参数都有引用。我拿去给投标经理看，他翻了大概十分钟，然后合上说了句：”你这个方案哪个项目都能用，但哪个项目都不能中。”

后来我才理解他的意思。投标方案最值钱的部分不是格式和章节，是针对这个特定项目的竞争策略——你怎么理解甲方的真实诉求、你跟竞争对手比有什么差异化优势、你在哪些条款上让步哪些地方坚持。这些东西在每个人脑子里，在饭局上的只言片语里，在上一次竞标失败的教训里。不在任何文档中。

知识库里灌不进去的东西，AI就不可能输出。我们又花了两个月试图让投标团队把”隐性知识”文档化，搞了几次workshop。结果大家写出来的东西跟没写一样——”需要深入理解客户需求””结合项目实际情况制定策略”——全是正确的废话。不是他们不愿意写，是这种判断力真的很难变成文字。

三个月后我跟领导说这个场景建议暂停。领导问为什么。我说：这个场景的价值部分恰好是AI做不到的部分。AI能写的那些，投标团队也不觉得难。我们在用AI解决一个不存在的问题。

第二个死掉的是会议纪要提取。这个更冤，因为技术上其实做得不差。语音转文字加大模型总结，准确率我们测下来能到85%以上。但上线两周之后日活就掉到个位数了。我去问用户为什么不用，有个项目经理特别实在：”开完会我顺手就把纪要写了，三五分钟的事。你那个系统我还得把录音传上去、等它处理、看完再改一遍，时间差不多。”

更要命的是另一个问题。会议纪要里经常有些”不方便写进去”的内容——领导暗示的方向、没说出口的否决、”这个事你心里有数就行别往下传”——AI会老老实实把这些全部提取出来放进纪要。有一次差点出事，一个项目经理发现AI把领导在会上的一句吐槽写进了纪要初稿，吓得他赶紧删了，之后再也没用过这个功能。

怎么说呢，会议纪要这个场景不是AI能力不够，是这件事本身就不太适合完全自动化。它需要的不是”忠实记录”，是”有选择地记录”——而”选择”的标准在人的脑子里，跟组织政治有关，跟技术无关。

好，说完两个死的，说活着的六个。

活下来的六个场景差异挺大。有简单的比如设备台账解析，就是把PDF里的设备参数抽取出来填进结构化表格，没什么技术含量但很实用，上线之后基本不用管。也有复杂的比如合同审核和可研报告生成，前前后后磨了大半年，中间翻过好几次车。

但我后来反复想这六个活下来的场景，发现它们有一个共同点。这个共同点不是”技术好”，不是”模型强”，不是”需求明确”——是**AI的能力边界被画得很死**。

什么意思呢？拿合同审核来说。我们最终上线的产品，AI做的事情被严格限定在一个框框里：只审已有规则库里的260条内控规则和65份法规文档覆盖的范围。超出这个范围的条款，系统直接标”超出审核范围，建议人工重点关注”。不猜、不编、不硬扯。

AI的输出格式也是死的——条款编号、风险等级、问题描述、修改建议、法规依据，五个字段缺一个都不行。不许输出”建议关注””值得注意”这种模棱两可的话。要么说清楚问题是什么、应该怎么改、依据是哪条，要么直接说”该条款未发现规则库内的匹配风险”。

甚至连AI的”态度”都是规定好的。它的角色不是”智能法律顾问”，是”初审助手”——帮法务把明确的问题先筛出来，拿不准的标出来，复杂的留给人。你注意这个定位：它不是来替代法务的，它是来当法务的”第一遍粗筛工具”的。这个定位一旦确定，用户的期望就对了——他不会指望AI给出高深的法律判断，他只需要AI帮他省掉逐条对照规则库的体力活。

可研报告生成也是类似的逻辑。我们最后的设计是分章节生成，一章一章来，用户确认了再往下走。每一段AI生成的内容旁边都有溯源标注，点进去能看到原始文档出处。如果某段内容没有找到强相关的依据，直接标黄——”该段落参考依据较弱，建议人工补充”。

你可能觉得这些限制会让产品”看起来很弱”。确实。我们的系统不会写出那种洋洋洒洒、看起来什么都知道的长篇报告。但法务用了两个月之后跟我说了句让我印象很深的话：”我信得过这个系统。它说有问题的地方我仔细看，它说没问题的地方我就过了。”

采纳率72%就是这么来的。不是因为AI写得有多好，是因为用户知道AI什么时候可信、什么时候不可信。这个确定性比输出质量重要得多。

回过头来看那两个死掉的场景，问题恰好反过来——AI的能力边界没有被画死。

投标方案辅助，我们给AI的定位是”方案初稿生成”。这个定位太大了。”方案”意味着要有策略、有判断、有取舍，这些AI做不到但它会假装自己做得到——它会生成一份看起来像方案的东西，但投标经理一看就知道是空架子。如果当初我把边界画死——AI只负责”从历史方案库中检索相似项目的技术参数和报价结构”，不负责生成策略部分——可能这个场景就不会死。

会议纪要也是。”自动生成会议纪要”这个边界太模糊了。会议纪要需要人的判断力来筛选什么该记什么不该记，AI不知道这个边界在哪。如果当初限定为”自动提取会议中提到的待办事项和时间节点”——一个更窄、更确定的功能——结果可能完全不一样。

所以我现在总结出来的规律是：一个AI场景能不能活，取决于你能不能用一句话说清楚AI在这个场景里”只做什么”。注意是”只做什么”，不是”能做什么”。

“能做什么”是技术团队喜欢聊的——模型支持多长的上下文、RAG能检索多少文档、生成速度怎么样。这些当然重要，但它们回答的是”AI的能力上限在哪”。而”只做什么”回答的是”我们选择让AI做哪一小块”。这一小块必须满足三个条件：AI确实能做好、做完用户能直接验证对不对、做错了能兜得住。

三个条件缺一个，场景就危险了。

投标方案：AI能生成文字但策略部分做不好——第一条就没过。会议纪要：AI做了但用户没法快速验证该不该这么记——第二条没过。我见过另一个项目，做的是合同金额自动计算，AI算对了99%但错了那1%涉及真金白银——第三条没过。后来改成AI只做预填、人工确认，才活了下来。

这个判断框架看起来简单，但你在项目早期很难用。因为早期所有场景看起来都很美好——甲方热情高涨，领导大力支持，技术方案评审顺利通过。那个时候你说”这个场景可能不适合做”，所有人会觉得你在泼冷水。

我后来学了一个笨办法：在立项之后、开发之前，先做一轮”反向测试”。不是测AI能不能做，而是测”AI做错了会怎样”。找几个最可能出错的case让AI跑一遍，然后把错误的输出拿给业务用户看，问他三个问题：这个错误你能一眼看出来吗？看出来之后你能快速改对吗？如果没看出来直接用了会怎样？

如果三个答案是”能看出来、能改对、后果可控”，这个场景可以做。如果有一个答案是否定的——特别是第三个——你就需要重新考虑AI在这个场景里的边界了。

投标方案那个场景如果做过这个测试，投标经理看到AI生成的策略部分肯定会说”这东西我没法一眼判断对不对，要是没改直接用了投标可能废了”——第二条和第三条都过不了。当时要是做了这个测试，可能三个月的时间就省下来了。

但说实话我也是踩了坑才想出这个办法的。当时如果有人跟我说”你先别做，先测测AI做错了会怎样”，我可能也听不进去。项目已经立了项、资源已经排了，所有人都等着看成果。在这种惯性下喊停需要的不是洞察力，是胆量。

三年做下来我有一个挺深的感触：做AI产品经理，最难的不是找到AI能做什么，是接受AI不能做什么。

你去参加任何一个AI产品的立项会，讨论的都是”AI能帮业务做这个做那个”。没人讨论”这件事AI做了但做不好怎么办”。因为立项会的氛围是打鸡血的，你这时候说”可能做不好”，跟在婚礼上说”可能过不长”一样扫兴。

但做不好的场景如果硬做，结果比不做更糟。不做，业务部门顶多觉得”AI还不够成熟”；做了但体验很烂，业务部门的结论是”AI不靠谱”。前者留了余地，后者关了门。

我砍掉那两个场景的时候压力不小。投标方案那个是甲方分管领导亲自点名要做的，砍的时候我做了一份很详细的分析报告，列了试点数据、用户反馈、继续做的预估投入和预期效果。领导看完沉默了一会儿说：”行，先放一放。”后来那个客户的二期合同里没有再提这个场景，但其他五个场景的续签额反而比预期高——我猜是因为剩下的场景因为更聚焦，做得更扎实了。

会议纪要那个砍得更干脆。两周日活掉到个位数之后我直接拉了一个复盘会，把数据摆出来：”日活3人、使用时长人均不到2分钟、生成的纪要0份被最终采用。”这些数字就够了，不用解释。

但我也承认，砍场景这件事，三年前的我是做不到的。那时候我觉得AI产品经理的工作就是把AI能力塞进尽可能多的场景里，场景越多显得越有价值。后来才明白，你塞进十个场景但八个没人用，不如只做两个但两个都真的帮上忙。甲方续签的时候不会数你做了几个场景，他会看哪个场景真的在用。

最后说一个我自己还在琢磨的问题：边界画在哪，是个动态的事。

去年合同审核的规则库是260条，今年客户想加到400条。加了之后AI的审核覆盖范围更大了，但准确率会不会下降？下降了怎么办？是扩大边界让AI审更多但偶尔出错，还是保持现有边界确保高准确率？

这个问题没有标准答案。客户说想要更多覆盖，法务说别降低准确率，研发说加规则需要时间。我现在的做法是每加一批规则就跑一轮评测，准确率掉到阈值以下的就回退。但这个过程挺磨人的——你得一直在”做更多”和”做更好”之间找平衡，而且这个平衡点会随着客户需求和模型能力的变化不停地移动。

做AI产品三年，如果只能留一句话，我会说：别急着想AI能做什么，先想清楚让AI只做什么。这个”只”字，是我花了两个死掉的场景和三个月的沉没成本才学会的。