“幫我在頁面上加一個‘附近門店’的功能。”

這是產(chǎn)品經(jīng)理最普通的一句需求。但對于接活的研發(fā)來說，接下來要面對的事情遠(yuǎn)比這句話復(fù)雜得多：數(shù)百個API，該用城市檢索還是周邊檢索？JSAPI和WebAPI選哪個？坐標(biāo)為什么偏了幾百米？

每個問題拆開都不算難。但連在一起，足夠讓一個熟練的開發(fā)者在文檔、控制臺和代碼編輯器之間來回拉扯上兩天。這是大量開發(fā)者在2026年面臨的真實處境：AI編程工具越來越強，但地圖功能像一道隱形的墻，精準(zhǔn)攔住了大模型的“知識盲區(qū)”。

在百度Create大會上，百度地圖開放平臺首發(fā)了地圖開發(fā)智能體——“脈芽”（MAPYA），要解決的正是這件事。它的邏輯很直白：AI時代，不需要先成為地圖專家才能解決地圖開發(fā)相關(guān)問題。

不用讀文檔，一句話拿到方案和代碼

脈芽的定位很清楚——它是百度地圖出品的對話式AI智能體，專門面向地圖開發(fā)者。區(qū)別于市面上通用的AI編程工具，它的底層接入了百度地圖官方維護的文檔知識體系和專業(yè)技能。也就是說，它給出的每一個答案、每一段示例代碼，依據(jù)的都是當(dāng)前最新、正在運行的接口規(guī)范，而不是訓(xùn)練數(shù)據(jù)里記下來的某個歷史版本。

這對開發(fā)者意味著兩件事。

第一，API選型不再靠“逐個翻閱對比”。開發(fā)者說一句“我想做附近搜索功能”，脈芽幾秒鐘給出明確推薦——Place API周邊檢索，配合定位SDK獲取用戶當(dāng)前位置，關(guān)鍵參數(shù)query、location、radius的含義和推薦值一并說清楚。而過去完成這件事，需要打開數(shù)百項API的目錄，在文檔之間反復(fù)跳轉(zhuǎn)，對比每個接口的適用場景。

第二，生成的代碼可以直接用。開發(fā)者要一個“地理編碼的Python調(diào)用示例”，脈芽給出的代碼片段包含接口地址、請求參數(shù)、返回值解析，參數(shù)準(zhǔn)確、坐標(biāo)系注意事項自動附帶。而用通用AI工具生成同樣一段代碼，參數(shù)名可能是舊版的，接口地址可能已廢棄，坐標(biāo)系轉(zhuǎn)換的處理時常被遺漏——結(jié)果要么報錯，要么返回的坐標(biāo)偏移幾百米。

地圖開發(fā)里的“雜活”，它一并接了過去

除了技術(shù)選型和代碼生成，脈芽還干了一件容易被忽略但實際很消耗時間的事：賬戶和平臺管理。

做過地圖開發(fā)的都知道，查AK列表、看API調(diào)用配額、確認(rèn)認(rèn)證狀態(tài)，這些操作本身沒有技術(shù)難度，但流程極其繁瑣——登錄官網(wǎng)控制臺，在AK管理、用量查詢、配額狀態(tài)、認(rèn)證信息幾個頁面之間來回切換，每查一項都要進不同的管理頁面。一次簡單的配額確認(rèn)，花10分鐘算是快的。

脈芽做的是把這些操作全部收進了對話里。開發(fā)者登錄授權(quán)之后，直接問“幫我看看我的AK列表”“本月消費量多少”“認(rèn)證狀態(tài)是什么”，答案全在對話框里返回。這背后接了23項控制臺管理能力，本質(zhì)上是用對話替代了控制臺里的多頁面跳轉(zhuǎn)。省下的不是“寫代碼的時間”，而是那些真正讓人煩躁的邊角料勞動。

從天級到分鐘級，差的不是速度，是工作方式

這些能力放在一起，產(chǎn)生的效果可以用一組數(shù)字來表達。

一個典型的地圖功能開發(fā)——比如做一個帶POI搜索、地圖嵌入和路線規(guī)劃的頁面——過去從翻文檔選接口、理解參數(shù)、處理坐標(biāo)系轉(zhuǎn)換，到聯(lián)調(diào)排錯最終上線，熟練開發(fā)者需要大概2個工作日。現(xiàn)在用脈芽確認(rèn)方案和代碼示例，再配合百度地圖CLI把能力接入本地AI編程環(huán)境，整體流程可以壓縮到2小時。

更小的場景變化更直觀。查一個API的參數(shù)含義，過去打開官網(wǎng)找到對應(yīng)文檔頁、閱讀理解、復(fù)制參數(shù)，10分鐘起步；現(xiàn)在對話里一句話問完，10秒拿到結(jié)果。新開發(fā)者首次接入百度地圖API，從注冊、認(rèn)證、創(chuàng)建應(yīng)用到獲取AK、跑通第一個接口，過去整套走下來要30到60分鐘；現(xiàn)在在脈芽里跟著引導(dǎo)走完全程，速度大幅提升。

這里面的本質(zhì)改變不是“變快了”，而是工作方式本身發(fā)生了位移。傳統(tǒng)的對接流程是“人理解文檔→人寫代碼→人調(diào)試”，脈芽把這套流程重構(gòu)成了“人說需求→AI給方案和代碼→人做確認(rèn)和精調(diào)”。開發(fā)者不再充當(dāng)“人工搜索引擎”和“參數(shù)搬運工”，他的時間可以被用在真正需要判斷的業(yè)務(wù)決策上。

地圖場景，不是通用聊天框能應(yīng)付的

一個容易被提出的問題是：這些能力，用通用AI聊天工具難道做不到嗎？

能做到一部分，但有兩個繞不過去的短板。

第一個是準(zhǔn)確性問題。通用大模型的地圖知識來自訓(xùn)練數(shù)據(jù)，它不知道哪個接口已經(jīng)被廢棄、哪個參數(shù)名在最新版本里改過，坐標(biāo)系處理更是一筆糊涂賬。這是“記憶力”問題，不是“智商”問題，靠更大的參數(shù)規(guī)模解決不了。

第二個是深度問題。地圖開發(fā)的場景差異極大——做商圈選址分析，需要調(diào)POI檢索加熱力圖加周邊設(shè)施統(tǒng)計；做旅游路線規(guī)劃，涉及多景點排序加交通方式選擇；做區(qū)域人口洞察，考驗的是平臺有沒有專屬的數(shù)據(jù)接口和知識庫。通用聊天框面對這些需求，能給的是泛化的回答，做不到“問人口洞察就調(diào)慧眼數(shù)據(jù)，問地圖可視化就調(diào)MapVGL渲染”。

脈芽的做法是給場景各配一套專屬知識和工具集：地圖開發(fā)、應(yīng)用生成、人口洞察、交通分析、地圖可視化、位置服務(wù)。問的是哪個領(lǐng)域的問題，就調(diào)用哪個領(lǐng)域的專業(yè)能力。這不是把一個通用模型變聰明的思路，而是把專業(yè)領(lǐng)域的知識體系結(jié)構(gòu)化、可調(diào)用的思路。

開發(fā)者的“最后一公里”，正在被拆掉

從更大的視角看，脈芽解決的問題其實不只是“地圖開發(fā)效率低”。它拆掉的是AI編程浪潮里的一道隱形門檻。

過去一年，AI編程工具讓越來越多人能用自然語言寫代碼。但到地圖功能這兒，這條曲線戛然而止。無論是什么編程工具，一碰到地圖相關(guān)的需求，出錯率明顯上升。原因很簡單：自然語言可以描述“我想要什么”，但描述不了“該用哪個接口”“這個參數(shù)在最新版本里改過了”——這些是“規(guī)則層”的知識，不在自然語言的表達范圍里，也不在通用模型的訓(xùn)練數(shù)據(jù)里。

脈芽做的事，是把這套規(guī)則層的能力用對話式智能體的方式開放出來。對入門開發(fā)者來說，不需要先搞懂?dāng)?shù)百個API的區(qū)別才能動手寫第一行代碼，問一句話就能起步。對有經(jīng)驗的開發(fā)者來說，不需要把時間花在翻文檔和比對參數(shù)上，快速出方案、快速落地。對正在構(gòu)建AI應(yīng)用的團隊來說，把地圖能力標(biāo)準(zhǔn)化、準(zhǔn)確的集成到自己的Agent里。

百度地圖開放平臺累計服務(wù)了超過400萬注冊開發(fā)者。這一次發(fā)布的“脈芽”，加上與之配合的百度地圖CLI和Docs-MCP文檔底座，本質(zhì)上是把整個平臺從“數(shù)據(jù)管道”重構(gòu)為“能力引擎”。它要回答的，是一個更長遠(yuǎn)的問題：當(dāng)AI越來越能寫代碼，基礎(chǔ)設(shè)施需要怎么變，才跟得上這個速度。

答案是——讓基礎(chǔ)設(shè)施本身學(xué)會用AI的語言說話。