生产力决定生产关系，生产关系必须适应生产力的发展水平。 ———— 马克思。
传统的生产关系（包括架构分层、角色分工、协作流程）是围绕旧时代的生产力建立起来的。现在，生产力跃迁了，旧的生产关系自然开始失效。
本文尝试从“生产力决定生产关系”的视角，探讨 AI 会如何重塑软件架构（技术结构）和团队协作（组织结构）。当然，本人水平有限，抛砖引玉，欢迎大家讨论。
AI 对软件架构最深刻的影响是如何让 AI 能够以最低的成本来理解代码、理解对代码。长期以来软件架构的演进方向都是“对人类工程师友好”，现在我们需要“对 AI 友好”的结构。从自我经验来尝试给出几个可能的演进方向。
传统的 MVC 、DDD 等分层模型，本质是约束人的行为，防止开发者在屎山随意拉屎，但是传统的分层方式天然对 AI 不友好，同一个领域的代码分布在不同的层级，AI 需要跨层理解大量文件才能理解一个业务。
领域优先（ Domain-First ）+ 自包含（ Self-contained ）的组织方式大概率会取代传统分层架构。相对于传统的 DDD ，分层将在领域内部，每个领域都要有完整的业务语义（数据模型、服务逻辑、用例、规则），而不是像传统的 DDD 一样，分层在领域之间。相当于每个领域都是一个小型的 DDD 架构。
这一类工具天然对 AI 不友好，人可以很容易提取出冗余信息中的重点。但是 AI 很难做到，而且用于造成大模型的幻觉。而 AI 的出现让这类工具的原始动机正在消失，AI 可以生成比这些工具更好的代码。这些工具的使用场景完全可以交给 AI 来完成。
现阶段很多大厂的团队压根就没有自动化测试这回事，有一部分中层管理混子压根都不知道测试金字塔是什么东西。更不要说小厂了。当然，一些人才密度比较高的团队还是做的比较好的。归根结底的原因是自动化测试的收益不可量化，在 OKR\KPI 的考核思路下，自动化测试属于善战者无赫赫战功。
而 AI 时代，自动化测试几乎会变成不可或缺，一是因为 AI 可以自动生成测试，成本较低，二是因为 AI 可以通过自动化测试发现自己代码中的问题。AI 可以自我测试、自我修正。这会让自动化测试的优先级大幅提升。就需要相关的基础建设来支撑。三是自动化测试会给 AI 的重构提供安全保障。
程序员比较常说的 “代码就是文档” 在 AI 时代是不生效的，一是会提高 AI 的理解成本，二是 AI 无法从代码中推断“为什么这样设计”，也无法从代码理解业务规则的隐性部分。很多业务逻辑甚至是口口相传的。这就是为啥很多旧项目只能重写，不能重构。
显式知识变得非常关键。未来的代码库中，需要包含：用例（ Use Cases ）、领域语义（ Domain Glossary ）、领域规则（ Domain Rules ）。因为这些是给 AI 看的，人能读懂只是附带好处。AI 自我实现自动化测试并且能够回归，非常依赖这些显性知识。
AI 对协作关系的影响，基本上已经到了技术的奇点，换句话说，现在让前端结合 AI 写普通的 CRUD 逻辑、让后端结合 AI 写普通的页面逻辑，已经差不多是水到渠成的事情。以下讨论一下可能的组织结构变化。
以下内容中 80% 是同一个语义的不同呈现：
全是沟通成本和理解成本，甚至夹杂着各种扯皮。个人觉得 AI 时代，这些会变成： 文档、代码、接口、测试都围绕同一份语义知识库生成。PRD 不再是单独的文档，而是代码库的一部分。所有团队围绕同一个“源头”协作。
传统协作的核心是“阶段隔离”：
这是工业化生产线式的协作方式，本质是因为过去软件开发的瓶颈在于工程师的编码效率。所以整个组织都围绕工程师的产出瓶颈来安排。所有需求都是一步步的走流程。
AI 的出现会让整个协作流程更加的灵活，甚至会带来岗位的合并，前后端不久的将来会合并成一个岗位。而且技术开发甚至可能是前置到需求前（听起来不可思议，但是现在技术架构的设计是不是已经走在需求前面了，AI 时代会有更多开发方面的内容走在前面）。当然，现阶段的此类变动还较少。属于各公司都在探索的阶段。
从瀑布流过渡到 scrum ，本质上也是一种生产力带来的组织结构调整。瀑布流是工业化生产线式的协作方式，最大的问题就是流程很容易失控，容易进入死亡之谷。不太适合互联网高速发展时代需求迭代的节奏。而 scrum 的协作方式现在看起来也不符合 AI 时代的需求。未来可能会有更小的团队粒度。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。