LLM实战指南：从text2json到Agent，拆解大语言模型的核心能力与边界
1. 从“强计算器”的比喻看LLM的真实能力边界
顶尖数学家将大语言模型（LLM）比作“强计算器但缺乏创造性思维”，这个比喻非常精准，也点破了当前很多人在使用LLM时最大的误解。很多人期待LLM能像人类一样“灵光一现”或进行“颠覆性创新”，这其实是对其能力边界的一次误判。
LLM更像是一个拥有海量知识、能进行复杂模式匹配和概率推理的超级计算器。它能处理自然语言这种极其复杂的“算式”，并给出一个高概率正确的“计算结果”。它的“强”体现在对已有知识的快速检索、重组、翻译和格式化输出上。比如，你让它写一份项目计划书、将一段技术描述转换成JSON格式、或者根据数据库表结构生成SQL查询，它都能做得又快又好。这正是“LLM写作助手”、“text2json”、“text2sql”等应用场景的核心价值——将一种结构化或半结构化的信息，高效、准确地转换成另一种格式。
但“缺乏创造性思维”这个判断，指的是它难以进行真正的、从0到1的、基于深刻理解的原创性推理。它无法像数学家一样，从一个全新的公理出发，构建一套前所未有的理论体系。它的“思考”始终建立在训练数据所涵盖的概率分布之上。理解这一点，是高效、正确使用LLM的前提。你不会指望一个计算器去证明费马大定理，同样，你也不应指望LLM去完成需要本质性概念突破的任务。
所以，这篇文章不是要争论LLM有没有创造性，而是想从一个实践者的角度，拆解清楚：在“强计算器”这个定位下，LLM到底能帮你做什么、不能做什么，以及如何绕过它的弱点，把它用在最该用的地方。无论是做开发的、写文档的、还是处理数据的，看完你应该能立刻判断，手头的活儿适不适合交给LLM，以及怎么交才能效率最高、翻车最少。
2. 拆解LLM的核心能力：它最擅长处理哪类“计算”？
既然把LLM看作“强计算器”，我们就要搞清楚它最擅长计算的“题型”是什么。从大量的实践和热搜词里提到的应用来看，它的核心优势区非常明确。
2.1 信息转换与格式化：从文本到结构数据
这是LLM目前最成熟、最稳定的能力之一。它本质上是在做“理解”和“映射”。
- 文本转JSON/XML (text2json)：给你一段非结构化的产品描述或用户反馈，让LLM提取出品牌、型号、价格、优缺点等字段，并填充到预设的JSON模板里。这比写正则表达式或手动提取要快得多，容错性也更好。关键点在于，你需要提供一个清晰的“槽位”（slot）定义，也就是告诉LLM你要提取哪些字段，每个字段大概是什么类型的信息。
- 文本转SQL (text2sql)：用户用自然语言问“上个月销售额最高的产品是什么？”，LLM需要理解“上个月”、“销售额最高”、“产品”这些概念，并将其映射到数据库具体的表、字段和聚合函数上，生成正确的SQL语句。这里成功的核心不在于LLM多聪明，而在于你给它的“上下文”是否清晰：数据库的表结构（Schema）必须准确、完整地提供给LLM。这就是“sql-assista”类工具的核心逻辑。
- 代码转换与解释：将Python代码翻译成Java，或者为一段复杂的函数生成详细的注释。这同样是模式转换：从一种语法模式转换到另一种，或从代码模式转换到自然语言描述模式。
实操建议：做这类任务时，提示词（Prompt）就是你的“算式输入框”。一定要把“输出格式”和“输入约束”写清楚。例如，不要只说“提取信息”，而要说“请将以下文本中的公司名、职位、工作年限提取出来，以JSON格式输出，键名分别为company,position,years”。
2.2 内容生成与润色：基于模板和风格的“计算”
LLM是强大的内容生成器，但它的“创作”是基于学习到的海量文本模式。
- 写作助手：写邮件、写报告、写营销文案、写技术博客初稿。它可以根据你给的几个关键词和大纲，快速生成通顺、符合语法的文本。它的优势是速度快、风格稳定（如果你指定了风格）、没有写作障碍。但劣势是内容可能流于表面，缺乏独特的洞察和真正的情感。
- 摘要与扩写：将一篇长文总结成要点，或者将一个简单的点子扩展成一段详细的描述。这本质上是信息密度的“计算”和调整。
- 角色扮演与对话：通过“扮演 提示词”，让LLM模拟客服、导师、面试官等角色进行对话。这其实是引导LLM调用特定领域的对话模式和知识库来回答问题。
实操建议：不要指望LLM凭空给你一个惊艳的创意。把它当作你的“高级速记员”或“初稿生成器”。你需要提供核心观点、关键数据、行文逻辑（甚至详细大纲）和期望的风格。最好的工作流是：你出骨架和灵魂，LLM帮你填充血肉和皮肤。
2.3 复杂任务规划与分解：Agent的核心逻辑
这是“LLM Agent”和“LLM 自我进化”等概念试图突破的方向。单个LLM可能不擅长创造性思维，但我们可以设计一个系统，让LLM作为“大脑”来调度各种工具（计算器、搜索引擎、代码执行器、专业API等），从而完成复杂任务。
- 任务分解：用户说“帮我分析一下这个季度的销售数据，做个PPT”。LLM Agent可以将其分解为：1. 读取销售数据文件；2. 调用数据分析工具计算关键指标；3. 根据指标结果撰写分析摘要；4. 调用PPT生成工具，将摘要和图表排版。LLM在这里的作用是“理解意图”和“规划步骤”。
- 工具使用：LLM知道自己“算不了”数学题，但它可以生成代码调用Python计算，或者把问题格式化后交给专门的数学引擎。这就是“强计算器”调用“专用计算器”的过程。
- 反思与迭代：一些先进的Agent框架引入了“反思机制”。让LLM对自己或工具执行的结果进行评估，如果不符合要求，则调整策略重新尝试。这在一定程度上模拟了“试错学习”，但依然是基于目标定义的优化计算，而非无目的的探索。
实操建议：构建或使用Agent时，重点在于设计清晰、可靠的工具集（Tools）和任务规划逻辑（Orchestration）。LLM本身是其中相对“不可靠”的一环，需要用严格的输入输出规范、结果验证和错误处理机制把它包裹起来。避免让它做开放性的决策，而是让它做结构化的选择。
3. LLM的“计算”短板与常见故障模式
理解LLM不能做什么，和知道它能做什么同样重要。以下是它作为“计算器”的典型故障模式，也是你使用时主要的“翻车点”。
3.1 幻觉（Hallucination）：输出看似合理但完全错误的内容
这是LLM最著名的问题。就像计算器偶尔会给你一个看起来很像答案但实际是乱码的数字一样，LLM会自信地编造事实、引用不存在的文献、生成看似正确但逻辑漏洞百出的代码。
- 为什么发生：LLM的训练目标是生成“概率上最可能的下一个词”，而不是“事实正确”的词。当它遇到训练数据中不明确或存在冲突的领域时，它会倾向于生成流畅、符合语法，但内容可能虚假的文本。
- 如何应对：
- 关键事实核查：对于人名、日期、数据、公式、法律条款等关键信息，必须通过权威来源进行二次核实。
- 提供参考源：在提示词中要求LLM基于你提供的特定文档或数据来回答，并注明出处。
- 领域限定：不要在它不熟悉的专业领域（如最新、非常小众的学术发现）依赖它的“知识”，而应将它限定为“信息处理工具”，而非“知识源”。
3.2 缺乏真正的逻辑与数学推理
LLM可以解决训练数据中出现过的、模式固定的数学题，但对于需要多步、深度逻辑演绎或抽象数学证明的问题，它很容易出错。
- 为什么发生：它是在模仿人类写出的解题步骤，而不是真正“理解”背后的数学原理。问题稍加变化，或者将多个知识点交叉组合，它就可能失败。
- 如何应对：
- 复杂计算外置：对于复杂的数学、统计、逻辑推理，最好的方法是让LLM识别问题类型，然后生成代码调用专业的计算库（如NumPy, SciPy）或定理证明器去执行。
- 分步验证：要求LLM将推理过程一步步写出来，你人工检查每一步的逻辑是否合理。这利用了LLM的“格式化输出”能力，将黑箱过程白盒化。
3.3 上下文长度与注意力局限
即使是支持超长上下文的模型，其对远处信息的“注意力”也会衰减。它可能忘记你在几千字前提到的某个关键约束条件。
- 为什么发生：技术架构（如Transformer）的限制。模型在处理长文本时，无法对所有位置的信息给予同等关注。
- 如何应对：
- 关键信息重复：在长对话或长文档处理中，将最重要的指令、约束条件在提问时简要重申。
- 分段处理：对于超长文档，不要一次性全部输入。先让LLM进行分段总结，再基于总结进行全局分析。
- 使用向量数据库：对于知识库问答，将文档切片存入向量数据库，让LLM只检索最相关的片段作为上下文，而不是塞入全文。
3.4 提示词敏感性与输出不稳定
同样的任务，提示词微小的改动可能导致输出质量的天壤之别。输出也可能有一定随机性。
- 为什么发生：LLM的生成具有概率性，且对输入表述非常敏感。
- 如何应对：
- 结构化提示词：采用类似“角色-任务-步骤-格式”的模板来编写提示词，提高可重复性。例如：“你是一个资深Python程序员。请将以下函数重构，使其符合PEP8规范。输出只需要给出重构后的代码。”
- 少量示例（Few-Shot）：在提示词中提供一两个输入输出的例子，让LLM明确理解你的格式和要求。
- 设置确定性参数：在API调用时，将
temperature参数调低（如0.1或0），减少随机性，使输出更稳定。
4. 实战指南：如何像使用高级计算器一样用好LLM
基于以上分析，我们可以建立一套稳健的LLM使用心法。核心思想是：扬长避短，人机协同。你负责创造性、决策性和深度验证，LLM负责高强度的模式化劳动。
4.1 任务评估：这件事该不该交给LLM？
在开始写提示词之前，先快速做一个判断：
- 适合交给LLM的任务（它的“送分题”）：
- 格式转换（文本->JSON/XML/SQL/表格）。
- 文档润色、语法校对、风格统一。
- 基于模板的内容生成（邮件、报告、简单代码）。
- 信息提取与摘要（从固定格式文本中抽字段）。
- 简单的、有大量示例的问答（客服常见问题）。
- 作为Agent系统的“规划中枢”和“自然语言接口”。
- 需要谨慎或必须人工介入的任务（它的“易错题”）：
- 涉及关键事实、数据、法律、医疗的建议。
- 需要深度逻辑推理或数学证明的问题。
- 开创性的、无先例的创意构思（它只能组合旧元素）。
- 对输出结果有极高确定性要求的生产环节。
- 处理非常新颖的、训练数据中可能没有的概念。
4.2 提示词工程：写出清晰的“计算指令”
好的提示词是成功的一半。把它当作给一个能力极强但有点“轴”的助理写工作清单。
- 定义角色：首先告诉LLM它应该扮演谁。“你是一位经验丰富的软件架构师”、“你是一个严谨的学术编辑”。
- 明确任务：用清晰、无歧义的语言描述你要它做什么。“请将以下会议纪要的‘行动项’部分提取出来，并按照‘负责人’、‘任务’、‘截止日期’三列整理成Markdown表格。”
- 设定步骤：对于复杂任务，分解步骤。“第一步，先总结每个段落的核心观点。第二步，将这些观点分类。第三步，根据分类生成大纲。”
- 规定格式：明确指定输出格式。“请用JSON格式输出，包含
title,author,keywords三个字段。”“请输出纯代码，不要有任何解释。” - 提供示例：对于格式复杂或容易出错的任务，给出一两个输入输出样例（Few-Shot Learning）。
- 设定约束：告诉它不要做什么。“不要添加任何个人评论。”“不要使用Markdown标题以外的格式。”
4.3 工作流设计：将LLM嵌入你的生产流程
不要孤立地使用LLM，把它变成你工作流中的一个环节。
- 预处理：在把数据丢给LLM之前，先进行清洗、格式化。比如，将PDF文字提取出来并去除乱码。
- LLM处理：执行核心的转换、生成、摘要任务。
- 后处理与验证：这是最关键的一步。对输出进行自动化或人工检查。
- 自动化检查：对于代码，运行语法检查或单元测试；对于JSON/SQL，用解析器验证格式是否正确；对于数据提取，可以抽样核对。
- 人工抽查：尤其是关键任务，必须安排人工审核环节。建立检查清单：事实对吗？逻辑通吗？格式符合要求吗？
- 迭代优化：如果输出不满意，不要只抱怨LLM“笨”。分析是提示词不清晰？示例不够？还是任务本身超出了它的能力？调整后重新运行。
4.4 工具链整合：让LLM调用“专业计算器”
这是发挥LLM最大威力的方式。你不需要一个会自己发明微积分的计算器，你需要一个能按你指令调用“积分计算器”、“矩阵计算器”的超级控制台。
- 代码执行：让LLM生成Python脚本来处理数据、调用API、进行计算，然后在一个安全沙箱中执行它。许多AI编程助手（如Cursor）就在做这件事。
- 搜索引擎/知识库查询：让LLM根据你的问题生成搜索查询，获取实时、准确的信息后，再基于这些信息组织答案。这解决了其知识陈旧和幻觉问题。
- 专业工具API：在Agent框架中，为LLM配置图像识别、语音合成、数据库查询、科学计算等专用工具的API。LLM负责理解你的自然语言命令，并将其转化为一系列API调用。
数学家说LLM是“强计算器”，这个定位既指出了它的强大，也划清了它的界限。对于我们开发者、内容创作者、数据分析师来说，这恰恰是最实用的视角：我们不期待一个“万能AI”，我们只需要一个足够强大、足够好用的“智能处理引擎”。
把创造性、战略性的思考留给自己，把那些重复、繁琐、模式化的“计算”工作交给LLM。通过精心设计的提示词、稳健的工作流和强大的工具链，你能让它发挥出远超“计算器”的价值，真正成为提升个人和团队生产力的“倍增器”。下次当你对LLM的输出感到失望时，不妨先问自己：我是不是在让它做一道它根本不擅长的“数学题”？我有没有把这道题，转化成它最拿手的“计算”形式？