感谢大家的捧场，上一篇应用分享，本来是“或”的解锁条件，满足了两项。所以，今天解锁第二个利用Gemini AI Studio的Build开发的第二个日常使用的工具：Narrator。最早其实是作为报告可视化用的，但是我一直想把音频旁白加进去，终于在10月20号前后，Build可以很顺利的调用两个TTS模型了。所以，应用也从Visualizer变成了Visualizer and Narrator，简称Narrator。
当然，也加入了Cloudflare后台接口的支持，加入到fabric项目中：https://github.com/dmquant/fabric
同时也开了AI Studio中的分享，有AI Studio的朋友可以直接访问：https://ai.studio/apps/drive/15RVSylPfO98uPN8GI1Kv52FuMm44DubE
这段时间不断修改后，目前的项目多少有了一点点“大杂烩”的意味，感觉超过了Google对Build的承载能力的设计。
简单说功能：
- 二维的报告可视化：目前设定了四种样式模版，可以选模型，中英文切换支持，还可以生成旁白的口播稿；
- 三维场景：这是一个尝试，后面再略微展开一下；
- 自动演示模式：可视化幻灯片+音频一气呵成，自动播放，只需要录屏就可以生成视频，我在视频号发过一期；
这也是几乎我每天都要用到的工具，边用边改细节。这大概也是Gemini模型能力的最佳代表：代码生成+图片+音频。以这样可复用的方式，几乎每天都可以得到稳定的多模态效果，肯定是无出其右的。
而且可以不断进化，比如，三维演播厅，就是我这几天一直在琢磨的方式。
这也是带语音可自动播放的，有兴趣的可以尝试一下。考虑到Build承载不了太大的3D场景，恰好，“三维重建”也是我过去几年里花了不少时间研究及尝试的课题，所以，我也会把这一部分搬出Build，结合Blender，进行拓展。另外，在有限的被传是Gemini-3.0的模型的尝试中，我对模型的三维空间理解力也有了更多的信心。或者说就是因为这种信心，让我回过来使用2.5模型进行了尝试。
这是否同时是“模型能够进步”和“现在模型已经很强，关键是如何挖掘潜力”的印证呢？
其实，还有些细节可以分享的，但是留给感兴趣的朋友吧，代码里面还有很多问题，包括提示词和流程，同样，留给感兴趣的朋友吧。
这个项目我前前后后修改了很多次，所以，以此来讨论一下vibe coding，可能是有意义的，我曾经写过一篇vibe coding的要点。这里，做些梳理和更具像化。
首先，Build真的是最好的vibe coding工具，完全体现了vibe的“要义”。对我而言，这甚至不是coding，就是vibe working。
其次，我总结一下，大概是四个流程：1.初步想法及初次构建；2.回到设计；3.改进；4.使用，并回到2。是的，我用了一种三十多年前的代码习惯：BASIC中的“GOTO”。我学编程时连英文字母都还认识不全，我最早学会的英文单词是{BEGIN,END,IF,THEN,LOOP,DO,WHILE,GOTO}，还有BASIC，AI Coding让我回到了那个时刻，很开心。
也因此我看不上现在到处散播的所谓Agent教程，这是最基本的程序思维，好吗？
回到主题：
- 初步想法及初次构建。这是跟我之前写的vibe coding要点最冲突的地方，按照我之前的说法，第一步永远是设计。但，Build就是一个非常不同的应用，它的代码架构很轻，所以就应该在第一时刻用最简单的描述让build“自由发挥”，看看能出来什么。这种MVP版本的尝试可以有效的帮助自己理清思路，提出更明确的需求；
- 第二步才是设计。设计还分两部分，我会将初次构建时的代码，UI同时给到Gemini-2.5-Pro Deep Think模型和GPT-5-Pro，让它进行详细设计，也会给到基于Gemini的设计应用Stitch，进行UI设计。Stitch也已经是我离不开的工具了，页面设计既可以导出代码，也可以直接导出到figma。
有了设计文档和UI设计后，回到Build，进行改进甚至是重建。我每一个项目都会同时让GPT-5-Pro和Gemini-2.5-Pro Deep Think出设计文档，但是我每一次都会采用Gemini的方案，原因很简单，因为只有Gemini的方案可以落地（无论是给Build，还是在其它coding环境里给claude或者codex）。GPT-5-Pro会给出看起来很完整很详细的方案，但，就是不能执行。Coding，虽然勤奋挺重要，但“天赋”更重要；
- 边用边改。Build开发的应用几乎都是为了原生调用Gemini系列模型的，一边使用，一边就会发现bug，界面设计的不人性化，提示词的缺点，一系列问题，那就一边用一边改，vibe working。我会不断回到stitch，比如修改UI，比如对于可视化结果，要给Build一些模版，等等。当然，有时候发现流程有问题，或者要新加功能时，就还是需要回到方案设计环节。三十年前参加竞赛（最近很多朋友好奇我的经历，这是我的一部分经历）时被严令禁止的“GOTO”，就这么堂而皇之的回来了，爽！
到这里，也不得不说一下Build适合的场景：
- 主要面向小工具，而不是大项目。我曾经试图将很多功能集成到一个应用中，结果就会把处理逻辑搞乱，其实今天分享的应用，已经有了这样的倾向了；
- 直接面向业务需求。这其实是一个很tricky的问题，Build可能就不是为程序员准备的，而是为能描述清楚业务需求的人准备的。但是坦白说，对于编程基础较少的人而言，又不是那么友好的，因为在改进过程中，确实会经常出现逻辑被大幅改写的状况，或者一些外部库调用的问题，这时候都需要一些经验来帮助它；
- 需要嵌入模型但不需要数据持久化的应用。如果要开发的应用在使用中本身不需要使用Gemini模型，那就不需要build。同样，除非跟我一样“外挂”一套后台存储，否则如果希望保存运行中数据的，也不适合Build。
简单一句话，轻而美的AI工具应用，一个应用解决一个问题。
分享到此，可能会有点混乱。只能看分享以后的项目中再优化了。
预告，下一个准备解锁的项目：公司深度研究：仅需输入一个代码，不限市场。
稍微提高一下解锁条件，此篇满足：OR（12K阅读量，60赞，220转发）。
