Claude Code 辅助编写 Lua 脚本时与宿主环境的交互陷阱

上周三凌晨两点，我盯着服务器监控面板上那条平直的心跳线，整整沉默了五分钟。一个由 Claude Code 生成的 Lua 脚本，在 Wireshark 的 Lua 插件里运行了不到 40 毫秒，就让整个网络分析系统陷入静默，没有报错，没有崩溃日志，只有一片死寂。

那是一个只有 87 行的脚本，逻辑清晰、注释完整、变量命名堪称教科书级别。但它犯了三个致命的错误：调用了被 Wireshark 沙箱禁用的 os.execute、覆盖了全局表里的 DissectorTable 对象、还用 Lua 5.3 的 string.unpack 语法在 Lua 5.1 环境里试图解析二进制数据。

这不是 Claude Code 的问题。这是每一个用 AI 辅助编写嵌入型 Lua 脚本的开发者，都注定会遇到的问题。

核心结论是什么？ Claude Code 生成的 Lua 脚本默认假设自己运行在一个完整、独立、标准的 Lua 解释器里。但真实世界的 Lua 几乎从不独立运行，它寄生在游戏引擎里、网络设备里、数据库里、抓包工具里。这些宿主环境有自己的内存模型、API 白名单、全局变量依赖、线程限制和版本魔改。Claude Code 不了解这些约束，因为它看不到宿主。

这不是一次偶然的翻车。在过去十个月里，我在 Redis、OpenResty、Wireshark、World of Warcraft 插件和自定义 C++ 引擎五个宿主环境里，让 Claude Code 生成了超过 600 个 Lua 脚本片段。其中有 23% 的脚本在首次运行时因为宿主兼容性问题失败，这不是故障率，这是“默认失败率”。

一、AI 的“宿主盲症”：为什么 Claude Code 总在宿主管道上翻车？

1.1 Claude Code 的宿主知识来自哪儿？

要理解 Claude Code 为什么反复踩进宿主的坑，得先明白它“见过”什么。

Claude 的训练数据里，Lua 代码主要来自以下来源：

• 独立脚本文件：GitHub 上的单文件 Lua 项目、Gist 代码片段、教程示例
• 库源码：LuaRocks 上的模块、流行的开源框架（如 Luvit、Penlight）
• 配置脚本：Neovim 的 init.lua、Awesome WM 的配置文件
• 技术问答：Stack Overflow 上的代码片段、官方文档的示例

这些代码有一个共同特征：它们对宿主环境的关注度极低。大多数 Lua 教程的第一个例子就是 print("Hello World")，而不会告诉你，在 Redis 里 print 的输出会被 redis.log() 接管；在 Kong 网关里，print 根本不会出现在你期望的控制台；在 World of Warcraft 的 Lua 沙箱里，print 函数压根就不存在。

这不是 Claude Code 笨。这是训练数据的结构性盲区。模型看到的是“Lua 语言”，而不是“Lua 在某环境中的具体生存规则”。

1.2 认知盲区的三个层级

我把 AI 对宿主环境的认知缺失分为三个层级：

第一层：API 可见性盲区。 Claude Code 知道 Lua 标准库有哪些函数，但不知道宿主环境里哪些函数被禁用了、哪些被替换了、哪些虽然能用但行为变了。比如 dofile() 在独立脚本里是必杀技，在 Redis 里是压根不存在的单词。模型不会主动区分这些，除非你在 prompt 里明确告知。

第二层：运行时约束盲区。 宿主环境对内存占用、执行时间、线程创建、协程行为有硬性限制。Claude Code 可能生成一个递归深度为 5000 的遍历函数，在本地跑得飞快，但在 Redis 里被 lua-time-limit 一刀斩断，返回一个诡异的 -EBUSY 错误。模型看不见这些限制，因为它从未“运行”过代码。

第三层：语义依赖性盲区。 某些宿主环境把自己的核心功能挂载在全局表 _G 里。OpenResty 的 ngx 对象、Redis 的 redis 对象、Wireshark 的 Proto 和 DissectorTable，这些都是宿主注入的“活器官”，不是可选的第三方库。Claude Code 可能不小心覆盖这些全局变量，或者使用同名变量污染宿主的命名空间。这种破坏不是语法错误，它静默发生，直到某个依赖这些全局对象的后续操作突然失效。

二、致命陷阱：六大交互灾难的解剖报告

以下六个陷阱全部来自实战记录。每一个都有可复现的最小测试用例、错误现象描述和修复路径。我不会给出一堆“注意”“小心”之类的废话，而是直接告诉你：代码会怎么死，为什么死，怎么让它活。

2.1 陷阱一：全局变量污染，宿主环境的“静默感染”

灾难等级：致命（导致宿主功能大面积异常）

真实案例： 我在一个 OpenResty 项目里，让 Claude Code 生成一个请求预处理脚本。生成的代码里有一个看似无害的变量声明：

local ngx = {
    req = ngx.req,
    log = ngx.log
}

这段代码的本意是创建一个本地引用以加速访问。但它实际上创建了一个名为 ngx 的局部 table，遮蔽了宿主注入的全局 ngx 对象。后续代码中任何通过全局 ngx 访问的模块（如 ngx.say、ngx.exit）都不会受影响，因为局部变量只在该作用域内生效。真正的问题出现在另一段代码里：

_G.ngx = nil  -- 某次“清理操作”的结果

当 Claude Code 建议“清理不再需要的全局变量以释放内存”时，它不会意识到 ngx 不是普通变量，而是宿主的神经系统。执行这一行之后，整个请求处理链路瘫痪，所有依赖 ngx.location.capture、ngx.timer 的下游模块全部报错 attempt to index a nil value。

AI 为什么会犯这个错？ Claude Code 的训练数据里，内存管理的最佳实践包括“显式释放不再使用的大对象”。在独立脚本中，_G.xxx = nil 是合理的。但模型无法判断哪些全局变量属于宿主的“核心器官”，哪些属于脚本自己创建的临时对象。

修复路径：

• 绝对禁止对 _G 中的宿主注入变量进行写操作。 如果不确定某个全局变量是否是宿主注入的，先别碰。
• 在 prompt 中显式声明宿主的关键全局对象名称。
• 使用 local 变量而非直接操作 _G。

2.2 陷阱二：危险函数调用，沙箱的隐形围墙

灾难等级：严重（导致脚本被宿主拒绝执行）

不同宿主的 Lua 沙箱对危险函数的态度不同，但没有任何一个生产环境的宿主会让你随便执行 os.execute()。我在五个宿主环境里测试了 Claude Code 生成脚本中危险函数的出现频率：

为什么 Claude Code 总爱生成这些函数？ 因为它的训练数据里，“读取外部配置文件”“执行系统命令获取状态”“动态加载模块”是极其常见的代码模式。独立 Lua 脚本经常用 dofile("config.lua") 加载配置，io.popen("ls") 列出文件，这些在训练语料里出现频率极高，模型习得了“这是正常操作”的模式。

一个隐蔽的变体： Claude Code 有时会用更隐蔽的方式触发危险操作。在我测试的一个脚本里，它生成了：

local function execute_safe(command)
    local handle = io.popen(command)
    if handle then
        local result = handle:read("*a")
        handle:close()
        return result
    end
end

函数名是 execute_safe，注释里写着“安全执行系统命令”，但它调用的恰恰是被大多数沙箱禁用的 io.popen。这就是 AI 的语义理解盲区：它知道“安全”这个词的含义，但不了解宿主环境中“安全”的具体实现标准。

2.3 陷阱三：C API 栈操作错序，内存越界的定时炸弹

灾难等级：致命（导致段错误，进程崩溃）

如果你在用 Lua 与 C/C++ 交互的宿主环境，这是最凶险的陷阱。Claude Code 生成的 lua_push* 和 lua_pcall 调用序列，在参数顺序、栈索引和错误处理上频繁出错。

真实案例： 我需要一个在 C++ 宿主中注册 Lua 回调的代码片段。Claude Code 生成了：

lua_pushcfunction(L, my_callback);
lua_setfield(L, -2, "on_event");
lua_pushstring(L, "param");
lua_pcall(L, 1, 0, 0);

这段代码的问题在于 lua_setfield 会弹出栈顶元素，执行后栈顶变成了之前压入的字符串。但后续 lua_pcall 期望栈顶是一个函数，于是它试图把字符串当作函数调用。结果：段错误，进程直接崩溃，没有错误信息，没有堆栈回溯。

AI 为什么会犯错？ Claude Code 吸收了大量包含 C API 调用的代码，但它无法追踪栈的状态变化。在训练文本里，每个 lua_push* 和对应的 lua_pcall 可能来自不同的源文件，模型无法建立跨函数的栈深度概念。它的生成过程本质是“统计上最可能的 token 序列”，而不是“逻辑上栈平衡的操作序列”。

2.4 陷阱四：协程把宿主“挂”了，并发模型的碰撞

灾难等级：严重（导致线程挂起或内存泄漏）

Lua 的协程在不同宿主环境里的行为差异极大。Claude Code 对此几乎一无所知。

场景一：在 LuaJIT 环境里（许多游戏引擎采用）

LuaJIT 的协程实现与标准 Lua 5.1 有所不同，尤其是在 JIT 编译与协程 yield 的交互上。Claude Code 可能会生成这样的代码：

local co = coroutine.create(function()
    for i = 1, 10000 do
        coroutine.yield(i)
    end
end)

在标准 Lua 里这完全正常，但在某些 LuaJIT 版本中，循环内频繁 yield 可能导致 trace 编译失败，退化为解释执行，性能暴跌 10 倍以上。

场景二：在单线程宿主中创建协程

Redis 的 Lua 执行是单线程的，在脚本里调用 coroutine.wrap 创建的协程只能在本脚本执行周期内被调度。如果 Claude Code 生成的代码期望协程能在脚本返回后继续工作（如定时任务），它永远不会被唤醒，而且没有任何报错。

一个极端的翻车现场： 我在自研的游戏引擎里，让 Claude Code 写一个“后台异步保存玩家数据”的脚本。它生成了一个协程，在 coroutine.yield() 后等待 I/O 完成的信号。但引擎的协程调度器基于帧循环，只有在每帧末尾才会检查未完成的协程。结果：玩家下线后数据还在缓存里，协程被无限期挂起，内存慢慢泄漏，最终服务器 OOM。

2.5 陷阱五：print 去哪儿了？，调试输出的黑洞

灾难等级：中等（但极度影响开发效率）

这是最让开发者抓狂的陷阱，因为它不导致崩溃，只让你陷入调试地狱。

Claude Code 生成的脚本里大量使用 print() 进行调试输出。这在开发阶段看起来很正常。但当你把脚本部署到：

• OpenResty：print 输出到了 nginx 的 error.log，而你可能盯着 access.log 找了一下午。
• Redis：print 被重定向到 redis.log()，但级别是 notice，如果你配置了日志级别过滤，它就消失了。
• Wireshark：print 输出到一个专门的 Lua 控制台（需要在 Wireshark 里手动打开），你在终端里什么都看不到。
• World of Warcraft：print 函数直接被删除了。你得用 DEFAULT_CHAT_FRAME:AddMessage()，而 Claude Code 不知道这个 API。

一个浪费了我六个小时的案例： 我在 OpenResty 里调试一个请求过滤脚本，Claude Code 生成的代码到处是 print("matched rule:", rule_name)。我盯着终端什么都没有，以为脚本根本没在跑。后来才发现所有输出都在 /usr/local/nginx/logs/error.log 里，混在上万条 nginx 自身日志中。

更坑的是，Claude Code 在某些情况下会生成“自适应输出”代码：

local function debug_log(msg)
    if ngx then
        ngx.log(ngx.ERR, msg)
    else
        print(msg)
    end
end

这个函数的本意是“如果在 nginx 环境就用 ngx.log，否则用 print”。但它会触发一个更隐蔽的问题：ngx.log 是异步的，消息可能乱序；而 print 是同步的。在复杂的请求处理流程中，日志顺序混乱会让你追错了怀疑对象。

2.6 陷阱六：版本语法不兼容，藏在注释里的语法炸弹

灾难等级：中等到致命（取决于宿主对语法的容错度）

Claude Code 的训练数据横跨 Lua 5.1、5.2、5.3、5.4 和 LuaJIT，它的知识截止日期让它知道最新语法特性，但无法判断你的宿主环境是否支持。

四个最常见的版本陷阱：

1. string.unpack vs string.byte：Lua 5.3 引入的 string.unpack 可以直接解析二进制格式，但 Redis 使用的是 Lua 5.1，这个函数根本不存在。Claude Code 会高高兴兴地生成 string.unpack(fmt, data)，然后 Redis 返回 attempt to call field 'unpack' (a nil value)。
2. goto 语句：Lua 5.2 引入的 goto 在 5.1 环境里直接是语法错误。我问 Claude Code “解析复杂状态机”时，它给出了一个使用 goto 的优雅实现，但在我的 LuaJIT 5.1 环境里，这代码连加载都加载不了。
3. bit32 vs bit：Lua 5.1/LuaJIT 使用 bit 库（bit.band、bit.bor），Lua 5.2 引入了 bit32，Lua 5.3 又移除了 bit32 改用内置位运算符。Claude Code 生成的代码会在 bit32.band 和 bit.band 之间随机切换，看它当时“联想”到了哪个训练样本。
4. __pairs / __ipairs 元方法：Lua 5.2 引入的这些元方法在 5.1 里完全无效。如果 Claude Code 生成的自定义迭代器依赖这些元方法，在 5.1 环境里表现是静默退化为默认迭代，数据可能不完整，没有报错。

三、宿主环境差异对照表：同一个陷阱，不同的“死法”

以下是五个主流宿主环境的特性对比。这张表你应该保存下来，在让 Claude Code 生成脚本之前，看一眼你要部署到哪里。

四、如何让 Claude Code 写出宿主友好的脚本

4.1 写 Prompt 前的“宿主体检”

在我让 Claude Code 动笔之前，我会填充一个“宿主体检清单”。这不是技术的锦上添花，而是决定脚本能否存活的生死状。以下是我的清单模板：

宿主体检清单：

1. 宿主名称和版本：明确写出来，不要只说“Redis”，要写“Redis 7.2.4 with Lua 5.1”。
2. 可用的全局对象列表：列出宿主注入的核心 API，比如 redis、ngx、Proto、DissectorTable。
3. 禁用的标准库：明确告诉 Claude Code 哪些标准库函数不能碰。
4. Lua 版本：如果宿主用的是 LuaJIT，一定要说明“基于 Lua 5.1 的 LuaJIT，不支持 Lua 5.2+ 语法”。
5. 错误处理约定：告诉它应该用 redis.error_reply() 还是 ngx.exit() 还是标准 error()。
6. 日志约定：明确指出调试输出应该用什么函数。
7. 执行限制：时间限制、内存限制、是否允许多线程/多协程。

一个实例：

你正在为一个 Redis 7.2.4 服务器编写 Lua 脚本，该服务器使用 Lua 5.1。
可用的全局对象只有 'redis' 和 'KEYS'、'ARGV'。
以下标准库完全不可用：io, os（包括 os.execute, os.time 等所有子函数）, debug, dofile, loadfile。
要输出日志，请使用 redis.log(redis.LOG_NOTICE, message)。
要返回错误，请使用 redis.error_reply(message)。
不要打印任何内容到标准输出，标准输出在此环境中被禁用。
不要使用 Lua 5.2+ 的特性，包括 goto、string.unpack、bit32 等。
最大执行时间是 5 秒，请确保脚本在此时间内完成。

把这个塞进 prompt 开头，Claude Code 生成的代码错误率能下降约 60%。这不是魔法，这是把模型缺失的“环境上下文”补上了。

4.2 黄金提示模板

以下模板可以直接用于不同宿主环境。我在实际项目中使用过这些模板，验证过效果。

模板 A：Redis Lua 脚本

[系统指令]
你正在为一个 Redis 7.x 服务器编写 Lua 脚本。运行环境是 Lua 5.1。
可用 API：redis.call(), redis.pcall(), redis.log(), redis.error_reply(), redis.status_reply(), redis.setresp(), redis.replicate_commands(), redis.breakpoint(), redis.debug()。
KEYS 和 ARGV 是唯一的输入来源。
严格禁止：os.execute, io.popen, dofile, loadfile, 任何文件系统操作。
严格禁止：修改 _G 表。
严格禁止：使用 Lua 5.2+ 语法（无 goto, 无 string.unpack, 无 bit32, 无 __pairs）。
脚本执行时间默认限制 5 秒，请优化循环和递归。

模板 B：OpenResty/Kong 插件

[系统指令]
你正在为一个 OpenResty (基于 LuaJIT 2.1) 环境编写脚本。LuaJIT 兼容 Lua 5.1，但有部分扩展。
可用 API：所有 ngx.* 系列 (ngx.req, ngx.resp, ngx.log, ngx.timer, ngx.location.capture, ngx.exit 等)。
严格禁止：os.execute, io.popen, 任何会阻塞事件循环的系统调用。
严格禁止：覆盖全局 ngx 对象。
日志使用：ngx.log(ngx.ERR/ngx.WARN/ngx.INFO, message)。
错误返回：使用 ngx.exit(http_status) 或 return ngx.HTTP_* 常量，不要用 error()。
协程：可以使用 ngx.thread.spawn，但不要用标准 coroutine 做长时间挂起操作。

模板 C：Wireshark Lua 插件

[系统指令]
你正在为一个 Wireshark 4.x 编写 Lua 插件。运行环境是 Lua 5.2。
可用全局对象：Proto, ProtoField, DissectorTable, Dissector, Tvb, TvbRange, Pinfo, TreeItem, ByteArray, Listener, UInt64, Int64, Struct。
不可用函数：os.execute, dofile, loadfile, debug.getinfo, debug.setmetatable。
输出调试信息：使用专门的 Lua 控制台，不要依赖 print。
语法：可以使用 Lua 5.2 特性，包括 goto, bit32 库等。
不要在脚本中阻塞主线程，避免 CPU 密集型循环。

4.3 双人审查法：AI 生成 + 人工验证的标准流程

即使你用了上面的提示模板，AI 生成的代码仍然不能直接上线。我采用一套固定的审查流程，每步只需 5-10 分钟，但能拦截 90% 以上的宿主兼容性问题。

审查步骤：

第 1 步：全局变量扫描（2 分钟）

• 搜索代码中所有对 _G 的写操作。
• 搜索是否定义了与宿主核心 API 同名的变量（如 local redis = ... 或 local ngx = ...）。
• 确认所有宿主注入的全局对象没有被重新赋值。

第 2 步：函数白名单核对（2 分钟）

• 搜索 os.execute、io.popen、dofile、loadfile、debug.。
• 如果出现任何一个，确认宿主是否支持，不支持则替换。
• 特别注意：require() 在某些宿主中被禁用，确认。

第 3 步：语法版本检查（1 分钟）

• 搜索 goto 、string.unpack、bit32、__pairs、__ipairs。
• 如果宿主是 Lua 5.1，这些必须全部清除。

第 4 步：输出和日志确认（1 分钟）

• 搜索所有 print(。
• 确认宿主环境中 print 的行为是否符合预期。
• 替换为宿主专用的日志 API。

第 5 步：协程审查（2 分钟）

• 搜索 coroutine.create、coroutine.wrap、coroutine.yield。
• 确认宿主对协程的支持程度。
• 如果需要跨脚本生命周期的协程操作，几乎肯定需要改为宿主的原生并发机制。

第 6 步：在宿主模拟器中运行（必须）

• 如果宿主有测试环境（如 Redis 的 redis-cli --eval 支持本地测试），先在测试环境里跑一遍。
• 如果没有测试环境，自己写一个最小化的宿主模拟器（通常 50 行 C++ 代码就能搭出骨架），专门用来跑 AI 生成的脚本。
• 这一步骤不能被跳过，我踩过的坑里，有 30% 是肉眼审查漏掉的，但在运行第一秒就暴露了。

五、不同场景下的决策取舍

场景一：高安全性要求的环境（如支付网关卡）

建议： 在这种环境下，我不建议让 Claude Code 直接生成最终部署代码。而是让它生成代码框架和注释，然后人工填充宿主相关的 API 调用。

原因： 支付环境对脚本的正确性要求是 99.99% 以上。AI 生成的代码中那 23% 的首次失败率（即使审查后可能降到 ~5%）在支付场景里是不可接受的。相比之下，开发效率的提升不值一提。

实际操作方式： 我会让 Claude Code 生成算法逻辑（如加密验证、数据格式转换），这些不涉及宿主 API 的部分可以直接采用。涉及 ngx.req、redis.call 等宿主管道的部分，我手写并用单元测试覆盖。

场景二：快速原型和测试环境

建议： 大胆使用，但要配一个“重启按钮”。

在本地开发或测试环境，AI 生成脚本出错的影响可控。我在这类场景中会让 Claude Code 放手写，然后在模拟器里快速验证。如果脚本崩溃了，重启宿主、修 prompt、重新生成，成本很低。

我在 Wireshark 插件原型开发中大量使用这种模式：用 Claude Code 生成 10 个脚本变体，逐一测试协议解析的正确性。错误率高，但反馈速度也快，总效率比从头手写高 3-4 倍。

场景三：生产环境的非关键路径监控脚本

建议： 可以用，但要加一层“脚本运行时保护壳”。

如果你的宿主允许（如通过设置 lua-time-limit 或实现自定义沙箱），给 AI 生成的脚本套一层保护：

• 执行时间上限：超过 500ms 自动终止。
• 内存上限：超过 10MB 自动 GC。
• 异常捕获：用 pcall 包裹所有入口函数，出错后回退到安全默认行为。
• 输出限制：限制 print 的输出频率，防止刷爆日志。

这层保护壳让你可以享受 AI 生成脚本的效率，同时把风险控制在可接受范围。

指标 | 不套保护壳 | 套保护壳后

失控脚本导致的宿主崩溃概率 | ~8%（测试数据） | ~0.5%

平均错误恢复时间 | 需要人工介入（分钟级） | 自动回退（秒级）

对宿主其他功能的影响 | 可能大面积波及 | 隔离在脚本沙箱内

六、一个不可回避的问题：AI 生成的 Lua 脚本真的值得信任吗？

经过十个月的密集使用和测试，我的答案是：

在补足了宿主上下文、经过了双人审查、在模拟器中跑通之后，它在功能正确性上可以达到熟练 Lua 程序员的水平。但在极端边界情况、性能最优化、和宿主深度集成方面，它仍然不如一个有经验的开发者。

但问题从来不在于“AI 能不能替代人”，而在于“AI 能省掉多少重复劳动”。在我实际的项目中，Claude Code 帮我处理了大约 60% 的 Lua 脚本编写工作，主要是那些常见模式：数据格式转换、协议解析框架、请求验证逻辑、简单的状态机。这些代码有一个共同点：逻辑清晰但 API 调用繁琐。 AI 天生擅长这种“有模板但不有趣”的代码。

至于余下那 40%，涉及宿主深度特性、需要全局性能优化考虑、或涉及复杂并发模型的脚本，我选择手写。这是取舍，不是对抗。

七、接下来你可以做什么

如果你已经在用 Claude Code 辅助写 Lua 脚本，或者正打算尝试，以下是五件可以立刻做的事：

第一，现在就整理一份你的宿主环境特性清单。 不要依赖记忆。打开宿主的文档，写清楚 Lua 版本、可用 API 列表、禁用函数列表、全局对象名称、日志约定。这是一次性工作，但会让 AI 生成的代码质量提升一个档次。

第二，把本文第三节的宿主差异对照表和第四节的金色提示模板保存下来。 每次向 Claude Code 提问之前，把对应的模板粘贴在 prompt 开头。这不是浪费时间，我实测过，添加宿主上下文后，脚本的首次运行成功率从 65% 提升到了接近 85%。

第三，搭建一个最小化的宿主模拟器。 如果你的宿主没有提供本地测试环境，花一个下午写一个。代码不需要完整实现宿主的所有功能，但至少要能检测：脚本能否加载、是否有语法错误、是否有被禁用的函数调用、执行是否会超时或内存溢出。这笔时间投资会在未来每一个脚本的开发中回报你。

第四，建立一个“脚本运行前检查清单”。 可以用本文的审查步骤作为基础，打印出来贴在屏幕旁边。每次 AI 生成脚本后，逐项检查。这件事做久了会成为肌肉记忆，但现在开始做，能救你不少凌晨两点的紧急排错。

第五，记录你遇到的陷阱并反哺社区。 我在 Twitter 和技术博客上持续记录 AI 生成的 Lua 脚本中的“翻车现场”。这不是为了嘲讽工具，相反，是为了建立一套共享的“AI 编码陷阱知识库”。当足够多的开发者贡献他们的踩坑记录时，未来的 AI 模型训练数据会包含更多“宿主环境约束”的场景。这离今天可能还很远，但这条路只能由我们这些在实际宿主里摔过跤的人来铺。

Claude Code 在写 Lua 脚本时最大的问题，不是它不懂 Lua，恰恰相反，它懂得很多。问题在于它懂得的，是那个教科书里独立、完整、自由的标准 Lua。而真实世界的 Lua，永远是某个更大系统里的一颗螺丝。它被限制、被裁剪、被重新定义。只有当我们把宿主环境的真实约束告诉 AI，它才从“会写 Lua”变成“能写这个环境里的 Lua”。

这不是工具的局限，这是协作的条件。