别再为了追求 AI 标签而把简单的逻辑判定交给大模型了
我们需要明确一个核心认知：确定性的判定逻辑与大语言模型（LLM）的推理能力根本不是一回事。if 语句是确定性的，响应时间在毫秒级，且运行成本几乎为零；而模型调用是概率性的，它伴随着不可控的延迟，并且每一词的生成都在消耗资金。
在实际构建工作流时，我建议开发者严格执行一套拆分标准，将“匹配”与“理解”彻底分开。
首先，凡是规则明确且定义清晰的场景，必须优先使用传统代码，比如正则表达式（Regex）、数据库查询（DB Lookup）或简单的布尔逻辑。举几个具体的例子：校验邮箱格式是否合法、检查购物车金额是否达到满减阈值、验证优惠券的过期时间戳，或者对一个列表进行简单的升序排序。这些场景不需要 AI 去“理解”语义，只需要程序进行精准的“匹配”。如果你在这里调用 LLM，你实际上是在用一个昂贵的概率引擎去模拟一个简单的开关。
其次，只有在需要主观判断或处理模糊输入的场景下，才应该引入 AI Agent 或 LLM。例如：分析用户投诉邮件中的情绪极性（愤怒、失望或满意）、将非结构化的长文本进行多维度分类，或者将枯燥的产品规格书转写为具有煽动性的营销文案。这些任务的特点是没有绝对的“正确答案”，需要模型在语义空间中进行权重计算。
为了让大家更直观地感受到差异，我们可以看一个判定工单是否“紧急”的实战对比。
如果你的业务定义中，“紧急”仅仅是指文本中包含了特定的关键字，那么最优雅的方案是直接写一个正则匹配。在 JavaScript 中，你只需要一行代码：const isUrgent = (text) => /紧急|故障|崩溃/i.test(text);。这段代码的执行速度极快，且在任何环境下结果永远一致。
但如果你的业务需求升级了，要求 AI 能够通过分析用户的语气、上下文语境来判断对方是否处于愤怒状态，且问题是否会对业务产生严重影响，这时候才轮到模型出场。你需要构造一个类似这样的 Prompt："分析以下用户反馈的紧急程度，仅输出 'Urgent' 或 'Normal'。考虑语气和潜在业务影响。"，然后输入类似 "我的账户资金在过去两小时内莫名消失了，这简直是灾难！" 这样的文本。在这种场景下，AI 的语义分析能力才能发挥价值。
如果把简单的关键字匹配交给 AI，你不仅在增加不必要的网络延迟（Latency），还在为本不需要的推理成本买单。更糟糕的是，你把一个本该 100% 准确的判定，变成了一个概率问题。模型在版本更新（比如从 GPT-4 升级到 GPT-4o）后，可能会因为温度（Temperature）设置或权重调整，导致原本判定为 Urgent 的请求突然变成了 Normal，这种随机误差在金融或医疗等严谨场景下是不可接受的。
总之，在追求 AI 化的过程中，请记住：能用 if 解决的问题，绝对不要写 Prompt。
