在人工智能时代，各类AI提效工具层出不穷，业界持续探索一套完整的智能化研发提效方案。我们团队结合自身特色，充分利用历史积累的知识库，落地了一套深度融合AI的工作流——用AI全面武装研发团队，实现研发效率的质变式提升。

先说几个核心判断：市面上现成的AI研发工具数量众多；团队内部的规范文档其实相当完备，但始终游离在实际开发流程之外；Code review、研发自测、接口文档更新等环节，消耗了大量宝贵时间。

目标非常明确：积极拥抱AI，推动团队迈向更先进的研发模式；用AI武装研发团队，通过资源的高效配合与协同，实现研发效率的显著跃升。

思路拆解下来仅需三步：拆分研发流程，精准找到AI结合点并将其串联成完整链路；深度探索AI IDE，摸索出可复制的最佳实践；盘活团队知识库，为AI提供强大的辅助能力支撑。

定位这件事，它是一个关键锚点——自此开始，团队研发流程正式向AI化方向转型。它也是一个全新的起点，带动团队和每位同学重新审视当前研发流程，共同建设更多高效的AI研发工作流。

研发链路拆解

对研发链路进行系统拆解，可以得到不同阶段的AI工作流形态，然后基于当前实践成果向下一阶段稳步推进。目前我们团队正处于阶段1接近完成、阶段2开始探索实践的关键节点上——下面分享的就是这些方面的真实实践。

原本研发链路：需求→设计→编码→测试→发布→运维

AI加持研发流程：AI-Cafes → AI-Docs → AI-DocsCoding → AI-Coding → AI-API → AI-CR → AI-Develops

对上面涉及的AI工作流做补充说明：

• AI-Cafes：利用AI自动生成需求文档、制作产品原型图，有效节省产品人力投入。

• AI-Docs：将需求文档自动转化为技术文档，大幅减少研发人员的梳理时间。

• AI-DocsCoding：基于技术文档自动生成不包含业务逻辑的基础代码，节省研发人天成本。

• AI-Coding：依据团队内部代码规范生成高质量代码，降低返工率和理解成本。

• AI-API：基于MCP Server打通接口文档，彻底杜绝文档更新不及时的痛点。

• AI-CR：基于预设Rules实现AI自动Code Review，提升审查效率。

• AI-Develops：AI赋能测试、验证、监控等运维环节，实现全链路智能化。

需求阶段实践

AI-CafeDocs

原本的工作流中，需求评审通过后，研发人员通常需要花费至少0.5天人力来落地技术文档、准备API接口。但这一步的大部分工作，本质上都是重复的、可替代的、可以节省的机械劳动。

为此我们实现了这样一条高效工作流：需求文档 → aisuda（百度的低代码平台）→ 大模型 → 技术文档（markdown）。

模型微调完成后，只需两步就能快速完成技术文档和API接口的准备：

1. 将需求文档投喂给大模型，获取初版技术文档。
2. 人工进行一轮核查确认。

技术文档快速生成后，后端再与前端沟通，根据具体细节调整实现方案。

AI-DocsCoding

拿到技术文档，下一步就是落地实现。不得不承认，日常工作中难免存在大量基础的CRUD环节——同样属于重复的、可替代的、可以节省的工作内容。

基于AI-CafeDocs的成功实践，我们做了进一步延伸：技术文档 → MCP Server → AI IDE。

通过MCP打通内部知识库，AI能够读取需求文档和技术文档，充分理解上下文，然后高效进行开发工作。当然，AI全流程自动开发目前还只是理想状态——就现阶段而言，AI-DocsCoding生成的代码并非完全可直接使用，业务逻辑越复杂，代码的正确性就越低。

但这并不要紧，设计这个流程时就已提前做好了准备。关键还是那句话：让AI取代重复的、可替代的、可以节省的工作。正确的操作流程是：

1. AI通过MCP读取需求文档和技术文档，自动生成本次功能的基础代码——除核心业务逻辑之外的参数处理、数据CRUD等基础代码。
2. 人工补充核心业务逻辑——研发人员只需专注于这些AI无法替代的关键部分。

可以看到，在这两个工作流中，人的角色已经发生了根本性转变——从执行者变成了驱动者和观察者，或者说产品经理——向AI提出需求，监督AI工作，最终验收AI的工作成果。

开发阶段实践

AI-Coding

AI-Coding主要围绕AI IDE的实际应用。市面上相关产品不少——Cursor、Comate、Trae等。很多人认为AI IDE的核心在于底层接入的模型，但实践经验表明并非如此。大模型的边界效应其实很强。

很多时候，我们对AI IDE的使用还远没到需要严格区分模型效果的程度。换个角度来问：就算用了世界上最好的模型，就能高枕无忧，让AI全程自动Coding且完全不需要人工Review吗？

至少到今天，AI-Coding仍然离不开人的关注和把控。如何更高效地使用AI进行Coding，是提效的必经之路。

合理使用Rule

在AI IDE中，Rule是极为关键的环节——它是连接开发者意图与AI代码生成行为之间的桥梁。

从定义上看，Rule的核心目的是指导AI更准确地理解当前代码库的上下文，严格遵循项目规范与编码标准，生成符合预期的优质代码。Rule内容会被包含在模型上下文的起始部分，为AI提供持续稳定的指导。

有一个关键点：所有Rule在使用时都会占用上下文token。因此如何更有效地使用Rule，是提升AI Coding能力的核心关键。

基于实践经验，我们建议将AI IDE的Rule进行层级化划分：

第一层：IDE全局层（User Rules）

• 位置：User Rules
• 范围：所有项目通用
• 内容：个人编码风格与偏好
• 限制：50行以内

第二层：项目基础层（Always Rules）

• 位置：.xx/rules/always/
• 范围：整个项目强制遵循
• 内容：技术栈、核心原则、基础规范
• 限制：100行以内

第三层：自动匹配层（Auto Rules）

• 位置：.xx/rules/auto/
• 范围：特定文件类型或目录
• 内容：模块专属开发规范
• 限制：每个规则200行以内

第四层：智能推荐层（Agent Rules）

• 位置：.xx/rules/agent/
• 范围：AI根据对话内容智能判断
• 内容：优化建议和最佳实践
• 限制：每个规则150行以内

第五层：手动调用层（Manual Rules）

• 位置：.xx/rules/manual/
• 范围：手动调用的代码模板
• 内容：完整的项目或模块模板
• 限制：每个规则300行以内

基于以上划分，再给出对已有/未有Rule规范的代码库的Rule创建规则（以Go语言为例）：

内容优化原则：

• 避免：过长的详细代码示例（每个100+行）、重复的概念解释。
• 推荐：简洁的要点列表（每个20-30行）、具体的操作指令。

globs精确匹配：

• 避免：过于宽泛，比如"**/*.go"匹配所有Go文件。
• 推荐：精确匹配，比如"internal/handler/**/*.go"只匹配处理器层，"internal/repository/**/*.go"只匹配仓储层，"**/*_test.go"只匹配测试文件。

优先级设置详解：

数值范围1-10，数值越高优先级越高。

优先级	规则类型	应用场景	Token占用权重	冲突处理
priority: 10	Always规则	项目基础规范	最高，始终加载	覆盖所有低优先级
priority: 8-9	Auto规则（核心）	核心业务模块	高，匹配时加载	覆盖priority≤7
priority: 6-7	Auto规则（辅助）	辅助功能模块	中，匹配时加载	覆盖priority≤5
priority: 5	Agent规则	智能优化建议	中，相关时加载	覆盖priority≤4
priority: 3-4	Manual规则	模板参考	低，调用时加载	被高优先级覆盖
priority: 1-2	实验性规则	测试功能	最低	被所有规则覆盖

优先级使用策略：

• 基础规范用10：项目必须严格遵循的核心规范。
• 核心模块用8-9：handler、service、repository等主要业务模块。
• 辅助模块用6-7：middleware、config、utils等辅助功能模块。
• 优化建议用5：性能优化、最佳实践等智能建议。
• 模板参考用3-4：代码模板、脚手架等参考资料。
• 实验功能用1-2：测试中的新规范，避免影响稳定功能。

冲突解决机制：

• 高优先级规则覆盖低优先级规则的冲突部分。
• 相同优先级规则按文件名字母顺序加载。
• Always规则始终优先于所有其他类型规则。

Rule的核心价值在于：它为开发者提供了一种精细化控制AI在代码理解、生成、重构等环节行为的机制。通过预设规则，可以把项目规范、编码标准、技术选型乃至特定业务逻辑“教会”给AI，从而显著提升研发效率、保障代码质量、确保项目规范性。它让AI从一个通用的泛化助手，转变为一个深度理解特定项目需求的“领域专家”。

记忆库

基于Rule的灵活运用，我们通过memory bank + rule的方式生成了专属的业务研发助手。

AI Coding中有一个常见的痛点：在复杂项目里，AI感知不到整个项目的历史上下文——即使有Codebase存在，它对业务逻辑的理解也往往一知半解。

实践中我们引入了记忆库模式：深化AI对项目的理解和记忆能力，让每一次需求迭代的上下文都被完整记录下来。生成memory bank后，随时可以通过对话查看项目大纲和具体内容，每次重新进入开发环境也不会丢失之前的记忆。

这种模式本质上属于Rules的一种应用——它将上下文总结在代码库的指定位置，强制AI每次进入时阅读上下文，快速回到上一次Coding的状态。对解决上下文丢失的问题帮助非常大。

这里可能有人会问：记忆库和IDE本身的长期记忆功能有什么不同？答案是：记忆库是公共的项目记忆库，而IDE长期记忆是私人的IDE使用记忆。至于记忆库的详细内容，这里不展开说明，它本质上就是一份精心设计的提示词——感兴趣的话简单搜索就能找到大量资源。

MCP Server（重点）

MCP（Model Context Protocol），即模型上下文协议，由Anthropic于2024年11月正式提出，旨在为大语言模型与外部数据源、工具、服务之间提供统一标准的通信框架，标准化AI与真实世界的交互方式。

MCP的核心架构包含三个关键环节：

• Host主机：用户与AI进行交互的应用环境，比如Claude Desktop、Cursor等。
• Client客户端：充当LLM和MCP server之间的桥梁——将用户查询指令、可用工具列表、工具调用结果发送给LLM，并将LLM需要使用的工具通过server执行调用。
• Server服务器：轻量级服务节点，赋予AI访问特定资源、调用工具能力的关键权限。这是MCP架构中最核心的组件。

在开发过程中，可以接入以下几种MCP Server：

1. 实时搜索：baidu/google/github/微博等。
2. 存储：mysql/redis等。
3. 工具：kubectl/yapi等。

用法一：接入百度搜索的MCP

• 搜索问题：开发之余搜索某本小说是否已完结。
• 搜索知识点：想了解Go 1.24新特性时，通过MCP搜索让AI自动总结。
• 搜索用法：想了解Linux快捷命令时直接搜索。

以上场景并非非MCP不可、非AI IDE不可，但通过这种集成方式，至少省掉了切换到浏览器、手动搜索、自己总结结论、再返回继续Coding这些繁琐步骤。

用法二：client里直接进行多client操作

• Redis自然语言查询。
• MySQL自然语言查询。
• GCP自然语言查询。

其他client（kubectl等）就不一一列举了。当IDE内部集成了各种client后，开发效率能够获得极大的提升。

当然，这里有两个关键点需要注意：

1. 接入MCP Server并不需要我们自己研究实现细节——只要把MCP Server的链接丢给AI，它自己就能开始接入。
2. 严禁在开发环境使用线上client的账号密码。

AI-API

相信无论是前端还是后端开发者，都或多或少被接口文档问题折磨过。前端经常抱怨后端提供的接口文档与实际代码不一致，后端又觉得编写和维护接口文档耗费大量精力，经常来不及及时更新。

无论是前端调后端，还是后端调后端，大家都期望有一份高质量且实时同步的接口文档。但随着时间推移和版本不断迭代，接口文档很容易滞后于代码，更会出现同学没交接清楚就离职的情况——留下繁重复杂的项目，重新梳理起来异常艰难。

核心痛点：

1. 重复劳动：每个涉及前后端交互的功能，研发人员都要手动维护接口文档。有时接口最终实现与最初的设定差异很大，每次改动都令人头疼。
2. 低效沟通：前后端反复沟通接口细节后，再进行对应代码开发——本质上还是重复的、可替代的、可以节省的工作。

为了解决这些痛点，我们通过引入AI自动化功能，搭建了API MCP Server，帮助团队解决这些冗杂工作，让研发人力更加集中在核心业务代码的开发上，提升效率、降低沟通成本。

这是我们一直畅想的理想场景：后端开发完代码 → AI自动推送接口文档 → API文档自动更新 → AI拉取接口文档 → 前端自动生成代码。前后端的研发人员只需关注业务功能实现，不需要再为接口对接的繁琐工作操心。

Better Thinking

这里补充两个使用AI Coding的核心思想，也是我们在实践中获得的深刻感悟。

一：学会递归式使用AI

场景：在IDE内配置MCP Server。

通常做法：到MCP Server市场找到想用的→手动配置部署好→调试→投入使用。

递归式做法：到MCP Server市场找到想用的→把链接直接丢给AI，让它自己安装（递归）→安装完成后让它自己修改mcp.json配置（递归）→修改完成后让它自己调通验证（递归）。

更进一步还能：让AI去网上自行搜索一个可用的MCP Server（递归）→ ...（递归）→ ...（递归）。

二：把AI当作一个真正的工具来使用

场景：撰写某篇文档时，突然想制作一个Gif格式的图片示例。

已知条件：电脑支持录屏功能，但缺少视频转Gif的转换工具。

麻烦点：使用网页在线工具需要搜索，还可能涉及付费；使用内部视频裁剪服务要启动服务；使用剪映等专业软件需要下载安装。都能做，但都相对繁琐——属于能做但又要额外浪费时间和精力。

解决方案：直接让AI写一个视频转Gif的小工具。

理论上让AI写和让GPT/DeepSeek写没有本质区别，但操作步骤得到了极大简化。也就是说，遇到很多自己能做但觉得麻烦、浪费精力的场景，以及大部分杂活琐事，都可以第一时间问自己：Can AI Do It？

包括但不限于：捞取数据、撰写文档、查找bug……

集成阶段实践

AI-CR

问题现状：

1. 时间压力：团队每周可能需要审查数十个CR，高T级别同学需要审查的尤其多，每个CR的细节审查耗费大量时间。
2. 沟通低效：CR评论描述不够清晰，开发者需要来回沟通确认具体的修改点。
3. 重复劳动：相似的代码改动反复审查，难以专注在真正的关键问题上。

通过引入AI自动化审查功能，提前规避基础性问题，让CR人力更多地聚焦在关键问题上，显著提升审查效率、降低沟通成本。

解决方案：

优化后的工作流：代码提审 → AI自动审查（基于Rules）→ 基础问题自动标记 → 人工审查关键问题 → 合并/修改。

运维阶段实践

AI-Develops

业务系统的复杂度持续攀升，运维过程中的告警数量急剧增长，传统的人工处理方式已经无法满足快速响应的需求。

就目前来看，现有运维体系存在明显弊端：告警存在非常厚的方向壁垒——不同方向的同学遇到另一个方向的告警，大多只能进行Case路由；告警也存在非常厚的年限壁垒——团队不同年限的同学处理同一Case的应对时间可能天差地别。

一个痛点是否足够痛，决定了是否值得优先优化。团队内积累了丰富的Case处理文档和记录，也有经验非常丰富的同学，但值班同学遇到告警轰炸时，同样会焦头烂额。

回顾告警处理的全过程，大部分其实都是重复的、可替代的、可以节省的工作——它们有成熟的方法论，并非遇到就手足无措。因此我们构建了智能化的应急诊断系统，通过AI技术大幅提升故障处理效率，有效减少平均故障修复时间（MTTR）。

在这种智能化模式下，AI自动捕捉消息，遇到告警信息时自动分析并给出结论。只有AI无法解决的疑难问题，才需要人工介入处理。

这种模式最大的优势在于：所有出现过的Case和已有文档都会沉淀为AI的记忆和知识库。从今往后，只有新增的Case需要人来解决，存量问题全部都会被AI有效拦截。换句话说，团队内多出了一个永远不会离开、且能同时接受所有方向培养的AI运维专家。

总结与展望

以上就是我们国际化广告团队在AI提效方面的实践分享。希望这篇文章能作为一个关键锚点，带动所有读到它的同学，重新审视所在团队的工作流程，共同建设更多高效的AI加持工作流。

其实AI的用法并不复杂——它就是我们的智能助手。假如日常工作中真的存在一些重复的、可替代的、可以节省的工作，不妨试着交给AI来处理。