AI 工具站的护城河在 Preview：两条路线，决定是两周上线还是两个月填坑

我们在做一款面向编程小白的AI应用生成工具，在做 demo 时，一个细节反复提醒：用户付费的往往不是“生成代码”，而是“看到成品在跑”。很多工具把交付终点放在 zip 上，对编程小白来说，zip 更像一份作业，解压之后下一步全靠猜。预览系统稳，信心就稳；预览系统飘，模型再聪明也像在放演示视频。

把市面上的 AI builder 拆开看，预览大致只有两条主流路线。很多产品表面都写“Vite + 预览 + 下载”，真正差异不在 Vite、不在 React，而在一个问题：项目到底由谁来跑。

一、路线 A：Blot 式预览，文件夹到静态站

这条路线把网站降维成文件集合：Markdown、图片、配置，经过解析与模板渲染，直接产出静态文件，再托管成可访问链接。工作方式很像印刷厂：稿件进来，成品出去。

优点很直给：
1）链路短，失败点少。渲染失败通常是内容或模板问题，定位快。
2）几乎不执行用户代码，风控压力小。
3）成本线性，静态托管和缓存容易估算。

边界也清晰：适合内容站、落地页、文档站、作品集一类“展示型交付”。一旦需求出现登录、数据库、复杂交互，能力就会明显吃紧。静态可以很强，但它更擅长“发布”，不擅长“运行”。

二、路线 B：AI Studio 式预览，生成后在平台里跑起来

这条路线把预览当作运行态：生成项目只是起点，平台需要安装依赖、构建、启动服务，再把运行中的页面映射成预览链接。工作方式更像食品加工厂：原料进来，流程一长，安全与卫生要全套。

好处同样明显：
1）交互型小工具能真正跑起来，右侧看到的是结果。
2）多轮修改能形成闭环：改一句话，预览刷新一次。
3）对小白更友好，交付物更像“已经完成”的东西。

代价也很真实：工程量与运维成本会陡增，尤其是并发上来以后。很多“看起来像 IDE”的产品，最终都在这一段被迫变成半个云平台。

三、同叫 Preview，难度差很大的原因

路线 B 的难点不在生成，而在把运行系统做稳。至少要扛住五件事：

1）隔离
每个项目需要独立环境，互不影响。最怕的不是项目跑不起来，而是项目 A 把项目 B 的资源吃光。

2）限额
CPU、内存、构建时长、并发都要有上限。不设限额，账单会替系统设限额。

3）观测
进度条与日志不是锦上添花，是“信心供给”。没有日志，用户默认卡死。给一行“installing dependencies”，耐心就能多 30 秒。

4）清理
预览链接要有 TTL，到期自动回收。否则等于免费长期托管，很快从创业项目变成公益项目。

5）风控
允许执行用户代码，就要默认存在滥用与误用。哪怕没有恶意，生成一个死循环也能让机器在角落里悄悄尖叫。

很多 demo 阶段看起来“能跑”，上线后变得“总在跑偏”，原因往往集中在这五件事没收口。

四、选路线的粗暴决策法

早期路线选择可以简单到两句：

• 交付物偏展示与内容：路线 A 更省心。
• 交付物偏工具与流程：路线 B 更贴近用户预期。

如果还不确定，可以看三个指标：
1）交互复杂度：越高越需要运行态预览。
2）目标用户编程能力：小白越多，越需要可分享预览链接。
3）预算与时间：两周上线通常从路线 A 或“窄版路线 B”开始。

“窄版路线 B”指的是先固定 2 到 3 个模板配方，先保证稳定交付，不急着覆盖所有框架与所有需求。自由度越大，跑偏概率越高，工单密度也越高。

五、稳定性才是第二护城河：多轮微调如何不飘

demo 阶段遇到过一个经典翻车：用户只是问“支持哪些类型”，系统却回了一句“已更新项目”，预览还停在占位页。后来复盘发现，模型并不关键，关键在产品逻辑没有把行为分流。

为了让多轮修改稳定，有三条原则被固定下来：

1）SSOT
工程文件是唯一真相源。聊天记录只能参考，不能当事实。

2）Patch
每次修改输出补丁，默认只允许 edit。新增与删除需要显式确认，避免“顺手把目录重构了”。

3）Guardrails
单次改动设上限，例如最多改 3 个文件、最多 120 行。超过就提示改动过大，需要重置。限制不影响聪明，限制提升可控。

再加一条“意图路由”会极大改善体验：把输入分成 ASK、EDIT、RESET。ASK 只回答不改工程，EDIT 才触发生成，RESET 需要二次确认。小白最怕的往往不是功能少，而是不确定系统下一步会做什么。

六、面向编程小白的交付方式：把 zip 放到第二位

在这个项目里，交付被拆成三件套：

1）可分享预览链接
先让成果可展示、可验收。哪怕是临时链接，也比 zip 更像完成品。

2）zip 导出
提供源码可带走，满足可控性与可迁移。对懂的人是资产，对不懂的人可以先不碰。

3）一页部署路线图
给出可复现步骤与常见坑位，避免“拿到 zip 就断档”。路线图不代办上线，只把路径写清楚。

“最后一公里”适合做成增值服务或合作交付，不建议塞进 MVP。MVP 阶段把上线也包了，工单会把节奏打散，迭代会被迫围着个案转。

七、MVP 实现清单：能跑起来比能生成更多更重要

前端壳：

• 三栏布局：Chat / Files / Preview
• 顶栏状态：Idle / Generating / Ready / Error
• 流式日志与进度条
• Settings：Provider、BaseURL、API Key 存本地

稳定性骨架：

• Intent Router：ASK 不触发生成
• ProjectState：文件 Map 做 SSOT
• Patch 协议与护栏
• Reset 二次确认

后端最小闭环：

• 任务队列：生成、构建、运行异步化
• 沙箱运行：隔离与限额
• 反向代理：预览链接映射
• TTL 清理：到期回收

如果还想进一步减重，可以先把“下载真 zip”换成“导出文件清单”，先把预览跑稳，再补交付形态。很多项目倒在“先把包装做完”，却没有一个稳定的预览闭环。

结语

预览系统稳了以后，AI 工具站才从 demo 变成工具。模型会变，提示词会变，预览让用户看到可验证结果，这件事很难被替代。

这个项目目前的方向很明确：bolt 风格的交互外壳，加上 AI Studio 风格的运行骨架，再用清晰的交付边界守住成本与风险。后续如果需要把多轮微调做得更像工程协作，Patch、护栏、意图路由会优先于换模型。