编程只剩架构和约束了

Qiuner — Mon, 21 Sep 2026 10:59:09 +0800

我最近一直在想一个问题。

身边好多没写过代码的朋友，现在都在用 AI 做东西。有人做了自己的作品集网站，有人做了个接单工具，有人直接用来跑业务了。做出来的东西颜值真的高——有时候比写了十年代码的人做的还好看。（文科生确实有不少有审美的）

但没有学过古法编程的人，是有天花板的。

局部很好，全局在烂

用 AI agent 做项目这段时间，我发现一件挺有意思的事：

你给它一个具体的小任务，它做得挺好的。改一个函数、写一个组件、调一下接口——没什么问题。

但你让它接手稍微大一点的项目，它就开始不知道自己在哪里了。这个模块改了会不会影响那个？状态应该放哪管？这个设计选择以后会不会越来越难扩展？——它不知道，也不会问你，它就直接写了。

它在每一个局部都在"尽力"，但全局在悄悄腐烂。

业界现在已经给这个现象起名字了，叫"Spaghetti Point"——vibe coding 在第一周感觉很快，但大概三个月后线就交叉了，加新功能开始把已有功能搞坏。这些相关的报道最近越来越多：

《Vibe Coding Technical Debt 2026: The 90-Day Reckoning》 — 数据很具体：AI 工具采用后技术债增加 30-41%，代码重复上升 48%，重构活动下降 60%。重构下降的原因很直接：团队在加速，没有在停下来整理。债在 90 天后开始集中爆。 👉 https://thevibelog.dev/blog/vibe-coding-technical-debt-2026/

《Vibe Coding Technical Debt: 8,000 Startups Are Now Paying to Rebuild》 — 到 2026 年中，大约有 8000 个用 AI 工具做出来的产品需要局部或整体重建，救场成本每家 $5 万到 $50 万不等。2026 年 3 月单月，有 35 个 CVE（安全漏洞）被直接归因于 AI 生成代码，一月份是 6 个，还在加速。 👉 https://getcreatr.com/vibe-coding-technical-debt

《Why Software Factories Fail》 — 作者 Dex Horthy 的团队 2025 年 7 月让 AI agent 完全自主写代码，三个月后放弃。结论：模型没办法可靠地区分好架构和坏架构，现有评测衡量的是"任务通不通过"，不是那种让每次改动都越来越难的、缓慢的架构腐蚀。这篇 HN 341 赞，评论区 240 多条。 👉 https://www.developersdigest.tech/blog/software-factories-fail-harness-engineering

《The Real Cost of Ignoring Vibe Code Technical Debt》 — CodeRabbit 分析 470 个开源 PR：AI 协作写的代码比纯人工多 1.7 倍重大问题，安全漏洞是 2.74 倍。Salesforce 分析师直接把 2026 年命名为"技术债之年"，原因就是 vibe coding 的规模化采用。 👉 https://azumo.com/artificial-intelligence/ai-insights/vibe-coding-rescue-roi

关于约束

有一篇文章里有句话让我印象很深：

那些用 AI 没有效率提升的人，是在没有计划的情况下乱 prompt。那些效率提高十倍的人，80% 的时间花在架构、规范和约束上，只有 20% 花在执行上。

"约束"这个词我越来越觉得是核心。

AI 不怕任务多，不怕代码长，它怕的是边界不清。你不告诉它这个模块不能直接调那个，它就调了。你不告诉它状态只能单向流动，它就双向搞了。你不告诉它这个接口以后要给三个不同的客户端用，它就按最简单的方式写了。

约束是架构的骨架。你给 AI 的约束越清晰，它产出的东西越不容易烂。

但约束从哪来？从你对整个系统的理解。你得先知道这个系统是什么形状，才能说清楚哪里不能碰、哪里可以乱。

所以现在编程剩下的核心工作，某种意义上就是两件事：架构（系统是什么形状）和约束（哪里不能乱）。写代码本身变成了执行层，AI 来就行。

零基础的天花板

再说回那些没有编程背景的朋友。

前端、动效、布局、响应式——AI 真会，他们的审美有时候甩老程序员几条街。

‘

但他们几乎必然会卡在同一些地方：

后端一复杂就打结。用户登录、权限控制、数据怎么存、API 怎么设计——AI 能给代码，但为什么这样设计，他们不清楚。每次改动都像开盲盒。

状态管理也是。这个数据应该放在哪里？这两个组件怎么共享？请求 loading 的时候界面该干嘛？要你脑子里有一张图才能处理这些。AI 写出来的能跑，但状态散得到处都是，项目稍微长大一点，自己改自己出 bug。

最根本的问题是——他们没有办法给 AI 好的约束。不是因为他们不聪明，是因为你得先理解系统是什么形状，才能说清楚约束是什么。这个理解没有捷径，目前为止 AI 还给不了。

LeadDev 今年四月有篇文章说得很直接：AI 让编码变快了，但真正的瓶颈移到了上游——问题拆解、方案定义、判断什么是对的。 👉 https://leaddev.com/?p=32743

Birdview 在做什么

这是我做这个项目的背景。

AI agent 对整个项目是盲的。它不知道自己改了什么、影响了什么、在整个系统里身处何处。Birdview 想做的是：在 agent 动手之前，先把架构图画出来，让它知道模块是什么、边界在哪、约束是什么，然后再改代码。

用 Birdview 来推翻古法编程！这是写代码的新时代与范式！

v0.1 刚出来，很早期。如果你也在用 AI agent 做中等以上规模的项目，也遇到过"改着改着就乱了"的感觉，可以来看看：

GitHub - Qiuner/birdview: Stop letting AI code blind. Map the architecture before every change with Birdview. · GitHub

issue 和 discussion 都开着，推荐的使用方式是先让 ai 画图，然后稍微大一点的需求才开启技能，你也可以要求全程开启，不过那样改个很小的前端都会先画图再落代码…比较繁琐。给我个 star 吧，屏幕前的大帅哥！

也欢迎大家一起进来贡献阿，定义新的编程范式！

Qiuner (觉悟空性)

编程只剩架构和约束了

局部很好，全局在烂

关于约束

零基础的天花板

Birdview 在做什么