作者 | 朱雷

使用 AI 类编程工具越多，我便越来越强烈地感觉到：AI 编程是一种“框架（Framework）”。

框架是每位程序员的老朋友，它通常针对特定领域所设计，能极大提升编码效率。以 REST API 服务为例，一些成熟的框架（比如 Django REST Framework[1]）能做到仅需定义数据模型和视图类 [2]，便生成一套功能完备的 CRUD API 服务。

AI 编程工具和传统框架一样，都是一种“杠杆”，它们允许人们用少量输入撬动庞大的功能。二者区别仅在于输入类型不同，框架需要代码（或配置），而 AI 仅需一句简单的自然语言提示词——“写一个书店网站”。

框架的问题

作为一种新型框架，“AI 编程”所带来的便利性，足以把人类从前发明过的任何一种框架按在地上摩擦，但是，框架天生所具备的问题并未消失。

1. 抽象泄露

所有框架都有一个共性，它们提供了极高级的抽象，以降低实现特定功能所需的工作量。比如，Django 的 ORM 提供了“数据模型”这层抽象，免去了手写 SQL 语言、设计数据校验等繁重工作。

但不幸的是，抽象都会泄露 [3]。

一名 Django 初学者编写的网站上线后，客户投诉爆表，因为列表页加载极为缓慢。此时，打开数据库监控面板，他会发现这个看似简单的页面，每访问一次就会发起 400 次数据库查询。要解决该问题，他必须弄脏双手，撕开 ORM 这个抽象层，弄懂“属性如何被加载？”，搞清楚“N+1 问题”的真相。

而使用 AI 编程工具，“抽象泄露”则发生在我们不得不抛弃轻松的自然语言提示词——“实现 XXX 功能”，转而说出 “你对 items 变量的状态转换的理解不对” 的时刻。

毋庸讳言，现阶段的 AI 仍存在智能瓶颈。当自然语言无法驱动 AI 准确完成工作时，打破抽象，打开已布满灰尘的 IDE，用精确到变量名的提示词帮 AI 找到根因，是我们的唯一选择。

2. 丧失控制权

世上实现代码复用的所有模式，大致可被分为两种： 框架（framework）和库（library）。

要区分一个东西是框架还是库，关键在于找到 “谁控制着程序的整体结构？” 这个问题的答案。使用框架，控制权牢牢掌握在框架手中，你所编写的程序，是镶嵌在伟岸的框架程序中的一部分。这有点像是去完成一副卡通图，所有元素都已用浅灰色线条勾边，你只负责给不同部位涂上不同颜色。

而使用库，控制权则仍掌握在你手里。你负责调配和使用不同的库，来搭建起整个程序。这像是玩积木，手边有千千万万个积木和模组，你负责把它们组装成想要的样子。

丧失控制权会带来哪些危害？这主要体现在可修改性上。

使用框架时，当程序需要定制一项功能，由于缺少控制权，工作的开展依赖于框架其是否支持该自定义选项。如果支持，那么整个过程会像热刀切开黄油一样丝滑。但假若框架并不支持，那么很不幸，你极可能在一个简单需求上花掉成吨时间。

平心而论，在“控制权”维度上，AI 编程还称不上天生属于“框架”还是“库”。但不可否认的是，当下最流行的一种趋势就是把它当成框架来使用。比如在 Vibe Coding 时，人类仅负责提供模糊的自然语言提示词，毫不关心程序的入出口与整体结构，一切由 AI Agent 这个框架所掌控。

认知成本：DRF 的启示

为何人们倾向于将 AI 当成框架？这是个有趣的问题。

我认为答案的关键在于一个词：认知成本。框架与生俱来的特质，给了我们一种暗示： 你可以用最低的认知成本实现最复杂的功能。 而人类生来就爱“省力”，少动脑而完成更多，是我们与生俱来追求的目标。

拿 DRF（Django REST Framework） 来举例。在 DRF 框架中，为一类数据模型实现一套 CRUD API，只需编写以下 4 行代码：

一个 class，三个属性，极低的认知成本，全套 RESTful API，怎么看这都是一门极其划算的生意。

但是，正如前面所提到的，框架的便利性是一把双刃剑，伴随框架出现的“抽象泄露”和“控制权丧失”问题不可避免。

做个假设，现在我们需要调整 API，让 create 方法返回不同的响应体，为 list 方法增加额外的过滤条件，基于以上代码该怎么做？答案是，先重写包含 get_queryset 在内的多个方法，再用一批 if/else 补丁将整个 ModelViewSet 爆改到面目全非。

既然如此，有没有更好的办法？答案是肯定的，我们完全可以弃用高级的 ModelViewSet，仅采用不附带任何魔法的 ViewSet，完全基于模块的组合来实现相同功能。

相比起来，新方案最直观的变化是代码量变多了，也显得更加啰嗦，但更大的改变其实发生在“认知成本”层面上。

在 ModelViewSet 版代码里，认知成本表面上很低，但更多成本其实被藏了起来，作为一种隐藏的认知债务所存在。后续，当需求发生变化时，这些债务给我们实现功能带来了巨大的麻烦。调整代码结构后，原本隐藏的债务浮出了水面，代码的可视性和可维护性也得到了有效提升。

假如以“框架和库”这个设定来观察上面的案例，新代码的组织模式更接近于“库”——人作为程序的主人去组织整个功能，而非“框架”——人仅作为 ModelViewSet 的仆人去填补空缺。

至此我们可以看到，框架与库并非一种对物品的二元化严格分类，而更像两种不同的思维方式。因为即便是在 DRF 这个庞大的框架中，也存在各种不同的代码组织模式，一些偏框架，另一些则明显偏向库。

也许，该把 AI 编程当成一种库

回到 AI 编程。将 AI 编程作为一种框架，会引导我们采用框架式思维，不断追求编写更短的提示词、对代码付出更少的关注，付出更少的认知成本来达成目的。

然而，就像前面的例子所展示的，在这种思维模式下，认知债务将不断堆积，框架与生俱来的“抽象泄露”与“控制权丧失”问题，也将在未来对我们产生严重危害。

既然如此，何不转变思维，将 AI 编程当成一种“库”？就像去使用任何其他库一样，我们作为程序的主人，调用它来完成工作。

这种思维模式的转变，可能意味着：

• 不再追求“写更少实现更多”：用更少的提示词（代码）实现更多功能，看上去很美，但也意味着大量的认知债务随之累积；

• 找到编写提示词的“甜蜜区”，付出 相对较少 而非绝对意义上的最少的认知成本；

• 关注程序结构： 比起在前 AI 时代，你现在可能更需要关注程序的整体结构，作为总设计师去设计整个程序，将正确的结构和约束内化到 AGENTS.md 中；

• 更精准的提示词： 在理解已有程序的基础上，编写更精准的提示词来引导 AI 完成工作，而不是任其发挥，让 AI 主导一切；

• 审查代码： 即便使用同一种框架，在遇到棘手问题时，一位熟读框架文档的人也会比另一位愣头青更有效率，如果把 AI 编写的代码归为框架，那么你应该去审查这份代码，从而在不可避免的“抽象泄露”发生时，将其危害降到最低。

毋庸置疑，AI 编程是一项革命性的进步，它的出现，让我们可以站在一个之前只存在于想象中的思维高度来编写程序，但 AI 编程毕竟不是魔法，如同历史上任何一个框架，极度便利的背后隐藏着抽象泄露、控制权丧失及认知债务等多重风险。

所以，AI 编程仍然不是银弹，它无法将我们从认知成本中真正解放出来。然而，在真正的银弹出现前，认识到 AI 编程作为一种新型“框架”的局限性，并适当使用“库”的心智模型来驾驭它，或许是我们的最佳选择。

引用链接

[1] Django REST Framework: https://www.django-rest-framework.org/

[2] 数据模型和视图类: https://www.django-rest-framework.org/api-guide/viewsets/#modelviewset

[3] 抽象都会泄露: https://en.wikipedia.org/wiki/Leaky_abstraction

作者简介：

朱雷（@piglei），程序员，爱好编程、阅读以及电子游戏，著有《Python 工匠：案例、技巧与工程实践》一书。

本文为作者投稿，观点仅供参考，欢迎基于事实的不同观点与讨论。