不装了,我实现了一个逼近免费的 bolt,一句话生成一个网页应用!

B站影视 2024-12-26 11:47 2

摘要:大家好!今天和大家分享一个我最近搞定的小工具,简单来说,它可以一句话生成一个完整的网页应用,成本低到不可思议——一毛钱就能实现一句话生成应用,甚至配合之前文章提到过的 open router[1] 上的开源 Google 的 Gemini2.0 免费大模型,完

大家好!今天和大家分享一个我最近搞定的小工具,简单来说,它可以一句话生成一个完整的网页应用,成本低到不可思议——一毛钱就能实现一句话生成应用,甚至配合之前文章提到过的 open router[1] 上的开源 Google 的 Gemini2.0 免费大模型,完全 0 成本!说了这么多,如果你觉得已经有 v0.dev 或者 bolt 这些现成的工具,为啥还造一个轮子,那我必须得说,我确实是“造了一个轮子”。不过,这背后有很实际的原因:成本

我的项目的界面

一个计算器应用示例

先来说说背景。很多朋友可能听说过类似 bolt 或 v0.dev 这样的工具,能快速生成应用,非常方便。但在实际场景中,尤其是一些小型项目,动不动几块钱、几十块钱的订阅成本就显得没那么友好了。于是,我尝试自己做了一款超轻量的工具,结合 DeepSeek API[2] 这种价格屠夫,很愉快的实现了极低的成本。

最终结果是:不到一毛钱就能跑一个项目!我 1 充值了 1 块钱,测试了几十次项目的生成,都还没用完。

deepseek 这个价格太感人了...

更棒的是,这套工具支持本地部署,可塑性很强,还非常适合做开发流程自动化。

整个工具的核心思想其实很简单,用一句话总结:把复杂需求拆解成多个小需求,逐步迭代完成,并用自动化工具保证结果正确

具体来说,我是这样实现的:

1. 需求拆分
我先把一个大需求分解成多个小需求。比如,“做一个登录页面”这个大需求,会被拆分成“实现登录接口”“编写前端页面”“配置后端校验”等小需求。2. 迭代执行
每个小需求完成后,用自动化测试工具 Cypress 进行验证。

基于每个 feature,写自动化测试代码

Cypress进行自动化测试,验证feature 是否 ok

如果测试通过,就开始下一个小需求;如果没通过,就重新实现直到通过。

3. 上下文传递
这个环节是整套流程的难点。为了让每个小需求都能“记住”上下文,我设计了一套“取巧”的方法:• 首先将文件目录结构和需求描述一起发送给大模型,让它分析应该用哪些文件。• 然后整理这些文件,连同需求一起交给大模型,生成具体实现。• 这样一来,模型能更精准地输出结果,减少不必要的返工。

选择和该 feature 相关的文件,作为上下文

在开发过程中,我深刻体会到一个词:解锁黑盒
每一步都像在拆开一个谜题,甚至有时候你还得自己造个工具来“开锁”。

为了解决重复实现的问题,我特别准备了一些自定义模板。比如,针对不同类型的需求(如表单处理、接口调用、文件上传等),先写好一套基础模板,后续需求都基于模板迭代。这不仅节省了时间,也大幅降低了 token 消耗。

为了让大家更直观了解,我画了一张流程图,看看整个工具的工作过程:

从代码实现的角度,整个工具的核心是上下文管理和文件解析。这是一个伪代码示例,展示了如何传递目录和需求:

import osfrom some_ai_model import generate_codefrom cypress_runner import run_testsdefprocess_task(task, context_dir): # 获取文件目录 files = os.listdir(context_dir) # 整理上下文 context = { "files": files, "task": task } # 调用大模型生成代码 generated_code = generate_code(context) # 保存生成的代码 save_code(generated_code, context_dir) # 运行测试 test_result = run_tests(context_dir) return test_resulttask = "实现登录接口"context_dir = "./project_files"ifnot process_task(task, context_dir): print("需求未通过测试,重新生成...")特点自制工具bolt / v0.dev 等工具成本低至一毛/项目相对较高是否支持本地部署支持部分支持可塑性非常高依赖平台

低成本是因为它完全基于开源技术和自定义流程,而非绑定商业平台。对于一些实验性质的项目、个人练习,甚至是创业团队的快速 MVP,这样的工具显然更灵活。

这次“造轮子”的体验让我感触很深。虽然从表面看,做这样一个工具是追求低成本,但实际上,它让我对工程化开发有了更多思考——如何用更高效的方式迭代需求?如何更精准地管理上下文?如何让开发和测试真正结合?

如果你也有类似的开发需求,欢迎一起交流。希望这篇文章对你有所启发!

本文,完。觉得本篇文章不错的,记得随手点个赞、收藏和转发三连,感谢感谢~如果想第一时间收到推送,请记得关注我们⭐~

来源:AIGC研究社一点号

相关推荐