一段时间都有在用大模型来辅助编程，不过现在很多都叫成vibe coding了，连胡彦斌都在vibe coding了，
现在是个全民皆可做软件开发的时代，包括像之前那个小猫补光灯，有的人的想法是说点子不重要了
我自己想的有点不一样，vibe coding现在是把成熟的开发者和小白或者完全不了解代码的人之间的差距磨平或者说缩小很多了
一旦有点子，很快就可以让大模型来做想法的实现，随着模型能力越来越强，
以前需要一定的开发知识来搞懂怎么建项目环境，构建，打包这些，都变得完全可以由大模型来处理
那么剩下的是什么呢，
一方面我理解还是对于把开发作为工作的软件工程师来说，对项目历史，背景，包袱的理解
这个很大程度也有很多人都在尝试通过SDD等方式来解决，但是目前看下来还是有一定差距，取决于项目背景的复杂度
还有一方面是做的事情是独立的还是需要多方合作，比如有个项目，涉及到四方合作开发，并且是一个流程上的上下游
你只是作为其中一个环节的开发人员，那么这个开发本身可能是问题不大，但是对于上下游的不可控，还是需要人力做比较大的介入和兜底
这里都基于一个是模型已经是比较强的情况下，如果模型是比较弱的
还需要考虑这个基础的上下文能让模型去理解，这里就有个很大的差异点，需要我们把任务，包括它的背景，上下文，项目的结构，代码逻辑都能够
作为prompt和rules等输入给模型，让它能产出质量比较好的交付代码，这个点我理解对使用者本身的要求是比较高的
并且需要进行反复的尝试纠错优化，包括结合模型能力，上下文大小等等
最终就是不同的人能对模型能力的放大或者缩小作用
我前面会用一句话来提出一些需求让大模型去开发
这些其实都是一些类似于todo工具这样网上一大堆代码样例，大模型本身可能已经学到过
但是如果是一些非常复杂包含很多背景知识和条件框架限制的，很重要的就是要把这些表达清楚
有条理，不能再试一句话需求，但也不能赘述太多撑爆上下文
再往深入纠缠下就是人如果能把一个复杂度1000的任务，拆解上12个复杂度100的任务，让模型来完成，然后再结合起来跑通这个复杂度1000的任务
也就是目前很牛的一个状态了，这里想的深入点跟架构师的能力也是类似的，首先要把这个难的任务做分解，那分解的依据就是架构本身
怎么去拆解子模块，子模块本身要完成什么目标，子模块之间要怎么衔接，非常考验人的架构能力
说到最后这都有个隐藏的前提，就是模型还未强大到面对各种复杂的任务都只要一句话就能完成
如果有那么一天，我理解可能大家都要退休了吧