O.Convertor网站的诞生源于O.Translator运营过程中收集的多项用户需求，如PDF字体预览、视频音频提取、PDF拆分合并等。作者利用国庆假期，选择部分可在浏览器本地实现的功能，借助Gemini Web和Gemini-cli进行开发。首先，通过Gemini Web生成包含UI预览的index.html文件，并将其拆分为index.html、script.js和style.css三个文件，便于调试和后续处理。随后，将HTML部分转换为React组件，同时保留script.js的纯JavaScript逻辑，以提高开发效率并降低维护成本。整个过程显示了Gemini在理解需求和代码逻辑完成度方面的显著提升，即使是Gemini-flash模型也能胜任任务，这对于传统前端开发者而言，带来了新的挑战和思考。

🛠️ **AI驱动的工具开发新模式**：O.Convertor项目展示了如何利用Gemini等AI模型，结合浏览器本地开发能力，快速响应用户需求，开发出如PDF处理、音频提取等实用工具，为O.Translator生态增添新功能。

💡 **Gemini在前端开发中的应用**：文章详细阐述了利用Gemini Web生成HTML、CSS、JavaScript文件，以及通过Gemini-cli将HTML转换为React组件的流程。强调了清晰的Prompt指令和将代码拆分成独立文件的策略，能够有效提升开发效率和代码可维护性。

🚀 **优化开发流程与效率**：通过将UI逻辑（HTML）与业务逻辑（JavaScript）分离，以及优先调试纯JavaScript文件，作者显著降低了将原生HTML转换为React组件时的错误率和开发成本，使得后续的工具功能迭代更为顺畅。

📈 **AI模型能力的提升**：作者观察到Gemini模型在理解复杂需求和代码逻辑的准确性上有了显著进步，能够更好地处理细致的指令，即使是Gemini-flash模型也能胜任当前任务，预示着AI在编程辅助领域的广阔前景。

🤔 **对前端开发者的启示**：随着AI在代码生成和开发流程中的作用日益增强，传统前端开发者需要适应这种变化，拥抱AI工具，并可能需要重新思考自身在开发流程中的定位，例如从“切图仔”向更侧重架构设计和AI协作的方向发展。

工具链接： https://oconvertor.com/zh

背景

在运营 O.Translator 的过程中，遇到一些需求：1 、针对 PDF 文档，经常会有字体的问题，比如字体乱码、字体覆盖等，这时需要提取并预览排查 PDF 中的字体；2 、在音频翻译流程中，需要给用户提供从本地视频中提取音频的工具，主打快捷；3 、用户要求只翻译 PDF 的某些页，虽然在翻译流程中已经支持了相关配置，但是发现用的人也不多，干脆做个 PDF 拆分合并的工具算了；4 、...
这些需求，大部分是我们自己研发需要，有些也是用户需要，正好国庆这几天有时间，从里面选择几个浏览器本地能做的，尝试让 AI 来做。于是就有了 O.Convertor 这个网站，整个过程体验感还是不错，下面是大体的流程。

流程步骤

1 、先用 Gemini Web 生成单页面工具

先在 Gemini Web 上生成 index.html ，好处是可以直接在 canvas 预览 UI ；

在这一步的经验是：在 Prompt 中，要清晰地告诉 Gemini “要做什么”，而不是“要怎么做”。你可以让 Gemini 生成一个包含所有代码的 index.html ，也可以要求它拆分成 index.html 、script.js 、style.css 三个独立文件，它都能很好地处理。我选择生成 index.html 、script.js 、style.css 3 个文件，方便后面处理；然后，不管是生成单个 index.html 还是“3 剑客”，直接下载到本地，浏览器打开 index.html 调试功能用 Gemini 生成 HTML ，也是为了方便调试；这一步，UI 可能需要慢慢调试，符合你的审美（ Gemini 的审美还是在线的），交互逻辑的完成度还是很高；

2 、转换成 react 组件

对于静态网站，第一步生成的单页面工具就能直接放到服务器使用了，但我希望这些工具页面都有共同的导航 Header 和 Footer ，Header 和 Footer 是项目中的 React 组件，所以我继续将这些 HTML 转成 React 组件。最开始，我是将 UI 和 js 逻辑都进行转换，但是这样效率不高：

会有各种 ts 报错； 修改原始 js ，重新生成组件之后，大概率会带来新的未知问题；

所以，就有之前提到的，将单 index.html 分解成 index.html 、script.js 和 style.css 3 个文件，只将 index.html 进行转换，通过 Script 引入 script.js ，能避免很多问题；

大量的交互操作是在 script.js 中通过纯 js 做的，所以只要调试好 script.js ，即使后续要修改工具能力，重新生成 index.html 对应的组件，成本要小很多；

第二步，是使用 Gemini-cli 在项目本地完成的；

并不是必须要转成 React 组件，像 i18n ，可以直接用 O.Translator 翻译整个 HTML 和 js 文件；像 SEO ，也可以直接写在 index.html 中；我只是想在每个工具页面统一 Header 和 Footer 而已，并且这两个组件会不断的修改；

整体就是以上这两步，但在转换成 React 组件的时候会有其他细节需要处理：1 、用 lingui 做 i18n ；2 、UI 风格统一、SEO 内容加强的控制；3 、第三方库资源加载逻辑；这些细节，会有一些指令控制的技巧，但整体难度不大，以后有时间再针对聊聊；

结尾

这次给我最大的感受是，Gemini 对于需求的理解，代码逻辑完成度很高，半年前会出现，你让他改 A ，他会改到 B 的情况，现在基本不存在了；模型大部分是 Gemini-2.5-pro, 小部分是 Gemini-2.5-flash ，即使是 flash ，也能完成任务。最后，作为老前端切图仔，瑟瑟发抖。