想象你来自非专业领域，通过 Vibe Coding 开发了一款软件并享受到了乐趣，于是想要继续钻研和深入。但是后面你在软件开发过程中感到越来越糟糕，当软件上线被使用之后暴露出来的问题就更多了。那么为什么会出现这样的情况呢？

这个问题看起来像是开发技巧造成的，但实际是由于软件失控造成的。根本原因是我们在开发过程中太过于追求一味的增长，而忽视了软件工程基础本身。

一、什么叫软件工程基础，以及为什么我们需要？

很多人第一次用 AI Vibe Coding出一个能跑的小软件时，都会觉得已经万事大吉，软件可以直接发布上线了，其实不是，真正困难的部分，往往不是“写出来”，而是“写出来之后还能不能一直用”。这就是软件工程最基本的地方：它关心的不是某一段代码写得漂不漂亮，而是整个东西能不能稳定地存活。要理解这一点，可以先从最基础的地方看起。

1.1 先让它能跑，再让它跑得稳

一个软件刚做出来时，大家期望他们都会像预期一样工作良好，然而事实情况是，越是优秀和高价值的软件，越可能在现实世界里遇到更多的问题。因此软件暴露出问题是非常正常的，软件工程作为系统工程学科，最基础的思路，不是追求一次写对，而是接受一个现实：软件不是写完就结束了，软件是要在各种意外里继续工作。

这也是为什么“能跑”只是第一步。真正重要的是：出错了会不会崩，改了会不会坏，别人接手还能不能看懂。但仅仅理解“能跑”还不够，问题会在后面逐渐出现。

1.2 测试不是多余步骤

很多人会觉得测试很麻烦。明明代码已经跑通了，为什么还要再多一套检查？因为现在看着“没问题”，不代表它以后真的没问题。没有测试覆盖的软件本身是脆弱的，今天你改了一个按钮，可能另一个页面就坏了；你修了一个 bug，可能顺手把以前正常的地方碰坏了。没有测试，你不能保证软件之前的功能没有被改坏。而有了测试，可以完全自动化的验证软件之前的功能是否还是正常的。

另外，软件测试的另一个重要作用，就是提前预防边界情况和糟糕问题的出现。前文提到，想要做出优秀的软件，总是会在现实里遇到许多的问题，而测试可以帮助我们提前模拟一下极端情况。除了稳定性问题，还有一个更容易被忽视的维度。

1.3 安全不是大公司才需要，小工具也一样要注意

很多人会以为“安全”是做银行系统、支付系统才要考虑的事。其实不是。只要你的软件会接收用户输入、会联网、会保存数据，就会有安全问题。比如用户乱输内容会不会出错，别人能不能随便看到不该看到的数据，上传的文件会不会带来风险。这些问题在小项目里看起来不显眼，但一旦上线，就可能变成真正的麻烦。用户隐私非常重要，大家都不希望下载一个软件然后自己的手机号码在各个二手市场上流通。还有一件事，它不会影响运行，但会影响你是否还“看得懂”。

1.4 文档是最优秀的软件开发工具

很多科班出身的程序员和工程师非常反感写文档这个事情，而该倾向在AI时代实际表现为特别坏的习惯。原因很简单，文档是保持信息实时、正确等关键因素的最小成本单位，尤其在当今时代，编写文档的工作全部交给AI完成，人类只需要做审查和同步即可。

软件开发里最常见的一件事，不是“不会写”，而是“过两周自己都忘了当初为什么这么写”。想象你今天加了个新功能，过两天忘了这个新功能是干嘛的，涉及到哪些具体的模块，改了会有什么影响，以后如果要重构需要从哪里开始着手。

如果没有文档，这些信息就只能留在人类的大脑记忆里。而文档如果存在，就可以作为事实源，更重要的是给Agent工作时进行参考，让Agent快速熟悉项目背景，让开发效率大幅提升。

不仅如此，文档还是在给“协作”铺路。在开发复杂软件，需要大家一起努力的时候，人们可以通过简明扼要的文档信息同步，对齐当前对项目的进展，心里有同样的预期，手里有同一杆秤。之后的分工协作会变得更加高效，各自的工作完成之后，大家可以再次通过文档来分享产出并对齐进展，这是一个非常高效的产出循环。

文档就是AI时代最优秀的工具！想象你是初创公司的CEO，想要验收今天AI员工的产出，你可以让Agent产出一份仅数百字的文档来告诉你今天完成了什么，而这基本相当于过去人类工程师数十天的产出，更重要的是，哪怕你完全不懂技术，你也可以让Agent把行业话语翻译成你能听懂的话，仅仅数百字就可以了解清楚进展，组织层级等因素带来的信息壁垒被大大的削减。

在AI时代，这些就是软件工程的基础，他们代表着软件开发过程中基本的准则，例如可维护性，健壮性，安全性，高内聚与低耦合等等。 正是这些内容，决定了开发出的软件质量高低。当这些基础被忽略时，在AI环境下会被进一步放大。

二、AI 越聪明，为什么可能更糟

你可能会想，我就开发一个小项目，搞得那么麻烦干什么，而且现在AI那么聪明。确实是这样，而且现在大家也发现模型能力越强，做软件也更加可靠，比如Opus4.8等。什么叫做可靠，其实就是软件开发的过程中，模型会对已知的信息更加敏感，比如有个地方的关键逻辑，在某个功能的实现之后会自动验证，保证没有把它改坏掉，而非顶尖模型可能就没有表现出来这个迹象。当然这是以牺牲了部分开发速度为前提的，而速度和质量不能总是平衡，能够根据项目的复杂程度和现状判断是最好的。除此之外，更重要的是，如果项目超过了个人能够控制的程度，变成了需要多人协作开发的复杂度，或者真正上限要大规模扩展等情况时，这时候最聪明的AI也无法保证开发的软件是可靠的，因为AI也不能同时考虑到所有事情，注意力是有限的，该问题会在注重开发效率而忽视代码质量，不重视和遵循软件工程基础时变得尤为严重，不可遏制地带来灾难。这时候问题就不只是理论上的，而是会直接影响你如何继续开发。

三、如果你还想继续用 AI 做软件，你需要遵守的几个简单规则

3.1 先接受一个现实：不要一次做太多变化

不要这样用 AI：“帮我优化一下这里，再顺便加个功能”。因为你会失去判断：哪一步导致问题，哪一步引入了bug。正确方式是：每次只让 AI 做一件事。

3.2 改完必须验证“最重要的功能还在”

不是做测试体系，而是：改完之后，至少手动确认核心流程还能用。比如：登录还能不能用，核心功能有没有坏，数据有没有异常。重点不是“全面测试”，而是防止最基础的东西被悄悄破坏。除了修改方式，还有一个更容易忽略的问题。

3.3 不要默认 AI 是对的，要让它解释

不要直接说：“帮我改一下”，要加一句：“改之前先说会影响哪些地方”。因为 AI 很容易：局部正确，全局破坏。

3.4 不要靠记忆，要留一句话说明

不需要文档体系，只需要：每个功能写一句话：它是干什么的。比如：这个是用来保存用户数据的，这个是处理登录逻辑的。目的只有一个：以后你自己还能看懂。

3.5 保留一个“可以回去的版本”

不需要复杂 Git 教学，只需要一个概念：每隔一段时间保存一个“确定能用的版本”，因为：一旦软件坏了，你需要能退回去，而不是继续修。把这些规则放在一起，其实指向的是同一个核心问题。

3.6 小结：你真正需要的不是技巧，而是一种“别乱掉的方法”

如果把上面这些事总结成一句话，就是：不要一次改太多，要能验证结果，要能看得懂，要能退回去。这四件事看起来都很简单，但它们解决的是同一个问题：让你不会越做越不敢动。但这些方法只是表面，更深层的问题在于系统本身的变化方式。

四、你做的不是软件，是一个会变化的系统

你不会突然意识到这一点，而是某一天才发现自己已经开始这样使用它。很多人刚开始用 AI 做软件的时候，会有一个错觉：只要功能能跑，就已经完成了。但现实是：软件从来不是“做出来”的，而是“在变化中活着的”。你每一次修改，都不是在“优化它”，而是在重新定义它。一开始你以为你在控制它，后来你会发现你只是在跟着它的变化走。AI 并没有改变这一点，它只是让这个过程变得更快、更明显。当你还能清楚说出它是怎么工作的，它就还是一个软件。当你已经说不清它是怎么工作的，它就变成了一个“你不敢动的东西”。 这就是界限。