为何AI无法替代软件设计人员?

    在上一篇文章中我们分享了AI目前无法完全替代程序员的观点。其实，有一部分原因来自于程序员这个职业在过去几十年的发展中，已经逐渐演化出了非常多不同层次的角色，比如高级程序员、架构师、系统分析师等。这些角色在软件开发过程中承担的，已经不仅仅是编码工作，而是更多偏向于设计。某种程度上来说，真正决定一个软件上限的，是软件设计本身。

    在日常语境中，一提到“设计”，很容易让人联想到艺术。但软件设计并不只是艺术，它同时也是一种工程活动。一方面，它具备很强的结构性和可复用性，比如各种设计模式、架构范式以及长期积累下来的工程经验；但另一方面，它又不可避免地依赖经验与判断，比如如何划分边界、如何做抽象、如何在不同约束之间进行取舍。这种既有结构性、又有经验性的特征，使得软件设计很难被完全形式化。

    从这个角度来看，软件设计更接近于一种持续做取舍的过程。过于“先进”的设计往往会带来高昂的开发成本，甚至让项目难以推进；而过度贴合当前需求的设计，又容易在需求变化时迅速失效。灵活性、复杂度、成本、性能，这些因素之间始终存在张力，设计者需要在其中不断权衡。而这种权衡，很大程度上依赖个体经验，也依赖对问题本身的理解。

    LLM的出现，确实在改变这个过程。它可以在很短时间内给出覆盖面很广的方案，在设计初期补足认知盲区，尤其是在不熟悉的领域中，这种能力非常有价值。但本质上看，它更擅长的是对已有模式的整理、组合和扩展，而不是主动选择一个“更高一层”的抽象方向。

    之前在做一个知识图谱系统时，有过一个比较直观的体会。由于缺乏相关的领域经验，一开始借助LLM来协助设计。设计之初，从人员、组织、关系、事件这些基础概念出发，LLM很快给出了一套相对通用的建模方式。比如对于“人”，会列出身份证号、手机号、邮箱等常见属性。这种设计是合理的，在很多场景下也足以支撑系统开发。

    但在继续推进的过程中，很快会发现一个问题：现实世界中的信息远比这些字段要复杂。对于“人”而言，除了身份证，还可能存在护照、驾驶证、军官证等多种身份信息。如果继续沿用原有的设计方式，只能通过扩展字段来满足需求，这会使模型变得越来越臃肿。

    在这种情况下，尝试引导LLM做了一次调整，不再枚举具体的证件类型，而是将这一类信息统一抽象为“身份ID”。具体的证件种类作为类型存在，而不是直接体现在模型结构中。这样一来，模型从描述已知情况，转变为具备了承载未知情况的能力。比如多国籍对应多本护照这样的情况，也可以自然地表达出来。

    这个过程里有一个比较明显的分工：LLM可以很快给出一个覆盖面较广、符合常见实践的设计，但是否需要进一步提升抽象层级，往哪个方向抽象，仍然需要人来判断。如果没有这个引导，它很可能会继续沿着已有模式进行扩展，而不是主动跳出当前建模方式。

    当然，更灵活的设计并不一定意味着更好的设计。抽象层级的提升，往往伴随着系统复杂度的增加，也会提高实现难度和出错概率。即使在有LLM辅助的情况下，这种复杂性也不会自动消失。因此，设计者仍然需要判断，这样的抽象是否值得，是否真的能够被实现，并且能够被用户理解和使用。

    换一个角度来看，软件设计在很大程度上，可以被理解为在既有经验与模式构成的“空间”中进行搜索和组合的过程。只是这个“空间”目前还没有被系统性地整理出来。程序员共享了大量代码，却很少共享构造这些代码背后的设计过程，这使得很多设计决策仍然停留在个体经验层面。

    也正因为如此，当前的LLM虽然可以显著提升设计效率，但仍然难以完全替代设计本身。它可以帮助我们更快地到达某些已有解，但对于问题如何被定义、抽象应该落在哪一层，这些更关键的决策，仍然依赖人来完成。

    可以想象，如果未来这些设计过程能够被逐步结构化，形成一个可以被检索和交互的知识空间，那么AI通过不断提问，引导非专业人员逐步明确需求，并最终生成一套相对合理的设计方案，是完全有可能的。那样，软件设计的门槛会被大幅降低。

    但在此之前，设计依然是软件开发中最难被替代的部分之一。