大模型能编程，软件规划设计更重要了

曾经，在一些公司，会编程的人很牛，因为别人不会，他会；出了错，也只有他能解决。他离职了，软件可能就瘫了，后面的人很难接手。后来，大公司逐渐完善了编程的流程，前要有需求文档，后要有设计文档、测试文档，且对编程过程提出了要求，这时，具体编程的人的重要程度降低了。

现在，大模型编程成为了一个推广的噱头，也确实有不少人，用大模型编出了能用的小程序，然后，有人预测，程序员将是大模型最先淘汰的行业。

其实，在大型软件的研发过程中，“编程”环节占比很低，甚至程序员自己的时间也有很大一部分用在“编程”之外，如用于软件功能定义和测试。

大模型会推进软件开发过程中的“中间件”、“零部件”标准化，将降低编程的强度，但用大模型开发软件并不现实，因为软件开发关键的是编程前的需求调研、产品规划、需求流程设计，短期内，这都很难被大模型替代。原因是，其中有一个重要的“需求转换”环节。提出需求的大都是软件外行，很难提出严谨的需求，程序员又不懂行业，这就需要专业的“软件规划设计”人员对来自外行的需求进行分析、转化。

例如，近日热议的“男子建行金卡莫名其妙被限额，客户经理也没办法，建议男子别用建行做主卡”，听起来可笑吗？看看网友投诉后，从客户经理那得到的反馈（部分）：

加强监管、利用大数据建模，没错吧？从上面内容看，很明显，需求方根据主管部门的指令提出了要求，没有经过详细的需求分析，就启动了项目，然后程序员实现了这个要求，就出现了上面的结果。

问题出在哪呢？大数据建模，实际是一个根据数据抽样总结结果判断个案的过程，这就需要处理好两个误差之间的关系。α误差指把合规的判定为不合规，β误差指把不合规的判定为合规。通常需求方希望β误差无限接近于零，但这意味着，会把大量的合规的也判定为不合规（α误差增加），尤其是政府背景的需求方。这使得企业在压力下不得不允许α误差增加，表现结果就是，给正常行为增加了复杂性，给合规用户增加了不合理的影响。

除银行外，一些地方的电信运营商也因放大监管部门的要求，造成正常使用的用户停机或部分功能被限制。

再例如，有网友发现，从邯郸到唐山有很多趟直达列车，大多没票，但如果你选中转，12306会建议你从邯郸到辽宁的葫芦岛、沈阳，甚至吉林的长春中转，这些车次经过唐山且在唐山停靠。

荒唐不？程序员接到了APP中实现中转联售的要求以及其他一些要求，没有经过详细的调研、设计，就开始编程。但这明显包含了流程设计的BUG。即使选了中转，也应该是直达优先。中转站应该位于起点和终点之间，至少是“起点-中转站”或“中转站-终点”两段都不能超过“起点-终点”距离的120%。直达无票，同日同车次同方向越过终点后有票，这一现象或反映了在分段放票设计细节上同样有考虑不足之处。

我们生活在一个复杂的社会，面临的“规则”之间都经常出现冲突。程序或APP或软件，要重写业务流程，有复制、有优化，甚至会再造，编程工作在不久的将来，可由大模型或其他工具辅助完成，但编程前的“软件规划设计”变得更重要了。