这篇文章记录 SayCraft 从一个想法变成产品的过程。不讲代码，只讲那些拿主意的时刻——为什么选这条路，又为什么后来推翻了。

起点：开会的时候，产品能不能自己长出来？

2026 年 5 月下旬，我在想一个问题：市面上的 AI 建站工具（Bolt、Lovable、v0）都是一个人对着输入框打字，写 prompt，等结果。这事儿本身没毛病，但它跟真实的产品开发差得远——真实场景是几个人坐一起开会，边聊边改，需求在对话中成形。

能不能做一个工具，开着会，说着话，产品就在旁边实时长出来？

这就是 SayCraft（当时还叫 FlashDesign）的起点。核心卖点用一个词概括：边说边渲染。

竞品分析：我们到底在跟谁打？

5 月 26 号我花了整整一天做竞品调研，结论让我松了口气：没有直接竞争对手。

Lovable 和 Bolt 做的是"把 prompt 变成页面"，一个人，一个输入框。Cursor 面向已经会写代码的人，帮他们写得更快。v0 是组件级生成，给开发者用的。Replit Agent 最接近，但它也是单人打字模式。

没有任何产品在做"多人实时对话 → 产品自动生成"这件事。这不是说我比他们强——是赛道不一样。他们在 prompt-to-page，我在 conversation-to-product。

他们把 prompt 变成页面，SayCraft 把对话变成产品。

这句话后来成了我们的核心定位。

架构选择：沙箱里养一个 Claude

技术方案经历了几次迭代。最终的架构是这样的：每场会议开一个 E2B 云沙箱，沙箱里跑一个长驻的 Claude Code 进程。用户说话 → 语音转文字 → AI 协调器理解意图、拆解需求 → Claude Code 在沙箱里写代码 → Vite 热更新 → 用户实时看到界面变化。

这个架构有一个关键决策：协调器（coordinator）和编码器（coder）是两个独立的角色。协调器负责"听懂用户在说什么、拆成技术需求"，编码器负责"写代码、出界面"。协调器永远不写代码，编码器不需要理解会议上下文。

为什么要这么拆？因为一开始我们试过让一个 AI 全干，结果它经常在理解需求和写代码之间来回跳，两头都做不好。拆开之后，每个角色的 prompt 可以做得很专注，效果好了不止一个档次。

模板系统：我的小巧思

这是我最得意的一个设计决策。

早期我让 Claude Code 从零开始写每个项目，发现两个问题：一是慢，从头搭 React 项目结构要好几分钟；二是丑，AI 写的 UI 千篇一律，没有设计感。

我的想法是：预先做好一套高端设计模板。用户开会说"做一个 todo app"，协调器根据需求选一个最合适的风格模板（比如极简风、赛博朋克、毛玻璃风），Claude Code 在这个模板的基础上改。模板已经有了漂亮的配色、排版、动效，Claude 只需要改内容和逻辑。

这一招同时解决了两个问题：速度快了（不用从零建项目），质量高了（模板兜底了设计水准）。后来我们做了 21 个风格模板，每个都包含完整的设计系统。

"过程有戏，成品干净"

5 月 27 号，我发现了一个让我兴奋的东西：Claude.ai 可以一边写代码一边实时渲染界面，每打一个字界面就变一下，视觉冲击力非常强。

我立刻想把这个效果搬到 SayCraft 里——开会的时候，组件一个一个淡入画面，用户能亲眼看到产品在"生长"。

研究之后发现，真正的逐 token 流式渲染在我们的架构下做不到（Claude Code 写文件是原子操作，一次写完一整个文件，不存在"写一半"的状态）。但我想到了一个替代方案：用 MutationObserver 监听 DOM 变化，每个新组件出现时自动加一个淡入动画。效果虽然不是真正的流式，但视觉上足够好。

关键的产品理念是：会议进行时要有"看戏"的感觉，但最终归档的产品要干干净净。我们利用了 Vite 的一个编译特性——开发模式下动效生效，生产构建时动效代码被自动移除。不用写任何开关逻辑，编译器帮你搞定。

调这个淡入效果花了整整 4 个小时，改了 8 轮。方案 2 小时就定了，剩下全在跟浏览器 API 的边界情况搏斗——React 的 StrictMode 会让组件挂载两次，Vite 的 HMR 热更新会重复触发动画，iframe 重载会导致已有组件重新淡入……每一个都是"听起来简单、调起来想砸键盘"的 bug。

图片填充的教训：确定性任务不该用 LLM

5 月 25 号踩了一个大坑。

模板里有很多占位图片需要替换成真实图片。一开始我们让 Claude Code 在沙箱里完成这个任务——它搜图、下载、替换路径。问题是这事儿又慢又不可靠：LLM 可能搜错图、下错路径、漏掉几张，而且每次结果不一样。

后来我们做了一个根本性的改变：把图片填充从 Claude Code 手里拿走，换成一个确定性的 Bun 脚本。脚本扫描所有 img 标签的 alt 文本，调 Pexels API 搜图，按规则替换。整个流程变成了：固定的输入 → 固定的逻辑 → 可预测的输出。

效果立竿见影。处理速度从 25 分钟降到 7 分钟，而且每次结果一致，不再有"这次搜到了那次没搜到"的问题。

确定性的任务，不要用 LLM 去做。LLM 擅长的是理解意图和创造性工作，不是按固定规则执行操作。

这个教训后来影响了很多决策。每次遇到新需求，我们都会先问一句：这件事是确定性的还是需要理解力的？

代码审查翻车：7 轮 review 都没查出来的 bug

5 月 28 号，我们做了一次全链路 code review。AI 做了 7 轮审查，从 CRITICAL 到 HIGH 到 LOW 到 0 finding，信心满满地部署上线。

结果用户一进 meeting 页面就报错。

原因荒唐得可笑：review 过程中 AI 给所有接口加了身份验证（通过 HTTP header 传 user ID），但前端根本没传这个 header。更要命的是，浏览器 WebSocket 协议根本不支持自定义 header——这是协议层面的限制，不是代码 bug。

7 轮 review 全用 curl 命令测试（curl 可以随便加 header），从来没有用真正的浏览器 WebSocket 客户端跑过一次。AI agent 做的"验证"也只是读代码，不跑浏览器。

教训很痛：

• curl 测试 ≠ 浏览器测试，协议边界的问题静态分析抓不住
• 加权限校验之前，先确认凭证传递的通路是通的
• AI review 是文本审查，不是运行时验证——涉及协议和浏览器行为的改动，必须跑真实客户端

最后那轮 review 加的所有身份验证代码全部回退。

从 FlashDesign 到 SayCraft

产品名字改了三次。

最早叫 FlashDesign。问题是"Flash"这个词太脏了——搜索结果里 Adobe Flash（已死的技术）、flash tattoo（纹身）、flash sale（促销）一大堆，品牌信号被严重稀释。

然后试了 JustTalk。概念很好（"只需要说话"），但有个同名的视频通话 app 焊死了搜索第一页。而且听起来像聊天工具，不像建站工具。

中间还考虑过 VoxShip、Enchant、Herald、TalkForge，全部因为域名被占、搜索有同名竞品、或者品类信号错误而淘汰。

最后定的 SayCraft。Say（说）+ Craft（做出来），不会写代码的人一看就懂。saycraft.ai 域名可注册，搜索引擎里没有任何同名产品——干净得像一张白纸。

取名过程中最大的认知纠正：品牌名追求的是"独占性"，不是搜索量。一个没人用的名字能在几周内排到搜索第一。搜索流量是靠内容页去抓的，不是靠品牌名。

品牌名负责被记住、被搜到时只指向你。搜索流量交给 SEO 落地页去抓。这是两件事，别让一个名字背两个 KPI。

回头看

从 5 月 22 号的第一行代码到 6 月 8 号正式命名 SayCraft，两周半。做了什么呢？

选了一条没人走过的赛道（对话即产品），搭了一套能跑的架构（沙箱 + 协调器 + 编码器），用模板解决了设计质量问题，用确定性脚本替代了 LLM 做不好的事，被 code review 翻车教了一课，改了三次名字。

每个决策当时都觉得"这还用想吗"，事后看才发现"想错了"或者"想对了但理由不对"。创业就是这样，你以为自己在做技术选型，其实是在跟自己的认知偏差搏斗。

这只是开始。后面还有 SEO 踩坑、定价纠结、部署灾难、模型选型……一个人做 SaaS，每天都在学新东西。

产品在这：saycraft.ai，一段 demo 视频在这：YouTube。