别怕被淘汰！AI 现在是，将来也永远只是人类的助手｜独家对话一线架构大佬 Christian Ciceri

在当下软件开发的快速演进与人工智能浪潮交汇的背景下，软件架构师的角色与方法论正在经历前所未有的考验与变革。

过去，架构师的核心职责主要集中在系统设计、模块划分和技术决策上，强调的是稳定性、可维护性以及对技术栈的掌控。然而，随着云原生架构、微服务、大规模分布式系统以及低代码 / 无代码平台的普及，软件系统的复杂性呈指数级增长，架构师面临的不再只是技术选择问题，而是如何在快速迭代与持续交付的环境中保持架构健康和团队效率的挑战。

与此同时，人工智能的兴起为软件开发注入了前所未有的工具和能力。自动化代码生成、智能测试、AI 辅助设计等技术，使得部分传统的架构任务可以由算法快速完成。架构师不再需要亲自绘制所有依赖图或手动分析性能瓶颈，而是可以借助 AI 快速发现潜在问题和优化空间。这一变化在提升效率的同时，也提出了新的问题：决策权、系统理解与技术判断仍然高度依赖人类的经验和洞察力，如何确保 AI 工具辅助而非替代，成为架构师必须面对的核心议题。

可以说，软件架构师正处在一个技术能力、业务理解与数据驱动决策三位一体的转型期。在快速迭代的环境中，他们需要掌握新技术、理解复杂系统的演化规律，同时引导团队形成共享愿景和架构文化。

Ciceri 的职业路径颇具代表性：他从一线软件开发与架构设计实践中积累经验，目睹了大型企业中灵活性不足、交付周期漫长、流程效率低下的常见挑战。2014 年，他与叶夫根尼·普雷丁（Evgeny Predein）在巴塞罗那共同创立了 Apiumhub，立志将敏捷方法论与软件架构紧密结合到业务运营的核心。正是在长期实践中，Ciceri 逐渐形成了“可度量、可演化架构”的理念，并将这一理念凝练在其著作《软件架构指标》中。他强调，构建稳固且具适应性的系统，不仅能提升软件交付质量，还能保证系统随业务需求同步成长。

在采访中，Ciceri 对“可观测性”（Observability）和“架构治理”进行了深入阐述。他指出，系统运行时的质量属性只是整体质量的一部分，真正的架构治理需要对所有软件属性保持持续监控。借助演化式软件架构中的适应度函数（fitness functions），团队能够实时监测架构健康状况，及早发现开发速度下降、缺陷增加或性能问题等架构退化迹象。

访谈中另一个高光时刻，是 Ciceri 对 AI 在软件架构中的角色的洞察。他明确表示 ，AI 可以辅助分析指标、提供可能的改进方案，但无法取代人类的判断与决策。他强调：“只有在人类驱动下，人工智能才能在软件设计中成为真正的生产力工具，而不是取而代之。”对于当前各种 AI 生成的架构建议，他仍然定位它们为“助手”而非“伙伴”，提醒架构师在拥抱 AI 时保持理性。

Christian： 我的职业生涯发展，得益于多年在大型企业从事软件开发与架构设计的实战经验。期间，我遭遇了行业常见的挑战，比如企业灵活性不足、交付周期漫长以及流程效率低下等问题。

2014 年，我与叶夫根尼・普雷丁（Evgeny Predein）在巴塞罗那共同创立了 Apiumhub 公司。我们的核心目标，是将敏捷方法论与软件架构置于业务运营的核心位置。

随着时间推移，我逐渐意识到，要创造长期价值，必须专注于可量化且可演进的架构设计。打造既稳固又具备适应性的系统，才能让团队交付高质量软件，并确保软件能随业务需求同步成长。这一理念，最终促使我撰写了《软件架构指标》（Software Architecture Metrics）一书中的相关章节。

Christian： 指标与度量是推动争议更趋近客观的有效方式。但需要注意的是，与团队共同秉持的架构愿景，仍是软件架构师日常工作中极为重要的一部分。

Christian： 虽然人工智能有望成为软件架构师工作中非常实用的助手，但我确实认为它无法取代技术决策过程。技术决策必须由人类的能力和经验来主导。

换句话说，我深信，只有在人类的驱动下人工智能在软件设计中才能成为真正的生产力工具，而非相反。

Christian： 在我看来，这些工具有助于提出可能的解决方案并发掘新的可能性，但正如我之前所说，它们无法取代人类的决策过程。在我看来，这些工具现在是、将来也永远会是有价值的 “助手”。

Christian： 在马丁・福勒一篇题为《谁需要架构师》的旧文中，他区分了传统架构师的两种角色 —— 决策者与引导者，其中后者是 “提升团队水平” 的最佳方式。这种方式有助于在团队内部建立真正的软件架构文化，与开发人员并肩工作，尤其是在建模阶段。

不过，我坚信软件架构是工程学这个更广泛领域内一门不断发展的科学。我的意思是，任何人都可以成为架构师，但这并非可以随意为之的事情。要成为一名高效的架构师，你需要研读大量的科学文献，并持续深化对该领域的理解。

Christian：“可观测性”通常指的是系统运行时的质量属性，而这只是系统整体质量的一部分。一般来说，为系统引入架构治理或者架构设计意味着要对所有软件属性保持持续的管控。实现这一过程的一个良好方法是采用“演化式软件架构”中的相关技术，其中最重要的概念就是适应度函数（fitness functions）。

Christian： 当我们从架构治理的角度思考“可观测性”时，一次架构性的错误，理想情况下应该能够通过失败的架构单元测试被检测到。不过，架构退化的迹象通常是逐步显现的，例如开发速度变慢、缺陷和运行时问题（如性能问题）增加、系统在应对更高负载时出现困难，以及其他类似的症状。

Christian： 根据我们的经验，这其实取决于团队的具体情况。总体而言，指标不应该被强制设定为目标，而应当结合团队的文化建设，谨慎地引入和推广——这才是真正的出发点。另一个关键点是，指标的使用应当建立在真实且公认的痛点之上，也就是那些团队成员都能感同身受、并一致认为需要重点关注的问题。

Christian： 我认为被 最滥用的指标 是测试代码覆盖率。问题在于，这个指标几乎无法告诉我们测试策略是否真正有效——测试效果主要取决于被测试模块（如类、方法等）的设计质量。不过话说回来，当代码覆盖率数字 非常低 时，它依然是一个有用的信号，因为这通常明确反映出团队生产力不足，或是开发流程存在问题。

Christian： 不，在我看来，这仍然属于“科幻”的范畴。虽然人工智能确实可以在分析指标、提出潜在改进建议等方面提供帮助，但它无法取代人类的判断力，也无法替代软件架构中所需的细致决策过程。软件架构涉及 权衡取舍、理解业务背景 以及 预判未来需求 等方面，而这些都是目前难以在自动化系统中完全编码和实现的。

Christian：你说的这 三种特质，包括分析能力、领导力、共情能力都很重要。分析能力当然是理解复杂系统、做出稳健架构决策的关键。但我认为，好奇心 同样珍贵——它推动持续学习，帮助你不断掌握新技术与新实践，并且常常能引导出那些 单靠分析无法得出的创造性解决方案。 在许多方面，正是好奇心让架构师能够在不断变化的领域中成长与适应。

Christian： 所有广为人知的领域驱动设计（DDD）著作都很有参考价值， 但如果你想获得更深入、且更贴近当代的软件设计洞见，我推荐阅读 Vladik Khononov 的《Balancing Coupling in Software Design》。

Christian： 我们这一行业的核心“黄金法则”是：把“我（I）从架构（architecture）中去掉。架构是一种共享的愿景，你不能仅凭自己对领域的理解就做出决策。真正的架构工作应当让整个团队共同参与，确保所有决策都是集体性的。

后续我将通过微信视频号，以视频的形式持续更新技术话题、未来发展趋势、创业经验、商业踩坑教训等精彩内容，和大家一同成长，开启知识交流之旅