从功能型产品经理转型AI产品经理，你是否也陷入了堆砌规则的陷阱？面对大模型的泛化能力，传统的决策树思维反而成为枷锁。本文深度剖析AI产品设计中常见的规则堆砌现象，从模型边界预判、规则灵活性设计到及时重构止损，为你提供一套应对新技术范式的思维转换框架。

随着AI渗透到越来越多的行业，很多垂域公司会在底层模型的基础上做AI应用，所以有不少功能型产品经理陆续转为AI应用型产品经理。

我之前做过纯功能型产品，做过搜推策略，也搭过传统的对话机器人，从23年正式转型AI产品，主导了几个AI项目，遇到蛮多同事，不论产品还是技术，大家总会下意识地用“堆砌规则”的方式去限制和调教模型，包括我自己也出现过这一问题。

所以想写这篇文章来聊聊，为什么大家会趋于堆砌规则？在需求设计时如何避免？

一、为什么会有堆砌规则这一现象

并不是因为大家的能力不行，而是因为我们在面对一种全新技术范式时，底层思维和认知出现了时差。

1、难以割舍的“决策树思维”与“解题思维”

过去做C端或B端功能，我们的底层逻辑是决策树，习惯于穷举各类边界条件，画出复杂的流程图。遇到问题，我们的本能反应是解题——加一个字段、写一个 if-else、上一条硬性校验。当我们把这种对确定性的极致追求平移到充满泛化能力的AI上时，就会本能地试图用规则把模型框死。

2、把模型能力当成了“静止态”

早期的大模型能力边界窄，特别是在2023年左右，容易幻觉、容易脱轨，我们确实需要靠大量的业务规则来兜底和限制。但问题在于，模型的演进是动态的，而写进代码里的规则是静态的。随着模型能力边界的拓宽，那些曾经的规则自然变成了束缚。

而且如果没有提前预设模型的演进，即没有预留演进空间，代价往往是得重构，甚至可能相比从0-1做的代价还会更高。如果项目此时还在运转，KPI还在压，重构的事情无法推进，最后只能妥协成了打补丁，枷锁越来越重。

二、如何避免堆砌规则

核心还是在于思维转变，做好AI应用的一个核心思维在于：如何喂给模型足够高质量的上下文（Context）。

强调不堆砌规则，绝不是让业务裸奔，而是要求我们在下手前多思考一下：为什么要加这条规则？通过什么方式加最合适？如果未来模型变强了，这块规则好不好删？（tips：每次设计需求时，如果涉及加规则，用上面的问题反问自己）

基于之前的个人经验，我大概总结了三条“如何做”：

1、有意识得感知并预判模型边界

很多死规则的产生，纯粹是因为产品经理自己对“大模型到底能干什么”缺乏体感。解决这个问题并不难，核心就是保持对业界顶尖大模型的高频使用和测试。

这里可能会面临一个现实痛点：我们所在的公司受制于资源和合规等要求，用不了业界顶尖大模型。比如我所在的金融行业，通常要求私有化部署，甚至为了适配内部安全规范会对模型做一定的阉割。这就导致我们在内网实际使用的业务模型，与国内甚至世界Top模型之间，往往存在一到两个代际的差距。

但这绝不该成为我们堆砌规则的借口，反而应该成为我们的“开卷考试”。站在同一个时间截面看，代际差距确实存在，但拉长时间周期看，今天Top大模型能摸到的边界，大概率就是半年或一年后我们内部可用模型的基准线。换句话说，我们其实已经提前拿到了技术演进的剧本。 既然已经预知了未来，我们在当下的产品、架构设计反而应该更加克制且留有余地。

在具体的落地中，比较推荐采用“先放后收”的兜底策略： 在需求验证初期，先克制住写约束条件的冲动，尝试把端到端的任务全权抛给模型去处理，去探它的真实极限。当发现模型在某些特定的关键节点确实搞不定、兜不住时，我们再往后退一步，在现阶段模型能切实解决的问题空间内，精准地加上必要的规则限制。

2、保持规则预留的灵活性

为了方便大家更好地理解“灵活性”，我虚构一个“产品咨询”的案例来阐述。

假设现在团队遇到一些Badcase：AI没有理解清楚用户的意图，或解答的产品对象错误。下面我们分别从交互层、逻辑处理层来看看有哪些处理方式，以及它们的灵活性差异：

（1）交互层

在用户端预留一个固定的产品咨询入口，用户可以通过这个入口明确产品意图，并且可以快速关联具体的产品。也就是将模糊意图通过前端交互来让Query规范化，从而减少Badcase。这种方式非常适合本身意图占比高，且Query输入门槛较高的情况。

这类需求设计很常见，但存在灵活性的考量：这里的Query规范化，需不需要与逻辑处理层耦合？

• 方案A（解耦）： 前端只是把Query规范化了一下，至于怎么应答由模型自行决定。这样即使后面前端交互有各种改版，逻辑处理层也不会受羁绊，具备很强的灵活性。
• 方案B（耦合）： 交互时在前端带上固定标识传给后端，然后强行切入某条定制化的规则分支。这类处理方式的灵活性明显受限。如果这类“直通车”规则加多了，后期的维护成本也高。

当然，并不是说方案B绝对不能选，而是需要衡量ROI。比如项目架构本身的前置流程较长，通过传参直通能极大地提升响应速度，那方案B可能是合适的。但在设计时必须意识到这笔“技术债”，提前考虑清楚后续的维护成本。

（2）逻辑处理层

前面说到，做好AI应用的核心是注入高质量的Context。如果说交互层是前置帮用户把Query质量提高，那逻辑处理层就是怎么把背景信息、参考资料、具体任务清晰传达给模型，同时也不会有过多无效信息干扰它的判断或影响它的速度。

针对产品咨询这个案例，逻辑处理层通常有以下几种处理方式：

• A. 引入增量数据： 与其写死规则，不如丰富Context。给模型喂入用户的个人记忆（如历史偏好、曾经咨询或购买过的关联信息）或当前的业务热门产品数据。让模型基于这些高质量的上下文自行推理，而不是靠规则去硬匹配；
• B. 提示词限制： 在Prompt里增加柔性的引导规则。比如当用户意图不明确时，要求模型主动进行追问澄清，或结合context给出几个合理的猜测选项供用户选择；
• C. 专门加一层意图识别： 如果前两者效果不佳，大家可能会本能地想加一层传统的“意图识别”来做分发流转，但我强烈建议慎用。 在LLM原生理解能力越来越强的今天，我个人认为传统的意图分类是落后且低效的。这是一个纯加法的工作，做加法容易，做减法极难。你的意图要定义到什么维度？你长期只会加这一个意图还是会越加越多？是加一整个产品维度的意图还是需要再细分到“产品推荐”“具体产品咨询”“产品对比”各个子维度意图？细分越多，你的分类器维护成本就越高，灵活性越差，等以后模型能力演进了想做减法也越难。越做到后面可能越会发现，你面临的不只是优化了，也就是我接下来会说到的第3点，你该重构了。

3、及时止损，按下停止键

当你发现堆砌的死规则越来越多，为了修复一类Badcase加了一条规则，结果这条规则又引发了新的Badcase，于是你不得不写更多的规则去给前面的补丁打补丁。这个时候，作为产品经理，请拉上技术团队，认真聊聊重构吧。

必须承认，重构并不是一件易事：

• 从心理上来说，它似乎是对我们过去劳动成果的一种否定，否定曾经的需求、否定曾经的技术选型。这和团队文化有关，如果无法接受或不愿承认团队曾经“犯错”，那这个团队毫无疑问也并不适合做AI。就像之前我在AB实验文章里提到的，实验失败本身就是一种有意义的结果，接受失败是做实验的必要条件；
• 从现状来说，可能面临数据带来的“虚假繁荣”。 项目已经在线上跑起来了，技术数据看着还不赖，甚至准确率还挺高。但背后容易被我们忽略的现实情况是：用户试了几次就会清楚地知道哪些问题你答得好，哪些问题你根本答不上来。久而久之，他们不会再问你答不上来的问题了。你的高准确率，其实是用户主动降低预期后形成的“信息茧房”。 这种没有被戳破的数据泡沫，也会让团队丧失重构的动力；
• 从成本来说，重构的成本可能比从0-1做还高，在不能停掉现有业务的前提下，你需要“边跑边换轮子”。这种要在新旧两套体系间兼容、分流、防止线上出Bug的折腾，远比在一张白纸上写代码痛苦得多。

所以，重构的决策很难做。但如果你是产品或者团队leader，你需要有这样的魄力。因为 AI 技术在狂飙，带着沉重的规则包袱去追赶大模型的新能力，只会越跑越慢，最终被用户抛弃。

三、写在最后

我始终不希望用一套方法论来“指导”大家，因为每个项目的context不同，更多是希望给大家带来不一样的视角和思考。

今天文章里所说的垂域AI，仅限于本身用户是愿意在你这里获取高自由度的非标准答案的。如果用户只愿意在你这里获取标准答案（比如客服AI），那就又是另一个可以再写一篇文章的故事了。