导言：不写代码的架构师是水货？

有人说：“你看那个架构师，连代码都不写，肯定是个水货。”

也有人说：“架构师亲自写代码太 low 了，老板招你来是搞架构的，不是搬砖的。”

现在，各种 AI 代码助手都在快速演进，架构师要不要写代码这个问题不但没有获得最终的答案，反而变得更加复杂化。

有的人认为，AI 代码助手对架构师提出更高要求，一定要朝市场，客户前面走一步，架构服务业务和场景，技术类架构师反而是越来越不值钱了。

而另一些观点则认为，架构师更要写代码了，代码可以借助AI工具，代码不仅仅是语法，更重要的是提示词这样的语义代码，代码层面发生变化语法+语义代码，架构层面自然也发生变化。

那么，架构师到底要不要写代码？

如果要写，该写多少代码？写哪些代码？

如果不写，怎么解决团队信任和协同的问题？

众所周知，软件工程里面的很多设计思想来源于建筑行业，所以我们用盖楼来做类比是非常合适的。如果只是盖个狗窝，根本用不着架构师，除非老板有钱烧的慌。但是盖摩天大楼就不一样了，如果不做详细的设计，找几个农民工直接上来就砌砖，最终结果铁定要出大事儿。

类似的，小系统、小用户量，没有架构师问题不大，找几个有经验的码农，也别搞什么设计，上去就堆代码；大系统、海量用户，情况就完全不一样了，尤其是一些涉及到用户资金的系统，真出事了不是赔钱的问题，弄不好会牢底坐穿。

所以，软件架构师更像建筑设计师，要保证整栋建筑的框架稳固、布局合理；而普通的程序员更像是建筑行业的农民工，主要做一些砌砖刷墙的工作。框架不稳会死人的，墙刷得不平可以铲掉再刷一遍。

现在有些架构师容易陷入一个误区，老是按着自己原来做架构，做软件设计的详细步骤去约束AI输出，这样其实是存在一些问题的。很多老师认为，要允许AI内部是黑盒，AI有自己的设计和实现思路。特别是反对还看到让AI输出详细的UML，再让AI按照UML去实现的一些做法。

从岗位职责的角度看，软件架构师不写代码合情合理。总不能让建筑设计师自己去砌墙，然后让农民工去做摩天大楼的设计吧？这不就全乱套吗？因此也有老师谈到，架构师更多是要能平衡好各方利益诉求，做好功能性和非功能性架构设计，做好行业领域的知识储备，架构决策和风险管理这些是AI暂时无法取代的，但能提供辅助。SDLC的开发测试部署应该会最早被替代。

所以，综上所述，架构师的主要工作内容应该是：

复杂系统的分解、物理模型的设计、技术组件和业务组件的划分、接口的抽象、各个子系统的耦合方式、系统的部署模式，核心数据模型或对象模型的设计等等，这些是更加重要的。

至于架构师不写代码，脑子正常的老板都应该能理解。

然而，理想很丰满，现实很骨感。

当我们回归现实就会发现，情况并没有那么简单。这是因为，在 IT 领域，技术人员有一些相似的心理和行为特征，如果架构师完全不写代码，兄弟们可能会怀疑老板招到了一个水货。一旦出现了这种状况，团队的工作气氛就完犊子了。

这时候，本来的岗位职责问题就变成了团队协作问题。

所以，从团队协作的角度看过去，架构师还是要写一些代码，其目的有二：一是展现架构师的技术实力、对领域知识的理解；二是保持系统中核心的、框架性的代码是稳固的。

同时，也要关注不同阶段架构师职责的变化，技术发展成熟的阶段，架构师的代码量或许要越来越少；而技术发展变革的阶段，架构师的代码量要越来愈多，等成熟后再逐步减少。主要原因是架构师要了解一线实际情况，避免空谈。

有一次晨会，我这儿有个架构师代码质量不错，服务也挺稳定的，产品提需求迭代也挺快的，每天早上都站会，架构师有一段时间支持需求一天开发完，然后提测，然后灰度，过程都挺顺利的，结果连续好几天站会都没有什么可说的。反而写屎山，维护屎山的小朋友们滔滔不绝的炫耀昨天改了多少个bug，改了多少功能，后来架构师自己都觉得工作没意思了……

就在那一刻，我悟了，这不就是老子说的“神人无功、圣人无名”吗？

架构师事情做得太完美，老板反而看不到你的功劳，

毕竟大多数公司的老板并不是技术出身，也不懂架构的重要性，甚至很多公司经常出现裁员裁到大动脉的现象。

这么看来，架构师还是对外为重会好一些：能够和业务沟通、能够推动非功能性需求和性能优化，还要具备一定的影响力和能够搞定业务和管理层。另外，也需要具备一定的政治能力，不然无法争取资源。和产品，领导，开发都要有良好的关系，如果全部聚焦在架构本身，贡献很难量化，甚至容易被老板忽视。

这就对很多技术出身的架构师提出了很高的要求，不是谁都能做到的，那怎么办呢？

要不然让老板自己亲自去做架构算了。

我不是故意要搞这种惊悚的小标题，实际上，老板亲自上场做架构师这种事情确实发生过，而且是很多次。

比方说，在腾讯发展初期，最初几个版本的 QQ 都是 Pony 自己写的，老板自己就是架构师。

类似的情况还有京东的东哥、小米的雷军、微信的张小龙，公司发展初期都是亲自下场，既是架构师，又是程序员。

但是，当公司发展壮大之后，老板亲自做架构师，甚至亲自写代码就不合适了。

第一个原因是：企业大了，各种事情多如牛毛，迎来送往的事情自不必说，工商、税务、融资......每天跑得鞋底冒烟，而且这些事情必须老板亲自到场，推都推不掉。

第二个原因是：老板亲自进项目组做架构，反而会让其他人不好发挥，如果老板做的架构有问题，请问项目组的同事是说呢还是不说呢？如果说了，老板可能会不开心；如果不说，项目可能会被干黄掉。一旦形成这种纠缠的局面，项目距离失控就不远了。

老板亲自做架构这件事，不是简单的对与错的问题，不同的时间、不同的发展阶段，同一件事可能会导致完全不同的结果。

近来，各种 AI 助手如雨后春笋般涌现，从刚开始的 Copilot，到后来的 Cursor ，再到 Google的 Claude，功能越来越强大。

我有一种感觉，在AI的加持下，代码的生产率会不断提升，这时候反而更加考验对软件系统的整体架构、领域知识的理解深度。真正有水平的架构师带着一群数字劳动力（Digital Labor），完全可以一个人顶一家公司。

那对于AI 时代的架构师而言，是否还应该继续写代码呢？欢迎留言评论，留下你的观点！

感谢本期参与讨论的名人堂老师（排名不分先后）：谢孟军、何明璐、张善友、刘歧、张虎、庄鹏、章小飞、毛剑、薛晓刚、沈淦、李健青、李庆丰、范赟鹏、杨卫华、周建平、翟永超、吴非、王晔倞、许小川、屠乐奇、沈欣、黄希彤、马俊、揭光发、王新栋、黄良懿

技术同盟专家谈1：AI时代的架构师要不要写代码？

技术同盟名人堂社群专家谈：AI时代的架构师要不要写代码？

人工智能

架构设计

软件工程

软件设计

软件架构

4位行业大咖将分享DeepSeek × 技术创作者：10倍速构建专业影响力讲座，助你抢占AI红利窗口！点击报名到场/直播预约：<a href="https://cloud.tencent.com/developer/salon/salon-2328" target="_blank">https://cloud.tencent.com/developer/salon/salon-2328</a><br/> 
 <img src="https://qcloudimg.tencent-cloud.cn/raw/3b8f3fb01c22a358ef9f87c7ffbddb3b.jpg"/>

技术同盟专家谈1：AI时代的架构师要不要写代码？

技术同盟专家谈1：AI时代的架构师要不要写代码？

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐