MinIO API文檔快速入門
當前我們團隊正處于階段 1 接近完成，階段 2 正在開始探索實踐的階段，因此下面我們會基于我們團隊在這些方面的實踐進行分享。
原本研發鏈路：
AI 加持研發流程：
對上面涉及到的 AI 工作流進行補充說明
AI-Cafes：AI 生成需求文檔，制作產品原型圖，節省產品人天。
AI-Docs：需求文檔轉技術文檔，節省研發梳理過程，節省研發人天。
AI-DocsCoding：基于技術文檔，生成基礎無業務邏輯代碼，節省研發人天。
AI-Coding：基于團隊內部代碼規范生成代碼，減少返工和代碼理解成本，深度提高研發效率，節省研發人天。
AI-API：基于 MCP Server 打通接口文檔，避免 api 文檔 / 技術文檔更新不及時，節省研發人天。
AI-CR：基于 Rules，進行 AI Code Review，節省研發人天。
AI-Develops：AI 賦能測試、驗證、監控環節，節省測試人天。
AI-CafeDocs
在原本的工作流中，在需求評審過后，研發同學通常需要至少 0.5d 的人力進行技術文檔的落地，以及 api 接口的準備。
但是這一步中的大部分工作是重復的，可替代的，可節省的。
因此我們實現了了__需求文檔 -> aisuda（百度的低代碼平臺）-> 大模型 -> 技術文檔（markdown）__的工作流。
在微調好大模型之后，我們只需要以下兩步就能完成技術文檔 + api 接口準備的工作：
1. 投喂需求文檔給大模型，得到初版技術文檔。
2. 人工 check 技術文檔。
在快速生成了技術文檔后，后端再和前端進行溝通，根據細節進行修改具體實現。
在得到技術文檔之后，我們下一步要做的則是落地。不得不承認，我們的工作中無可避免的會存在一些基礎的 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 IDE 的使用，現在市面上有很多的產品，比如 Cursor、Comate、Trae 等。其實在許多人看來，AI IDE 的核心在于底層能夠接入的模型，但是我覺得這不盡然，大模型的邊界效應很強。
有些時候，我們對 AI IDE 的使用，還沒有達到需要區分模型效果的地步。或者說，如果我們使用了世界上最好的模型，那我們是否就高枕無憂了，可以讓 AI 全程進行 Coding 而不需要人為 Review 了？
至少使用到今天為止，我們認為 AI-Coding，還離不開人的關注，因此如何更好地使用 AI 進行 Coding，是 AI 提效的必經之路。
在 AI IDE 內，Rule 是一個非常重要的環節，它是連接開發者意圖與 AI 代碼生成行為之間的關鍵橋梁。
定義：Rule 的 核心目的是指導 AI 更準確地理解當前代碼庫的上下文、遵循特定的項目規范與編碼標準、生成符合預期的代碼，或輔助完成復雜的工作流程。Cursor 官方文檔將其描述為 “控制 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，數值越高優先級越高
優先級使用策略：
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（Model Context Protocol），模型上下文協議，由 Anthropic 于 24 年 11 月提出，旨在為大語言模型和外部數據源、工具、服務提供統一的通信框架，標準化 AI 與真實世界的交互方式
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 賬號密碼
相信無論是前端還是后端開發，都或多或少地被接口文檔折磨過。前端經常抱怨后端給的接口文檔與實際情況不一致。后端又覺得編寫及維護接口文檔會耗費不少精力，經常來不及更新。
其實無論是前端調用后端，還是后端調用后端，都期望有一個好的接口文檔。但是隨著時間推移，版本迭代，接口文檔往往很容易就跟不上代碼了，更會出現之前的同學沒有把接口文檔交接清楚就離職，留下一個繁重復雜的項目，重新啃起來異常艱難，不亞于自己從頭寫一遍。
1. 重復勞動：每一個涉及到前后端的功能，研發都需要手動進行維護接口文檔，在一些時候，接口最后和最開始的設定有可能大相徑庭，每一次改動都是非常令人頭疼的工作。
2. 低效溝通：前后端在溝通接口后，再進行對應的代碼開發，其實是一件重復的，可替代的，可節省的工作。
為了解決這些痛點，通過引入 AI 自動化功能，搭建 API MCP Server，幫我們解決這些冗雜的工作，讓研發人力更多的集中在核心業務代碼的開發上，提升代碼開發效率、降低溝通成本。
這是我們一直暢想的場景，后端開發完代碼 -> AI 推送接口文檔 -> API 文檔自動更新 -> AI 拉取接口文檔 -> 前端生成代碼
也就是前后端的研發同學，只關注業務功能的實現，而不需要關注這些接口對接的繁瑣工作。
這是我想補充的兩個使用 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. 如果通過剪映這樣的工具，那還要下載一個軟件。
以上這些點，都不算困難，但都相對麻煩，屬于能做但是又要浪費一點精力。
解決方案：
理論上讓 AI 寫和讓 GPT/Deepseek 寫沒什么區別，但是我們的操作步驟得到了以下簡化：
也就是說，我們在遇到很多 ** 自己能做，但是又覺得麻煩，浪費精力的場景以及大部分的雜活 **，都可以第一時間 Ask Ourself，Can AI Do it？
包括但不限于：
撈數據
寫文檔
找 bug
…
AI-Coding VS Original-Coding
1. 時間壓力：團隊每周可能需要審查數十個 CR，高 T 同學需要審查的居多，每個 CR 的細節往往耗費大量時間。
2. 溝通低效：CR 評論描述不清晰，開發者需要來回溝通確認修改點。
3. 重復勞動：相似的代碼改動需要重復審查，難以專注關鍵問題。
為了解決這些痛點，通過引入 AI 自動化功能，提前規避一些基礎問題，讓 CR 人力更多的集中在關鍵問題上，提升代碼審查效率、降低溝通成本。
工作流
隨著業務系統的復雜度不斷增加，運維過程中產生的告警數量急劇增長，傳統的人工處理方式已經無法滿足快速響應的需求。
目前在我們來看，現有的運維體系存在了以下的弊端：
1. 告警存在非常厚的方向壁壘，不同方向的同學遇到另一個方向的告警時大都只能進行 Case 路由。
2. 告警存在非常厚的年限壁壘，團隊不同年限的同學遇到 Case 的應對時間有可能天差地別。
一個點是否足夠痛，決定了我們是都要優化。
在我們團隊內，有豐富的 case 處理文檔和記錄，也有著應對問題經驗非常豐富的同學，但是在值班同學遇到告警轟炸的時候，同樣會焦頭爛額。
回顧起告警處理的過程，其實大部分都是重復的，可替代的，可節省的工作，它們是有方法論的，并非遇到之后就手足無措。因此我們構建一個智能化的應急診斷系統，通過 AI 技術提升故障處理效率，減少平均故障修復時間 (MTTR)。
在這種模式下，AI 可以自動捕捉消息，在遇到告警信息的時候自動分析給出結論，如果有 AI 無法解決的問題，才會輪到人工進行介入。
這種模式最大的優點在于：所有出現過的 Case / 已有的文檔都會沉淀為 AI 的記憶和知識庫，從今往后只會有新增的 Case 需要人來解決，存量全都會被 AI 攔截，換而言之，團隊內多出了一個永遠不會離開，且能夠同時接受所有方向培養的 AI 運維人員。
以上就是我們百度國際化廣告團隊的 AI 提效實踐，也希望這篇文章能作為一個錨點，帶動所有看到這篇文章的同學 review 自己所在團隊的工作流程，共建更多的 AI 加持工作流。
就如我上面說的，其實 AI 的用法很簡單，它就是我們的助手，假如我們的工作中真的存在一些重復的，可替代的，可節省工作，那不妨把這些工作交給 AI 試試。
原文引自：https://my.oschina.net/u/4939618/blog/18687336
