作者 | AICon 全球人工智能開發與應用大會

策劃 | 燕珊

編輯 | 宇琪

隨著 Agent 的普及，技術的復雜性越來越被模型封裝，業務層的工作量和難度都在下降。再加上 AI 編程的提效，工程師不再炙手可熱，反倒成為被優先優化的對象。那么，產研人如何適應？是否要向業務轉型？

近日 InfoQ《極客有約》X AICon 直播欄目特別邀請了AI 師傅創始人 CEO 孫志崗擔任主持人，和ThinkAny & MCP.so 創始人艾逗筆（idoubi）、Agently.tech 創始人莫欣、AI 師傅聯合創始人 / 首席產品官何少甫一起，在AICon全球人工智能開發與應用大會2025 北京站即將召開之際，共同探討 AI 產品開發的那些事兒。

部分精彩觀點如下：

• 做產品固然重要，但除了產品本身，還需要具備前瞻性，同時要重視推廣和 SEO，不能只埋頭開發。

• 很多產品經理設想通過“氛圍編程”或借助 AI 編程工具，就能獨立開發一套系統，但現實并不那么理想。

• AI 編程目前最大的短板在于缺乏架構思維。

• 融資環境不確定的當下，更應該關注的是如何通過產品本身實現收入持續化。

在 6 月 27-28 日將于北京舉辦的AICon 全球人工智能開發與應用大會上，我們特別設置了 【AI 變革下的工程師】 專題。該專題將圍繞產品經理、前后端工程師等產研人的個人發展，探討如何抓住挑戰背后的機遇。查看大會日程解鎖更多精彩內容：

https://aicon.infoq.cn/2025/beijing/schedule

以下內容基于直播速記整理，經 InfoQ 刪減。

完整直播回放可查看：

https://www.infoq.cn/video/9AKrwxwTaE6jFdK20zxa

從“做了什么”聊起

孫志崗：請三位先各講一個你最有代表性的 AI 項目，成的、敗的都行。你當時怎么選這個方向？做的過程中碰到什么坑？最后學到了什么？

idoubi：那應該是我最近在做的 MCP.so，就我自己來看，它可能是目前全球排名第一的 MCP 導航平臺。這個“第一”體現在幾個方面，首先是收錄數量，在相當長一段時間內，我們平臺收錄的 MCP 服務器數量是最多的。其次，在搜索引擎中檢索 MCP 相關關鍵詞，我們的導航站也是排名最前的。此外，從功能覆蓋上看，我們不僅提供導航服務，還有在線聊天、云部署、在線試用等一系列功能，遠超一般的導航站。因此，這也是我迄今為止最具知名度和流量的項目。上個月網站訪問量超過了 270 萬，整體流量持續成倍增長。它還出現在多個出海產品榜單上，是我今年全力投入的重點項目。

至于為何做這個項目，其實是一個“無心插柳”的過程。去年 11 月下旬 MCP 協議發布，在國內一度引發熱議，雖然熱度持續時間不長，但引起了不少自媒體的關注，大家普遍認為它將帶來 AI 領域的重大變革。與以往某些“爆款”AI 產品或模型不同，MCP 是一套協議，其意義類似于 Web 時代的 HTTP 協議，它更像是基礎設施的更新。我之所以看好它，是因為深入理解了協議設計的細節，并結合我們在開發 AI 應用時的諸多痛點，認為 MCP 有潛力提升開發效率，推動整個 AI 應用生態的發展。

于是我開始與朋友探討如何切入 MCP 的生態。最初，我做了兩件事：第一，我搭建了一個導航網站，自動收錄全球開發者提交的 MCP 服務器，并進行數據整理和推薦，幫助用戶高效找到優質服務器；第二，我嘗試開發一個類 ChatGPT 的對話客戶端——Chat MCP。這個項目從去年 12 月開始動手，但由于當時生態還不成熟，熱度下降后便暫時擱置。不過 MCP.so 這個導航站我一直在維護，并不斷做 SEO 優化。

今年 3 月，隨著 Manus 等產品的發布，MCP 熱度迅速上升，大家猜測這些產品是基于 MCP 協議開發的。由此帶動 MCP 被更多廠商接入，生態開始快速發展。我在去年底就預測 MCP 會遇到所謂的“雞蛋悖論”——如果沒有一端先啟動（平臺或應用），協議難以落地。但后來一些明星應用和大廠服務接入打破了這個僵局，推動 MCP 快速成長。

隨著這個悖論被打破，MCP 的搜索熱度在 3、4 月持續走高。我也決定將全部精力投入 MCP 生態的建設。我認為導航站只是表層入口，MCP 是近年來 AI 發展中首次出現的平臺級機會，它具備連接上下游的能力。我希望圍繞這個協議生態，拓展更多方向，比如云部署、服務平臺、路由平臺、客戶端連接等，為生態建設做出更深層次的嘗試。

孫志崗：我這才剛知道，原來你很早就開始做 MCP.so 了。我之前還以為是它火起來之后，你花兩天時間快速搭建的。

idoubi：其實確實是花了不到兩天就做出了原型，畢竟只是一個功能相對簡單的導航站，而且代碼是開源的。但真正關鍵的是前期的積累，尤其是 SEO 的布局是需要時間的。

孫志崗：那你當時怎么判斷它會火呢？

idoubi：并沒有明確判斷。這類協議的成功很依賴生態的發展和行業內的共識建立，而共識是否能夠建立，以及何時建立，都是不可控的。它需要一個契機，比如一個明星產品的帶動。3 月份 MCP 能火，很大程度上是因為 Manus 這個應用的爆紅起到了推動作用。

孫志崗：從你的分享里我學到一個重要的點：做產品固然重要，但除了產品本身，還需要具備前瞻性，同時要重視推廣和 SEO，不能只埋頭開發。

莫欣：我們當前的核心項目是AgentlyAI 應用開發框架（官方網站：https://Agently.tech），其起點源于 2023 年初的一次探索。當時，大多數人還停留在使用 ChatGPT 或簡單接入 GPT 的“套殼”產品，我們嘗試構建更復雜的交互方式，比如通過思維導圖管理發散型對話，從而暴露出模型與應用之間的工程性鴻溝：模型沒有記憶能力，多輪對話依賴工程手段維持上下文；用戶提問能力有限，系統需要主動引導；而模型輸出若缺乏結構化，也無法被業務系統直接調用。

這些問題在當時缺乏現成解決方案，市面上的 LangChain 等工具支持有限、易用性差。因此我們動念將反復在工程中解決的共性問題抽象成一個框架，專注于模型的輸出控制與流程編排，幫助開發者以更高效、穩定的方式將 AI 嵌入真實業務。兩年打磨后，我們認為，AI 應用落地并非僅靠模型和數據，還必須有一套完整的控制系統，將自然語言意圖轉化為工程可執行的結構化指令，使 AI 真正具備產品能力。

在此基礎上，我們進一步探索了商業路徑。目前嘗試通過培訓服務幫助開發者理解并高效使用框架，通過咨詢服務協助企業將 AI 能力集成進既有系統，并正在開發一套平臺化產品，支持按規范構建模塊化 AI 功能，系統可自動封裝為 API 接口，打通從基于模型能力開發服務模塊到線上系統可用的“最后一公里”。我們的目標，是讓 AI 能力不再停留在 Demo 層面，而真正進入可控、可用、可集成的應用階段。

何少甫：我最想分享的代表性項目，是“AI 師傅”。在這個產品中，每位用戶與 AI 師傅互動時，例如學習編程，AI 會根據用戶的背景給予定制化的回答。例如，用戶可能來自產品、銷售或非互聯網行業，系統會結合這些背景提供相應的教學內容。

當然，這種能力與 ChatGPT、豆包等聊天機器人是有區別的。我們并不是單純依賴開放式問答，而是在背后由人設計和編排了一整套內容體系。雖然用戶的互動是主動的，但整體的教學脈絡和知識結構由“老師”來把控，因此更系統、更有引導性。

如果回到今天的主題，其實我有一個很深的體會，可以等會兒詳細聊：很多產品經理設想通過“氛圍編程”或借助 AI 編程工具，就能獨立開發一套系統，但現實并不那么理想。

觀眾提問：現在有大量的從業者開始轉行做獨立開發者或出海，如何看待這個趨勢？

何少甫：我原先做的產品是面向獨立開發者的低代碼平臺，同時也結合了 AI 編程的能力，開發者在平臺上不僅編程，還能完成上線發布和運維等全流程操作。獨立開發者的趨勢的確存在，包括前段時間爆火的“貓咪補光燈”，都是獨立開發者的產品。但要做出既成功又具備可持續商業模式的產品，并帶來穩定營收，難度很大。

孫志崗：現在越來越多大廠員工準備轉型做獨立開發者，這種趨勢在你那里明顯嗎？

何少甫：坦白講，我之前所在的大廠并沒有特別明顯的離職潮。在我之前大廠的客戶群里，獨立開發者非常多，感受更為強烈。

孫志崗：為什么選擇做獨立開發者？

idoubi：我認為有兩方面原因：一方面是時代趨勢，AI 發展熱度堪比移動互聯網初期，見證過那場浪潮的人，都想抓住這次機遇。另一方面是經濟形勢——全球經濟不佳，大廠裁員常態化，很多人在為“退路”做準備：一方面保住現有工作，另一方面學習 AI 模型、工具和全棧開發技能，以備不時之需。

真正“裸辭”投入獨立開發的人并不多，大多數人選擇一邊上班、一邊通過副業試水：學習 AI 編程、出海產品運營等。如果副業收入穩定且可觀，才會考慮辭職。有不少人已經實現了副業收入超過主業的情況，但這畢竟是少數，大多數人仍處于“觀望＋學習”階段。

AI 項目落地的真痛點

孫志崗：AI 項目落地過程中會遇到哪些痛點？少甫老師從產品經理的角度來談談，利用氛圍編程做一個 AI 的產品，有怎樣的感受？

何少甫：在“AI 師傅”項目中，我們嘗試了兩種模式。第一種是直接在主代碼分支里進行氛圍編程，我描述需求后，AI 自動生成代碼并提交 PR。然而，AI 生成的代碼，自動檢測工具會檢測出了大量問題。修復過程中，我們發現 AI 很難復用已有的抽象，常常出現重復代碼或者修改不達預期位置的情況，最終還是需要查看并理解生成的代碼。第二種模式是基于以組件級的代碼進行協作，我先用自然語言在 V0 上定義新組件，如登錄頁。產出獨立組件后，我將在線預覽鏈接分享給前端同事，基于他們反饋在需求限制里加入接口調用和組件拆分等細節后，AI 最終生成了可用性比較高的代碼。這種模式下，我既不需要直接更改主代碼庫，也能快速確認 UI 效果并減少設計溝通時間，前端同事只需下載最終代碼，大幅提高協作效率，節省了大約三分之二的開發工作量。

孫志崗：莫欣老師，從你的角度，代碼質量和架構治理怎么保住？AI 寫出來的代碼是不是很難維護？

莫欣：當我們面對一個完整的項目去構建頁面或實現大功能時，可能會發現生成結果的可用性并不高，工程師接受度也有限。但如果把它抽象為一個獨立的主鍵，拆出來單獨處理，反而更容易推進。我們在討論中將這類情形定義為“白紙型項目”，即從零開始構建的項目，與基于現有架構繼續開發的項目不同。兩者在生成結果的質量上存在明顯差異。“白紙型項目”沒有歷史負擔，比如不受限于特定技術棧或語法規則。

產品經理更關注的是界面是否美觀、交互是否符合用戶流程等。而 AI 能幫助產品經理更清晰地表達需求，與研發溝通時直接展示界面和代碼原型，顯著降低了溝通成本。這是一項真實存在的收益，我們是認可的。但如果要構建底層框架級別的功能，情況就不同了。比如我曾嘗試開發一個復雜數據結構處理模塊，這也是一個“白紙型”任務，但效果并不好。因為對這個模塊的要求非常細，比如數據校驗、路徑識別、繼承機制、嵌套和遞歸等。在僅提供需求描述的情況下，生成的結果往往無法滿足要求。

后來我們嘗試了“測試用例驅動”的方法：不直接讓 AI 寫代碼，而是先生成測試用例。通過測試用例表達需求，再去編寫代碼，成功率顯著提高。當然，這種方式也有邊界。即使使用能力較強的 Claude 3.5，在處理遞歸邏輯時也會遇到問題。因此，目前仍然存在一定的局限性。

總的來說，AI 編程更適用于實現簡單業務邏輯和沒有沒有歷史包袱的“白紙型項目”，這在一些出海項目中表現得尤為明顯。比如現在有不少從產品運營轉型的獨立開發者，其中一些甚至完全沒有編程經驗，也能通過 AI 開發出完整的小程序。這類項目通常前端占比高，強調交互，后端相對輕量，非常適合用 AI 編程生成高質量結果。

孫志崗：idoubi 老師，你一人干到底的經驗多，你覺得“多角色協作”現在需要重構嗎？

idoubi：我每天都會使用 AI 編程，但它并不是我工作的主要方式，大部分代碼還是由我自己編寫。AI 編程的價值在于，它降低了編程的門檻，使很多原本沒有經驗的人也能上手做項目。但對于已經有幾年經驗、做過多個項目的開發者來說，仍會傾向于自己動手。

一方面是因為 AI 目前還不具備完整的架構設計能力。比如做一個簡單的 landing 頁面或登錄表單，確實可以通過一句話指令讓工具如 Bot、Vercel、Webflow 等自動生成并上線，但如果是一個生產級別的項目，比如我們自己的 Bot.6 項目，僅靠 AI 是無法完成的。另一方面，架構設計不僅僅涉及前端交互，還包括后端邏輯。AI 可能能幫你生成一個 HTML 文件，但要讓用戶能夠預覽這個內容，可能需要引入集群、容器、K8s 等更復雜的基礎設施。這些都超出了 AI 編程目前的能力范圍。

對我而言，AI 更像是一個參考工具。有時我已經有了思路，但不確定怎么實現，就會告訴它我的想法，讓它給出一份實現方案，我再在此基礎上調整完善。有時我也會把它當作“技術合伙人”來交流方案。前提是我和它都具備一定的技術背景，能理解彼此的語言。在這種情況下，它確實能幫我解答疑問。但對于編程經驗較少的人來說，往往很難精確描述問題，而這直接影響 AI 的輸出質量。

所以從行業角度看，AI 編程是一件好事，它加速了創意的實現。但關于“AI 會不會取代程序員”這個話題，我認為取代專業程序員仍然非常困難。生產級項目依然需要經驗豐富的人來進行架構設計、代碼審查和單元測試。AI 更適合作為輔助工具，幫助開發者減輕部分工作負擔。

孫志崗：你這么快地做產品，是不是有工具組合拳的秘密？

idoubi：如果每一行代碼都手動敲，即使打字再快，很多項目在工程時長上也難以大幅縮短。所謂“做得快”，其實本質是熟能生巧——因為做得多，所以知道怎么做，常用的功能也早就實現過，自然能快速搭建起來。

比如我曾做過的一個項目——星巴克的 AI 紅包封面工具。那是前年春節前幾天上線的，當時流量還挺大。我用一小時完成了整個項目，現在如果再做類似項目，可能半小時就能搞定。這并不是因為我打字快，也不是因為我比別人更會用 AI。

真正讓我提速的有兩個關鍵原因：第一，我做過很多類似項目，有大量可復用的組件。比如我一開始就能預判項目需要登錄、支付、表單、landing 配置等功能，而這些我都有現成的框架和模板，稍加修改就能直接上線。第二，我的很多模板已經在 GitHub 上開源，絕大部分新項目和我以往做過的功能相似，僅需調整一兩個業務邏輯即可。登錄、支付、表單、多語言等基礎功能我都能快速復用，這才是我項目推進效率高的核心原因。

莫欣：AI 編程目前最大的短板在于缺乏架構思維。在 idoubi 老師開發應用的過程中，首先考慮的不是代碼如何實現，而是要解決的問題該用哪些模塊、如何搭建整體結構，這種架構思維正是他能高效完成項目的關鍵所在。

idoubi：舉個例子，今年 2 月我做了一個名為「Copy Web」的項目，用戶只需輸入一個網址，它就可以復刻該網頁并上線。這個項目其實是一個垂直場景下的網頁復刻工具，邏輯上類似于 bot.6 的輕量版。

項目開發時，我很快就明確了架構：第一步獲取網址，第二步截圖，第三步用視覺模型復刻頁面，第四步生成代碼后通過 iframe 展示。整個流程十幾分鐘內就規劃清楚了。之后只需逐一實現這些模塊并串聯起來，其它如登錄、支付、注冊等功能，我直接復用已有組件。實際開發中，我只需要編寫復刻網頁的主流程，效率自然就非常高。

觀眾提問：有制造業應用落地案例分享嗎？

莫欣：分享一些典型的場景需求：

第一個是操作手冊輔助查詢。在制造業中，有許多技術工種的工人，尤其是在需要跨多個機型進行操作或維修的崗位上，他們必須熟悉大量復雜的設備信息。例如同一組維修人員可能需要服務多個品牌和型號的熱水器，這時，對操作手冊的高效檢索就非常關鍵。理想的解決方案類似于一個知識庫檢索系統，甚至可以理解為技術工人的“Copilot”，能夠快速查找設備功能、操作步驟等，提升工作效率。

第二個是自動化產線工程指令代碼輔助生成。隨著制造業的自動化推進，產線上的一些控制邏輯越來越依賴于代碼。但這些代碼使用的語言不同于 Vibe Coding 常見使用的比如 Python、Go 之類的編程語言，而往往基于匯編或企業自研的指令型語言，在這類場景下的工程指令代碼但仍有較強的 AI 應用空間。例如：根據輸入參數自動生成生產或設計方案、自動調整設備運行邏輯等。這種類型的需求在一些自動化較高的工廠中較為常見。

觀眾：Dify 是否可以與 MCP 對接，并能否調用 API？

孫志崗：目前，Dify 官方尚未對 MCP 提供原生支持，因為它有自己的插件機制和工具市場。不過，從技術實現角度來看，對接 MCP 并不困難，可以通過自定義插件完成。

idoubi：Dify 支持將工作流一鍵導出為 API，并且可以將其以 MCP 的形式暴露給其他系統調用，但目前應該還不支持反向接入已有的 MCP，也就是說它可以作為 MCP Server，而非 MCP Client。

莫欣：開發一個 MCP Client 并不復雜。如果希望在 Dify 中調用已有的 MCP 工具，可以構建一個 MCP Client，負責向 MCP Server 請求相關工具功能，并將其封裝為 API，再將該 API 接入到 Dify 中即可。

孫志崗：idoubi 老師，你產品多、速度快，那你覺得上線的最大障礙是技術還是商業模式？

idoubi：過去幾年，我做了很多項目，這在外人看來可能是高產和成功的象征，但實際上給我帶來了不少焦慮和困擾。由于項目太多，導致精力分散，缺乏專注，進而影響了深度和長期價值的積累。

我涉足了各類 AI 應用，包括搜索引擎、播客、試衣、音樂播放器、壁紙等多個方向。雖然不少項目初期流量可觀，比如去年的 AI 搜索工具，一度在全球擁有幾十萬訪問量，但隨著大廠入局，競爭迅速加劇，個人項目逐漸失去優勢，最終熱度下降、流量流失，項目也逐漸淡出。我一度陷入迷茫，懷疑自己是否應該堅持做一件事情，堅持一年或更久是否就一定有結果。但現實是，即使長期投入，也可能敵不過資源和團隊都更強的大公司。

當前的 MCP 項目月訪問量已達一兩百萬，持續增長中，但我每天依然很焦慮，擔心它會重演之前項目的命運，被后來者或大廠快速超越。我開始思考如何把握當前的領先優勢實現商業化，比如做增長、融資或考慮被收購等方向。

孫志崗：莫欣老師呢？

莫欣：我認為我們的創業經歷大致可以分成兩個階段。

第一階段是最初做開發者市場時面臨的最大挑戰：持續性營收來源不明確。一開始，收入模式極為不穩定，比如有時有人請我們做一次分享或培訓，會支付一些咨詢費，但無法預測下個月是否還有收入。雖然我們后來簽了一些更長期的培訓協議，但依然缺乏對未來營收可持續性的信心。即使流量高、熱度在，也很難確立穩定的商業基礎。那時我們也考慮過是否要融資來推進項目，或者繼續探索自我造血的方式。隨著對市場的進一步理解，我們逐漸明確，融資環境不確定的當下，更應該關注的是如何通過產品本身實現收入持續化。

今年是一個轉折點，市場變得活躍，越來越多的人關注如何將 AI 能力與原有工程經驗結合。我們開始嘗試與企業建立更長期的合作關系，比如簽訂框架協議、通過 API 提供訂閱服務等，終于看到了一些“轉起來”的營收跡象。盡管還未完全穩定，但已經跨過了“最黑暗的時刻”。

然而隨之而來的就是第二階段的挑戰：精力分配和團隊能力不足。一方面，我們不僅僅在做工具，而是在幫助開發者構建 AI 能力的認知體系——他們不僅要會用工具，還得明白如何在實際開發中結合 AI 做出真正有價值的產品。我們需要輸出大量內容、優化框架體驗、做平臺化服務等，事務繁雜但人員有限。此外，整個行業還面臨一個共性問題：懂 AI 應用落地的工程師太少。雖然市面上懂 AI 產品的人不少，但能將 AI 真正集成到工程體系中的開發者仍很稀缺。我們希望能夠吸引更多真正動手做開發落地的工程師、開發者加入到我們的行列中來。

何少甫：從產品的角度來看，尤其是在 AI 時代到來、大模型興起之后，大家一直在探討產品應該做什么。我們目前正在做 AI 應用，但 AI 應用的真正價值在哪里？它是否真的能借助 AI 的能力，不斷提升產品質量？它的邊界又在哪里？

比如近期的一個新話題——“模型級產品”。過去我們需要為產品編排工作流，理解業務場景，構建邏輯。但現在的模型級產品，模型本身就能完成這些任務，甚至于在模型里能主動調用搜索引擎。

目前存在兩種觀點的碰撞：一種是由 AI 全權制定工作流，另一種是由人來主導。我們現在仍認為人是非常重要的因素，但這個“人”的角色應該發揮到什么程度，目前很難下定論。可以說，在 AGI 時代，人類的核心邊界是什么，仍沒有明確答案。而這正是我們這些做 AI 應用產品的人需要關注的核心問題。如果忽略了，很可能會被模型能力的飛速增長所取代。

6 月 27～28 日的 AICon 北京站將繼續聚焦 AI 技術的前沿突破與產業落地，圍繞 AI Agent 構建、多模態應用、大模型推理性能優化、數據智能實踐、AI 產品創新等熱門議題，深入探討技術與應用融合的最新趨勢。歡迎持續關注，和我們一起探索 AI 應用的無限可能！