一、基本原理（先讲清楚它是什么）
大语言模型（LLM）本质上是一个文本生成器。给定一段输入，它根据训练时学到的统计规律，一个词一个词地往后接，直到输出结束。它不是数据库，不是计算器，也不是真的"理解"了你的意思。
它之所以看起来很聪明，有两个原因：
- 训练数据量大。公开网页、开源代码、技术文档、书籍、论坛帖子，几乎所有公开的文本都进过训练集。
- 上下文窗口大。现代模型能同时看到几千到几百万字的输入，可以把整段对话、整个代码文件作为参考来续写。
但它生成的机制永远是"猜下一个最可能的词"，所以它不会主动停下来告诉你"我不知道"------在信息不足的情况下，它会顺着统计规律编一个看起来合理的答案，这就是通常说的幻觉。
有一个关于幻觉的基准测试（Earn an Honest Dollar，2026-09）：让模型从网页里抽取商品价格、作者等字段，页面里故意把一些字段留空。不加约束时，模型对空字段的编造率是 70.7%；只要在提示词里加一句"页面里没有的值填 null，不要猜测"，编造率直接降到 20.2%。说明幻觉不是无解的，但需要明确约束。
二、它擅长做的事
下面几类活，LLM 的产出质量相对稳定，可以放心作为辅助工具使用。
1. 写样板代码
CRUD 接口、参数校验、分页查询、Excel 导出、邮件发送、单元测试这种有固定套路的代码，LLM 几分钟能出一版能跑的。你只需要把表结构、字段名、运行环境说清楚，它生成的代码改改变量名就能用。
2. 读代码
接手老项目、看别人写的方法、理解一段没注释的逻辑，把代码贴给它，让它用大白话讲清楚这段是干什么的、有哪些边界情况，比自己一行行啃效率高很多。
3. 排查报错
把完整的错误堆栈贴给它，它一般能给出几条靠谱的排查方向。注意是"方向"，不是结论，最终还是要自己验证。
4. 零碎工具活
写正则、改写 SQL、翻译英文文档、给变量/接口起名字、写注释、写 commit message。这类任务对错一眼就能看出来，效率提升最明显。
5. 起稿和搭骨架
从零写一个东西是最费劲的。LLM 先给你搭个架子，哪怕有错，你在它基础上改，也比面对空白文件起步快。
一句话总结：套路越固定、验证成本越低的活，它越好用。
三、它的边界和常见问题
下面这些坑在实际开发里反复出现，要提前知道。
1. 会编造不存在的 API、类、方法、参数
这是代码场景下最常见的幻觉。它生成的代码语法没问题、逻辑读起来通顺，但框架里根本没有那个方法，或者第三方库没有那个参数，或者某个 Composer 包压根不存在。原因很简单：它没在你的环境里跑过，只是在照着它见过的代码模式拼接。
2. 版本信息滞后
训练数据有截止日期。你用的框架最新版改了用法、某个 PHP 版本废弃了某个函数、某个扩展在你环境里没装，它不知道。你不提前说清楚约束，它就按自己见过的版本给你写。
3. 精确计算不可靠
算数、金额计算、日期边界、正则的贪婪/非贪婪匹配，这些要求分毫不差的事，它容易出错。它不是计算器，是文本生成器，数值计算必须用代码本身跑，不能信它口算出的结果。
4. 长上下文不等于真的都用上了
模型标称的上下文窗口（比如 128K、1M）是它"能看到"的上限，但不代表它能稳定用好每一段内容。研究（"Lost in the Middle"，Liu et al., TACL 2024）发现，信息放在开头和结尾模型记得最牢，塞在中间的内容容易被忽略。实际使用中，上下文用到标称上限的 60%~70% 时，回答质量就已经开始下降。不要指望把整个项目代码塞进去就能让它完全理解。
5. 它没有记忆，也不会自己验证
每次请求对它来说都是独立的。上一轮说过的东西这一轮没带上，它就不知道。如果不给它配工具，它不会真的去跑代码、查数据库、调接口，它只会在文本层面推断。"看起来对"和"真的是对"之间，还差一次实际运行。
6. 代码能跑不代表符合规范
Linux 内核社区 2026 年 9 月有过一轮讨论，维护者吐槽 AI 生成的补丁：代码能跑，但编码风格不符合内核规范、抽象层次混乱、边界条件处理粗糙。不过同一批维护者也承认，让 AI 读代码找 Bug 效果不错。生成容易，验证难。
7. 安全风险不可忽视
2026 年 9 月有安全事件显示，部分 AI 编程工具的代码索引功能会把本地工作区完整上传到云端，即便关闭开关也可能存在后台上传的情况。此外有安全研究表明，攻击者可以在项目配置文件里埋隐藏指令，诱导命令行 AI 工具执行恶意操作、泄露本地密钥。生产环境的密钥、客户数据、核心业务代码，不要随便贴给来源不明的 AI 服务。
四、工程上的使用建议
知道了边界，就知道怎么兜底。下面是实际工程里可以直接照着做的几点。
1. 约束写死，不要让它猜
提问时把运行环境、PHP 版本、可用的类库、字段名、数据来源、边界情况说清楚，最后加一句"不确定的地方直接说不知道，不要猜测"。前面提到的实验已经验证，这一句话就能把幻觉率砍掉一大半。
示例对比：
差：写一个订单导出功能
好：用 PHP 8.2、ThinkPHP 8.0，只用 PhpSpreadsheet，
不要发请求，不要用 exec，字段是 id/order_no/amount/created_at，
amount 单位是分导出时转元，中文文件名处理乱码问题。
不确定的地方直接说明，不要猜测。
2. 要结构化结果，不要要自由文本
当你需要把 LLM 的输出接到程序里处理时，不要让它写一段话然后用正则去抠。直接用函数调用（Function Calling）或者模型原生的结构化输出（JSON Schema），让它按固定字段返回。
实测数据显示（掘金三方评测，2026-04）：
- 纯提示词要求返回 JSON，成功率约 85%~92%；
- 使用 Function Calling，成功率在 95% 以上；
- 使用模型原生 Structured Output，生成阶段就会校验格式，稳定性最高。
代码示例：
// 不推荐：正则抠 JSON，用户名里带引号就会 parse 失败
preg_match('/\{.*\}/s', $reply, $m);
$data = json_decode($m[0], true);
// 推荐：走 Function Calling，直接拿结构化参数
$toolCalls = $response['choices'][0]['message']['tool_calls'];
$args = json_decode($toolCalls[0]['function']['arguments'], true);
3. 查真实数据要配工具，不要让它背
涉及订单、库存、价格、配置项这类真实数据，不能让模型凭记忆回答，必须给它配上对应的查询工具（数据库查询、API 调用），让它通过工具拿数据，再基于真实数据回答。工具的参数 schema 要写细，枚举值、类型、必填字段都标清楚，减少参数填错的概率。
4. 关键节点必须人工核对
涉及金额、权限、删除、对外发送（邮件/短信/推送）的代码和逻辑，模型的输出必须人工过一遍再上线。该跑测试跑测试，该走流程走流程。
5. 重要信息放两头
由于模型对中间位置的信息记忆较弱，最关键的指令、约束、上下文尽量放在提示词的开头或结尾，不要埋在一大段文本中间。
6. 管好数据
公司的代码、密钥、客户数据不要上传到个人账号的第三方 AI 服务。公司内部如果有部署合规的内部模型，优先用内部工具。
五、对普通开发者的影响
LLM 目前的定位，比较贴切的说法是"初级实习生"：手快、知识面广、不抱怨，但判断力差、容易自信地犯错、不会主动承认自己不懂。
对PHP 开发者（其他语言应该也是一样的）来说，影响是双向的：
- 写样板代码、查资料、写文档这类"体力活"的价值在下降，这块它确实做得又快又便宜。
- 把需求描述清楚、把约束说严谨、把边界想全、把代码质量兜住，这些能力的价值在上升。
- 以后的工作更像是"带实习生"：你要会给它派活、会挑它的错、会在它翻车的时候顶上去。
不用神化它，也不用排斥它。把它当一个随时可用、但必须人工复核的工具，是目前最务实的用法。