如今，AI 编程工具正在重塑软件开发，其核心目标直指“开发民主化”。它们不再仅仅是补全代码片段的助手，而是能理解自然语言需求、生成可运行代码框架、甚至参与系统设计的“协作者”。这一背景下，越来越多的企业开始对外发布相关产品，美团便是其中之一。
6 月 10 日，美团正式推出了自己的首款 AI Coding Agent（AI 编程智能体）产品 NoCode。那么，在激烈的 AI 编程市场，美团如何定位其产品的核心竞争力？其底层模型具体如何平衡代码生成的质量与速度？未来的 AI 编程产品是否还是围绕 IDE 的延长线做？
这次访谈中，美团基础研发平台工程效率负责人、美团技术委员会委员程大同，对各种大家关心的问题进行了解答。主要观点如下：
尺寸越大，模型的吞吐速度会受影响，特定的任务需要不同的模型完成，团队对小尺寸模型做了针对性的优化，来平衡性能和效果。
后期难以维护问题确实存在，但是本质是代码，随着 Coding Agent 的演进，这类问题会自然而然解决。
AI Coding 效率提升的衡量是比较复杂的，当前阶段比较合理的观察就是 AI 增量代码占比以及 AI Coding 的采纳率。软件工程本质是很复杂的，包括流程、人、组织，以及用户和交付。
AI Coding 的核心竞争力，首先在于模型，其次是上下文工程，然后是对云 infra 和流程的集成与自动化，另外产品交互和品味也很重要。
NoCode/CatPaw 还是聚焦在技术突破，商业化思考并不太多。
“一周上线，团队非常有激情”
InfoQ：NoCode 项目从 2024 年 10 月启动，今年 5 月发布。半年多时间，你们主要都在做什么事情？整个研发规划是怎样的？
程大同：这半年主要是对内部的支持，在内部受欢迎程度很高，能快速交付产品原型，以及一些产品或运营系统，包括工具类的开发。
我们未来规划，会和内部更强的 Coding Agent CatPaw 联动起来，同时在后台 infra 支持上更加多元化，以及在这个过程中做好大规模下的稳定性和性能。
InfoQ：7 个月的时间里 AI 技术发展节奏是非常快的，你们期间有为此做过什么调整吗？如何保持整个产品的技术先进性？
程大同：实际上 NoCode 投入并不多，几个人开发出来的，一部分代码甚至是 NoCode 自己给自己生成的。大的方面没有什么调整，5 月份对外的版本花了差不多 1 周时间就上线了，团队连续工作了 1-2 周，非常有激情，对 AI Coding 也有信仰。
先进性主要是在一些云 infra 的支持、Agent 任务评测、产品交互与品味，我们认为很多技术小白是我们非常重要的用户。
InfoQ：总体来说，NoCode 如何实现“1 秒生成 200 行代码”的高效输出？美团自研 7B Apply 专用模型如何实现 2000 tokens/s 的推理速度？怎么做速度和质量的平衡？之前采访中提到，如果用大尺寸模型，生成速度可能只能达到几十 tokens/s，为什么模型越大生成速度反而更低了？
程大同：这些算是模型工程层面的优化，有一定的算法要求和技术壁垒，尺寸越大肯定模型的吞吐速度会受影响，小尺寸模型我们是做了针对性的优化，能平衡性能和效果。
InfoQ：美团 HR 团队用了 NoCode 发红包，但还是需要研发辅助。如今非研人员用是不是还不能自己“无痛”使用零代码 AI 应用开发工具？其中的难点是什么？有什么使用技巧可以分享？
程大同：如果能用到产品的中等能力，本质应该没有什么难点，唯一的难点就是你能不能和 AI 一起进步学习，持续学习很重要。当然，你想要使用的更专业更有挑战，那可能需要花一点时间去理解计算机相关的知识，但我认为借助其他 AI 工具，也能快速成长起来。使用技巧非常多，NoCode 论坛和公众号都有相关的推送，挺不错的，包括用户登录、音视频播放、大模型接入、微信收费等等。
InfoQ：在你们的宣传中，有提到对标 Lovable。Lovable 确实增长最快的 AI 工具之一，有观点认为它本质上是一个从文本生成 App 的工具，那么在你们看来，除了“从文字生成一整个交互式 App”之外，这类工具跟现在的 App 构建器有什么本质区别？
程大同：纠正一下，并不仅仅是文本，也支持图片相关的能力，包括图生码，NoCode 内部版本是支持的。这个跟 APP 构建器有本质的区别：用户不一样，NoCode 面对的是不懂技术的同学，当然懂技术的同学也能更好的使用；技术原理不一样，一个是偏规则或者固定系统架构，NoCode 是 AI 类 Agent，更智能，在产品能力上有更多想象空间，同时 Agent 还能调用工具或者 infra，在 App 构建时更自动化、更迅速敏捷。
InfoQ：我们观察到，有些开发者觉得 AI 工具生成的项目虽然“漂亮”，但后期难以维护，不如直接用 GitHub 上工程化的模板，而有的用户觉得可以迅速上手、做出能用的 App。你们怎么看这类产品的用户画像？你们更倾向对标新手、初学者、非技术用户，帮助他们“零起步”做出能跑的产品？还是更希望服务工程经验丰富、有长期迭代需求的专业开发者？从产品设计角度，你们如何平衡这两类用户的差异化需求？
程大同：后期难以维护确实有这类问题存在，但是本质是代码，我相信随着 Coding Agent 的演进，自然而然解决这类问题，比如通过 rules 的要求等等。
关于低代码，不是一类产品，当然 LLM 也可以参考一些模版化来实现局部的 AI Coding。可以参考前面回答过的问题，我们的目标用户当前是新手或者非技术用户，但实际上我们也有不少的专业开发者，或者互联网产品及运营同学。从产品设计的角度，我认为创造力或者想象力非常丰富、且能够持续学习的同学，应该是这类产品的主要用户。
InfoQ：还有反馈说这类工具静态页面它能一把梭，交互复杂了就容易“力不从心”。你们怎么看这个产品的使用边界？更希望谁来用、用在哪儿？
程大同：需要一点耐心，我们用的好的同学、会用的同学对话轮数少则几十轮，多则几百轮，几个小时甚至几天就能交付一个可用的系统。你看到“一把梭”，但实际上 Agent 也不断在持续进步，一方面给用户呈现的方式感觉是“一把梭”，实际上也是局部的修改，另一方面精准的 diff 的方式，以及局部代码生成也是我们 Agent 持续迭代的方向。
InfoQ：NoCode 属于氛围编程理念吗？你们如何看待“氛围编程”？有观点认为，prompt 驱动的氛围编程不利于组件化和复用，大型工程中难以落地，您怎么看？如何解决“氛围编程”的模糊性、开发流程不可控等问题？
程大同：当前虽然叫做的 vibe coding，本质上还需要持续去解决工程上的复杂挑战，NoCode 本质也解决了不少，比如存储、计算、数据库，包括云上的环境资源，以及通过 rules 或者 prompt 要求哪些组建或者程序版本。后续随着 Code Agent 的演进，以及模型能力的提升，不限于数据算法和 RL/SFT 对软件工程的理解，本质上是可以解决这些模糊、不可控的问题。
InfoQ：Code Agent 核心竞争力是否是底层的大模型能力？为什么？另外，为了让智能体输出更准确、稳定，现在大家开始主张“上下文工程”，上下文工程为什么火了？能否谈下上下文工程的具体技术实现？具体效果如何？
程大同：首先模型是很重要，其次上下文工程也很重要。我们确实做了很多上下文工程的事情，比如 Index 的效果和速度，我们都做了很多针对性优化。然后是对 infra 和流程的集成与自动化，这部分性能和稳定性还是很复杂。另外，在产品交互和品味上也很重要，因为模型的输出和用户交互，本质很多流式或者异步的处理，链路极其复杂，如何更好的呈现到产品上，是我们要思考的。最后，我认为还比较重要的是评测，评测是保证这些复杂链路的稳定性和性能。
InfoQ：很多人试图搭建一个网站，参考已有示例复刻很顺利，但最终会碰到“最后一公里”的问题，比如集成分析工具、添加某些库支持等，这些还没有支持。对于“最后一公里”的问题，你们是如何规划的？怎么看待当前产品的极限以及未来一两年的能力边界？
程大同：现在支持数据库存储，以及数据分析场景，一些比较常见的能力都有适配，可以访问我们的论坛或者最佳实践。未来还是要解决多技术栈和后台能力，让 Coding Agent 能解决更多复杂的产品开发问题。
“Cursor 也会逐步覆盖 NoCode 方向”
InfoQ：切换到 Dev Mode 的 CatPaw 定位是专业开发者的 Agentic IDE，其技术架构与 NoCode 相比复杂性体现在哪里？
程大同：更 Agentic 一些，ReAct 更强，更多的专有模型、更复杂的链路，包括我们对 IDE 的开发投入。如果把整个 Catpaw Agent 的核心架构利用起来，自定义上下文工程、工具流程、Prompts 和 Rules，再放到一个特定的业务场景下，我认为它不局限于 Code 场景，当前是因为我们放入到了 CatPaw 或者 NoCode 这个产品中，所以叫 Code Agent。
InfoQ：CatPaw 从 2022 开始做的，对标 Copilot。24 年开始往 NoCode 投入时，你们怎么给这两个产品做区分？现在两者的资源投入比分别是多少？你怎么看这些工具之间的关系？它们是各自属于不同的产品层，每个层级都有自己的赢家？还是说这些工具未来会合并，最终发生整合？
程大同：NoCode 是 CatPaw 的研发团队孵化出来的，从产品层面上我认为不会那么快合并，因为解决的问题和用户场景还是有区别，不过技术架构和 Agent 发展方向会逐步有一些协同，本质是你在不同的用户场景换不同的环境或者工具就能解决不同的问题，但 AI 的思考模式也可以基于场景来定制，比如 prompt、rules 等等。
InfoQ：美团如今 50%新代码由 AI 生成，你们怎么度量 AI 对开发效能的真实提升？是否存在“生成量高但代码冗余和维护困难”的陷阱？
程大同：AI Coding 对效率肯定是有提升的，这个不用多说了，整个事情怎么衡量是比较复杂的，当前可能最好的方式就是看这个指标，只能说明大家用的更多了，但如何用好它们，以及解决一些复杂的问题还需要人和组织去决策，一些技能和知识还需要时间去发展。软件工程本质是很复杂的，包括流程、人、组织，以及用户和交付，因此这么多年也不太好衡量。
关于代码质量和冗余，人写的代码也会有类似的问题，但是我认为管理好 AI 应该比要求人更容易，前提是你要非常懂 AI。开发者更多是一个“调度员”角色，指导 AI 完成具体的编码任务，工程师聚焦更复杂的系统架构设计和更有创造性的产品设计任务。未来将会是一个人机协作的编程模式， AI 工具应作为开发者的得力助手，而非完全替代品。
InfoQ：当前，大部分 Coding Agent 总体还是围绕 IDE 的延长线在做，未来会不会有变化？如果大家都挤在这条路上，后来者要如何追赶 Cursor 等？
程大同：如我说的，NoCode 和 CatPaw 在系统架构上会有一些协作复用，Coding Agent 最终会变成一个 remote agent，它自己有一套 sandbox 或者开发环境帮用户实现对应需求。当前 NoCode 就是这类，因此 CatPaw 也能，甚至可以更专业。
Cursor 本质会逐步覆盖 NoCode 这个方向，甚至其 Agent 架构再叠加特定的上下文工具、Promots、Rules 以及一些自定义 Agent，来覆盖更多的业务场景，不限于 Code 场景。不过大家会有一定的差异，可以等一等再看。
InfoQ：Cursor 最近以各种第三方模型“每次请求成本差距极大”为由调整价格，这反映了当前 AI 编程工具商业模式上的哪些问题？怎么平衡用户的成本和体验？NoCode/CatPaw 如果未来商业化的话会选择什么样的模式？
程大同：正常，现在 Cursor 虽然 ARR 增长不错，但是还是亏钱的。AI Coding 还在快速发展，随着算力芯片的成本下降和模型能力的提升，我认为是可以达到平衡的，这里面还有现有的流程、组织和人，都要考虑进来。
NoCode/CatPaw 还是比较聚焦技术上的突破，商业化思考并不太多，当前主要聚焦在 AI 技术上的探索以及让更多用户使用上更好的 AI Coding 工具产品。
