背景
各类AI研发工具层出不穷，很多现成工具可使用，业界都在探索一套完整的AI加成的提效方案
团队内部规范文档完备，但是没有融入开发流程中
Code review、研发自测、接口文档更新消耗大量时间
目标
1. 拥抱AI时代，让团队更先进。
2. 用AI武装研发团队，通过资源的配合与协调，实现研发效率的提升。
思路
1. 拆分研发流程，并找到AI结合点，并将其串联起来。
2. 深度探索AI IDE，得出最佳实践。
3. 利用起团队的知识库，为AI提供辅助能力。
定位
1. 这是一个锚点，自此开始团队研发流程向AI化转变。
2. 这是一个开始，带动团队与其他同学review当前研发流程，共建更多研发工作流。
01
对研发链路进行拆解，得到不同阶段的AI工作流形态，并基于当前形态向下一形态进行推进。
当前我们团队正处于阶段1接近完成，阶段2正在开始探索实践的阶段，因此下面我们会基于我们团队在这些方面的实践进行分享。
原本研发链路：
AI加持研发流程：
对上面涉及到的AI工作流进行补充说明
AI-Cafes：AI生成需求文档，制作产品原型图，节省产品人天。
AI-Docs：需求文档转技术文档，节省研发梳理过程，节省研发人天。
AI-DocsCoding：基于技术文档，生成基础无业务逻辑代码，节省研发人天。
AI-Coding：基于团队内部代码规范生成代码，减少返工和代码理解成本，深度提高研发效率，节省研发人天。
AI-API：MCP%20Server%E6%89%93%E9%80%9A%E6%8E%A5%E5%8F%A3%E6%96%87%E6%A1%A3%EF%BC%8C%E9%81%BF%E5%85%8Dapi%E6%96%87%E6%A1%A3%2F%E6%8A%80%E6%9C%AF%E6%96%87%E6%A1%A3%E6%9B%B4%E6%96%B0%E4%B8%8D%E5%8F%8A%E6%97%B6%EF%BC%8C%E8%8A%82%E7%9C%81%E7%A0%94%E5%8F%91%E4%BA%BA%E5%A4%A9%E3%80%82">基于MCP Server打通接口文档，避免api文档/技术文档更新不及时，节省研发人天。
AI-CR：基于Rules，进行AI Code Review，节省研发人天。
AI-Develops：AI赋能测试、验证、监控环节，节省测试人天。
02
AI-CafeDocs
在原本的工作流中，在需求评审过后，研发同学通常需要至少0.5d的人力进行技术文档的落地，以及api接口的准备。
但是这一步中的大部分工作是重复的，可替代的，可节省的。
因此我们实现了了需求文档 -> aisuda（百度的低代码平台）-> 大模型 -> 技术文档（markdown）的工作流。
在微调好大模型之后，我们只需要以下两步就能完成技术文档+api接口准备的工作：
1. 投喂需求文档给大模型，得到初版技术文档。
2. 人工check技术文档。
在快速生成了技术文档后，后端再和前端进行沟通，根据细节进行修改具体实现。
AI-DocsCoding
在得到技术文档之后，我们下一步要做的则是落地。不得不承认，我们的工作中无可避免的会存在一些基础的CRUD环节，这是正常的，也是重复的，可替代的，可节省的。
因此，基于以上的 AI-CafeDocs环节，我们进行了进一步的延伸，实现了技术文档 -> MCP Server -> AI IDE 的工作流
我们通过MCP打通了内部的知识库，使得AI能够阅读到需求文档和技术文档，了解上下文，并进行对应的开发工作。
当然，AI全流程开发只是一种理想的状态，就当前而言，AI-DocsCoding写出来的代码并不是完全可用的，在涉及到的业务逻辑越复杂时，代码的正确性就越低。
但是不要紧，我们在设计这个流程的时候，就早有准备。
还记得我们强调的一点：让AI取代重复的，可替代的，可节省的工作，那么正确的流程为：
1. AI通过MCP阅读需求文档、技术文档，生成本次功能的基础代码——除却业务逻辑之外的参数处理、数据处理的CRUD代码。
2. 人工补全核心的业务逻辑处理，人也只需要关心真正的业务逻辑，这些事AI无法替代的。
可以看到，在以上的两个工作流里，人的角色从执行者，变成了驱动者/观察者，或者说产品经理。
我们通过向AI提出需求，监督AI工作，验收AI工作结果的方式进行工作。
03
AI-Coding
AI-Coding这一块主要围绕 AI IDE的使用，现在市面上有很多的产品，比如Cursor、Comate、Trae等。其实在许多人看来，AI IDE的核心在于底层能够接入的模型，但是我觉得这不尽然，大模型的边界效应很强。
有些时候，我们对AI IDE的使用，还没有达到需要区分模型效果的地步。或者说，如果我们使用了世界上最好的模型，那我们是否就高枕无忧了，可以让AI全程进行Coding而不需要人为Review了？
至少使用到今天为止，我们认为AI-Coding，还离不开人的关注，因此如何更好地使用AI进行Coding，是AI提效的必经之路。
合理使用Rule
在AI IDE内，Rule是一个非常重要的环节，它是连接开发者意图与 AI 代码生成行为之间的关键桥梁。
定义：Rule 的 核心目的是指导 AI 更准确地理解当前代码库的上下文、遵循特定的项目规范与编码标准、生成符合预期的代码，或辅助完成复杂的工作流程。Cursor 官方文档Agent%20%E6%A8%A1%E5%9E%8B%E8%A1%8C%E4%B8%BA%E7%9A%84%E5%8F%AF%E5%A4%8D%E7%94%A8%E3%80%81%E6%9C%89%E4%BD%9C%E7%94%A8%E5%9F%9F%E7%9A%84%E6%8C%87%E4%BB%A4%E2%80%9D%E3%80%82">将其描述为“控制 Agent 模型行为的可复用、有作用域的指令”。
作用：大型语言模型（LLMs）本身在多次交互之间通常不具备持久记忆。Rule 通过在每次 AI 请求的提示词（prompt）层面提供持久化、可复用的上下文信息，有效解决了这一问题。当一个规则被应用时，其内容会被包含在模型上下文的起始部分，从而为 AI 的代码生成、编辑解释或工作流辅助提供稳定且一致的指导。
上面有一个非常重要的点，那就是所有的rule在使用的过程中，都会占用我们上下文的token，因此如何更好的使用Rule，是提升AICoding能力的关键。
基于我们的实践，我们建议将 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占用权重 | 冲突处理 |
| Always规则 | 项目基础规范 | 最高，始终加载 | 覆盖所有低优先级 |
| Auto规则（核心） | 核心业务模块 | 高，匹配时加载 | 覆盖priority≤7 |
| Auto规则（辅助） | 辅助功能模块 | 中，匹配时加载 | 覆盖priority≤5 |
| Agent规则 | 智能优化建议 | 中，相关时加载 | 覆盖priority≤4 |
| Manual规则 | 模板参考 | 低，调用时加载 | 被高优先级覆盖 |
| 实验性规则 | 测试功能 | 最低 | 被所有规则覆盖 |
优先级使用策略：
1. 基础规范用10：项目必须遵循的核心规范
2. 核心模块用8-9：handler、service、repository等主要模块
3. 辅助模块用6-7：middleware、config、utils等辅助模块
4. 优化建议用5：性能优化、最佳实践等智能建议
5. 模板参考用3-4：代码模板、脚手架等参考资料
6. 实验功能用1-2：测试中的新规范，避免影响稳定功能
冲突解决机制：
当多个规则应用于同一文件时，高优先级规则会覆盖低优先级规则的冲突部分
相同优先级规则按文件名字母顺序加载
Always规则始终优先于所有其他类型规则
Rule 的核心价值在于它为开发者提供了一种机制，用以精细化控制 AI 在代码理解、生成、重构等环节的行为。
通过预设规则，开发者可以将项目规范、编码标准、技术选型乃至特定业务逻辑“教授”给 AI，从而显著提升 AI 辅助编程的效率、保证代码质量的均一性，并确保项目整体的规范性。
它使得 AI 从一个泛用的助手，转变为一个深度理解特定项目需求的“领域专家”。
记忆库
基于Rule的运用，我们通过memory bank + rule生成专属业务研发助手
在AICoding的使用中，有一种常见的痛点场景，就是在复杂的项目中，AI无法感知到整个项目的历史上下文，即便是有Codebase的存在，也对业务逻辑是一知半解。
在我们实践的过程中，引入了记忆库的模式，深化AI对项目的理解和记忆，使得每一次需求迭代的上下文都被记录下来。
生成了memorybank后，我们可以随时通过对话查看项目大纲和内容，并且每一次重新进入开发，不会丢失之前的记忆。
这种模式，其实就是Rules的一种应用，它把上下文总结在代码库的制定位置，强制AI在每次进入时会阅读上下文，回到上一次Coding的状态，对于解决上下文丢失的问题有非常大的帮助。
这里可能有人会问，记忆库和IDE本身的长期记忆功能有什么区别？
答：记忆库是公共的项目记忆库，IDE长期记忆是私人的IDE使用记忆。
而记忆库的详细内容，这里不作详细分享，它只是一份提示词，感兴趣的同学只要简单搜索一下就能找到很多的资源。
MCP Server（重点）
MCP（Model Context Protocol），模型上下文协议，由Anthropic于24年11月提出，旨在为大语言模型和外部数据源、工具、服务提供统一的通信框架，标准化AI与真实世界的交互方式
before MCP | with MCP |
 |  |
MCP的核心架构包括三环：
Host主机：用户与AI互动的应用环境，如Claude Desktop、Cursor；
Client客户端：充当LLM和MCP server之间的桥梁，将用户查询指令、可用工具列表、工具调用结果发给LLM，将LLM需要使用的工具通过server执行调用；
Server服务器：轻量级服务节点，给予AI访问特定资源、调用工具能力的权限；目前已有数据库类（如SQLite、supabase）、工具类（如飞书多维表格）、应用类（如高德地图）服务器。是MCP架构中最为关键的组件。
在开发中，我们可以接入以下几种MCPServer
1. 实时搜索，baidu/google/github/微博等
2. 存储，mysql/redis等
3. 工具，kubectl/yapi等
用法一：我们接入百度搜索的MCP
1. 搜索问题：在开发之余搜索一下 夜的命名术 是否完结。
2. 搜索知识点：在想知道Go1.24新特性时，通过MCP进行搜索，让AI进行总结。
3. 搜索用法：在想了解Linux的快捷命令时进行搜索。
以上这些场景，并非非MCP不可，非AI IDE不可，但是通过这样的方式，我们至少节省了切换到浏览器，搜索，自己总结结论，返回继续Coding这些步骤。
用法二：client里直接进行多client操作
1. Redis自然语言查询：
2. MySQL自然语言查询：
3. GCP自然语言查询：
其他的client（kubectl等）我就不一一列举了，但是可以看到，当我们在我们的IDE内集成了各种各样的client后，开发效率能极大地提升。
当然，这里有两个关键点：
1. 接入mcpserver并不需要我们研究，我们只要把mcp server的链接丢给AI，它自己就能开始接入
2. 禁止在开发环境使用线上client账号密码
AI-API
相信无论是前端还是后端开发，都或多或少地被接口文档折磨过。前端经常抱怨后端给的接口文档与实际情况不一致。后端又觉得编写及维护接口文档会耗费不少精力，经常来不及更新。
其实无论是前端调用后端，还是后端调用后端，都期望有一个好的接口文档。但是随着时间推移，版本迭代，接口文档往往很容易就跟不上代码了,更会出现之前的同学没有把接口文档交接清楚就离职，留下一个繁重复杂的项目，重新啃起来异常艰难，不亚于自己从头写一遍。
痛点
1. 重复劳动：每一个涉及到前后端的功能，研发都需要手动进行维护接口文档，在一些时候，接口最后和最开始的设定有可能大相径庭，每一次改动都是非常令人头疼的工作。
2. 低效沟通：前后端在沟通接口后，再进行对应的代码开发，其实是一件重复的，可替代的，可节省的工作。
为了解决这些痛点，通过引入 AI 自动化功能，搭建API MCP Server，帮我们解决这些冗杂的工作，让研发人力更多的集中在核心业务代码的开发上，提升代码开发效率、降低沟通成本。
这是我们一直畅想的场景，后端开发完代码 -> AI 推送接口文档 -> API文档自动更新 -> AI 拉取接口文档 -> 前端生成代码
也就是前后端的研发同学，只关注业务功能的实现，而不需要关注这些接口对接的繁琐工作。
Better Thinking
这是我想补充的两个使用AICoding的思想，也是我使用下来的一个感悟。
一：学会递归使用AI
场景：在IDE内布置MCP Server
通常的做法是：
1. 在MCP Server市场找到想用的MCP Server
2. 把配置部署好
3. 开始调试，完成后投入使用
递归式使用做法：
1. 在MCP Server市场找到想用的MCP Server
2. 把链接丢给AI，让它自己安装（递归）
3. 安装完后让它自己修改mcp.json的配置（递归）
4. 修改完成后让它自己调通（递归）
更进一步我们还可以：
1. @Web 让AI找一个可用的McpServer（递归）
2. ...（递归）
3. ...（递归）
4. ...（递归）
二：把AI当成一个真正的工具
场景：写某篇文档的时候，我突然想要做一个Gif格式的图片示例。
已知：电脑支持录屏，但是我缺少视频转Gif格式的工具。
麻烦点：
1. 如果通过百度/Google搜索网页在线工具，非常麻烦，还要付费。
2. 如果通过内部的视频裁剪服务，还需要起服务来处理。
3. 如果通过剪映这样的工具，那还要下载一个软件。
以上这些点，都不算困难，但都相对麻烦，属于能做但是又要浪费一点精力。
解决方案：
DeepSeek%E5%86%99%E6%B2%A1%E4%BB%80%E4%B9%88%E5%8C%BA%E5%88%AB%EF%BC%8C%E4%BD%86%E6%98%AF%E6%88%91%E4%BB%AC%E7%9A%84%E6%93%8D%E4%BD%9C%E6%AD%A5%E9%AA%A4%E5%BE%97%E5%88%B0%E4%BA%86%E4%BB%A5%E4%B8%8B%E7%AE%80%E5%8C%96%EF%BC%9A">理论上让AI写和让GPT/Deepseek写没什么区别，但是我们的操作步骤得到了以下简化：
也就是说，我们在遇到很多自己能做，但是又觉得麻烦，浪费精力的场景以及大部分的杂活，都可以第一时间Ask Ourself，Can AI Do it？
包括但不限于：
捞数据
写文档
找bug
...
AI-Coding VS Original-Coding
04
AI-CR
问题
1. 时间压力：团队每周可能需要审查数十个CR，高T同学需要审查的居多，每个 CR 的细节往往耗费大量时间。
2. 沟通低效：CR评论描述不清晰，开发者需要来回沟通确认修改点。
3. 重复劳动：相似的代码改动需要重复审查，难以专注关键问题。
为了解决这些痛点，通过引入 AI 自动化功能，提前规避一些基础问题，让CR人力更多的集中在关键问题上，提升代码审查效率、降低沟通成本。
解决方案
工作流
05
AI-Develops
随着业务系统的复杂度不断增加，运维过程中产生的告警数量急剧增长，传统的人工处理方式已经无法满足快速响应的需求。
目前在我们来看，现有的运维体系存在了以下的弊端：
1. 告警存在非常厚的方向壁垒，不同方向的同学遇到另一个方向的告警时大都只能进行Case路由。
2. 告警存在非常厚的年限壁垒，团队不同年限的同学遇到Case的应对时间有可能天差地别。
一个点是否足够痛，决定了我们是都要优化。
在我们团队内，有丰富的case处理文档和记录，也有着应对问题经验非常丰富的同学，但是在值班同学遇到告警轰炸的时候，同样会焦头烂额。
回顾起告警处理的过程，其实大部分都是重复的，可替代的，可节省的工作，它们是有方法论的，并非遇到之后就手足无措。因此我们构建一个智能化的应急诊断系统，通过AI技术提升故障处理效率，减少平均故障修复时间(MTTR)。
在这种模式下，AI可以自动捕捉消息，在遇到告警信息的时候自动分析给出结论，如果有AI无法解决的问题，才会轮到人工进行介入。
这种模式最大的优点在于：所有出现过的Case/已有的文档都会沉淀为AI的记忆和知识库，从今往后只会有新增的Case需要人来解决，存量全都会被AI拦截，换而言之，团队内多出了一个永远不会离开，且能够同时接受所有方向培养的AI运维人员。
06
以上就是我们百度国际化广告团队的AI提效实践，也希望这篇文章能作为一个锚点，带动所有看到这篇文章的同学review自己所在团队的工作流程，共建更多的AI加持工作流。
就如我上面说的，其实AI的用法很简单，它就是我们的助手，假如我们的工作中真的存在一些重复的，可替代的，可节省工作，那不妨把这些工作交给AI试试。
