作者认为，当前行业对大模型在软件开发中的作用存在过热和浮躁情绪。他引用图灵奖得主Brooks的“没有银弹”理论，指出仅靠大模型自身技术的发展，无法解决软件开发的根本性困难（Essence），即概念结构上的分析和设计，因为它主要解决的是偶然性困难（Accident），即编程实现。因此，我们不能寄希望于大模型降维打击，而应从软件工程的本质问题出发，探索人机协作的正确路径。
文章摘要：大模型时代的软件智能化开发：我们在哪里？该往何处走？
核心论点
1. 我们在哪里？—— 对现状的冷静观察
点击展开/折叠当前应用的四个现实
积极进展：
- 局部智能化成为常态：代码补全、解释、问答等功能已广泛应用，提升了个体开发者的效率。
严峻挑战与隐患：
- 企业层面增效不明显：编码环节在整个开发流程中占比较低，任务协调和知识缺失等“堵点”问题未被解决。
- 加剧开发者分化：专家型开发者能利用大模型成为“超级程序员”，而普通开发者仅获浅层收益，甚至引入质量隐患。
- 维护类任务支持有限：大模型难以理解复杂遗留系统的上下文和设计知识，在问题定位、影响分析等关键维护任务上能力不足。
- 潜在的质量隐患： 大模型的滥用可能激发人性的“懒”，导致未经推敲的代码进入仓库，或用AI生成低效测试用例刷覆盖率，埋下长期质量炸弹。
2. 为什么会这样？—— 软件工程的三大本质困难
点击展开/折叠大模型难以逾越的鸿沟
作者认为，大模型的能力之所以受限，是因为它难以应对软件工程固有的三大根本性挑战：
- 软件形态的多样性：软件是一个宽泛的频谱。一端是个性化小应用，适合“自然语言编程”；另一端是大规模复杂系统（如操作系统），其复杂性远超当前AI能力范畴。用一种范式讨论所有软件是不合适的。
- 软件的系统复杂性：
- 外部复杂性： 理解代码需要代码之外的背景知识（硬件、人、流程、环境）。
- 内部复杂性： 设计知识淹没在代码中，关注点“混杂”与“散布”。
- 演化复杂性： 系统在长期“适应性生长”中形成独特性，甚至出现“代码的神秘主义”（不敢删无用代码）。
- 软件开发的探索性：软件开发并非简单的“文本到代码”转换。它是一个探索问题空间（与用户共同明确需求）和解空间（通过运行、测试来发现和修复问题）的过程，类似于机器人的“具身智能”，需要与环境和人进行交互探索。
3. 该往何处走？—— 三个有希望的探索方向 (具体行动建议)
点击展开/折叠未来的正确姿势
作者提出了三个具体的、有希望的方向，强调人与AI的深度结合以及知识的重要性。
方向一：新应用开发
- 采纳演进式、人机协作的开发模式：放弃让AI一次性生成完整应用的想法。应由人来做合理的特性拆解和规划，然后引导AI进行增量、迭代的开发。这样能让AI始终获得足够上下文，并允许用户持续审视和反馈，避免被带入歧途。
- 结合DSL（领域特定语言）与大模型：将知识驱动（低代码/DSL）与数据驱动（大模型）相结合。DSL凝练了领域知识和编程抽象，能极大缩小AI的解空间，从而显著提高生成代码的准确性和质量。
方向二：复杂软件维护
- 构建基于大模型的“代码数字孪生”：解决软件维护中最大的痛点——知识的缺失。利用大模型强大的知识抽取和关联能力，从代码、文档、历史记录中提取高层设计知识，构建一个与代码协同演化的“数字孪生”，并激励开发者以众包方式贡献自己的经验和理解。
总结与哲学反思
点击展开/折叠核心结论
- 核心结论：当前大模型主要在局部任务上发挥作用，其技术发展本身无法触发软件开发的质变。突破口在于将人的规划、设计、反馈能力与AI的生成能力有机结合。
- 对应用开发：应追求“人机协作的演进式生成”和“知识与数据双驱动”。
- 对系统维护：应致力于通过“代码数字孪生”进行系统化的知识积累与利用。
- 最终反思：未来是否还需要编程，取决于人类的价值观选择——我们是否愿意将世界的控制权让渡给一种我们无法完全理解和控制的概率化“智能”。