标签归档：AI编程

AI 编程后，软件的本质复杂度会有变化吗？

发表回复

最近一直在深度使用 AI 编程，从完全无代码的开发哥网站，到 AI 生成后台代码；从 Cursor 到 Trae AI，能明显感受到 AI 可以帮我写大量代码。最多的时候，5 个小时写了超过 2000 行可以运行的代码。但一个奇怪的感受是，尽管 AI 让代码生产更快了，软件开发的复杂度却没有降低，项目的构建需要的心力依然和以前一样。

这让我不禁思考：AI 真的在降低软件开发的复杂度吗？还是说，复杂度只是被转移了？

1. AI 编程 ≠ 复杂度消失，而是复杂度转移

在《人月神话》中，布鲁克斯提出了软件开发的四大本质复杂度：复杂度、一致性、可变性、不可见性。即使 AI 能够自动生成代码，这些复杂性依旧存在。

  • 业务复杂性：AI 可以帮我们写代码，但它无法自动理解业务规则的变化。例如，一个 AI 生成的电商促销规则，可能在逻辑漏洞下导致「满 100 减 200」这样的错误，造成严重损失。
  • 技术复杂性：AI 可以优化 SQL 查询、生成索引，但 AI 生成的代码仍然可能隐藏性能瓶颈，甚至带来更高的架构耦合度。
  • 治理复杂性：AI 代码的可维护性、可解释性，仍然是一个巨大的挑战。AI 生成的代码往往不是“最优解”，而是“看起来能跑”的解。

AI 并没有消除软件开发的复杂度，而是将其转移到了其它的层面：

传统复杂度 AI 时代的复杂度转移
人工编写 CRUD 代码 提示工程（Prompt Engineering）
手动优化数据库索引 AI 生成索引，但需要人类调优
代码逻辑的可读性 AI 生成的代码可能变成「黑盒」
需求沟通的精确表达 需要用更严谨的自然语言指导 AI

2. AI 让开发更快，但项目建设更复杂

布鲁克斯认为，软件开发的困难分为根本困难（Essential Complexity）和次要困难（Accidental Complexity）：

  • 根本困难：软件本身的固有复杂性，不会因技术进步而消失。
  • 次要困难：开发过程中人为引入的复杂性，如编程语言、工具、调试方式等，可以通过技术优化。

AI 编程 主要解决的是「次要困难」，但无法消除「根本困难」。让我们来看看布鲁克斯提出的软件开发四大根本困难，以及 AI 编程是否真的能克服它们。

2.1 复杂度（Complexity）

布鲁克斯认为，软件的复杂度源自以下几个因素：

  • 组件交互的指数级增长（比如微服务架构）。
  • 代码状态的激增（如并发编程）。
  • 业务逻辑的无限变化（如金融风控规则）。
  • 缺乏对整个系统的全局掌控能力。

AI 确实能快速生成代码，但它无法减少软件的业务复杂性。 例如：

  • AI 可以帮你写一个支付系统的 API，但它无法理解跨境支付的法律法规，仍然需要人类去设计合规架构。
  • AI 生成的代码可能没有考虑到以前没有见过异常情况，导致后期维护困难。

结论：AI 不会减少软件的复杂度，只是让代码生产更快，但架构和业务逻辑的复杂性依然存在。

2.2 一致性（Consistency）

软件必须兼容历史系统、旧数据、第三方 API 和用户习惯，这导致：

  • 新系统必须适配旧架构。
  • 代码风格和 API 设计必须保持一致。
  • 数据格式、协议、接口规范不能随意更改。

AI 可能会破坏一致性，而不是增强一致性。

  • AI 生成的代码风格可能不统一，团队成员需要额外时间进行重构。
  • AI 可能会引入隐性的兼容性问题，导致老系统无法正常运行。

结论：AI 不能自动保证代码和系统的一致性，反而可能引入新的不兼容问题。

2.3 可变性（Changeability）

软件必须不断适应需求变化：

  • 政策法规变化（如 GDPR 隐私保护要求）。
  • 新业务功能增加（比如直播带货）。
  • 技术栈升级或迁移（比如从 MySQL 迁移到 PostgreSQL 等）。

AI 确实可以加速代码变更，但它无法理解业务变更的深层逻辑：

  • AI 可能会机械地替换代码，但不会思考整体架构是否需要调整。
  • AI 可能会优化单个函数，但不会考虑整个系统的长期演进。

结论：AI 可以加速代码变更，但无法主动适应业务变化，反而可能增加技术债务。

2.4 不可见性（Invisibility）

软件不像建筑或者机械产品那样，可以从物理空间上直观理解。软件的结构是逻辑性的，导致：

  • 沟通困难：不同开发者对系统的理解可能不同。
  • 调试困难：AI 生成的代码可能变成「黑盒」，难以分析问题。
  • 架构复杂化：AI 生成代码可能会引入隐形的设计缺陷。

结论：AI 代码的「黑盒性」可能让软件的可见性更差，导致调试和维护的挑战更大。

3. AI 编程的真正价值：降低「次要困难」

虽然 AI 无法消除软件的根本复杂度，但它确实在减少次要复杂度（Accidental Complexity），包括： ✔ 代码生成：AI 可以帮你写 CRUD、API、测试代码，提高开发效率。
✔ 调试辅助：AI 可以自动分析日志、找出潜在 Bug。
✔ 文档生成：AI 可以自动补充代码注释，提升可读性。
✔ 代码优化：AI 可以推荐更优的算法或 SQL 查询，提高性能。

但与此同时，AI 也引入了新的复杂度： ❌ Prompt 设计复杂度：如何写出好的 Prompt，才能让 AI 生成高质量代码？AI 代码质量很大程度上依赖于输入的提示（Prompt），这意味着开发者需要掌握新的技能，比如如何编写高质量的 Prompt。 ❌ AI 代码治理：如何审查 AI 生成的代码，防止安全漏洞？
❌ 技术债务：AI 可能会生成「能跑但难维护」的代码，如何管理长远的架构演进？ AI 可以帮助我们快速生成大量代码，但如何组织这些代码、保证架构的可维护性，仍然是开发者的责任。

4. 未来开发者的核心竞争力：驾驭 AI，而不是被 AI 取代

AI 编程时代，开发者的角色正在改变：

  • 过去，开发者的价值在于写代码。
  • 未来，开发者的价值在于驾驭代码复杂度，利用 AI 高效开发。

开发者的三大新技能

✅ 语义工程：如何用精准的 Prompt 让 AI 生成高质量代码？

  • AI 代码质量的高低，取决于开发者如何设计 Prompt。
  • 但 AI 无法判断哪种方案最适合当前业务场景，这仍然需要开发者的经验与判断。

✅ AI 代码治理：如何审核 AI 代码，防止技术债务？

  • AI 代码可能会引入新的技术债务，比如：

    • 代码结构混乱，缺乏一致性
    • 逻辑错误难以发现
    • AI 生成的代码难以调试
  • 未来，AI 代码审查（AI Code Review）可能会成为开发流程的新标准。

✅ 架构思维：如何让 AI 代码符合长期可维护的架构设计？

  • 未来的开发者，需要具备更强的系统思维：

    • 如何拆解业务需求？
    • 如何设计可扩展的架构？
    • 如何管理 AI 代码的质量？
  • 开发者需要从「被动写代码」转变为「主动设计系统」。

5. 结尾

AI 让代码生成变得简单，但软件架构仍然需要人类设计。

未来，AI 编程会让开发变得更加高效，但开发者的核心竞争力将不再是写代码，而是驾驭复杂度。

未来，AI 可能会替代低端的代码搬运工，但无法替代深刻理解复杂度的架构师。

「AI 不会取代开发者，但懂得驾驭 AI 的开发者，将取代那些不懂 AI 的人。」

以上。