Published on 2025-09-04

AI辅助编程中的声明式误区与改进思路

从风格上来区分，编程可以分为命令式编程和声明式编程，顾名思义，前者明确每一步，而后者只关心最终的结果。用行业上常见的类比来阐述似乎更直观：命令式编程就好像拿着菜谱，一步一步的做菜；声明式编程就是打电话点那道菜作为外卖。

这概念并不新鲜，而在AI交织进入我们生活，特别是编程场景中，从命令式编程和声明式编程区分的维度上，是否可以让AI辅助编程更加有的放矢呢？

直观的看，AI辅助编程更贴近于只关注结果，不关注细节的声明式编程。但具体实施过程中，声明式编程在AI辅助过程中，相对于事必躬亲的命令式编程，更容易出现问题。下面是我经常碰到的一些问题：

• 代码可维护性不佳：即使满足当前需求，在迭代时成本极大，例如大量潜在风险，需要瞻前顾后；
• 代码间耦合严重：修改一点内容，却牵一发而动全身；
• 出现了性能问题：不知道瓶颈在哪里，无从定位。 ...

看起来契合AI编程的声明式编程风格，哪里出了问题呢？管中窥豹大语言模型的运作原理，我们不难发现，这个超级”成语接龙“中，越是多约束，越是符合预期。而不符合预期的范畴内，存在着约束少而导致的预期不足，和缺乏知识边界带来的幻觉。我姑且将他们分为两类。于是，顺理成章的改进方法是增加约束和增加知识（某种意义上的上下文）。

但是如果约束多，比如添加技术细节、实现路径、分解为多个小任务等等，那么AI辅助是否多此一举，人们已经做了足够多的事情了，似乎直接基于经验操作不就可以了，毕竟AI是希望提升效率的，而不是降低效率的。

这样的情况，困扰了我良久。

直到最近我在尝试swiftUI开发时，我发现之前我所谓的声明式开发是存在重大误区的。声明式开发，不是对需求进行文字描述这样肤浅了事的，也不是描述好所谓的story就可以交付给AI自由发挥的。声明式开发（起码我现在认为的）是需要对产品需求进行技术化描述，至少做到类型严格定义的开发模式。

比如在一个solidjs项目中，需要的是按钮点击后，将表单数据提交到数据库，快速的用Optimistic UI进行渲染（在写入数据库完成前完成渲染），而当数据写入不顺利时，页面进行弹窗提示。在不描述技术细节时，AI的返回大概率会有问题。 然而，若是将声明进一步技术化描述，比如：点击form中的按钮，通过触发form的submit，执行form的action（具体的action名称），然后利用action的useSubmission.input属性值，对页面进行渲染。同时，监听useSubmission.result，若存在错误返回，返回solid-ui的dialog弹窗。这样我想效果会好很多。

问题接踵而至，如果我不了解solidjs，如何能够对声明式编程进行技术描述呢？

AI辅助人类为主的方案设计与技术选品，快速的让人学会某个技能，或者说，查询到某个技能的说明，这是AI辅助编程中一个重要而容易被忽略的作用。AI在现阶段是个工具，类似于字典、百科全书的工具。