关于AI编程的一些思考: 哪些东西最好是手写？

这些年AI编程工具层出不穷，从最早的copilot 到 curror，再到claude code，还有所谓的氛围编程。各种产品百花齐放，各种奇怪的路数都有人去探索。

然后每天公众号里推的各种相关咨询，里面透露出对AI编程的态度就是在两种极端反复横跳。要么就是说自己用了某某AI产品之后有多神，要么就是吐槽AI经常把自己的代码搞乱，AI不行。可能在这样的网络环境里，只有足够咋咋唬唬的文章才有流量吧。

我想每一个真正每天都在使用AI闷声工作的人，应该都很清楚，目前的AI绝非万能，但也确实能极大的提高编程效率。如何能够更好地使用AI工具，关键在于摸清楚模型的能力边界。换句话说就是整明白哪些代码能放心交给你面前的这个AI，哪些代码只能自己手写。

这里我想简单总结一下我这两年与AI合作的编程经验。关于哪些代码能交给AI，我觉得现在AI能做的事很多，只要prompt写得足够好 AI 的潜力可以很大，这方面网上很多人都在分享各自的经验，我也有些体会，但目前还没整理好，以后有机会再分享。现在，我想谈谈另一方面，也就哪些事哪些代码一定得自己做自己写。

首先，就是数据结构，一定得自己设计编写。我这里所说的数据结构是个抽象概念，不同领域有不同的指代。如果是在一般业务后端开发中，指的是数据库的结构设计，在前端开发中则指的是业务组件的核心状态数据结构。

经过多年的开发工作，无论前端后端，我发现一个系统的核心数据结构会直接决定代码逻辑的复杂度，进而决定开发难度和隐含的bug量，再进一步决定你接下来几个月是不是得996。

这个道理其实很简单，做后端开发的同学可以试着想想，在一个老系统里动一下数据库表的关联结构，得重写多少代码。对于喜欢直接拿后端api返回数据作为业务组件状态的前端同学，可以观察一下当后端同学随意改api返回的数据结构时，自己的血压状况。对状态管理有经验的前端同学可以思考一下Redux为什么要那样设计。

所以啊，数据结构，兹事体大，开发工作开展前期设计好，后面少改动，能省很多事。

而之所以这事情不应该交给AI来做，除了改不好代价大以外，还有两方面原因。首先是数据结构怎样设计才算是“好”，其实很难与AI勾兑清楚的，这太过于抽象难以表达。另一方面是我发现阶段的AI还是比较短视的，你让它开发一个功能，它就只是以跑通这一个功能为目标输出最直接的代码，你不说它不会考虑更多，而之后，当你再让它完成第二个功能时，它又直管眼前功能的实现，而不管会不会把前一个功能改挂。

所以，设计这样的数据结构，是需要纵观整体的需求，以一种全局视角整合各种信息，平衡利弊，设计出尽可能简单小巧但又足以满足整体需求的结构。

而当你通过自己手写完成整体结构的设计之后，就得到了一个把控项目整体质量的一个重要抓手。接下来再让AI在此基础上补充逻辑代码，即使AI再怎么胡作非为，不良的影响面往往也只局限于单点单面，不太容易扩散到全局。

所以数据结构方面的代码自己手写，成本不高，过程可控，收益巨大。

另一个在工作中，我觉得必须自己手写代码的场景是那种极为复杂且抽象的业务逻辑或算法。

其实理论上，只要你把 prompt 写得足够好，再复杂的逻辑的现在的AI都是有能力把代码写好的。但问题就在于，面对高度复杂的抽象逻辑，写这样的 prompt，其成本很可能远高于直接写代码。

怎样的 prompt 算是完美的？ 我的答案是：信息完备的文本。

当你对 AI 说：“嘿，帮我开发一个电商app”时，其实这个 prompt 中有巨量的隐含信息没有表达出来。我们都知道开发一个电商app是个复杂的系统工程，这背后隐含着无数的细节，大到用什么语言开发，接什么样的支付方式，小到某个页面上一个按钮该怎么摆放。这些细节信息中，既有你不在意的，也有你在意的，只要没说明白，AI 就会自由发挥来补齐这些信息，然后很可能做出不符合预期的选择。当那种你在意却又没说明白隐含信息越多，那么AI做出来的东西不符合你预期的概率也就会指数倍增长。

所以，prompt编写的关键就在于，你能否使用你的母语在 prompt 中把你在意的信息以足够充分、具体、严谨且无歧义地表达出来。即便你无法一次性完成这样的工作，你也不得不在接下来与AI 的反复拉扯中补齐这些信息。可见，写 prompt 其实并没有想象中那么简单。

现在到处都在鼓吹自然语言编程的美好未来，但是不知道有多少人能意识到，自然语言本身是有其局限性的，而这种局限性，在描述复杂抽象逻辑的场景下，更是暴露无疑。

想要感受一下这种局限性非常简单，找本你所知道的任意一个哲学家的原著看看，我推荐笛卡尔的《谈谈方法》，看看他是怎么从“我思故我在”的基础上用类似数学推导的方式来证明上帝的存在。当你看晕的时候（我相信不需要太久）你就能明白，用自然语言描述复杂且抽象的逻辑有多么费劲，光是读就很费劲，写只会更费劲。

而这种自然语言本身的局限性，是人类大脑的计算能力所决定的，人类大脑只能在短时间内通过语言输入和输出简单的信息，多了或者复杂了大脑就处理不过来。

想想上数学课的时候，老师为啥必须一边讲解一边还要在黑白板上不停地列公式？想想计算机算法书上，为什么除了文字描述，还要写伪代码，或是直接上代码？为什么都不是纯文字讲解？为什么即便这样很多人学起来还是费劲？

自然语言太弱了。用自然语言编程的愿景，在很多年前，在历史上某个教师在课堂上第一次使用伪代码讲解算法时，就已经被无意间证明是高成本且低效的。我甚至悲观地认为，这并不会因为AI大模型的持续改良而有所进步，除非人类的大脑也能像AI模型一样进化。

但换一种角度来看，无论是数学公式还是代码，实际上都可以被视为，为弥补自然语言的天然缺陷而被发明出来的扩展插件。当然这种插件还有很多，比如数据图表，思维导图等等等等。

思考进行到这，让我们回到最初的命题：为什么在开发复杂且抽象的业务逻辑或算法的时候，最好是自己手写，而不是交给AI？因为，此时此刻，写代码本身就是最高效的方式。

但是，在这个过程中，利用AI取巧的机会也还是有的。比如，可以在prompt中写伪代码描述核心逻辑，或是直接写完核心逻辑后，让AI补齐其他边边角角的逻辑，然后再给出测试方案。只可惜，我目前在这方面还没有形成稳定的方法论，很多时候也是在撞大运，等整理好了再分享。

嗯，今天就写到这。

此篇文章最早发布于我的微信公众号[独孤玩], 欢迎关注交流.