这个标题看起来是机翻过，或者被截断了，我先联网检索确认它原本说的到底是什么产品。

我找到了原始出处，这是国产开源项目 “光船” 的版本发布；我再去核实一遍细节。

标题：光船 1.1.0 特默尔尝鲜版二：AI 现在能自己建项目会话，但离 “一句话出系统” 还隔着几道坎

先把这条发布说清楚：这是一个单人维护的开源项目，不是商业产品。2026 年 11 月 13 日，通用代码生成器 “光船”（LightBoat）发布 1.1.0 “特默尔尝鲜版二”，新增的两件事都挂在 AI 上 —— 支持用人工智能生成会话、支持用人工智能做项目设置。技术骨架也换了，从 SpringBoot 4.1.1 加 SpringAI 2.0.1 撑起来，通过 MCP 协议连到 OpenRouter，再由 OpenRouter 打通多家大语言模型；界面上分成 “伪人工智能操作界面” 和 “人工智能操作界面” 两套，后者会把请求回调到光船自己的 MCP Server，从而完成对示例的 “自动解析 + 全自动操作”。听着很像 “一句话生成系统”，但作者自己在文档里写得很直白 —— 已经打通了通用 AI 和通用代码生成器的连通，“已实现的功能相对有限”。

一、这次发布的到底是什么

这个项目的 “通用” 不是指什么都能生成，而是指一套模板能出前后端两套代码。它的方法论叫 “动词算子”：把新增、修改、删除这类动作拆成可组合的算子，再用电子表格形式的 SGS2 模板描述业务，一次生成前端加后端。

二、新增的两件事：AI 会话与项目设置

调用链路可以拆成四段来看：

1. 浏览器里的 AI 界面收到一句自然语言需求。
2. 请求经 MCP 协议发往 OpenRouter，由它路由到具体模型。
3. 模型产出结构化指令，回调光船本地的 MCP Server。
4. MCP Server 把指令落到代码生成器内核，走模板、走算子，出前端和后端两套代码生成物。

这条链路的真正意义在于方向：过去是 “人读文档、填模板、点生成”，现在多了一条 “模型读需求、调工具、填模板”。工具没变，入口变了。

三、骨架换了：从 war 包到 SpringBoot 应用

骨架换代带来一个副作用值得注意：war 包体积一直是这条产品线的老问题 —— 此前多个版本因为打包超过 150MB 而停止提供直接下载，只能自己用 Maven 从源码编译。改成 SpringBoot 直跑，本质上是把 “下载即用” 换成 “编译即用”，门槛从 “会不会部署” 变成 “会不会配环境”。

四、跑起来需要什么

这些前置条件说明一件事：所谓 “全自动”，自动的是 “从需求到模板” 这一段，不是 “从零到上线”。环境还是得自己配，数据库还是得自己建，SQL 脚本还是得自己跑。

五、动词算子体系这次长出了什么

作者对 “组合” 和 “扩展” 有一段挺实在的自我批评：算子组合像带着镣铐跳舞，只能在现有实现上加功能，没法从零开始精准、无附带效应地做出想要的东西；所以他认定扩展才是这条路走通的必由之路。这句话其实也是整个项目的方法论底色 —— 它不追求覆盖所有场景，追求的是 “可被人改”。

六、它在整条产品线里的位置

把这张表摆出来，就能看出光船的定位：它是这条阵列里第一个把 “模型” 接进来的成员。其余兄弟项目仍然停在 “模板 + 算子” 的纯规则路线，没有一个接大语言模型。

七、三个必须看到的 “但是”

还有一处容易被误读的地方：这次 “AI 能设置项目会话”，说的是让 AI 参与会话生成和项目配置，不是让 AI 替代代码生成器内核。生成逻辑仍然走模板和算子，模型只是站在入口，把自然语言翻译成模板操作。

八、什么人值得动手试

把整件事收成一句：光船这次做的不是 “AI 写代码”，是 “AI 当遥控器”。它把大语言模型接到了自己那套已经很成熟的模板与算子体系前面，让入口从表单变成对话。这套做法方向是对的，也很省力 —— 不用重写内核，只需要多一层 MCP。但它同时也把天花板暴露得很清楚：能生成什么，仍然由模板决定；能自动到什么程度，仍然由本地环境决定。想验证 “AI 加代码生成器能走多远”，这是个成本很低、透明度很高的实验样本；想拿它直接上线，还早。

【相关 FAQ】

问题 1：光船 1.1.0 特默尔尝鲜版二这次新增的 “人工智能设置项目会话” 到底是什么功能？

回答 1：按发布说明，这一版支持人工智能生成会话和项目设置两项能力。用户在 AI 操作界面里用自然语言发起需求，请求经 MCP 协议发到 OpenRouter，由其路由到具体大语言模型，模型再把结构化指令回调光船本地的 MCP Server，落到代码生成器内核完成对示例的自动解析与执行。换句话说，AI 负责 “下指令”，光船负责 “真生成”。

问题 2：光船这个通用代码生成器为什么要通过 MCP 协议去连大语言模型？

回答 2：因为 MCP 提供了一个稳定的 “手” 给模型用。光船的生成能力本来就在本地，通过 MCP 把生成器的能力暴露成工具，模型不需要理解内部模板结构，只要按约定调用即可；同时换模型、换供应商也不用改内核。这一版正是用 SpringAI 2.0.1 加 MCP 打通 OpenRouter 才实现了全自动操作界面。

问题 3：想跑光船特默尔尝鲜版二，环境上要准备哪些东西？

回答 3：代码生成器本体需要 JDK 和 Maven，推荐 mvn spring-boot:run 直接跑源码，服务在本机 8080。接 AI 需要 OpenRouter 账号设置 OPENAI_API_KEY，示例里的外部服务还需要 weatherapi.com 的 WEATHER_API_KEY。跑代码生成物时，后端要 Rust 1.85 并执行 cargo run（8082），前端要 Node.js 配 webpack-dev-server（8000），Node 18 或 21 还需加 openssl legacy 参数。

问题 4：光船属于动词算子式代码生成器，这里的 “动词算子” 在特默尔尝鲜版二里有什么新扩展？

回答 4：原有的 “三支箭” 是空动词、动词别名和引用插件体系；这一版在光船上新增了客户化动词和文本模板两个主要扩展，文本模板又分注释、注释模板、文本模板、代码模板四类。作者的观点是算子组合只能在现有实现上加功能，算子扩展才能精准、无附带效应地做出新东西，所以扩展才是这条体系完善的必由之路。

问题 5：光船特默尔尝鲜版二的 AI 能力，和光船尝鲜版二比提升了多少？

回答 5：AI 以外的代码生成能力，官方说明是与光船尝鲜版二等价的，没有额外增强。尝鲜版二本身修的是数据磨坊功能群、SQL 文件生成、前端代码生成这几块，并大幅增加了可用测试案例。所以这次升级的价值集中在 “入口” 和 “连通”—— 多了一条用自然语言驱动生成的路径，而不是生成能力本身变强。

问题 6：光船名字里的 WebAssembly，在特默尔尝鲜版二里实现了吗？

回答 6：还没有。项目文档写得很明确，尚未启动 WebAssembly 技术栈的开发，目前是 Rust 语言 tower 技术栈的测试项目。名字里的 WebAssembly 是项目初衷与方向，现阶段真正能跑的是 Java 写的生成器本体，加上 Rust 和 Vue 两套代码生成物。

【参考资料】

[2026-11-14]（开源资讯列表：通用代码生成器光船特默尔尝鲜版二，昨日 17:32 更新）OSCHINA 开源资讯

[2026-11-13]（通用代码生成器光船，特默尔尝鲜版二，人工智能设置项目会话）OSCHINA

[2026-10-23]（动词算子体系中，何为名词？）OSCHINA 火鸟 1995 个人空间

[2026-10-20]（数据库自动反射功能主题页：收录动词算子式代码生成器阵列）Gitee

[2026-10-15]（通用代码生成器光船特默尔尝鲜版发布，连通大语言模型）OSCHINA

[2026-09-10]（通用代码生成器：光船尝鲜版二，蛋糕船示例生成演示）OSCHINA

[2026-08-27]（无远弗届，驭光而至，通用代码生成器：光船尝鲜版，蛋糕船示例生成演示）OSCHINA

[2026-06-01]（通用代码生成器光船所有插件源码发布）OSCHINA

Gitee免责声明：本文信息来自 OSCHINA 的项目发布页、作者火鸟 1995 的 OSCHINA 个人空间、Gitee 项目页与公开介绍视频，均为项目方自行披露的内容；文中技术细节（SpringBoot 4.1.1、SpringAI 2.0.1、MCP 与 OpenRouter 通路、环境变量与端口）以官方 README 表述为准，实际运行效果受本地环境、模型供应商与版本差异影响，可能存在出入。该项目定位为 “研究和学习目的”，属尝鲜版本，功能与稳定性不代表生产可用性；本文不含任何代码或部署指导，不构成选型建议。文中对 “动词算子”“三支箭” 等概念的归纳为便于理解的转述，准确含义请以项目文档与作者原文为准。