第一性原理｜理解 LLM 的本质

LLM 怎么「思考」的

大语言模型的工作方式可以用一句话概括：逐个预测下一个 token。

接下来把这个词加入序列。再预测下一个，如此循环直到生成结束，这种方式被称为 。

理解这一点很关键，因为它说明了 LLM 的几个本质特征：

. 没有独立于输出的「思考」过程：L​LM 的推理就是生成本身。它不能先想好再说只能边说边想。这就是为什么让模型「一步步思考」会效果更好 — 你是在给它更多的「思考空间」，让它中间步骤来辅助推理。说起来，尽管新一代模型很多都带有显式的 reasoning 能力。依然脱离不了这个范式，

. 上下文就是全部记忆：L​LM 没有独立的记忆存储。它对当前对话的所有「理解」，完全来自于输入给它的。窗口之外的内容，对模型来说就是不存在的。

. 生成具有概率性：L​LM 每一步预测都是基于概率分布采样，这代表着一样的输入可能产生不同的输出。

的内容再喂回去继续生成。这个机制很强，但也天然带来一些局限，在 Coding Agent 里这些局限会被放大。因为软件开发是「长链路、强约束、强验证」的任务。

当前 Coding Agent 普遍出现的问题：

. 局部最优：一步一步「续写」。不等于全局规划

• 容易先写得很像、很顺，接下来在后面发现不对再补丁式修修补补。

• 多文件重构/架构调整这种「先规划后落地」的任务。 会变成边写边想，导致接口不一致、重复实现、遗漏迁移步骤。

• 对「最终能不能/CI」缺乏感知，除非你把测试结果显式喂回 agent 循环。

. 一旦走偏。会沿着偏差继续滚雪球

• 早期误读需求/误判代码库的约束，导致后面每一步都在错误世界观里自洽。

• 生成了一个不存在的函数名/类型后后续会越来越「相信它存在」，直到编译/运行时打脸。不过，

• 在长对话、长任务里尤其明显：越写越像「另一个项目」。老实说，

. 输出是流式的。无法回头修改之前输出的内容

• 擅长「写新文件/新段落」，相对不擅长在复杂代码中做精确、最小化、局部一致的编辑。

• 容易倾向于「重写一遍」而不是「修改」，导致 diff 过大、review 成本高。

• 在需要保持大量不变量的仓库里尤其痛苦。其实，

. 满足约束的能力有限。而代码是强语法/强语义约束的

• 「看起来合理」的实现，经常在边界条件、并发、错误处理、资源释放上出错。

• 跨文件的符号解析、泛型/模板推导、宏/代码生成等，靠纯文本推断很容易漏。

• 复杂的重构没有 AST/语义工具辅助时错一个引用就全盘崩。