GitHub上看到了一个非常值得关注的项目

这个联系人管理应用居然能跑起来，而且看起来功能齐全：可以创建联系人、查看列表、编辑和删除，页面还能返回 JSON 接口。但有一点很奇怪——开发者没有写传统意义上的业务逻辑代码。没有 Controller、Service、DAO，也没有用 Vue 或 React，连前后端的那套分层都省了。

先说结果：所有对联系人增删改查的工作，都是让一个大模型在“运行时”决定的。换句话说，应用把大模型当成了真正的后端程序来用，模型负责处理 HTTP 请求、生成 SQL、渲染 HTML、返回 JSON。听起来像科幻，实操起来也的确 能响应用户请求。

回到技术实现层面。项目用了一个传统的 Web 服务器来接入用户请求，核心放在一个叫 LLM Handler 的组件里。这个组件把收到的 HTTP 请求填进提示词模板，同时把数据库访问、文件访问等工具的能力一并交给大模型。大模型收到这些信息后，会判断要不要查询数据库、修改数据或渲染页面，最后返回 HTML 或 JSON 给用户。核心逻辑就几行代码，主体在于把请求交给模型并把模型的输出直接当作响应发回去。为此，项目实际上写了约 687 行代码，把模型包装成一个“可调用的应用运行时”。

功能和界面方面，模型自己设计了数据库表结构，给字段选了合适的类型和索引；构造了参数化的 SQL 查询，注意到了防注入的写法；生成了遵循类 REST 的 API 路由；前端部分则用响应式的 Bootstrap 布局，模型还生成了表单校验逻辑和基本的错误处理。访问 /contacts 会得到一个完整的 HTML 页面，访问 /api/contacts 则返回 JSON。首页是一个空列表的视图，创建页面包含表单，列表页和详情页都能正确显示数据。这些页面并非硬编码，而是每次由模型根据请求和上下文生成。

实现过程中有几处关键点值得注意。第一，大模型本身无法直接访问数据库或文件系统，也不能充当一个真正的 Web 服务器，所以工程上必须提供外部工具和接口，把这些能力通过 LLM Handler 暴露给模型。其次，提示词模板里不仅包含请求信息，还包括如何构造响应的指令，模型据此决定要执行哪些数据库操作或生成什么样的 HTML。最后，项目加入了对极端情况的处理逻辑，列如当模型输出不符合预期时的兜底流程，确保不会直接把错误内容返回给用户。

不过，实际运行时的问题也很明显。每次点击或提交表单，处理延迟在 30 到 60 秒之间，比传统 Web 应用慢许多，差不多慢 300 到 6000 倍。成本方面，每次请求消耗大约 0.01 到 0.05 美元的 token，这比常规服务器计算贵上 100 到 1000 倍。界面一致性也不可靠：一样的页面在不同请求中可能会出现颜色、布局变化，甚至字段顺序改动，体验不稳定。总体上，这套方案在性能、费用和稳定性三方面都不具备商业化优势。

看到这些细节，能理解项目作者的出发点：想验证一个观点——大模型是否能承担应用逻辑并生成可用的前端界面。答案是肯定的，至少在功能覆盖上是可行的。作者在代码仓说明里提到，当前的痛点都和速度、成本和一致性有关。如果模型推理速度能够每年提升十倍，推理费用趋近于零，同时输出稳定性提高，那问题或许会慢慢减少。换句白话，就是技术进步能把这些短板逐步抹平。

我个人觉得，这种做法有强烈的实验意味。把模型当成运行时去调用，少了大量模板化的开发工作，但也把系统的可靠性和成本压在了模型服务上。到头来，是换了一种方式花钱换便利，还是彻底改变开发模式，还得看未来几年算力和成本的变化。说起来挺大胆，但也带点“把所有赌注压在模型身上”的味道。

项目源码托管在 GitHub，仓库名是 nokode，地址是
https://github.com/samrolken/nokode 。有兴趣的可以去看看实现细节、提示词模板和那几百行的包装代码。欢迎在评论区交流见解。