Agent 当道、模型封装一切：AI 时代的产研人如何不被“优化”？

随着 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 变革下的工程师】专题。该专题将围绕产品经理、前后端工程师等产研人的个人发展，探讨如何抓住挑战背后的机遇。

以下内容基于直播速记整理，经 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，不能只埋头开发。

莫欣： 我们当前的核心项目是 Agently AI 应用开发框架（官方网站：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 应用产品的人需要关注的核心问题。如果忽略了，很可能会被模型能力的飞速增长所取代。