大家好，我是来自阿里云块存储的邱浩。今天我想分享的是如何用 Qoder 加速前端巨石应用的架构演进。重点在于"加速"------架构本身并不重要，关键是在整体开发过程中，怎样把 Qoder 用起来。
项目背景与挑战
我们面对的是一个典型的企业级应用，这类系统在很多公司都很常见：架构复杂、业务场景多样、迭代周期长。我们的平台已经运行了八九年，人员更替频繁，技术栈也非常复杂。
这是一个分布式平台：最前端是前端应用，中间是 Java 服务，后端还有 C++ 的底层系统，以及 Python 脚本。近年来又陆续引入了很多 Go 服务，前端内部甚至同时存在 Vue 和 React 应用。整个系统非常庞大，且长期处于持续迭代状态。
作为负责人，我一边要开发新功能，一边要维护旧代码。那种感觉就像手里攥着一个雷------你知道它迟早会爆，所以必须想办法把它解掉。
正是在这种背景下，我们从 2022 年开始设计新架构，2023 年启动落地。到今年年初，整个功能迁移的进度还不到 50%。而剩下的这一大半，是在 AI Coding 的帮助下，于今年陆续完成的。我们预计在春节前、甚至今年年底，就能完全下线旧系统。
Qoder 的核心应用场景
很多人关注"从 0 到 1"，但对我们来说，"从 1 到 100"------也就是如何完成全面切换，才是真正的挑战。这也是 Qoder 的优势：面向真实软件的开发平台。
当前我们的新架构是基于 React 的企业级前端架构。架构本身很常见，也不重要。真正关键的是：如何使用 Qoder 将整个系统从旧架构完整迁移到新架构。
我本身在AI时代之前就是一个全栈开发者。在没有 AI Coding 之前，前后端都要写，代码风格杂乱，上下文频繁切换。现在有了 AI Coding 的加持，这种"全栈开发"变得更加频繁------各种语言来回切换，上下文也不断切换。Qoder能够在这个过程帮助我很多。
我希望我的全栈的经验可以借助Qoder来在整个业务团队普及，从而做到业务交付加速、架构迁移加速。
在传统开发中，前后端职责分明，相互依赖也相互制约。前端需要后端提供 API，后端需要前端开发功能的最后一环。
但现在，我们通过 Qoder 改变了这一模式。当前端需要后端配合时，我们可以借助 Qoder 去做一些原来后端的事，前端可以更专注自己的部分，后端则转变为"端到端功能交付者"------不仅提供 API，还能借助 Qoder 自动生成对应的前端调用代码，实现完整功能闭环。
这本质上是一种按职责划分的协作方式，而非按技术栈划分。
那我们是怎么通过Qoder让大家突破岗位扩大自己的职责范围呢？通过以下这些场景来一点一点做到。
场景1：
用 Quest Mode 为存量项目批量生成测试层
我们使用 Qoder 的 Quest Mode，为存量前端项目批量生成测试层。Quest Mode 支持多种模式，我们主要使用云端模式，因为它不会干扰本地开发任务。
在编写 Prompt 时，我们会明确要求生成一份完整的设计文档。基于这份文档，我们为所有存量代码库生成对应的测试用例。有了测试层之后，才能安全地进行重构、迁移等操作。
这也印证了我们一直倡导的 TDD（测试驱动开发） 理念：任何改动之前，必须先有测试，这样才能确保我们做了任何改动之后系统的行为不变。
场景2：
通过 Repo Wiki 与 Agent Markdown 实现知识同步
Qoder 的 Review & Wiki 功能对我们非常有用。我们的团队中有大量跨技术栈的同学参与开发，包括一些完全不懂前端的底层系统开发同学。
Qoder 能帮助他们快速理解项目结构。尤其是在需要快速交付功能时，它能迅速定位到关键代码位置，并提供"快速开始"指引，包括如何搭建环境、如何运行项目等。
更重要的是，这个知识库能与代码版本保持同步。过去我们常遇到"代码已更新，文档仍陈旧"的问题，现在 Qoder 会自动检测代码变更，并提示更新文档。如果对生成的文档不满意，也可以直接修改------它本身就是 Markdown 格式，提交后所有团队成员都能看到。
场景3：
Qoder Rules + 测试 + Agent自动化重构迁移代码
在迁移旧库到新技术栈的过程中，我们结合了多个 Qoder 能力：
在新架构目录中，我们通过规则文件（Rules） 明确规范：包括国际化要求、API 调用方式、组件优先级、技术栈标准等；
对旧库，我们使用 Repo Wiki 生成完整知识库；在根目录放置 Agent Markdown，作为大模型的"Readme"，描述项目结构与开发规范；
最后，通过 Quest Mode 在云端运行自动化重构任务，并强制要求所有测试用例通过后才通知完成。
如果测试失败，Qoder 会不断重试，直到成功为止。这种机制极大提升了重构的可靠性。
场景4：
用Qoder配置MCP，快速串联企业级开发流程
MCP（Model Context Protocol）是当前实现 AI 自动化不可或缺的能力。在企业环境中，开发涉及多个平台：代码平台、CI/CD 系统、发布平台等。过去，我们只能靠文档一步步指导新人："第一步做什么，第二步做什么......"
现在，我们通过 MCP 将这些平台的操作串联起来。只需一位熟悉流程的开发同学，用自然语言编写一套 Prompt，将各平台的 MCP 能力组合成自动化流程。
例如："发布日常环境"对应一套操作序列；"发布线上环境"对应另一套；发布后的配置变更、API 调用等，也能通过 MCP 一并完成。
这对跨技术栈或全栈开发者来说，提效非常明显。
场景5：
将规范文档转化为代码卡口
我们曾写过大量开发规范文档，但落地效果不佳------没人看、没人遵守。现在，我们用 Qoder 将这些文档快速而低成本地解析为可执行的检查工具，直接嵌入代码提交卡口。
例如：国际化规范检查；API 调用方式校验；UI 组件使用规范（我们基于 Ant Design 封装了内部组件，用法特殊，需严格约束）。
这些检查被集成到 Git 提交钩子中，由 Builder 自动执行。过去，针对这些文档规范想要写一套自动化检查工具成本很高，第一步都迈不出去；现在，用 Qoder 很容易就能迈出第一步。后续我们就只需不断优化校验逻辑和规则细节即可。
使用 Qoder 的实战经验总结
-
经验1、Agent Markdown：统一多工具认知
我们团队同时使用 Qoder、Cursor、通义灵码等不同工具。为了让它们对项目有统一理解，我们采用 Agent Markdown ------这相当于面向大模型的 Readme。
它通常由 Repo Wiki 精简而来，放在项目根目录。目前大多数 AI 编程工具都会优先读取该文件，已成为事实上的默认规范。
-
经验2、提示词管理：封装为 MCP 服务
早期，我们的钉钉里到处飞着各种 Prompt，传着传着就被改了，导致生成结果不可控。现在，我们自建 MCP 服务，将常用 Prompt 封装为工具接口。
这样，即使不了解细节的同学，也能一键调用，避免因本地环境（CPU、内存、硬盘）或使用水平差异导致效果不稳定。
-
经验3、开发模式的悄然转变：从写代码到写文档
我现在自己写代码很少，更多是在写文档。开发模式已从"写代码"转变为"写高质量文档"。
AI Coding 的本质，正逐渐演变为基于文档的人机协同研发。和 AI 交互中，你需要写清楚思路、明确需求、定义行为边界，这些最终都体现在 Markdown 文档中。
-
经验4、技术栈选择：越通用，AI 支持越好
在迁移过程中我深刻体会到：你使用的技术栈越普适、越公共，AI 的支持成本就越低。
如果你不指定技术栈，AI 默认生成的往往是 React + TypeScript + Tailwind 等社区主流组合------资料丰富、生成质量高。而一旦使用自研封装或小众框架，AI 的表现就会打折扣。
因此，在 AI 时代，团队是否要自建技术栈或者说要做到什么程度，都需要重新权衡。不是不能做，但要评估投入产出比。
-
经验5、AI 落地原则：人能兜底，专家护航
我们做的是存储业务，对稳定性要求极高。因此，我们也坚持一个原则：只有人能 hold 住的场景，才允许使用 AI。
即使一线开发者无法完全掌控，也必须有领域专家兜底------负责制定规范、设置卡口、处理线上问题。这样即使 AI 出错，影响也可控，整体效果反而更好。
以上就是我的全部分享。感谢大家！
关注我，掌握Qoder最新动态
