现如今，AI 编程的门槛似乎越来越低。Vibe Coding 这样的名词诞生之后，给人描绘了一种美好的场景：你只需要随便说一句话，一个漂亮的界面、一个精美的产品功能就瞬间出现了。于是你满怀期待地投身实践，尝试 Vibe Coding，完全让 AI 写代码。

然而，理想很丰满，现实很骨感。在一开始，对于一个从零开始的小项目，对于简单的小功能，AI 确实能给出完满的答卷。但是随着项目继续推进，这种美好的体验正在逐渐消失。你会发现，AI 开始频频出现理解偏差，写出来的代码越来越容易出错，调试的时间也越来越长。

为什么会这样？难道 AI 编程注定只能用来写一个小玩具？难道它注定写不出可维护的有用代码？

如果你也曾被这样的问题所困扰，本文会为你解开心中的疑虑。AI 编程的这种问题，其实是由于大模型的内在特点所决定的。本文将介绍一种行之有效的方法来保证 AI 生成代码的可维护性。

AI 编程可维护性问题的本质

AI 编程的这种「开头顺利、后续困难」的问题，其实是软件工程中的一个经典问题：可维护性。按照定义，可维护性是指代码在后期开发和维护过程中，能够轻松修改、扩展和修复的特性。

在 AI 出现之前，软件的可维护性就是一个经常被人讨论的话题。不可维护的代码，往往是因为代码结构混乱、逻辑复杂难懂，导致后续想添加新的功能变得无比的困难。

项目的规模越大，功能越复杂，保持可维护性就越难。这就像搭积木游戏。你想把积木搭得越高，那么下面的积木就需要越稳定。地基不牢，搭到 10 层的时候还可以勉强维持，搭到 30 层的时候可能就直接塌了。

项目维护就像搭积木游戏

项目维护就像搭积木游戏

AI 编程更是放大了项目可维护性的问题。如果你项目的代码大部分都是用 AI 来写的，你会发现积木倒塌的速度非常之快。你让它搭 10 层的积木，它的目标就是搭出 10 层不会倒的积木，至于继续搭到 11 层的时候会不会倒，who cares。

这便是 AI 的思维盲区：它只会用最直接的方式完成任务。

AI 就像一个没有责任心的实习生，眼中只有任务目标，可维护性之类的问题并不在考虑范围之内。（这也意味着，永远不要直接用人话跟 AI 沟通，关于这一点的展开说明可以看：为什么 AI 编程效果不好？因为你把 AI 当成人来沟通了）

AI 的这种逆天特性，注定了代码可维护性是一个难题。那么，我们该如何约束 AI，让它写出稳定、可扩展的代码呢？

快捷方法：为 AI 制定编程规范

这是我推荐的基础版方法，如果你希望快速让 AI 写出代码的可维护性上一个台阶，这是最快捷和简便的方案。

它的思路很简单：既然 AI 只会遵循明确给出的指令，那我们就把编程规范和可维护性流程直接写在指令里就可以了。

你在各种论坛、社交媒体上看到的技巧和 trick，其实大部分都是这类思路。它的本质是把一些人工总结好的项目规范写成 Prompt，让 AI 遵循。例如：

在 Cursor 流行的时候，有一个著名的「RIPER-5 模式」，可以让 Cursor 能够应对复杂的项目。RIPER-5 模式定义了 5 种编程中的模式：调研（Research）、创新（Innovate）、计划（Plan）、执行（Execute）、评审（Review），同时规定了 5 种模式的行为规范和切换规则，这让 Cursor 的行为能够做到严格的有迹可循。

在 Claude Code 流行的时候，有人把 Linux 之父做成 Prompt。这是一份带有「角色定义」「核心哲学」「沟通原则」的 CLAUDE.md 文件，让 Claude Code 拥有了 Linus Torvalds 风格的结构化思维。关于这个 Prompt 的讲解可以看我写的前一篇文章：为什么把 Linux 之父塞进 Claude Code 可以这么管用？讲讲 AI 编程的底层逻辑

Kiro 这个新出的 AI 编程工具甚至内置了一套软件开发流程，包括需求文档、编码、测试验证。这样的流程约束了 AI 的行为，避免了 AI 随意发挥带来的不确定性。（如果你对 Kiro 的原理感兴趣，欢迎留言，我会考虑更新一篇 Kiro 的流程拆解）

因此，如果想要快速提升 AI 编程的可维护性，直接套用这些现成的编程规范是一种最快捷的方式。

进阶方法：让 AI 深度思考关键决策

直接使用现成的编程规范，大约可以把 AI 编程的可维护性从 20 分提升到 40 分，但是想继续提升就变得困难了。

这是因为，这些编程规范虽然可以指导 AI 遵循通用的行为标准，但是无法解决你项目中的一些具体问题。这是网上那些宣传「万能 Prompt」不会告诉你的地方。

让我们考虑这样的场景：

你的项目需要实现一个关键的功能，这个功能可以在方案 A（实现简单，结构清晰）和方案 B（架构复杂，易于扩展）之间进行选择。这是很多项目中的常见选择，对于后续的可维护性影响重大。

你可能会问，对于这种情况，我直接在指令里给出「请选择最合适的方案」不就可以了吗？

非也。你可能以为，AI 会像人类程序员一样，在面对「方案 A 还是方案 B」的问题时，会首先调研这两种方案的优劣，然后结合项目情况进行选择。

然而现实是，AI 依然只会用最直接的方式完成任务。这个「直接」体现在，即使你的指令里缺少一些重要的背景信息，使它无法判断方案 A 还是 B 更好，它也不会停下来询问你，而是会根据自己掌握的上下文猜出一个最合适的方案。

这便是 AI 的行为模式：它不会承认「我不会」，而是会尽可能给出一个正确概率最高的答案，即使这个答案已经错到离谱。

这便是很多项目可维护性的瓶颈所在：很多时候，AI 并不能选择真正合适的方案。对于这种情况，我想给你推荐一种进阶方法，让 AI 能够真正对方案做仔细的思考。

这里我给出一个我最近常用的流程，在一些复杂的决策中行之有效：

  1. 说明我的需求，让 AI 先拟定一份计划，写到文档里

  2. 清空上下文（新开一个对话），讨论和评审上一步生成的计划，重点关注：这个计划是否适合当前项目的背景与阶段

  3. 如果计划没问题，则继续实现；否则，废弃或者修订原先的计划，从头开始

为了规避 AI 的思维盲区，我会先把 AI 的计划保存下来，然后强制要求它审视自己的计划，让它有机会给出「我不会」或者「我缺少一些关键信息」的回答。

这个流程里的重点在于：在评审计划的时候，一定需要新开一个计划，清空上下文。如果继续在原来的对话中讨论，AI 会受到历史信息的影响，大概率会认为原先的计划非常合理，而非反思自己的计划。

这其实是 AI Agent 中「上下文冲突」的一个经典的例子。AI 拟定计划的过程，你在同一个对话（上下文）中指出计划有问题，让它进行反思，那么「计划很对」和「计划有问题」的信息就同时存在于上下文中，AI 的思路就会混乱，产出结果的质量也会下降。如果你对这方面的原理感兴趣，请告诉我，后续会写文章来介绍。

对于项目中一些比较基础的、关键的功能，你可以使用这个方法，让 AI 深度思考关键决策，让项目的可维护性再上一个台阶。

这里给出一个具体的 Prompt，供你参考：

计划评审的 Prompt

计划评审的 Prompt

Prompt 原文链接：https://github.com/nettee/ai-collection/blob/master/content/prompts/plan-review.md

总结

相信看到这里，你也已经明白了为什么 AI 编程常常陷入「开局惊艳，后续维艰」的困境，问题的重点在于项目可维护性的缺失。AI 如同一个目标驱动但缺乏远见的实习生，只会用最直接的方式完成任务，而不会主动考虑代码未来的扩展性和稳定性。

要解决这个问题，你有两种方法可以选择：

  • 快捷方法：为 AI 指定明确的编程规范，这能快速约束 AI 的行为，将代码质量提升到基本可用。

  • 进阶方法：通过清空上下文让 AI 对自己制定的计划进行深度反思，这能针对项目做出更合适的计划和决策，长效提升项目可维护性。

这也告诉我们，AI 编程绝非简单的 Vibe Coding。它需要我们不断在关键的环节进行把关。持续约束 AI 的行为，让 AI 不仅仅是写出将将能用的代码，而是一个可以持续演进的项目。

希望本文能帮助你更好地驾驭 AI 编程，既能走得快，也能走得远，完成更稳定、质量更好的 AI 编程项目。

我是 nettee，致力于拆解 AI 编程的底层逻辑，帮助你在 AI 时代减少焦虑，掌握不变的原理。如果你喜欢我的文章，欢迎点赞、转发、关注，让我们在 AI 的新时代里携手同行。