AI 时代我们的 IT 团队架构应该如何应变

在 GitHub Copilot 发布的头 6 个月，在美国的开发人员有 92%拥抱采用了它或者同类生成式 AI 工具进行编码开发。可见码农天然的人皆有“偷懒”之心 - 如果更快、更高质量的炮制出一些代码，少掉几根头发，有什么不好呢？

2023 年 AI 代码生成只发生在个人的 IDE 里

迄今为止，这些“AI 降神”，只是赋能了工程师个人做一些局部的工作。接下来，该轮到在团队协作层面、在整个 SDLC（Software Development Lifecycle - 软件开发生命全周期）产生影响了。在 12 月份，Google Cloud 宣告发布 Duet AI For Developers，而著名开发协同工具 JIRA、Confluence Wiki 的提供商 Atlassian，则推出 Atlassian Intelligence，把生成式 AI 的能力内置于这些产品中。

是时候动软件开发组织的奶酪。有很多岗位可能被消灭、有很多事情应该被自动化、有很多技能不再重要、有很多沟通协作成本也许被清零。新的技术带来新的技能，新的技能带来新的分工，在整个软件开发生命周期里，组织结构与协作方式，都将发生巨变。

2024 年 AI 将影响 IDE 外的事

软件开发，并不只是写写代码。在一套软件的开发过程中，实质上大部分的工作都不是编码，而是交流对话、团队会议、邮件来回、白板讨论、设计论证、新团队成员上手代码（Onboarding）、工作任务交接（Context sharing）... 正如 Google Duet AI For Developers 的专家所说，在软件开发全生命周期里，最容易的部分，可能就是在 IDE 里写那几行代码了。

软件工程，不仅是在 IDE 里面，更加是在 IDE 外面、在打开 IDE 之前、在关闭 IDE 之后。

所谓“台上一分钟，台下十年功” - IDE 里写十行有效、最终成为投产软件一部分的代码，那前前后后得做多少功夫？

对于企业 IT 来说，恐怕最迫切需要解决的还不是工程师个人 IDE 里的事情，而是在 IDE 外的那些团队沟通协作的事情 - 那往往是软件开发过程中低效的根源、软件产品里很多 bug 的根源。

老生常谈的康威定律又来了

说到组织、沟通、协作，又不得不把康威定律挖出来讲一下。事实上，每个技术更迭的世代，貌似都要把康威定律又挖出来讲讲。最近的一次，应该是在移动互联网、云计算、大数据各类技术栈涌现的近十年吧。

移动互联网时代，开发人员的“技术栈”、分工，基本上就是写 HTML5 的前端岗位、写 Objective-C/Swift 的 iOS 端岗位、写 Java/Kotlin 的 Android 端岗位、写 Flutter 或者 React-Native 的移动端岗位、写 REST 服务和数据库增删改查的后端岗位，此外可能还有数据库管理岗位（DBA），还有搞大数据的岗位，还有做分布式架构或者中间件的岗位，可能还有得懂点容器技术又写点脚本语言的 DevOps 岗位...

这些岗位所依赖的技术工具、开发框架、甚至一定程度上的知识结构，都很不一样。形成很细很专门的分工。岗位之间，“隔行如隔山”，都是写代码，但彼此不能打替补互相救援。码农日益像工业时代工厂流水线上的机械工人：专职拧一个螺丝或者专职锤一个钉子。iOS 开发忙的人仰马翻，写 JavaScript 的，过来帮一下忙？门都没有 - 需要重新学习培训，每个一年半载没戏，还不说这些人是否有动力和意愿去学。甚至在 HTML5 的编写工作里还要细分，得专门有人写 CSS（负责给前端“技术工程师”嫌弃做的页面外观“涂脂抹粉” ）。

反正，IT 部门不得不“被动”的把员工按技能形成组织，但往往又非常不满意于这种被动形成的组织的协作、交流方式之下的效率。总是想基于业务线、产品线的维度去改良更高效敏捷的组织。究竟应该按码农的专业技能来组织成“资源池”？还是按所支持的业务职能来组织成“攻坚小组”？这个“专业技能 - 业务职能”的“矩阵”，哪个为主、哪个为次？哪条汇报线是实线、哪条是虚线？永远在反复的纠结、来回的摆动中。

屁股决定脑袋 - 康威定律本质上讲的其实是这个事情，一个软件开发组织所设计的系统的架构，受制于产生这些设计的组织的沟通协作的结构。而这些组织的架构，又被带时代烙印的技术栈所导致的技术分工、技能隔离所深刻影响，往往并不能让组织的领导者随心所欲的去构建出真正符合业务发展需要的组织。

开发过程的沟通成本，就在这些令业务部门无法理解的 CSS 开发、JavaScript 开发、iOS 开发、Android 开发、REST 服务开发、数据库开发、数据库管理、系统运维等等各色人等、各种岗位之间消耗。每一个岗位都不能缺、忙不过来其他岗位也无法替补...

生成式 AI 加持下，各种代码生成工具纷呈。在大部分的应用场景下，用什么计算机语言编程日益不重要 - 不都是用自然语言给大模型写提示生成代码吗？下一代软件工程师的知识结构、所掌握的技术栈，将截然不同。

一个全新的技术世代在开启，这个时代下的软件开发组织该是怎样的呢？

AI 消除程序员的“生殖隔离”

都是学计算机的，都接受过“离散数学”、“数据结构与算法”、“编程语言与编译器”、“操作系统”、“软件工程”、“计算机网络”的训练，为啥懂 Java 的就不能写 C、写“前端”的就搞不定“后端”？这是让业务部门搞不懂、而 IT 部门解释不清的“悬疑”。

“用任何可能的最佳技术手段，完整解决一个实际问题” - 虽然这是作为软件开发者最本来的使命与职责，遗憾的是，这个世界上大部分的开发人员只考虑如何用现实问题去匹配他们狭隘的知识 - “我只负责前端，后端我不懂”、“我只写 Golang，JavaScript 别找我”。所以大多数时间里，任何一个种类的开发人员，都无法独自开发出一个“端到端”能跑的软件...

软件工程确实是一个众多角色、各种技能、丰富知识下的协同大生产。但令人头疼的是，不同领域的程序员，知识技能不仅无法共享、交换，他们甚至令人怀疑是不是同一个物种：就像智人和尼安德特人虽然都是“人属”，却是两个有“生殖隔离”的物种。后端开发看不懂前端开发的代码，Android 工程师不明白 iOS 工程师的算法逻辑...

所以，生成式 AI 进入软件开发领域，第一件事情是消除一部分隔离（虽然完全抹平恐怕是短期内不太现实的事情）。

其次，IT 组织一直纠结的治理架构：团队人员按技术栈决定的技能来分组？还是按所参与的业务条线分组？也许接下来的“革新”，既不取决于“技能”，也不完全取决于“职能”，因为“智能”将带来颠覆。

支持软件快速交付的团队拓扑结构

上述“生殖隔离”般的问题，已经引起业界的思考。团队拓扑（Team topologies ），可以说是近年来出现的一种试图作出的改变，而且其本质上也践行了康威定律的理论。它是 Matthew Skelton 和 Manuel Pais 在 2017 年出版的《Team Topologies: Organizing Business and Technology Teams for Fast Flow》一书中提出的一种团队组织结构模型。该模型认为，团队组织结构应该根据团队的职责和业务流来设计，而不是根据技术或领域来划分。

Team topologies 将团队分为四种类型：

• 业务流团队（Stream-aligned teams）：指匹配业务领域或组织能力的持续流动的工作任务的团队，端到端负责交付一个特定的产品或服务，共同负责产品的整个生命周期。它对应于一个产品、一项服务、一组功能特性等。成熟的产品导向团队，能端到端地完成交付用户价值，而无需将部分工作交由其它团队完成。这类团队的关键是：快速反馈、敏捷。

• 赋能团队（Enabling teams）：如果业务流程团队是“纵向”的，那么赋能团队就是“横向”的 - 为流程团队提供支持的团队。赋能团队通常负责基础设施、工具、培训和其他支持性工作。这类团队的关键是：促进软件开发交付的最佳实践与规模化。

• 复杂子系统团队（Complicated-subsystem teams）：负责构建与维护一个验证依赖于专业领域知识的复杂子系统的团队。团队通常由具有特定技术技能和知识的工程师组成。他们中大多数是相关领域的专家，其目标是降低各个产品导向团队的认知负荷。

• 平台团队（Platform teams）：为整个组织提供基础设施和工具的团队。平台团队通常由具有广泛技术技能和知识的工程师组成。

本质上，Team Topologies 提供了具体可行的实践指南，优化组织沟通结构，使软件系统更好地满足业务需求。它可能是 20 年来试图突破以技术栈和技能为组织分工的制约，对 IT 组织分工协同模式的一次重新变革。

生成式 AI 加持下的团队拓扑

生成式 AI 与相关系列技术的出现，和 Team Toplogies 的模型似乎能形成非常自然的结合，在此我们不妨“畅想”一下。

平台团队将承担起建立、提供和维护以大语言模型为核心的“自然语言计算机”系统的重任 - 这套系统把冯诺依曼架构深深隐藏，统一管理与输出：

• CPU、TPU、GPU 的混合算力

• 各种通用或专用模型包括代码生成模型

• 矢量数据库、数据训练工具以及 RAG 相关基础设施

• 自然语言处理、机器学习、数据集管理、数据安全管理、ChatBot 等服务

为其他团队的 开发工作提供基础 AI 设施与服务。

赋能团队将负责对业务流团队提供 AI 赋能。他们将培训开发团队如何妥善运用提示（Prompting）、检索增强生成（RAG）、精调（Fine-tuning）、对齐（Alignment ）等方法去获得所需的结果，像过去的“敏捷教练”那样，扮演“AI 教练”的角色，帮助业务应用团队更好地整体理解和使用 AI 技术，从而让整个企业的基因 AI 的软件开发最佳实践得以横向复制、规模化。

复杂子系统团队将由企业内某些领域的专家组成，他们将负责领域模型的训练、微调和知识库的建设。这些领域模型将为企业的 AI 开发工作提供有力的支持。

业务流团队将是整个组织中最贴近各类业务与市场的多支团队。他们将利用平台团队、赋能团队和复杂子系统团队提供的支持，持续高效地基于市场、客户需要，以极小的时间单位为交付周期，在平台团队所提供的 AI 基础设施上，在赋能团队的辅导下，交付软件产品。

有理由相信，业务流团队甚至不再归属于传统 IT 部门 - 因为以自然语言为基础、业务语言为核心的开发工作，可能不再需要传统意义上的软件开发工程师去负责，而是由既懂得业务、又贴近客户与市场、并接受 AI 赋能团队指导的业务部门人员去承担。

AI 如何降低软件开发过程的“摩擦”？

在软件开发生命周期中，一直存在许许多多的“摩擦”（Friction），如果能消除这些摩擦，让协作过程变得无缝、丝滑，让软件开发者本身获得良好的开发体验（Developer Experience），他们才有可能高效的开发出有优良用户体验的软件。

除了谈宏大缥缈的什么组织结构、定律，我们也可以更加务实的去看，AI 具体在哪些场景下有助于让软件开发团队的协作更加“无摩擦”（Frictionless）。

• 新成员加入（Onboarding）：生成式 AI 应该能构建整个软件项目沉淀的知识库并随时“答疑”新团队成员关于项目背景知识的各种解答，甚至充当新成员的 mentor（导师）

• 任务交接（Context sharing）：因团队成员的休假、调岗或者离职，过去仅存在于他/她头脑里的知识，需要较长的交接时间 - 1 个月？2 个月？3 个月？永远有可能在交接过程遗漏的信息点。在大型银行、一些求稳的金融机构，交接 6 个月也未必让担心出纰漏背锅的领导者放心。生成式 AI，作为软件项目中不会缺席的成员，不厌其烦、不遗余力的记忆项目的发展，对各种工作任务的背景、上下文，有望提供最详尽可靠的信息

• 测试：在 IDE 里，Copilot 们已经可以帮助开发者生成高水平的测试代码，让不愿意“浪费”时间写 test case 的码农没有借口。在 IDE 外，测试用例的设计与生成、测试报告的撰写、测试的自动化、甚至一些人类测试工程师未必能考虑到的边角测试场景，也许 AI 都能帮上大忙

• 文档：这个毋庸多言，理解代码生成代码注释、生成开发接口的文档说明、甚至生成示范例子，应该都是生成式 AI 的拿手戏

• 代码评审（Code Review）：首先对于评审者，回顾与评审他人代码不再是那么大一个负担，对于不熟悉的语言，AI 助手帮助分析和评论，评审者可能不过是再把把关审核一下。事实上专门聚焦对代码库进行代码评审、自动化提交合并的基于大语言模型的智能工具已经出现，也许 Code Review 已经不再是一个人类的工作

• Debug：掌握整个代码库的 AI，对于定位代码、自动发现潜在缺陷并进行修复，有实现的可能。聚焦这个领域的工具也开始出现

过去的开发团队，对自己的项目尤其是大型项目的代码库，是做不到“了如指掌”的，因此也无法“随心所欲”的修复缺陷、增加功能、敏捷发布。在大语言模型和无数的 RAG、ChatBot、Agent 工具协助下，这方面将得到极大的改观。

但在这整个软件开发生命周期中，有多少人类开发工程师还能继续存在于新一代的开发组织中呢？只有实践才能回答了。

本文转载至 FinClip 博客