一句被用滥的话
"上大模型"成了很多企业的标配动作。管理层一句"我们也得用 AI"，下面就开始找场景往模型上套。但我们见过太多项目，模型很先进，落地点很尴尬——比如花几个月训了个模型去做原本几行公式就能算准的事，或者把模型塞进一个出错要担责的流程，最后没人敢用。根子在于：它本不该用 AI，是被"锤子思维"硬按上去的。
我们给客户划三条线
第一条：能用规则解决的，别上模型。
固定流程、明确条件的判断，写 if-else 比调模型更稳、更便宜、可审计。AI 不是用来替代确定性的——它擅长的是"模糊、不确定、靠人脑也费劲"的那类事。我们内部有个粗暴的判断法：如果这件事一个实习生照 SOP 培训半小时就能做对，就别上模型。上模型的理由只有一条——规则写不清或写起来太贵。
第二条：要担责的决策，留人在环。
合同审批、放行指令、安全操作，模型可以建议，落子必须人拍板。我们把这类叫"人兜底节点"。这不是不信任模型，而是责任结构决定了——出错时得有人能解释为什么、能担后果。把模型推到担责链条的最末端，既不符合合规，也会让一线的人本能地不信任它。正确姿势是模型做初筛和排序，人做最终确认。
第三条：数据出不了门的事，先谈部署。
涉及核心工艺、涉密数据、个人信息的场景，公有云大模型直接用有合规风险，轻则数据出境违规，重则核心 know-how 外泄。私有化或本地推理要先于功能讨论。我们遇到过客户功能聊了三轮，最后卡在"数据不能出内网"上推倒重来——如果第一条线就把部署形态定下来，后面就不会白忙。
一个对照
| 场景 | 该不该上 AI | 理由 |
|---|---|---|
| 工单自动分类 | 该 | 模糊、量大、容错高 |
| 财务报表勾稽 | 慎 | 错不得，需人核 |
| 设备异常初筛 | 该 | 先做提醒再人工确认 |
| 核心配方优化 | 先谈部署 | 数据敏感 |
| 固定税率计算 | 不该 | 规则明确，写死即可 |
| 简历初筛排序 | 慎 | 涉及公平，需留痕 |
后两行是我们补的常见误用——前者是典型的"锤子找钉子"，后者是合规留痕要求高、不能黑箱决策。
收尾
AI 的价值不在"能不能做"，在"该不该做"。划清边界，比盲目铺开更专业。
金兰信息——把 AI 用在它真正擅长、且风险可控的地方。