> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh/2026-nian/w16nocode-kuai-su-die-dai-yu-xin-de-gong-cheng-yue-shu.md).

# W16-nocode、快速迭代与新的工程约束

上周 HR 发了一个金服 10 年的 Vlog 活动。整个项目是我们一位实习同学罗华煜用 nocode 做的。我上周看了看这个项目的代码，有一些很有意思的发现。

第一，no-code 在这类项目上的生产力提升，几倍甚至几十倍，我都不会觉得意外。让我惊讶的是，这个项目整个过程一共生成了 268 个版本。我们都知道，AI 会持续加快软件交付速度，未来线上的生产项目大概率也会比今天快上几倍。但速度变快之后会发生什么，这个项目我觉得就是一个很好的例证。

前些年做类似抽奖活动时，通常是一个前端加一个后端，给半个多月时间，大家吭哧吭哧干一个多星期，先做出一个 MVP。客户看完提一轮建议，开发拿回去迭代，过两天再给客户看，往往还是不满意，再继续改一轮。最后常常是时间不够了，客户说“先这样吧”。整个过程中，客户真正能看到的版本，可能也就三四个，迭代条很快就走到头了。

但 nocode 把需求到实现之间的距离压缩到了很短，客户获得反馈的速度变快了，产生新想法的速度也变快了。同样是半个月时间，迭代条却往前走了 200 多个版本。以前很多根本不会发生的迭代，现在开始有条件发生。所以很重要的一点是，生产力提升以后，时间和资源未必会明显下降，反而更可能符合杰文斯悖论。因为实现的门槛下降了，想法就会变多，迭代也会变多，需求是可以趋近于无限的。消失的未必是工作量，更多只是把原来做不到的迭代释放了出来。

第二，看完这个项目的代码，我有一种挺强烈的感觉，人平时很少会主动写出这样的代码。这样一个完整的 Web 服务，没有独立的 server 端，而是由前端直接访问数据库，一共用了 16 条数据库存储过程。整体上，这是一个很典型的 Frontend-only + BaaS 架构。前端用 React + Vite 构建 SPA，没有单独的后端服务，所有数据操作都通过 supabase-js 在浏览器里直接调用美团私有化部署的 Supabase，底层数据库是 PostgreSQL。

业务逻辑被拆成了两部分。简单校验和频率限制放在前端 worksApi.js 里处理，涉及并发安全和数据一致性的核心逻辑，比如投票、点赞、删除，则封装成 PostgreSQL 存储函数，通过 supabase.rpc() 来触发，权限控制主要依赖数据库层的 RLS 策略兜底。这样的方案开发效率很高，也省掉了独立服务端的维护成本，但问题也很明显。业务逻辑同时散落在前端 JavaScript 和数据库 PL/pgSQL 两处，可维护性比较一般，一些敏感信息，比如管理员名单，也不得不以硬编码的方式放在客户端里。

这个项目的价值，不只是说明 nocode 能把一个活动页做得更快，而是很具体地展示了 AI 时代软件交付的一种新常态。版本会变得更多，反馈会变得更快，架构也会越来越倾向于先走最短实现路径。对团队来说，这里面既有很现实的生产力机会，也会带来新的工程约束。以后真正稀缺的，可能不是把功能先写出来，而是在极快迭代里，仍然能守住架构边界、可维护性和长期演进能力。