大模型+AIIDE在软件开发中越来越广泛，甚至很多团队cursor、copilot等都成为了标配。
在编程领域的深入应用大模型的程序员就像冷兵器时代使用弓箭的士兵换装了热兵器时代的火枪。
不过虽然火枪使用化学能替代了弓箭的肌肉能，产生的威力更加强大，但是同样会带来新的挑战。
比如火枪中的滑膛枪没有膛线，所以单个枪支射出的子弹根本就没有准头，但是多枝滑膛枪排列成枪阵，形成一道弹幕，只要在射程和左右射界之内，击中就成为必然。
新的武器，必须配合新的战法，否则只能是刻舟求剑。
大模型编程带来的新挑战主要来自于五个方面：一、两极分化简单功能更简单、复杂的功能更复杂。大模型基础编程能力非常强，甚至可以说资深程序员的多年积累的基础编程能力都会被平权掉，一个新员工在大模型的协助下，在基础功能开发上很可能超越很多不使用大模型的老员工。 但是，对于强私域复杂场景，大模型由于没有多年私域知识的全面侵浸和深刻认知，很可能无法把握场景的本质复杂度，从而把功能实现的更复杂。软件开发的成本主要由以下构成：其中本质复杂度对应了其中的内在成本，额外带来的冗余实现带来额外的维护成本属于偶发成本，长久以往，随着偶发成本逐步增加，系统维护的难度将会急剧加大。
二、少与多
照猫画虎和画蛇添足
大模型写文档有个特点，就是面面俱到，结构化很强，但是往往缺乏重点，不够深入，让人一眼就能看出大模型味道十足。
大模型写代码时也会有同样的问题，往往要点没有实现，或者是仅仅通用实现，私域能力却没有注入；
而不需要改动的地方往往会不经意改动某个函数或变量，而且还会生成一大堆的额外的readme等使用文档等。
三、代码读写比
很多资深程序员都有体会，读复杂代码是一件挺难得事情，读别人的复杂代码是一件很残忍的事情，甚至读自己很久以前写的复杂代码也会觉得挺困难。
读复杂代码一般会碰到三高两难：
先看三高：
1、记忆成本高
必须记住沿途大量的数据结构、函数、数据值，才能还原代码片段的上下文。2、搜索成本高必须及时搜索关联和波及的数据和算法，弄清楚这些数据和算法的用途，并搜索这些数据的来龙去脉，才能继续读下面的代码。3、推断成本高必须根据代码片段和上下文、波及数据反向猜测代码意图、用途，非常像破案的过程，罪犯实施犯罪的时候，可能不经意留下蛛丝马迹，但根据已有现场反向推断蛛丝马迹怎么来的，那可是要在n多可能中做遍历和求证，非常耗脑细胞。再看看两难：1、区别代码中主流程和附加流程难自己写代码的过程，都是先实现主流程，跑过TDD用例并调试通过后，然后再逐步添加附加流程，每个流程都区分的很清楚，自己也很容易理解和hold住。 但是给你一段别人的糅合了主流程及n个附加流程的复杂程序，让你理清其中的来龙去脉，那可是抽丝剥茧，找到一个线头就要逐步梳理，那可是要苦不堪言的过程。2、区别正常流程和异常流程难同理，要区分正常流程和异常流程也会碰到和主流程揉合n多附加流程通同样的困境。
四、不一致性
软件开发本质复杂度之一是不一致性问题，即开发人员脑海中装着不同的片段知识进行作坊式手工协同，从而在需求理解、设计认知、代码约束、测试方向等等各个方面不统一或者貌合神离，进而造成功能、性能、易用性上各种不一致，从而造成系统重大隐患和难以维护。人使用大模型编程，不一致性同样存在，主要体现在人和大模型之间的不一致性，不同大模型甚至大模型不同时刻生成代码的不一致性也通常会存在，这些都需要通过一种合适的手段去化解。否者，这些新的不一致性很快碎片化你的架构蓝图，让你的架构变得支离破碎，从而使得整个系统变得无法理解。
五、饮鸩止渴
以上种种情况如果代码不加思索就接受并合入代码库，久而久之，很容易造成代码架构的腐化，继而造成代码维护成本越来越高，可理解性也会越来越差，即使用大模型新增功能也会越来越难。根据以上分析，我们把大模型生成的代码按人能不能读懂和测试对不对分成四个象限，在不同象限代码的危险程度是不同的。对于大模型生成代码来说，I象限表示既能看得懂，测试后也对，这种代码是可以直接采纳并合入分支的。II象限表示看得懂，但是测试发现不对，这种情况可以引导大模型不停纠偏，逐步向I象限演进。II象限表示看不懂测起来也不对，这种情况代码直接丢弃就可以，想办法重新组织提示词让大模型再生成。IV象限属于测试结果对，但是代码看不懂，这种情况代码要不要接受并合入呢？其实在复杂场景下，测试一下对不一定代表代码实现的对，因为复杂场景的会有n多状态组合，所谓测试一下对很可能就是挑了一个正常场景，或者少数人还会挑一个碰巧想到的异常场景测试下，某些极端场景的状态你不一定想得到，更不会去测试了，比如类似无锁队列这种代码，极端场景很容易出现状态死锁，而且一旦采纳并上线，如果线上出了这类问题，很难复现和定位，往往就会束手无策。所以IV象限的大模型生成的代码是非常危险，一旦不慎采纳，很可能给系统引入巨大隐患。另外这种代码也会给功能带来加速腐化，一旦这种不能理解的代码被新功能包裹并叠加起来，那就会造成这部分代码的快速严重腐化，从而极大程度降低系统可维护性，造成人看不懂，大模型也看不懂的代码，后续一旦出现人员变动，这块功能的业务可连续性立即回受到极大的挑战。接下来，问题的核心编程如何轻量级看懂大模型的实现，又能快速确认功能正确，快速针对性纠偏是你用好大模型是你的核心竞争力。使用大模型大家一定要有清醒的认证，你能够控制的事物才能为你所用，否则，你一定会遭到他的反噬。大模型也一样，大家如果现在用大模型生成代码又快又爽，但是如果你不能快速理解大模型生成的代码，并能够规范和纠偏大模型的输出，那你很快就会陷入代码腐化、无法维护的焦油坑。出来混，总是要还的。针对上述大模型编程的问题，我们的《超级工程师战训营》超级工程师（一人团队）实践的方法论：人机协同契约给出了答案，告诉大家如何控制大模型，如何形成线性阵列枪阵，带领大家更好地跨越高效使用大模型的鸿沟，从而高速驾驭大模型成为超级工程师，为自己的软件职业生涯更上一层楼。超级工程师战训营已经开了多期，学员反馈挺不错，期待更多人加入。部分学员反馈：
声明：来自丁辉的软件架构说，仅代表创作者观点。链接：https://eyangzhen.com/2571.html
