P6-1.2 作为阅读生成式 AI 中心案例的 LLM¶

Section ID: P6-1.2 Version: v2026.07.26

生成式 AI 包括图像生成、语音生成、视频生成、代码生成等多种流程。Part 6 不会深入处理所有这些流程。在这个 Part 中，我们把 LLM(large language model) 作为中心案例，阅读生成式 AI 的工作原理和使用结构。

把 LLM 放在中心案例的位置，并不是因为 LLM 就是生成式 AI 的全部。文本生成式 AI 最直接地在一个 Part 中展示下面这条流程。

flowchart TD
  A["用户请求"]
  B["LLM 回答产出物"]
  C["prompt 补强"]
  D["外部证据连接"]
  E["工具执行"]
  F["评价与运行记录"]

  A --> B
  B --> C
  B --> D
  B --> E
  C --> F
  D --> F
  E --> F

这条流程不会停在 LLM 制造回答。请求进入后，LLM 会先制造一个可以阅读和书写的产出物，但在真实服务中，还需要用更好的 prompt 控制这个产出物，或用外部文档补强证据，或接上工具执行和评价记录。

在图像或语音生成中，制造产出物并检查产出物 这个共同问题仍然存在。不过 Part 6 的代表路径是文本 LLM。先阅读文本 LLM，就能把 prompt、RAG、工具使用、AI agent、评价、运营约束连接成一条流程。

文本 LLM 适合作为代表案例，并不是因为输出是句子所以看起来容易。相反，句子产出物会在同一个画面中暴露用户在真实服务里遇到的多种问题。

LLM 不是生成式 AI 的全部，而是连接点¶

把 LLM 作为中心案例来阅读，并不意味着图像生成或语音生成不重要。Part 6 的目的不是按类型浏览整个生成式 AI，而是一路跟踪一个生成产出物在使用场景中怎样被补强、怎样被检查。

文本 LLM 很适合这个目的。用户请求、模型的中间输入、检索到的文档、函数调用参数、评价记录，都容易以文本或结构化文本的形式留下来。因此，读者可以练习不只看屏幕上的回答，还要一起阅读这个回答生成前后的痕迹。

生成式 AI 流程	共同问题	在 LLM 中特别容易看到的点
图像生成	必须检查产出物是否符合请求意图。	很容易用句子追踪 prompt 加入或删去了哪些条件。
语音生成	必须确认语气、发音和上下文适合性。	可以先把脚本、指示、安全标准拆成文本来看。
代码生成	必须确认执行结果和错误。	说明、代码、测试、执行日志会连接成一条流程。
文本回答生成	必须一起检查事实、证据、权限和格式。	会直接连接到 RAG、tool use、评价、运营记录。

因此，在 Part 6 中，LLM 不是 最重要的生成式 AI 这一结论，而是 生成、补强、执行、检查在一个画面中延续的代表路径。有了这个视角，后面出现的术语才不会像产品功能列表一样散开。

补强结构会随请求性质而变¶

用户请求	LLM 单独可以先做的事	为什么难以就此结束	需要的补强
`请告诉我退款政策`	制造自然的说明。	政策可能已经改变。	找到并接上最新文档。
`请计算这个金额的税`	说明计算方法。	数字计算即使错一位也会成为问题。	用计算工具确认数值。
`请给客户发送回复`	制作回复草稿。	实际发送需要权限和记录。	留下批准流程和执行记录。
`请评价这个回答是否安全`	制作自我检查句子。	没有评价标准时，检查会接近感觉。	接上标准表和人工检查。

这张表的重要点，不是说 LLM 能独自解决所有问题。正因为 LLM 能读取用户请求并制造产出物，所以哪里可以先用句子生成处理，哪里必须转交给检索、计算、批准、评价，会显得很清楚。Part 6 是练习阅读这条边界线。

因此，这里要纠正三个误解。LLM 不是生成式 AI 的全部，而是代表案例。生成式 AI 不是制造产出物就结束的技术，而是在使用场景中必须接上检查、补强和记录的结构。文本生成也不是单纯的写作功能，而是很容易连接到检索、工具、评价、运营结构的执行流程。

案例与示例¶

下面这些请求看起来都像 请制造回答，但需要的结构并不相同。

请求	可以先制造的产出物	卡住的地方	下一步要接上的结构
`请把会议内容总结成三行`	摘要文	如果依据已经在输入里，大体上只需调整 prompt。	格式指示、长度限制
`请总结我们公司的安全政策`	政策说明文	模型记忆或一般知识无法保证最新内部政策。	文档检索、证据引用
`请计算这个订单的运费`	计算说明文	必须准确计算实际订单金额、地区、优惠券条件。	数据查询、计算函数
`如果符合条件，请处理退款`	处理说明文	实际状态变更需要权限、批准和记录。	函数调用、批准、执行日志

这张表的四行，是之后 Part 6 目录的压缩地图。prompt 会调整产出物的格式和上下文。RAG 会接上外部证据。工具使用负责查询、计算和执行。AI agent 与 harness 会重复多个步骤，并把它们留下为记录。

直接应用一下¶

请阅读下面的请求，并把 只靠 prompt 可以先尝试的事 与 必须接上结构的事 分开。

请求	只靠 prompt 可以先尝试的事	必须接上结构的事
`请把这份公告改得柔和一点`	指定语气、长度、读者水平。	通常不需要额外结构。
`请按今天的汇率写报价单`	指定报价单格式和语气。	需要查询最新汇率和计算工具。
`请给客户发放优惠券并告知客户`	指定说明句的形式。	需要优惠券发放权限、执行 API 和记录。

把 LLM 作为中心案例来阅读，是因为这条边界很容易看见。文本回答是起点，真实服务则是在这个回答上接上证据、执行、评价和记录以后才完成。

练习与示例¶

请看下面的请求，并分别标出只靠 LLM 产出物难以结束的一个理由。右侧列是检查说明。

请求	生成产出物	额外需要的结构
`请比较我们公司最新收费方案`	比较说明	最新文档检索
`请按本月使用量计算预计费用`	计算说明	实际计算工具
`请给客户发放补偿优惠券`	说明句	权限确认和执行记录

三个请求看起来都是文本回答，但需要的补强结构不同。必须有这个区分，才能把 LLM 看成阅读生成式 AI 服务结构的中心案例，而不是单纯的聊天工具。

这个区分建立后，就不会只把 LLM 看成 在聊天画面里写句子的功能。LLM 不是生成式 AI 的全部，而是让我们把生成产出物、补强结构、运营记录作为一条流程来阅读的代表案例。

检查清单¶

能说明 LLM 不是生成式 AI 的全部，而是代表案例。
能说明 Part 6 为什么以文本 LLM 为中心。
能区分图像、语音、视频生成与 LLM 之间的共同点和范围差异。