前端学 LLM

LLM 能做什么，不能稳定做什么

学习 LLM 最容易走向两个极端：一种是觉得它无所不能，另一种是因为它会出错就觉得它不可靠。更好的方式，是把它当成一种能力很强但边界明确的生成系统。

工程师不需要崇拜模型，也不需要低估模型。我们需要知道：哪些事情可以直接交给模型，哪些事情必须通过上下文、工具、检索、权限、评估和产品设计来补齐。

LLM 擅长做什么

LLM 最擅长处理语言和符号序列。这里的语言不只是自然语言，也包括代码、JSON、Markdown、SQL、HTML、日志和配置。

常见能力包括：

  • 聊天与问答。
  • 写作、改写、扩写、压缩。
  • 翻译和多语言表达。
  • 文档总结。
  • 代码生成和代码解释。
  • 信息抽取。
  • 格式转换。
  • 意图识别。
  • 文案生成。
  • 任务拆解。
  • 工具调用参数生成。

这些能力有一个共同点：输入和输出大多可以表示为文本或结构化文本。

LLM 很适合做“语言接口”

传统软件通常需要用户适应界面：用户必须知道按钮在哪里、表单怎么填、筛选条件怎么组合。

LLM 带来一个变化：用户可以先用自然语言表达目标，再由系统把目标转成操作、查询、草稿或工作流。

例如：

  • “把这段文案改得更适合 B 端官网。”
  • “总结这个 PR 的风险点。”
  • “从这份合同里提取付款条款。”
  • “根据当前页面客户信息生成一封跟进邮件。”
  • “帮我把这个 JSON 转成 TypeScript 类型。”

这类任务不是简单聊天，而是把自然语言变成产品能力入口。

LLM 不能保证事实正确

LLM 是生成模型，不是事实数据库。它会根据上下文生成看起来合理的回答，但“看起来合理”不等于“事实正确”。

它可能：

  • 编造不存在的链接。
  • 混淆相似概念。
  • 给出过期信息。
  • 在不确定时仍然用肯定语气回答。
  • 生成格式正确但内容错误的引用。

所以涉及事实的问题，不能只依赖模型内部知识。你需要引入检索、工具、引用来源、校验逻辑或人工审核。

LLM 不能天然访问最新信息

模型的训练数据有时间范围。即使模型知道很多历史知识，也不代表它知道今天发生了什么。

如果你的产品需要最新数据，比如价格、库存、新闻、政策、版本文档、账户状态、订单进度，就必须通过工具或检索系统把最新信息提供给模型。

对工程实现来说，这意味着：

  • 需要搜索工具或业务查询工具。
  • 需要把工具结果作为上下文传回模型。
  • 需要在回答里区分“模型推断”和“外部数据来源”。

模型本身不是实时浏览器。

LLM 不能天然记住所有历史

ChatGPT 产品看起来能记住上下文，但 API 层的对话并不是模型自动保存了一切。

在大多数 LLM API 里，每次请求都需要应用层提交上下文。你希望模型参考哪些历史消息，就要把哪些消息重新传进去。

这带来几个工程问题：

  • 历史消息会消耗 token。
  • 上下文窗口有长度限制。
  • 太长的上下文会增加成本和延迟。
  • 无关历史会干扰当前任务。
  • 旧指令可能和新指令冲突。

所以“记忆”通常不是模型真的记住，而是应用层存储、筛选、总结并注入上下文。

LLM 不能天然执行真实操作

模型可以说“我已经帮你发邮件了”，但除非你的应用真的提供了发邮件工具，并且执行了这个工具，否则它没有完成真实操作。

LLM 的输出只是文本或结构化指令。要执行真实操作，需要应用层：

  1. 定义工具。
  2. 让模型生成工具参数。
  3. 校验参数。
  4. 检查权限。
  5. 必要时请求用户确认。
  6. 执行工具。
  7. 把工具结果返回给模型或展示给用户。

这就是 Tool Calling 的意义。模型负责理解意图和生成参数，应用负责真实执行和安全边界。

LLM 不能天然理解你的业务规则

模型知道通用知识，但不知道你的公司内部规则、产品配置、用户权限、数据口径和流程约束。

例如：

  • 哪些用户可以查看哪些文档。
  • 哪些订单可以退款。
  • 某个字段在你们系统里代表什么。
  • 某个业务流程必须经过几级审批。
  • 哪些内容不能被发送给外部模型。

这些规则必须通过系统 prompt、业务上下文、工具权限、后端校验和产品流程体现出来。

不能因为模型“看起来懂业务”，就跳过传统软件工程里的权限、校验和审计。

能力边界决定架构设计

理解 LLM 的限制，不是为了少用它，而是为了正确使用它。

一个可靠的 AI 应用通常会把任务拆成几层：

  • 模型负责理解、生成、总结、改写、规划和参数生成。
  • 检索系统负责提供外部知识。
  • 工具系统负责访问真实世界和业务系统。
  • 应用层负责权限、状态、上下文、日志和成本。
  • UI 负责展示过程、暴露不确定性、收集用户反馈。
  • Eval 系统负责持续评估输出质量。

这样做的结果是：模型的长处被放大，模型的短板被系统兜住。

小结

LLM 能很好地处理语言、代码、结构化文本和开放式任务，但它不能天然保证事实正确，不能自动访问最新信息，不能无限记忆历史，不能自行执行真实操作，也不能天然理解你的业务规则。

把这些边界理解清楚，后面的 RAG、Tool Calling、Memory、Agent、安全和 Eval 就不再是额外复杂度，而是让 AI 应用真正可用的必要工程层。