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

问题：用户的需求描述往往模糊不清，AI 难以理解其意图，导致生成的代码质量不高。问题：在每次与 AI 交互时手动提供完整的项目特定上下文（编码规范、技术栈、架构模式、API 约定等）效率低下且容易遗漏，导致 AI 生成的代码不符合项目要求或团队标准。解决方案：利用现代 AI 编码助手提供的“项目规则”或“自定义指令”功能，预先定义项目上下文信息，使 AI 能够自动加载并遵循这些规则。这需要结合有效

CodeReviewAgent（主 Agent）/执行整体任务编排，负责 diff、lint、issue、测试等多源信息的聚合。AutoDev 智能审查流程可以概括为一个串联的四步流水线：先收集全部静态上下文，再用 LLM 做深度分析，然后生成可执行的修改计划， 最后由多 Agent 协作完成自动修复。等长期痛点：Lint、测试、Issue、变更记录散落在不同系统里；，AutoDev 让 AI 像

昨天，和我的前同事（他们 Thoughtworks Global，我们前 Thoughtworks 中国区，现 Inspire）聊完 AI Code Review 之后，觉得有几个点非常不错 的点，应该会影响到不少人对于对 AI 代码检视的架构设计与思考。简单来说，如果你要 review 10 行代码，那么我从我的上下文工程中，应该获取到 10 行的上下文信息， 诸如于：用户意图、文件依赖关系、预

由于 AutoDev 的新架构是多端统一的，同样的 CodingAgent 代码和 Renderer 机制，就可以确保我们在 CLI 遇到的问题，99%（只能是大概率）都会 在 Desktop、Mobile 等其它端遇到。在学习了基本的 AI Agent 和对应的上下文工程之后，你很容易理解这个提示词的用途 —— 运气好的情况下，你可以直接有一个可运行的 AI 辅助问题修复的 AI Agent。A

覆盖从需求分析、代码编写、文档管理到代码审查的完整开发流程，并且支持 Desktop（macOS/Windows/Linux）、CLI、VSCode、JetBrains IDE、Web、Android 和 iOS 全平台运行。从需求理解、架构设计、代码实现，到测试验证、文档编写、代码审查，乃至 UI 调整和团队协作，Xiuper 的每一个 Agent 都对应真实工程角色，实现完整的。（SDLC），

自然而然的，我们做一个关于 Code Review 的研究，肯定不是为了好玩，所以在这一篇文章里， 我们将介绍 AutoDev 的新 Agent，基于多端架构的 SubAgents 体系的 Code Review Agent。只是对于核心的软件开发系统来说，Code Review 是非常有必要的，可以改善质量，毕竟要花费大量的时间。现在的软件往往有着非常复杂的软件架构，诸如于多系统集成的微前端应用

TL;DR：我们试验了将 AI 应用到基于 Protobuf 的微服务架构中，基于 ArchGuard 治理平台、Shire AI 助手、Team AI 三个工具中，构建了一套完整的 AI4SE 原型，在需求、设计、开发、测试和运维等阶段，这里是我们的思考和实践。过去几个月里，我们在各大技术大会上频繁看到生成式 AI 的应用，很多研发组织都在尝试将其引入开发的各个环节。然而，随着 AI 技术的深入

在先前的一系列《云研发：研发即代码》文章里，我们介绍了软件工程的代码化闭环。同时，在《Water：云研发架构模式》介绍了设计这样的开发环境里，我们所需要的一些模式。今天呢，作为这一系列的落...

我对于无代码编程的研究也有些年头了，从国内最早的『无代码编程』相关的文章，到最近的『流程即代码：云研发 IDE Uncode』，我大抵是有资格再聊聊这个行业。最近，我们 Inherd 开源...