在引入 LLM 之前先问的六个问题
2026 年 7 月 22 日，工程师 Cameron Palmer 在 Medium 撰文，提出一份务实的工程决策清单。
核心观点
不是所有问题都适合用 LLM 解决。很多任务用确定性规则、查表、正则、传统分类器或简单检索就能更便宜、更快、更可靠地完成。
LLM 的隐性成本
| 维度 | 代价 |
|---|---|
| 成本 | token 计费，规模化后显著 |
| 延迟 | 网络 + 推理时延 |
| 可靠性 | 输出不确定，难以保证一致 |
| 评测 | 难以像确定性代码那样精确测试 |
决策框架（该不该用 LLM）
- 任务的容错空间有多大？
- 是否要求确定性输出？
- 延迟与单次调用成本是否可接受？
- 有没有更简单、可验证的基线方案？
启示
把 LLM 用在刀刃上，避免“为了用而用”，才能控制总拥有成本与可靠性风险。
AI Master 解读
核心事件
一篇文章提出“在引入 LLM 之前先问的六个问题”，帮团队判断到底需不需要 LLM。
行业影响
在“什么都想接个 LLM”的热潮里，这篇文章的价值在于踩了一脚理性的刹车：不是所有问题都适合用 LLM 解决。很多看似需要“智能”的任务，其实用确定性规则、查表、正则、传统分类器或简单检索就能更便宜、更快、更可靠地完成。LLM 带来的不只是能力，还有 token 成本、网络延迟、输出不确定性与评测难度。
这类“先问该不该用”的决策框架，本质是在帮工程师做成本—收益—风险的权衡：任务的容错空间有多大？是否要求确定性输出？延迟与单次调用成本是否可接受？有没有更简单、可验证的基线方案？只有当这些问题的答案都指向“确实需要生成式能力或难以规则化”时，LLM 才是合适的选择。
这与近期业界对“LLM 不是万能锤”的反思一致：把 LLM 用在刀刃上，而不是为了技术时髦而强行套用，才能真正控制系统的总拥有成本与可靠性风险。
AI Master 建议
立项时为每个“拟引入 LLM”的功能写一份简短的“该不该用”论证：明确容错空间、确定性要求、延迟/成本预算与可验证的简单基线；能用规则或传统方法稳定解决的，优先用更轻量的方案，把 LLM 留给真正需要生成与泛化能力的环节。