在实际开发中最频繁听到的问题不是“AI 能做什么”而是“这件事到底该不该用 AI 做”。很多人一看到新模型、新工具就急着往业务里塞结果要么效果不稳定要么成本失控要么维护成本比传统代码还高。判断一个任务是否适合引入 AI本质上不是看模型多强而是看任务的失败模式、评估难度和成本空间是否匹配 AI 的特性。这篇文章会从工程视角给出一个可以复用的决策框架。读完你可以用它给候选任务打分用最小可行性验证消除主观判断再按工程化顺序落地并知道上线后哪些信号说明决策做错了、应该怎么排查。1. 先理解“该不该用 AI”本质是成本和失败模式的权衡1.1 为什么很多任务不适合 AIAI 模型是概率系统不是规则系统。传统代码对同样输入永远返回同样输出而模型会受提示词、温度参数、上下文长度、模型版本、甚至输入顺序影响。只要任务要求“结果必须百分百确定”AI 就天然有风险。典型场景包括用户手机号校验、订单金额计算、库存扣减、权限判断。这些任务看似简单一旦交给模型会出现两个问题一是模型无法保证每次都返回合法结果二是生成错误后很难定位原因。规则代码可以用单测覆盖模型错误却很难系统化复现。所以判断流程的第一步不是问“模型能不能做”而是问“这个任务允许出错吗”。1.2 判断 AI 适用性的四个核心维度实际评审一个任务时我会先看四个维度第一输出是否允许近似。如果下游系统要求严格的 JSON 结构、枚举值或精确数值模型输出必须再经一层解析和校验这部分工作成本经常被忽略。第二可接受错误率。不同业务对错误率容忍完全不同。内容摘要允许个别信息点遗漏但医疗建议、合同条款解析不允许关键信息错误。第三规则能否穷举。如果业务规则可以用条件判断完整写出来就直接写规则。规则写不出来或写出来要维护上百条分支才值得考虑 AI。第四是否具备评估数据。没有数据就无法量化效果所谓“效果不错”就只停留在 demo 阶段。数据不只是样本还要有标注结果和评估指标。这四个维度决定了一个任务能否用 AI而成本和延迟只决定用什么方案。判断维度偏向传统代码偏向 AI输出确定性字段强校验完全确定允许内容生成结构固定错误容忍度错误不可接受允许小比例误差规则覆盖规则可穷举规则边界模糊数据反馈无样本、无标注有持续数据和反馈闭环2. 用一张评分卡快速判断任务是否适合 AI2.1 评分卡设计与打分标准主观讨论“适不适合”没有效率建议直接打分。每个维度打 1 到 5 分标准要具体到可执行避免不同人打出来的分差太大。维度1 分3 分5 分输出确定要求输出必须精确匹配不能有变体结构固定内容允许用词变化输出本身就是开放式文本错误容忍度错误会导致资损或安全事故允许 5% 以内的非关键错误允许 10% 以上内容错误且可后置修正规则可穷举性规则完全明确分支写不完也能抽象规则能覆盖大部分剩余靠人处理规则无法穷举依赖语义理解数据与反馈没有历史数据也没有标注有离线数据但缺少在线反馈有持续数据回流和人工反馈渠道成本与延迟单次成本必须极低响应必须毫秒级有预算可以接受秒级响应可接受较高成本和分钟级任务2.2 计分方式与三个典型示例五个维度各乘权重可以更贴合业务。简单场景直接取平均分即可。下面给出一个带权重的示例WEIGHTS { output_certainty: 0.3, error_tolerance: 0.3, rule_exhaustive: 0.2, data_feedback: 0.1, cost_latency: 0.1, } def score_task(items, weightsWEIGHTS): total 0.0 for key in weights: total items[key] * weights[key] return total三个真实场景可以验证这套评分卡客服工单分类。输出类别固定允许小概率分错规则边界随时间变化且有历史工单可做标注。综合分通常在 3.5 分以上适合用 AI。手机号归属地解析。输出必须准确规则能通过号段表完全维护错误会直接导致业务错误。综合分通常在 2 分以下不适合用 AI。代码注释生成。输出是自然语言没有严格正确标准规则无法覆盖语义场景适合 AI。综合分通常在 4 分以上。2.3 评分低于多少该放弃我个人不建议设死板阈值但可以参考这个边界总分低于 2.5 分先不要引入 AI2.5 到 3.5 分之间需要先做小成本验证再决定高于 3.5 分可以正常立项。低于 2.5 分不是模型能力不行而是任务的评估成本和失败代价太高。即使模型准确率达到 99%剩下 1% 的错误也可能让整个系统不可用。这时候应该把精力放在优化规则或重构流程上而不是押注模型。注意评分卡解决的是“值不值得试”不是“能不能用”。评分高只说明值得进入验证阶段不说明可以直接上线。3. 判断之后用最小可行性验证消除主观偏差3.1 最小验证流程评分卡属于静态判断模型实际效果必须靠实验数据说话。最小验证流程可以控制在三天以内核心是五个步骤定义输入输出、准备小样本集、设定基线指标、跑批量验证、对比决定去留。这五步的目标不是做出一个完美系统而是回答三个问题模型能否稳定解析输入输出是否能被下游消费错误率是否在可接受范围内。在验证阶段不需要搭复杂服务写一个离线脚本直接调用模型接口即可。学习环境可以在 Jupyter 或本地脚本中完成生产环境才需要考虑服务化、缓存、限流和监控。3.2 验证样本集要覆盖三种类型样本集不能只选“模型表现好”的例子。至少要包含三类正常样本、边界样本、异常输入。正常样本用于判断主流程效果。边界样本包括长文本、歧义表达、中英文混合、特殊符号。异常输入包括空字符串、纯数字、格式完全不符合预期的内容。没有覆盖这三类的验证结果不具备参考意义。下面是一个工单分类验证样本的 JSON 示例[ { input: 我的订单已经付款了什么时候发货, expected: order_status }, { input: 可以改一下收货地址吗, expected: address_change }, { input: 1234567890, expected: unknown }, { input: , expected: empty } ]这里expected是期望类别empty和unknown用于验证模型是否会在异常输入上强行输出业务类别。3.3 一个可直接参考的批量验证脚本下面的脚本使用兼容 OpenAI 协议的客户端通过环境变量配置接口地址和密钥只用于验证阶段不直接作为生产代码。import os import json from openai import OpenAI client OpenAI( base_urlos.getenv(LLM_BASE_URL), api_keyos.getenv(LLM_API_KEY), ) SAMPLES [ {input: 我的订单已经付款了什么时候发货, expected: order_status}, {input: 可以改一下收货地址吗, expected: address_change}, {input: 1234567890, expected: unknown}, {input: , expected: empty}, ] SYSTEM_PROMPT 你是客服工单分类器。只输出类别名称不要输出解释。 def predict(text: str) - str: response client.chat.completions.create( modelos.getenv(LLM_MODEL, gpt-4o-mini), messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: text}, ], temperature0, max_tokens10, ) return response.choices[0].message.content.strip() def evaluate(): total len(SAMPLES) correct 0 empty_output 0 for sample in SAMPLES: try: result predict(sample[input]) except Exception as exc: print(调用异常:, sample[input], exc) continue if not result: empty_output 1 elif result sample[expected]: correct 1 else: print(错误分类:, sample[input], -, result, 期望, sample[expected]) print(正确率: %d/%d % (correct, total)) print(空输出数量:, empty_output) if __name__ __main__: evaluate()脚本里的temperature0很关键。验证阶段要把随机性降到最低否则同一个输入跑两次结果不同指标就不可复现。max_tokens10限制了输出长度避免模型生成多余解释。如果模型对空字符串、纯数字这类异常输入也输出了业务类别说明需要增加系统提示约束或者在下游加拒绝逻辑。3.4 定义成功基线和评估指标验证前必须明确什么叫“成功”。常见指标包括准确率、格式合法率、空响应率、平均延迟和单次成本。超过一半的 AI 项目在验证阶段失败不是模型不行而是没有定义指标导致全靠主观感受判断。指标含义建议最低标准准确率预测结果与期望一致的比例视场景而定通常不低于 85%格式合法率输出可被 JSON 或枚举解析的比例95% 以上空响应率模型没有输出的比例低于 2%平均延迟请求到响应的时间低于业务容忍上限单次成本每次调用的 token 费用低于规则成本注意不要只验证程序能跑通还要验证输入、输出、异常分支和日志是否符合预期。验证脚本输出的每个错误分类都应该人工查看一次从中判断是提示词问题、样本标注问题还是模型能力问题。4. 任务确实适合 AI 时的工程落地顺序4.1 先选提示词方案再考虑微调验证通过后不要直接进入微调。绝大多数任务先用提示词解决把系统提示写清楚给出输入输出示例用少量样本测试稳定性。提示词方案解决不了时再考虑微调。微调适合输出格式非常固定、提示词难以约束、或者需要模型模仿特定风格的任务。但微调需要准备高质量标注数据还要维护训练流程和模型版本成本远高于提示词方案。方案适用场景成本维护难度提示词任务边界清晰少量示例即可稳定低低少量样本示例需要模型模仿特定输出格式低中微调提示词无法稳定满足格式或语气要求高高RAG答案依赖私有知识库需要引用来源中中4.2 数据准备与评估集划分任何 AI 任务落地前都要沉淀一套评估集。评估集不等于训练集它在日常迭代中保持不变用来判断每次提示词或模型版本变更是否带来效果回退。建议将数据按时间切分用老数据评估历史效果用新数据评估当前效果。如果只使用同一批数据反复调试大概率会出现过拟合提示词的问题也就是换一批真实输入后效果明显下降。评估集要包含输入、标准答案、可接受范围。例如文本摘要任务标准答案不一定是唯一句子可以设置“必须保留”的关键点和“禁止出现”的错误点这样评估更接近真实业务。4.3 上线前必须定义降级方案AI 服务不可能永远正确。生产环境必须设计降级路径模型输出置信度低时怎么办模型接口超时怎么办模型接口完全不可用时怎么办。常见的降级策略有三类规则兜底、缓存命中、人工处理。对强约束任务可以先做规则校验校验不通过就拒绝 AI 结果并走规则流程。对高并发场景相同输入直接走缓存。对内容生成任务可以设置审核队列低置信度结果进入人工确认。ai_classifier: fallback: rule_engine_enabled: true cache_enabled: true manual_review_enabled: true threshold: confidence: 0.85 circuit_breaker: error_rate: 0.1 window_seconds: 60这个配置示例描述了一个分类服务的降级策略置信度低于 0.85 进入人工审核近 60 秒错误率超过 10% 触发熔断避免故障扩散。4.4 成本、延迟与在线监控指标上线后不能只看业务指标还要看成本指标和稳定性指标。成本指标包括每次请求的 token 消耗、credits 消耗、月度费用趋势。稳定性指标包括调用成功率、平均时延、P95 时延、空响应率、降级触发次数。成本失控是 AI 项目的常见问题。模型输出长度、请求上下文长度、重试次数都会放大成本。建议在日志中记录每次请求的输入 token 数、输出 token 数和模型名按业务模块统计费用才能在成本升高时快速定位。监控项告警条件处理思路调用失败率超过 5%检查模型服务、网络、限流P95 延迟超过 3 秒减少上下文切换更小模型单次请求成本超过预算阈值缩小 prompt开启缓存降级触发次数持续增长检查模型效果和输入分布变化5. 常见“误判”和排查路径5.1 现象一AI 能跑通 demo但线上效果不稳定demo 阶段样本量小挑选的都是“看起来合理”的例子。线上环境输入分布更复杂用户表达方式、输入长度、特殊字符都会影响模型输出。排查顺序先检查线上输入与验证样本的分布差异再检查系统提示词是否被业务代码动态拼接最后检查模型版本是否在验证后发生变化。如果线上输入分布与验证集差异不大但效果仍不稳定就需要检查是否对相同输入做了不同处理。模型接口可能因负载均衡路由到不同版本或者请求上下文被其他逻辑追加了内容。5.2 现象二幻觉导致业务出现错误结果幻觉是模型生成了看似合理但不符合事实的内容。业务场景越开放幻觉风险越高。完全消除幻觉不现实但可以在工程上限制影响范围。对高风险任务至少要增加三层防线第一层用系统提示限制输出范围要求只能根据给定知识回答第二层用代码校验输出检测结果是否包含非法枚举值第三层对关键实体做白名单匹配。ALLOWED_CATEGORIES {order_status, address_change, refund, unknown} def validate_result(text): return text in ALLOWED_CATEGORIES把校验从模型层剥离出来用普通代码执行是防止幻觉影响核心逻辑最有效的方式。AI 只负责生成候选结果规则代码负责决定结果是否可用。5.3 现象三成本高到无法承受成本问题通常不是模型单价造成的而是 prompt 太长、输出 token 过多、重复请求太多。排查时先看日志统计确认成本集中在哪些业务模块再检查平均输入 token 数和输出 token 数。解决手段包括使用更小模型、压缩系统提示、减少历史对话携带、加入缓存、对低价值请求降频。如果任务允许批量处理还可以用批量接口降低成本。5.4 常见的“认为适合但实际不适合”的任务关键词匹配任务。直接用规则或数据库查询更准确AI 反而可能语义扩展过度。纯计算任务。金额分摊、日期计算、百分比统计必须用代码。强一致性查询。订单状态、库存余量、用户权限数据来自数据库AI 不应该参与判断。完全开放的内容生成。没有约束的创作任务评估困难容易偏离业务目标。误判类型错误做法正确做法关键词匹配让模型判断文本是否包含关键词使用正则或倒排索引精确数值计算让模型计算折扣金额使用 BigDecimal 或数据库计算权限判断让模型根据对话判断用户角色从会话中读取用户角色字段状态查询让模型推断订单是否发货查询订单状态接口6. 最佳实践把 AI 决策变成团队评审清单6.1 用任务卡片固化判断过程每次评审新任务建立一张任务卡片内容包括任务描述、输入输出定义、错误容忍度、数据来源、评估指标、负责人、评审结论。这样后续有人提出“是否能用 AI”的问题时先看卡片而不是重新讨论一遍。字段内容示例任务名称客服工单自动分类输入用户留言文本输出类别枚举值错误容忍度允许 5% 分类错误但退款类不可错数据情况有 10 万条历史工单无标注评估指标准确率、准确率、退款召回率评审结论可以先做最小验证再决定立项6.2 需要避开的三个坑第一个坑是没有基线就上线。规则代码的效果、人工处理的耗时都没有数据AI 上线后就算回归也没有参照物证明比原方案好。应该在引入 AI 前记录一个基线。第二个坑是只看演示不看边界。演示只证明模型在几个样本上表现好不代表真实输入分布下同样好。必须用足够覆盖度的样本集验证并明确模型在哪些输入上会失败。第三个坑是把提示词当作不维护的代码。提示词会随业务变化而失效需要版本管理、变更记录和效果回归。建议像管理代码一样管理提示词甚至通过配置中心下发。6.3 可以继续深入的方向决策框架只是第一步。长期实践可以往几个方向扩展把判定规则固化成团队内部评审流程把验证脚本沉淀为可复用工具把提示词、评估集、监控指标纳入统一平台管理。对做 Agent 或自动化业务的团队可以把这套判定逻辑写入系统设计评审让每个被 Agent 调用的子任务都明确回答“为什么这个步骤用 AI而不是规则”。这样可以避免 Agent 项目越做越复杂却说不清每个节点使用 AI 的收益。对技术栈偏 Java 的团队可以关注 Spring AI 这类生态框架它能帮你统一模型调用、提示词模板和向量库集成。但框架解决的是开发效率替代不了任务是否适合 AI 的判断。先判断再选工具顺序不能颠倒。这套判断框架适合作为团队习惯长期沉淀。每次评审都按维度打分、按验证数据决策慢慢就会形成一份适合自己业务场景的 AI 适用性清单。对于刚开始接触 AI 工程的同学建议从一个小任务开始把评分卡、最小验证、监控指标完整走一遍再扩展到更复杂的场景。