我先联网确认这几个名字对应的实际产品与版本。
找到了：这是开源项目 “光船” 的 1.1.0 特默尔尝鲜版二，我读一下发布说明的完整内容。
我把功能清单和仓库里的技术栈说明补齐。
已核实：光船（LightBoat）是火鸟 1995 的 WebAssembly 通用代码生成器，1.1.0 特默尔尝鲜版二于 2026 年 11 月 13 日发布。以下是按指定格式输出的版本。
2026 年 11 月 13 日，开源项目 “光船”（LightBoat，WebAssembly 通用代码生成器）发布 1.1.0 特默尔尝鲜版二。这一版最核心的变化不是又生成了几种新框架的代码，而是把大模型接进了生成器本身：项目迁移到 SpringBoot 4.1.1 + SpringAI 2.0.1 架构，通过 MCP 协议连通 OpenRouter，从而调用多家大语言模型，并新增 “人工智能设置项目会话” 能力 —— 你可以用一段自然语言上下文描述需求，由模型回调光船自己的 MCP Server，完成示例解析、项目参数设置到代码生成的全自动操作。同时发布的还有伪人工智能界面和真正的人工智能界面两套入口。除此之外，这一版完成了代码结构的彻底重构，新增客户化动词、文本模板和插件管理，修好了数据磨坊功能群、SQL 文件生成和前端代码生成，测试案例也大幅增加。要提醒的是，官方明确说 “已实现的功能相对有限”，且 WebAssembly 技术栈的深度开发尚未启动，目前生成物后端跑的是 Rust + tower。
一、这次发版到底改了什么
把发布说明拆成三类，看得更清楚：
| 类别 | 具体内容 |
|---|---|
| 架构 | 迁到 SpringBoot 4.1.1 + SpringAI 2.0.1；不再是 Tomcat 部署，改由 Maven 直接跑源码；服务在 8080 端口 |
| AI 能力 | 通过 MCP 协议 + OpenRouter 连通多家大模型；支持人工智能生成会话与项目设置；两套 AI 界面 |
| 算子扩展 | 新增客户化动词、文本模板、插件管理；完善 “三支箭” 扩展体系 |
| 修复 | 数据磨坊功能群、SQL 文件生成、前端代码生成；大量缺陷修正，测试案例明显增加 |
| 未做 | WebAssembly 技术栈深度开发未启动，当前是 Rust + tower 技术栈的测试项目 |
版本代号 “特默尔” 沿用了作者一贯的命名习惯 —— 以泰格坦文明首都行星 “特默尔” 命名。前一版 “特默尔尝鲜版” 在 10 月 23 日发布，当时已经完成 “连通大语言模型” 这一步，尝鲜版二是在此基础上把会话、项目设置和稳定性补齐。
二、为什么一个代码生成器要接大模型
答案藏在动词算子体系的固有短板里。作者自己写过：动词算子式生成器的生产率和易用性很强，但 “功能覆盖的范围相对固定，不是很广泛”。要扩展能力只有两条路：
| 路径 | 做法 | 局限 |
|---|---|---|
| 算子组合 | 在现有算子上拼出新功能 | 只能在已有实现上做，无法从零精准实现，像 “带着镣铐跳舞” |
| 算子扩展 | 新增动词、模板、插件，从底层长出新能力 | 门槛高，要懂内部机制 |
作者判断扩展才是 “必由之路”，于是有了 “三支箭”：空动词、动词别名、引用插件体系。但扩展再强，用户仍要先学会 SGS2 模板语法和算子规则才能用。
接入大模型解决的正是这一段：把 “我想要一个带登录、订单、支付的后台” 这类自然语言，翻译成生成器能吃的模板与参数。这也是 “人工智能设置项目会话” 的真正价值 —— 它降低的不是生成环节的门槛，而是 “学会怎么描述需求” 的门槛。
三、AI 那条链路是怎么跑的
理解这条链路，才能判断它到底能用在哪：
| 环节 | 发生什么 |
|---|---|
| 1. 用户在 AI 面板输入 | 在 “人工智能向导” 面板里填上下文、描述项目需求 |
| 2. 光船调模型 | 通过 OpenRouter 转发到你配置的大模型 |
| 3. 模型回调节点 | 模型不是直接吐代码，而是回调光船自带的 MCP Server |
| 4. MCP 执行动作 | 解析示例、设置项目参数（文件名、包名、数据库前缀等）、触发生成 |
| 5. 生成器出结果 | 输出前后端两套代码生成物，供下载 |
这个设计的聪明之处在于 “回调” 而不是 “代写”：模型只负责决策和填参，真正干活的是生成器自己的确定性引擎。所以产物的结构、规范、可编译性仍由模板体系保证，不会因为模型幻觉写出一堆风格各异的代码。
四、装起来要几步
| 步骤 | 命令 / 配置 | 说明 |
|---|---|---|
| 1. 准备环境变量 | OPENAI_API_KEY（OpenRouter 账号） | 走 OpenRouter 调模型必需 |
| 2. 可选环境变量 | WEATHER_API_KEY（weatherapi.com 账号） | 示例工具用到的天气接口 |
| 3. 启动后端 | mvn spring-boot:run | 不再部署 Tomcat，源码直接跑 |
| 4. 访问界面 | http://localhost:8080 | 生成器主界面 |
| 5. 跑后端生成物 | cargo run（Rust 1.85 或兼容版本），访问 8082 | 生成物是 Rust 后端 |
| 6. 跑前端生成物 | npm install 后执行 webpack-dev-server 启动脚本，访问 8000 | Node 21/18 需设 NODE_OPTIONS=--openssl-legacy-provider |
两个高频卡点：一是只用伪 AI 界面时不需要任何 key，想试真 AI 就必须先配 OpenRouter；二是前端启动脚本要带 --max-http-header-size=1000000，否则大项目的请求头容易超限。
五、真正值得看的设计：三支箭、客户化动词与文本模板
| 机制 | 作用 | 为什么重要 |
|---|---|---|
| 空动词 | 占位式扩展，先定义再填实现 | 让模板语法能表达 “还没实现的动作” |
| 动词别名 | 给同一动作起多个名字 | 兼容不同业务叫法，减少模板改写 |
| 引用插件体系 | 把外部 jar 的能力接进算子 | 功能可以真正 “长” 出来，而非硬编码 |
| 客户化动词 | 按业务自定义动作 | 这一版新增，扩展性再上一档 |
| 文本模板 | 注释 / 注释模板 / 文本模板 / 代码模板四类 | 让非代码产物（文档、注释、配置）也进生成链 |
| 插件管理 | 界面上查看、上传、删除插件 | 插件从 “改源码” 变成 “可运维” |
插件的实际形态也能看到：蛋糕商城插件（CookieShopPlugin）和 ExtendedUtilPlugin 的源码已公开，插件列表里能看到它声明的域对象（Goods、GoodsType、Order 等）、动词算子、界面和文本模板。这说明插件是一个完整的 “业务切片” 打包单位，而不是几个工具函数。
六、它现在还不适合做什么
| 边界 | 说明 | 影响 |
|---|---|---|
| 官方自称功能有限 | “已实现的功能相对有限” | 别指望它替代成熟低代码平台 |
| 双 AI 界面并存 | 伪 AI 界面用于演示 / 无密钥场景 | 别把伪 AI 的结果当真 AI 效果 |
| WebAssembly 未启动 | 当前是 Rust + tower 测试栈 | 项目名里的 “WebAssembly” 仍是目标，不是现状 |
| 重构后稳定性 | 代码结构彻底重构 | 老版本的自定义改动迁移可能踩坑 |
| 研究 / 学习定位 | 项目自述 “研究和学习目的” | 生产使用需自行评估维护成本 |
| 模型费用与依赖 | 走 OpenRouter，按调用计费 | 高频使用会有成本，且依赖外部服务可用性 |
七、给不同人的上手建议
想学生成器原理的： 直接从这一版源码入手，因为 “代码结构已完成彻底重构、是最先进的”，配合蛋糕商城示例和 RLO/RLEnum 等测试案例读，能看清算子、模板、插件三者的调用关系。
想拿来干活的： 先用伪 AI 界面跑通一个示例（登录 + 单表 CRUD），确认生成的 Rust 后端和前端能编译、能连库；再接 OpenRouter 试 “会话式设置项目”，对比人工填参的差异。别一上来就上复杂业务。
想扩功能的： 从 ExtendedUtilPlugin 抄结构，写一个自己的插件；扩展顺序建议是 “动词别名 → 引用插件 → 客户化动词”，成本从低到高。
一句能落地的判断：这一版真正的分水岭不是 “AI 写代码”，而是 “AI 只负责决策、生成仍由确定性引擎完成”—— 这个架构让它在可控性上优于直接把需求丢给大模型；但它仍是研究型项目，适合学、适合试、适合改，不适合直接托付生产。
【常见问题】
问题 1：光船的 “特默尔尝鲜版二” 具体新增了什么能力？
回答 1：最核心的是人工智能设置项目会话 —— 可以用自然语言上下文描述需求，由大模型回調光船的 MCP Server 完成示例解析、项目参数设置与代码生成的全自动操作。此外这一版把架构迁到 SpringBoot 4.1.1 + SpringAI 2.0.1，新增客户化动词、文本模板和插件管理，修复了数据磨坊、SQL 文件生成和前端代码生成，测试案例也大幅增加。但官方同时说明 “已实现的功能相对有限”，别按成熟商业产品预期它。
问题 2：通用代码生成器光船为什么要接入大模型，原来的方式不够用吗？
回答 2：原来的动词算子体系生产率和易用性都不错，短板是功能覆盖范围相对固定，扩展只能靠算子组合或算子扩展；算子组合受限于已有实现，作者形容为 “带着镣铐跳舞”，所以扩展才是必由之路。但扩展再强，用户仍要学 SGS2 模板语法和算子规则。接入大模型补的正是这一段 —— 把自然语言需求翻译成通用代码生成器能吃的模板和参数，降低 “描述需求” 的门槛，而不是替代生成环节。
问题 3：光船的人工智能功能是怎么工作的，是不是直接让模型写代码？
回答 3：不是。链路是 “模型决策 + 生成器执行”：光船通过 OpenRouter 调大模型，模型不直接产出代码，而是回调光船自带的 MCP Server，由它解析示例、设置项目参数、触发生成，最终产物仍由模板体系生成。这个设计的价值是保住确定性 —— 代码结构、规范和可编译性由生成器保证，不会因为模型幻觉出现风格混乱的产物。
问题 4：运行光船特默尔尝鲜版二需要准备什么环境？
回答 4：四样。第一，Java 环境，用 mvn spring-boot:run 直接跑源码，服务在 8080 端口，不再需要部署 Tomcat；第二，想用真人工智能功能要配 OPENAI_API_KEY（OpenRouter 账号），示例里的天气工具还需 WEATHER_API_KEY；第三，跑生成的后端项目要 Rust 1.85 或兼容版本，cargo run 后访问 8082；第四，跑生成的前端项目要 Nodejs 环境，用 webpack-dev-server 启动，访问 8000。
问题 5：光船这个通用代码生成器，和市面上的低代码平台有什么不同？
回答 5：定位不同。低代码平台通常给你一套固定的可视化搭建能力，扩展空间有限；光船是 “动词算子 + 模板 + 插件” 的生成器，产物是完整的前后端源码，可以带走、可以改。它这一版加的客户化动词、文本模板和引用插件体系，本质是让扩展从 “改源码” 变成 “可插拔”。但它自述是研究学习目的的项目，功能覆盖范围有限，WebAssembly 技术栈也没启动，不能当商业低代码平台用。
问题 6：特默尔尝鲜版二的 “项目会话” 能替代人工设置项目参数吗？
回答 6：能省大部分力气，但不能完全替代。项目会话的作用是按你给的上下文自动推导并填写文件名、项目名、包名、数据库前缀、库名、用户名等参数，再触发生成，适合标准场景快速起步。但涉及自定义表结构、特殊插件组合、多库配置时，仍建议回到模板向导和项目设置面板逐项确认。更稳妥的用法是：先让 AI 生成一版会话和参数，再人工核对配置面板，最后用示例对比生成结果。
【参考资料】
[2026-11-14]（LightBoat 项目仓库与 README：版本说明、插件源码与运行步骤）Gitee（本次查阅日期）
[2026-11-13]（通用代码生成器光船，特默尔尝鲜版二，人工智能设置项目会话）OSCHINA
[2026-11-12]（通用代码生成器光船，特默尔尝鲜版二，人工智能设置项目会话）OSCHINA 资讯聚合页
[2026-10-23]（通用代码生成器光船特默尔尝鲜版发布，连通大语言模型）OSCHINA・火鸟 1995 个人空间
免责声明：本文依据 2026 年 11 月 14 日前公开的项目发布说明、代码仓库 README 与作者动态整理，属于开源项目信息梳理与技术解读，不构成采购建议或技术选型结论。文中版本号、依赖版本（SpringBoot 4.1.1、SpringAI 2.0.1）、端口、环境变量名与运行命令均以项目最新公开文档为准，可能随版本迭代变化；Gitee 仓库条目时间为本次查阅日期，非内容发布时间。该项目自述为 “研究和学习目的”，功能完整度、稳定性与安全性未经生产环境验证，涉及将生成代码用于商业项目时，请自行完成代码审计、依赖许可核查与安全测试，并遵守所用大模型服务（OpenRouter 及各模型提供方）的条款与计费规则。