讨论下 AI 时代的软件架构与协作关系的几个可能的变化

[weixind]

生产力决定生产关系，生产关系必须适应生产力的发展水平。 ———— 马克思。

传统的生产关系（包括架构分层、角色分工、协作流程）是围绕旧时代的生产力建立起来的。现在，生产力跃迁了，旧的生产关系自然开始失效。

本文尝试从“生产力决定生产关系”的视角，探讨 AI 会如何重塑软件架构（技术结构）和团队协作（组织结构）。当然，本人水平有限，抛砖引玉，欢迎大家讨论。

软件架构的变化可能有哪些

AI 对软件架构最深刻的影响是如何让 AI 能够以最低的成本来理解代码、理解对代码。长期以来软件架构的演进方向都是“对人类工程师友好”，现在我们需要“对 AI 友好”的结构。从自我经验来尝试给出几个可能的演进方向。

1. DDD 的迭代：从约束人到方便 AI 理解

传统的 MVC 、DDD 等分层模型，本质是约束人的行为，防止开发者在屎山随意拉屎，但是传统的分层方式天然对 AI 不友好，同一个领域的代码分布在不同的层级，AI 需要跨层理解大量文件才能理解一个业务。

领域优先（ Domain-First ）+ 自包含（ Self-contained ）的组织方式大概率会取代传统分层架构。相对于传统的 DDD ，分层将在领域内部，每个领域都要有完整的业务语义（数据模型、服务逻辑、用例、规则），而不是像传统的 DDD 一样，分层在领域之间。相当于每个领域都是一个小型的 DDD 架构。

2. 减少生成工具（ Swagger 、codegen 等）的使用

这一类工具天然对 AI 不友好，人可以很容易提取出冗余信息中的重点。但是 AI 很难做到，而且用于造成大模型的幻觉。而 AI 的出现让这类工具的原始动机正在消失，AI 可以生成比这些工具更好的代码。这些工具的使用场景完全可以交给 AI 来完成。

3. 自动化测试变成 AI 时代的基座

现阶段很多大厂的团队压根就没有自动化测试这回事，有一部分中层管理混子压根都不知道测试金字塔是什么东西。更不要说小厂了。当然，一些人才密度比较高的团队还是做的比较好的。归根结底的原因是自动化测试的收益不可量化，在 OKR\KPI 的考核思路下，自动化测试属于善战者无赫赫战功。

而 AI 时代，自动化测试几乎会变成不可或缺，一是因为 AI 可以自动生成测试，成本较低，二是因为 AI 可以通过自动化测试发现自己代码中的问题。AI 可以自我测试、自我修正。这会让自动化测试的优先级大幅提升。就需要相关的基础建设来支撑。三是自动化测试会给 AI 的重构提供安全保障。

4. 项目文档的变化

程序员比较常说的 “代码就是文档” 在 AI 时代是不生效的，一是会提高 AI 的理解成本，二是 AI 无法从代码中推断“为什么这样设计”，也无法从代码理解业务规则的隐性部分。很多业务逻辑甚至是口口相传的。这就是为啥很多旧项目只能重写，不能重构。

显式知识变得非常关键。未来的代码库中，需要包含：用例（ Use Cases ）、领域语义（ Domain Glossary ）、领域规则（ Domain Rules ）。因为这些是给 AI 看的，人能读懂只是附带好处。AI 自我实现自动化测试并且能够回归，非常依赖这些显性知识。

团队协作的变化可能有哪些

AI 对协作关系的影响，基本上已经到了技术的奇点，换句话说，现在让前端结合 AI 写普通的 CRUD 逻辑、让后端结合 AI 写普通的页面逻辑，已经差不多是水到渠成的事情。以下讨论一下可能的组织结构变化。

1. “文档→设计→代码”将变成“中心化协作”

以下内容中 80% 是同一个语义的不同呈现：

• 产品 PRD
• 设计稿
• 接口文档
• 代码
• 测试
• 运营手册

全是沟通成本和理解成本，甚至夹杂着各种扯皮。个人觉得 AI 时代，这些会变成： 文档、代码、接口、测试都围绕同一份语义知识库生成。PRD 不再是单独的文档，而是代码库的一部分。所有团队围绕同一个“源头”协作。

2. 需求、设计、开发之间的“阶段式协作”将被打破

传统协作的核心是“阶段隔离”：

• 产品：拉需求、写 PRD
• 设计：出稿
• 前后端：排期、对接
• 测试：收尾

这是工业化生产线式的协作方式，本质是因为过去软件开发的瓶颈在于工程师的编码效率。所以整个组织都围绕工程师的产出瓶颈来安排。所有需求都是一步步的走流程。

AI 的出现会让整个协作流程更加的灵活，甚至会带来岗位的合并，前后端不久的将来会合并成一个岗位。而且技术开发甚至可能是前置到需求前（听起来不可思议，但是现在技术架构的设计是不是已经走在需求前面了，AI 时代会有更多开发方面的内容走在前面）。当然，现阶段的此类变动还较少。属于各公司都在探索的阶段。

3. 瀑布流、scrum 的协作方式会慢慢迭代掉

从瀑布流过渡到 scrum ，本质上也是一种生产力带来的组织结构调整。瀑布流是工业化生产线式的协作方式，最大的问题就是流程很容易失控，容易进入死亡之谷。不太适合互联网高速发展时代需求迭代的节奏。而 scrum 的协作方式现在看起来也不符合 AI 时代的需求。未来可能会有更小的团队粒度。

[YanSeven]

现在的 Coding + AI 我觉得还不足以支撑软件架构的变更，我仍然只能支撑部分岗位的变更。

也就是一个中级开发+AI 可以相当于以前的一个中级开发+一两个初级开发,做到这个层面。

[sentinelK]

基于目前的大语言模型的上下文长度限制，目前对于软件工程的架构设计而言，属于一个非常尴尬的地位。

如果彻底向 AI 效率妥协（尽量压缩上下文），那么人对于程序的理解难度会上升，代码可读性会下降。
这会导致人工干预时的判断力与正确率下降。导致无法正确合理的拆解工作，也会增大提供上下文描述的错误概率。

如果向人类可读性妥协，那么会削弱 AI 的视野能力（因为上下文的效率更低）。导致 AI 生成的代码的全局性欠佳。
Agent 模式能一定程度的解决此问题，但不能精确、彻底解决。


至于说分工方式。过去青睐于层级分工，或者说分层开发，是因为人的能力问题（不可能寄希望于一个人同时精通 UI/UX 、前端开发、后端算法、以及数据库访问，乃至库表设计）。

目前的代码结构也是针对此来定义的。也就是“康威定律”所描述的那样。
但我认为，如果 LLM 的上下文能力没有再一次的飞跃的话，距离全面的垂直开发，还有一定的距离。

[ssssiiiirren]

非常有意思的思考。
不论 AI 时代是否能真的改变团队协作的方式，但是 AI 时代确实真的极大的提高了“文档”的重要性，甚至好的“文档”可能会比好的代码更加重要。

[moxuyou]

很有道理，不过个人感觉初创团队适合，成熟业务还是追求稳定，如果 LLM 还能跃迁一次才有可能影响到成熟业务的团队

[yeelooyeeuu]

很有道理

[wu00]

好文！

[mightybruce]

有思考的好文

[William97]

很棒的文章，有些点和我的想法差不多，但是要比我细致很多，膜拜大佬。

[William97]

@sentinelK 假设上下文限制有了一个很大发展，是不是还有幻觉问题需要解决

[weixind]

@sentinelK

我觉得现阶段大模型的上下文长度差不多已经够用。现在最大的问题是 agent 使用的过程中夹杂了太多冗余信息，不同文件间跳转，包括各种 toolcall ，多跳几次，再加载几个冗余的大文件就不够用了。虽然会有上下文压缩和总结，但是会造成信息的缺失。

如果代码组织的够好，几十上百万的 token 大概率能够覆盖大部分场景。

[weixind]

@William97 #9

我自己最近使用 cursor 、antigravity 的经验来看，出现幻觉的场景已经比较少了，大部分集中在可能使用了旧版本的 api ，本质上还是上下文缺失。只要让 agent 自己运行并检查基本上能够自行修复。

[maolon]

基本同意
细粒度的 ddd 带来的主要是 context control 的好处，
生成工具我认为他们依然能提供生成 ground truth 的能力，交互化和添加 context 控制功能也是一种方向，
自动化测试现在 e2e 方向的能力依然有限（受限于多模态和 context 长度限制）但是未来肯定会变得非常可用，
我觉得“语义知识库”是个很好的概念，现在基于文档的 SDD 应该是很早期的语义库的版本，应该会过渡到基于语义知识库的版本控制，协同编辑，和开发，以及围绕这个的一系列工程化的经验和方法。应该很快就是文档即代码的时代了。
以及随着 人-AI 的合作进一步加深，目前的管理体系肯定会随着变化，现在的人和人的交流拟定方案再到人翻译给 ai ，等待 ai 执行，评估结果再交由人类审核，然后重新规划的模式并没有充分利用 ai 的能动性

[redbeanzzZ]

我只能感觉到当前的生产关系会发生变化，但是具体要往哪个方向变确实思考不出来，膜拜下大佬