生成式 AI 在软件研发和知识管理上，有着非常大的潜力，也因此这项技术被越来越多的企业所采用。而在一些新兴的技术上，诸如于鸿蒙操作系统，它带来了一些新 的理念、开发工具 DevEco Studio、新的语言 ArkTS、新的 UI 框架 ArkUI 等等。从模式上来说，它与生成式 AI 结合企业内部的基础设施过程非常相似。因此，我们开始在 AutoDev 中探索如何结合这些新知识的可能性，同时降低

架构工作台是一个环境，其设计初衷用于帮助人们设计架构、演进架构、观测架构，并有效地运用架构所需要的高质量工具，如交互式的架构开发和分析。在上一篇文章《架构即代码：编码下一代企业（应用）架构体系》中，我们介绍了架构即代码的思想，它是如何围绕于架构的一系列模式，将架构元素、特征进行组合与呈现，并将架构决策与设计原则等紧密的与系统相结合。而为了实施及落地架构即代码的理念，还需要...

在过去的几个月里，随着智能体语言 Shire 的不断开发，我们也在使用 Shire 来自举，即使用 Shire 来进行 Shire 语言的开发。其中的一个重要应用场景是：使用 Shire 来生成 Shire 文档。在这篇文章里，我们将分享其中的三个实践：生成自定义风格注释借助 pipeline 函数，自动生成文档文件结合 RAG 技术，自动化分析文档以及我们的一些思考。经典文档工程的解决思路过去在

在 2024 年年底，终于将我之前想跟随的自定义多文件编辑功能发布了。在最新的版本里，你可以体验一系列的 AI IDE 智能体特性：自定义 ChatBox 行为 + Patch Sketch。一次让 AI 修改多个代码文件，并且将与更友好的视图来展示它们。流式 Diff。现在你可以在 Shire 上体验到实时的代码差异比较功能（基于 Continue 的 UI 修改）。智能上下文感知。当你在 Ch

长太不看版：基于领域驱动设计思考的 AI Agent 框架 Chocolate Factory，框架现在还在 PoC阶段，欢迎加入开发。（当前主要关注于 SDLC + AIGC 的场景）。GitHub：https://github.com/unit-mesh/chocolate-factoryDemo 视频：在过去的一段时间，我们尝试从先前的 AIGC 应用经验里，进行一些再提炼和总结。从起先的.

TL；DR：我们需要一个新的框架、胶水层，来帮助我们适配生成式 AI 的输出，以及解决流式数据传输的问题。在过去几个月里，我们一直在项目上探索：如何设计更好的架构，以将业务流程和开发流程中的各类智能体结合起来，进一步释放生成式 AI 的潜力？诸如于面向 IDE、DevOps、Team AI 等多个不同消费端的智能体。在这个过程中，浮现了一种新的架构模式：流式 BFF。流式 BFF（Streamin

太长不看版：在新版本（0.8）的 Shire 中，你可以通过 Shire 智能体市场，一键下载和安装多个智能体，并直接在你的当前项目中使用。与此同时，你还可以 将你的 Shire 代码段或者智能体上传到 Shire 智能体市场。详细见视频：WHY：AI 智能体应用于真实世界软件开发的挑战？在软件开发中，确定性是非常关键的，特别是在像实例化需求、格式化测试用例等环节，开发人员需要完全可控、精确的结果

在 AutoDev 1.7.2 中，我们开始构建一个新的 AI Agent 语言：DevIns，即 Development Instruction。即 DevIns 可以让用户更快速描述软件开发任务， 同时，还可以自动化处理来自 AI Agent 返回的内容。诸如于：/write:README.md\n```\n# Hello, World!```\n"，AutoDev 将会翻译并执行这个指令，.

尽管，如过去构建 AutoDev 的 AutoCRUD、精准测试功能一样，我们有意去构建一个完全自动化的 API 开发智能体。但是依旧的，我们会遇到一些问题：API 设计是需要人类参与的，因为它需要考虑到业务逻辑、数据结构等等。API 文档是结合上下文与业务背景的。一次生成大量 API 代码存在大量的安全风险。AI 生成大量的代码，需要人类参与进行代码审查。大量的测试可以提升 API 的质量，但是

在开发 IDE 插件 AutoDev 时，我们一直遵循着 Unit Mesh 的基本思想，即 AI 所生成的应该是可执行的单元（Unit）。在底层构建丰富的各类单元/工具， 再结合 DevIns 来构建强大的智能体能力。在初步完成了 AutoDev 的整体蓝图（MVP）之后，我们开始强化原来的准确性问题，即 AI 所生成的代码是否可以被编译器编译，是否可以被测试覆盖等。在这些 功能中，我们最想解决