AI在实际生成环境中的提效实践

AI时代，各类工具层出不穷，业界都在琢磨一套完整的AI提效方案。我们团队基于自身特色，把历史积累的知识库利用起来，落地了一套深度结合AI的工作流——用AI武装研发团队，实现效率的质变。

先说几个核心判断：各类AI研发工具很多，现成的不少；团队内部规范文档其实挺完备的，但一直游离在开发流程之外；Code review、研发自测、接口文档更新，这些环节吞噬了大量时间。

也很明确：拥抱AI，让团队更先进；用AI武装研发团队，通过资源配合与协调，实现研发效率的提升。

拆解下来就三步：拆分研发流程，找到AI结合点并串联起来；深度探索AI IDE，摸索出最佳实践；用活团队知识库，给AI提供辅助能力。

这件事，它是一个锚点——自此开始，团队研发流程向AI化转变。它也是一个开始，带动团队和同学重新审视当前研发流程，共建更多研发工作流。

研发链路

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

：需求→设计→编码→测试→发布→运维

：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接口。但这一步的大部分工作，说白了就是

的。

所以我们实现了这样一条工作流：

。

模型微调好之后，只需要两步就能完成技术文档+API接口准备：

1. 把需求文档投喂给大模型，拿到初版技术文档。
2. 人工check一遍。

技术文档快速生成后，后端再和前端沟通，根据细节修改具体实现。

AI-DocsCoding

拿到技术文档，下一步是落地。不得不承认，工作中难免有基础的CRUD环节——同样

。

基于AI-CafeDocs，我们做了延伸：

。

通过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，是提效的必经之路。

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

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

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

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

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

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

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

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

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

基于以上划分，再给出对

的代码库的Rule创建规则（以Go为例）：

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

• 避免：过于宽泛，比如"**/*.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的运用，我们通过

生成了专属业务研发助手。

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

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

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

这里可能有人会问：记忆库和IDE本身的长期记忆功能有什么区别？答：

。至于记忆库的详细内容，这里不展开，它本质上就是一份提示词——感兴趣的话简单搜索就能找到很多资源。

，由Anthropic于2024年11月提出，旨在为大语言模型和外部数据源、工具、服务提供统一的通信框架，。

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等。

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

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

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

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

当然，这里有两个关键点：

1. 接入MCP Server不需要我们研究——

   只要把MCP Server的链接丢给AI
   ，它自己就能开始接入。

2. 禁止在开发环境使用线上client账号密码。

AI-API

相信无论是前端还是后端开发，都或多或少被接口文档折磨过。前端经常抱怨后端给的接口文档跟实际情况不一致，后端又觉得编写及维护接口文档耗费精力，经常来不及更新。

无论是前端调后端，还是后端调后端，都期望有个好接口文档。但随时间推移、版本迭代，接口文档很容易跟不上代码，更会出现同学没交接清楚就离职的情况——留下繁重复杂的项目，重新啃起来异常艰难。

1. 重复劳动
   ：每个涉及前后端的功能，研发都要手动维护接口文档。有时候接口最终和最初的设定大相径庭，每次改动都令人头疼。

2. 低效沟通
   ：前后端沟通接口后，再进行对应代码开发——还是

   重复、可替代、可节省
   的工作。

为了解决这些痛点，通过引入AI自动化功能，搭建

，帮我们解决这些冗杂工作，，提升效率、降低沟通成本。

这是我们一直畅想的场景：

。前后端的研发同学只关注业务功能实现，不需要操心接口对接的繁琐工作。

Better Thinking

这里补充两个使用AI Coding的思想，也是实践下来的感悟。

场景：在IDE内布置MCP Server。

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

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

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

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

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

麻烦点：用网页在线工具需要搜索，还可能要付费；用内部视频裁剪服务要起服务；用剪映等工具要下载软件。都能做，但都相对麻烦——

。

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

理论上让AI写和让GPT/DeepSeek写没什么区别，但操作步骤得到了极大简化。也就是说，遇到很多

，以及，都可以第一时间问自己：Can AI Do It？

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

集成阶段

AI-CR

1. 时间压力
   ：团队每周可能需要审查数十个CR，高T同学需要审查的居多，每个CR细节耗费大量时间。

2. 沟通低效
   ：CR评论描述不清晰，开发者需要来回沟通确认修改点。

3. 重复劳动
   ：相似的代码改动重复审查，难以专注关键问题。

通过引入AI自动化功能，提前规避基础问题，

，提升审查效率、降低沟通成本。

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

运维阶段

AI-Develops

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

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

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

回顾告警处理过程，大部分其实都是

的工作——它们有方法论，并非遇到就手足无措。因此我们构建了智能化的应急诊断系统，通过AI技术提升故障处理效率，减少平均故障修复时间（MTTR）。

这种模式最大的优点：所有出现过的Case和已有文档都会沉淀为AI的记忆和知识库。从今往后，只有新增的Case需要人来解决，存量全都会被AI拦截。换而言之，

。

总结

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

其实AI的用法很简单——它就是我们的助手。假如工作中真的存在一些

的工作，不妨试试交给AI。