bolt.diy本地模型实测：代码生成了，报名页却没跑起来

一次真实的“拿来干活”测试

把一个十人活动的报名页需求交给 bolt.diy，同时接入本机的 8B 视觉模型——这个组合看起来能跑通“看图写代码”的闭环。需求本身不复杂：页面能显示报名成功，后台要多一笔三人记录并扣减剩余七个名额；同一笔报名重复提交不该重复扣名额；数据要存到服务端，重启后能读回来；同一活动和邮箱不能重复报名。

作者把原型图和规则一起塞进同一次请求，期待生成完整工程。结果是：代码确实生成了，报名页却没跑起来。这个结果比“生成失败”更有参考价值——它暴露了本地模型组合在实际工程里的断点。

第一轮：计划卡在六步，代码还没影

工作台负责规划步骤，模型负责看图和写代码。第一轮就卡住了：工具调用重试后，计划步骤仍超过六步上限，反复合并到六步，模型才读到项目文件列表。

计划通过了，但报名代码还没写出来。随后又遇到长时间等待——工作台等了两分钟没收到新内容，就重发了一次请求；可本地模型其实还在生成。作者把本地模型的等待上限调到十分钟，并修了记录请求时的取消处理。继续任务后，又发现另一条调用路径仍只等 45 秒，得再补齐这一处。

这些运行环境的调整全部由人完成。换句话说，本地模型组合的“可用”建立在大量手工调参之上，而不是开箱即用。

工具调用（Tool Calling）与 Agent 工作台：文中“工作台负责规划步骤，模型负责看图和写代码”描述的是典型的 Agent 编排模式。工作台（如 bolt.diy）本身是一个编排层，它把用户需求拆解为多个步骤，每一步通过“工具调用”接口请求模型输出结构化动作（如读取文件、写入文件、执行命令）。模型返回的不是自由文本，而是符合预设 schema 的 JSON，工作台据此执行真实操作。由于本地小模型对复杂 schema 的遵循能力较弱，常出现步骤数超限、格式不合法等问题，工作台便需要重试、合并步骤甚至截断计划——这正是文中“计划卡在六步”的技术根源。理解这一层，才能明白为何“生成失败”未必是模型不会写代码，而是编排协议在本地模型上难以稳定跑通。

代码落地了，但页面没接上

第二次纠正后，文件终于写进工程。报名表单组件、保存逻辑和接口入口都有了，代码可以导出。

接下来直接启动工程，看小宇能不能真正报上三个人。先看页面：工作台显示没有可用预览。再打开导出的主页面文件，里面仍然只有初始提示，没有进入计划——刚生成的报名组件虽然出现在目录里，但页面还没有把它接起来。

随后在独立本地环境原样运行它给出的后台启动命令，进程退出，错误落在第一行：配置把整个工程设为 ES 模块，后台却用 Require 加载依赖，两边写法没对上。服务还没开始接收报名请求，就已经停下了。

ES 模块与 CommonJS 的互操作冲突：文中后台启动即退出，错误是“配置把整个工程设为 ES 模块，后台却用 Require 加载依赖”。这是 Node.js 生态中两类模块系统不兼容的典型表现。在 package.json 里设置 "type": "module" 后，所有 .js 文件默认按 ES Module 解析，必须使用 import/export；而 require() 是 CommonJS 的加载方式，在 ES 模块作用域中并不存在，运行到第一行就会抛出 ReferenceError。反过来，ES 模块也不能被 require() 直接同步加载。生成代码常见的错误是把前端（Vite/ESM）与后端（传统 CommonJS 写法）混在同一工程配置下，却没有统一模块制式或使用 .cjs/.mjs 后缀区分。这类问题在“看起来代码齐全”时极易被忽略，却会让服务在接收任何请求之前就崩溃。

一个藏在源码里的致命逻辑

源码检查还发现一个和三人报名直接相关的问题：计算余额时，它数的是数据库记录条数，再用 10 减掉这个数。按这段逻辑，一笔记录即使写着三个人，也只会扣掉一个名额。

这是源码检查发现的问题，实际报名测试还没走到这一步。但它的意义在于提醒：生成的代码“看起来对”和“业务上对”是两回事。保存、重启回读、重复请求、名额检查这些验证项，本轮都还没有执行。

业务逻辑正确性与“可运行”的差距：文中名额扣减按“数据库记录条数”而非“人数”计算，属于典型的语义级错误——代码语法无误、能跑通，却与需求语义不符。这类缺陷很难被静态检查或单元测试自动发现，因为测试往往由同一模型生成，容易继承同样的错误假设。在报名、库存、计费等场景中，正确做法是把“一笔记录”建模为包含人数、状态等字段的实体，扣减时对人数字段求和，并配合唯一约束或幂等键防止重复提交。作者强调“保存、重启回读、重复请求、名额检查”尚未执行，正说明验证必须覆盖业务断言，而不能止步于“文件已生成、命令能启动”。

上手成本：不是几分钟能算清的账

从没有现成环境开始，工作台安装用了约 4 分 41 秒，视觉模型下载、校验和登记用了约 7 分钟。这还没算生成等待、环境调整和逐项核对的时间。

部分中断调用没有返回完整用量，作者只保留已知记录，没有给出一个看似精确的总数——这个处理方式本身值得借鉴：本地模型的真实成本很难用单次生成时长来概括。

这轮结果：部分完成

最终状态是部分完成：生成了表单、组件和后台文件，也修正过计划与运行环境；但页面接入、服务启动仍有缺口。开头那笔三人报名，本轮尚未真正保存下来。

作者也提到两条替代路线：界面起点可以看 Screenshot to Code；已有前后端工程、习惯在终端里修改，可以看 Aider。用图片辅助修改时，所选模型还得有视觉能力。这两条路线没有同题运行，所以不排生成质量名次。

如果你要借这类工具起一个工程，作者的建议很实在：把页面接入、启动和一笔真实回读放在最前面检查。就这次本地模型组合而言，还需要有人继续调试，才能把报名流程接通。