如果说氛围是过家家，那工程化就是开公司
为什么VibeCoding不能解决复杂问题？
VibeCoding，也就是氛围编程，在当前互联网环境下指将项目开发完全交给AI，不手动编写代码，只向AI提出需求，然后由AI完成项目代码的编写。
这种方法可以做出来一些小的作品，比如一个可以在网页运行的贪吃蛇游戏，一个简单的TODO List应用，一个静态的个人网站。但是一旦涉及到数据库、API接口、后台逻辑等依赖较多的项目，VibeCoding就只能做出一个风味应用：只能看，不能用，或者只有部分能用。用过后发现了问题，继续交给AI修改，过了几轮后，Token烧了不少，问题仍然没有得到很好的解决，经常是按下葫芦浮起瓢，这个bug刚解决，之前的一个bug又不知道从哪里冒了出来，然后就陷入了无尽的bug循环中……
纵观自2022年末GPT-3.5发布后的3年半里，从网页对话，到MCP接入各个AI网页端，到Agent概念的浮现，再到Skill、CLI的大火，最后到了现在以Claude Code、Codex为代表的harness工程化解决方案，可以发现，AI的能力想要更好的发挥，必须要辅以各种工程化、流程化的解决方案，才能解决实际存在的问题。而VibeCoding是期待一句话能够解决所有的问题，但现实世界中的问题有简单有复杂，简单的问题可以由个体独立解决，但复杂的问题一定是需要有组织的解决。所以说VibeCoding只能解决一些简单的问题，更复杂的问题，需要用工程化、系统化的思维来解决。
AICoding Engineering与中大型软件工程
中大型软件工程往往涉及到很多功能，比如：账号模块、数据库模块、权限模块、前端页面、测试模块、业务逻辑模块等等。这些模块之间需要相互调用，也就是软件工程中常说的依赖。
打个比方，水龙头想要出水，得有管道和高于水龙头的水源，想要干净的水还得有自来水厂承担净水的工作，想要更大的水压就要水泵来为更高的水源灌水。而作为用户能看到的就是拧开水龙头，水从水龙头流出，最多看到水龙头后面的那一节管道。但是水在从水龙头流出之前发生了什么，作为用户的我们是看不到的。
那AI能看到吧？当然可以，而且对AI来说，它的训练资料比大多数职业程序员脑中的经验要多的多，但目前的AI有一个短板：一次能看到并记住的有限，专业一点就是上下文有限。目前AI的上下文长度最长是1M，大约是 75万 个英文单词，40万 - 60万个汉字。一个中型的软件工程项目大约在10万行代码，Token数在40万左右，也就是说，1M的上下文可以装2.5个中型项目。看起来似乎问题已经得到解决，但问题是，如果项目把上下文装满了，后面的沟通呢？要新加功能怎么办？而且大模型的注意力是有限的，1M的上下文一次只能选有限的部分关注。 但AI出现之前，人类程序员也完成了很多大型的软件工程，比如微信、淘宝、QQ等。而人类是不可能一次将一个工程所有的代码都记住的，甚至上周写的代码都记不住。那这么大的软件工程项目是怎么完成的呢？肯定是很多人协作完成的，但是维护开源项目的人形形色色，很多人互相之间不认为，也根本分不清这个代码到底是谁在什么时候出于什么目的开发的，那后续的迭代应该如何进行呢？这就不得不提到开源界的标杆：Github。
Github的项目管理机制
Github是一个依托于Git的代码托管平台，很多大型的软件工程就是依托这个平台来完成迭代的。其迭代逻辑可以简单概括为：创建Issue——>创建开发分支——>提交Pull Request（PR）——>合并合并到主分支。在提交PR到合并主分支之前，还会有三道闸门：自动化测试（CI），代码审查（Code Review），冲突处理。
对于本地项目的开发，在完成MVP的产品开发后，需要不断进行Debug，后续有新增功能也要在源代码的基础上继续开发，这时建立一个可以人机共读的Issue机制就很重要。
有了Issue机制，就可以对出现的问题/bug进行系统化的管理：哪些bug很紧急，不修复就没法用？哪些功能很重要，需要尽快上线？哪些bug可以忽略，不影响使用？同时，建立一个Issue机制，可以在交给AI处理bug之前，让AI帮忙看一下这个bug是由哪些部分引起的，在这个过程中，AI可以将这个问题描绘的更详细，也方便了后续的Debug环节。这就建立了一个基本的循环。