在设计 Unit Mesh 架构时，其思想是以 Unit（如代码单元）作为 AI 辅助生成的元素，以辅助人类解决复杂的软件开发问题。

围绕于 Unit Mesh 的理念，在 AutoDev 1.6.0 版本中，我们开发了更多的生成 “单元” 的功能：

• 生成 React 前端单个组件、页面的： AutoPage
• 生成后端代码 SQL 中的：AutoSQL

即在这里的页面、SQL、函数是一系列的 AI 生成的 “单元”， 以更好地探索我们对于生成式 AI 辅助思考。

如何解决复杂软件问题？

由于人类本身的能力限制，所以对于复杂任务来说，首先要做的事情是拆解。随后，要么我们委托给其他人来完成，要么我们自己 “努力” 完成。而在有了 AI 之后，如何让 AI 协助完成复杂任务，这是我们考虑的合理。

分而治之的软件架构

正因为问题本身过于复杂，边界模糊不清，所以前人（Eric Evans）总结了《领域驱动设计：软件核心复杂性应对之道》。在有了明界的边界之后，实现起来就简单了，模板化的服务化、模块化代码。

在不同的时代里，它应用对于不同的解决方案：

• 上一个时代，在复杂系统里代表性的架构是类似于 OSGi 的可插拔性、插件化的架构。
• 这一个时代，微服务是在结合软件复杂性、知识负载的一种架构模式。
• 在下一个时代，Gartner 等公司在预测可组合架构可是下一个趋势。

但是，其核心的思路是不变的，将复杂的问题拆解到人类可以解决的范畴。

软件架构的设计：协作以收集信息

在设计软件架构时，要做的很重要的一个沟通活动是：与利益相关者达到对系统的一致理解。简单来说，我们需要收集不同与这个系统相关的人员对系统的理解、要求等一系列信息，他可能是系统的使用者、各级领导等。

在理解软件架构时，需要从不同层次的实现去理解宏观和微观的实现。如我们在设计 ArchGuard 架构治理平台时，我们结合 C4 模式与一系列依赖分析模式，以期望从现有的代码中理解软件的设计。它需要从软件库依赖、API 依赖、模块依赖等构建出完整的信息。但是，我们可能对于业务信息还是缺乏理解的，毕竟软件的功能可能实现是错的。

软件架构的实现：围绕任务的拆解

在有了充足的信息（大部分时候都是不充足的）之后，我们就需要考虑如何去实现这个功能，所以就有了一系列的架构文档、决策记录等。简单来说，它就是我们针对于这个任务的初步计划。我们需要考虑设计每一部分如何实现，以及需要哪些人员支持等。

拆解完后，在进入开发后，一个功能进而被分解为一系列的需求/用户故事、详细的验收标准。而当开发人员接到一个需求时，就需要考虑（后端为例）：

• 是否需要新的 API，如果不需要要改哪个 API？
• API 的输入和输出是什么？
• 需要调用哪个 Service？
• 需要实现对应的数据库调用吗？

也就是我们在 AutoDev 中实现的 AutoCRUD 的功能。

AI 辅助的开发范式与思维框架

在有了生成式 AI 的辅助之后，人类的产品经理们，一直在纠结人与 AI 的边界：到底哪些事项应该交由人来实现，哪些应该交由 AI 来实现？

不过，至少大部分人能达成一致：AI 不能为你坐牢。所以呢，人类还得为 AI 生成的内容负责，还得检验 AI 生成的代码是否可靠。

在现有范式增强的 AI 辅助

从个人对于架构设计的理解来说，我会把它划为四个步骤：

• 分析。即基于上述的协作设计的架构概念达到一致。
• 设计。生成系统的逻辑架构与物理架构（即部署架构等）。
• 次序。生成一系列的架构决策以及软件所需要的优先级。
• 实现。结合技术决策，实现对应的软件架构。

在这几个阶段里，AI 在分析阶段可以帮助我们理解现有系统的设计，帮助我们设计通用的实现步骤。但是，由于我们需要对结果负责，所以并没有那么大的可信度。简单来说，对于精准的内容，还需要由人来把握。

GitHub 的 AI 辅助复杂任务框架

相似的，GitHub 也基于《Social Integration of Artificial Intelligence: Functions, Automation Allocation Logic and Human-Autonomy Trust》构建了自己的 AI 辅助解决复杂问题的思维框架：

1. 构建感知。收集和综合形成任务背景的所有相关信息。
2. 制定决策。提出应该针对这个任务采取的措施 。
3. 制定行动。定义执行任务的具体步骤和步骤的顺序。
4. 实现任务。执行按照定义的顺序进行的步骤。

从 GitHub 对于开发者的调研结果来看：

开发者对于在构建感知和制定行动计划方面，接受 AI 的协助。而对 AI 在制定决策、实现任务方面的自主性持谨慎态度。

那么，我们应该如何去设计 AI 工具的能力。

AutoDev 对于 AI 辅助复杂任务的思考

在探索性的构建 AutoDev 的 AutoCRUD 一个基于特定步骤的 AI Agent 时，我们发现了生成式 AI 并不能很好地处理这种高可靠的场景。所以，转为构建了针对于每个更细小任务的功能辅助。在具备了大量的子任务能力之后，便可以实现转由 AI Agent 来接入和改进。

上下文感知的任务辅助：AutoXXX

在现在 AutoDev 中，我们设计了一系列围绕于实现某一个需要所需要的一系列子任务。即诸如，当你需要写一个 API 时，你需要写文档、 SQL 、单元测试等，由这一系列更小的子任务去完成你的需求。对应的包含功能有：

• Code Complete 。自动代码补全
• Document。自动编写文档
• AutoTest 。自动生成单元测试并运行
• AutoPage 。自动生成前端页面
• AutoSQL 。自动生成后端 SQL
• AutoCRUD 。早期的探索性编码 agent

尽管我们采用的是静态代码分析方式，具备比 GitHub Copilot 更好的上下文能力和架构，但是生成式 AI 并没有能力来确保结果的准确性。

也因此，我们可以达成上述的那个结论：AI 的实现并没有那么靠谱。但是，它依然可以快速帮你完成你的一部分任务。

有限知识的任务分析与行动生成： Tasking

显然与编写代码相比，人们还需要的一类功能是：理解现有的代码。即从一个现有的知识中，萃取出完成任务所需要的信息。而由于，我们是从准确性的代码中生成内容，并且我们对于结果准确性的要求并没有那么高。所以，但是它节省了信息收集的时间，并可以为我们提供了初步的行动建议。

在有了运行建议之后，我们便可以将先前的一系列子任务辅助结合在一起。这就是我们正在设计的AutoDev Tasking 相关的功能。但是，它也不非那么可靠的，如果过去的知识并非语义化的，语义化搜索（RAG）相关的体系会在此失效。

从确实性的结果中，得到一份参考，其接受率往往会更高。 s

其它

在 2023 年，从各类的报告中，我们可以看到：AI 工具缺乏设计，导致开发人员准备内容（上下文）的时间过长，进而带来的负的效率提升。而随着工具的进一步成熟，对应的成本会进一步下降。而随着 AI 能力和工具的演进，模式将进一步演进。