DeepSeek 点燃 AI 编程新战局，深度探讨编程范式变迁与实践

DeepSeek 的横空出世，在全球范围内掀起了新一轮的 AI 热潮。惊艳的代码生成能力，对复杂算法的深刻理解……AI 驱动的编程时代，是否已经悄然来临？AI 编程助手，究竟能帮我们到什么程度？AI“程序员”能突破人类思维的局限吗？

近日 InfoQ《极客有约》X QCon 直播栏目特别邀请了 字节跳动豆包 MarsCode IDE 研发负责人马翀 担任主持人，和 字节跳动豆包 MarsCode IDE 架构师段潇涵、网易低代码业务中心技术负责人姜天意 一起，在 Qcon 全球软件开发大会2025 北京站 即将召开之际，共同探讨 AI 在编程领域的最新进展。

部分精彩观点如下：

• 模型的提升极大地推动了 AI 与编程结合的应用，AI 生成的代码能够服务于实际生产。

• 将 DeepSeek 用于逻辑推理和任务拆解，比如用户意图识别和逻辑推理，而将代码生成交给更成熟的下游模型。

• 国内外模型的差距在逐步缩小，甚至缩小的速度越来越快。

• 低代码是一个很好的机会，可以创造一种与 AI 交互的中间语言，从而实现高效生成。

• AI 的积极作用在于帮助人们拓展编码能力：不会编码的人可以用它来编码，而会编码的人则可以更高效地开发出更有意义的工具。

在 4 月 10-12 日将于北京举办的 Qcon 全球软件开发大会上，我们特别设置了【AI 驱动的工程生产力】专题。在该专题中，行业领军企业将分享成功经验，探讨 AI 如何革新传统的工程开发模式，显著提升研发效能。同时将通过实际案例，展示 AI 在提升工程生产力方面的突破性应用，助力与会者把握 AI 时代的工程效能革新机遇。  

查看大会日程解锁更多精彩内容：https://qcon.infoq.cn/2025/beijing/track

以下内容基于直播速记整理，经 InfoQ 删减。

AI 对编程能力的冲击和改变

马翀：首先我们从在内部使用 AI 辅助编程的进展说起，比如在实际工作中使用 AI 辅助编程主要解决哪些痛点？最常用的工具和场景是什么？有没有统计过对开发效率带来多大提升？ 我先来谈谈我的看法。

我们团队在这一领域涉足较早。部分听众可能知道，2023 年底，在杭州举办了一场 AI 沙龙。在圆桌讨论环节，我也有参与并建议对 AI 有想法的企业和个人尽早拥抱并尝试这一技术。我们团队在字节跳动主要负责 AI Coding 领域的建设，致力于提升工程生产力，目前已对外发布的产品包括 MarsCode、Trae IDE 等，这些产品在技术沉淀和实践应用方面取得了显著进展，我们还在 Trae 中推出了对标 Cursor 的 Composer 功能。

去年，AI 对研发的影响尚不太明显，许多人仍处于尝鲜阶段，模型、工程技术能力也需要提升。而现在，短短一年的时间，变化已翻天覆地。我们团队日常开发均使用前述的自研 AI Coding 工具，这些在效率、体验以及减少重复性工作方面都表现出显著优势。

姜天意： 网易公司高层对 AI 技术非常重视，甚至可以说是强力推动。公司内部举办了多次 AI 分享会、设立了相关奖项，并组织了培训和考试，高层每天都会转发大量 AI 相关的文章给我们。2023 年，我和团队主要使用 GitHub Copilot。当时市场上已经出现了一些智能体产品，如 Devin、Meta GPT 和 Auto GPT，但经过评估，这些产品的效果并不理想，因此并未在实际工作中采用。

2024 年中下旬，我从 Cursor 转向了 Windsurf，两款工具我都深度使用过。相比 Cursor，Windsurf 在大型项目的智能化支持方面表现更为出色。Windsurf 采用了一项名为 Cortex 的 RAG 技术，能够有效处理代码库的向量化，因此它在代码搜索、修改以及上下文识别方面表现出色。我们曾使用过 Windsurf 进行性能优化，询问其对组件和代码的优化建议，效果显著。此外，团队中的服务端开发人员对测试用例生成功能非常满意。编写测试用例对开发者来说通常是一项繁琐的任务，但网易内部开发的工具结合 GPT 技术，能够通过简单的命令快速生成当前文件的测试用例，极大提高了效率。

我个人深度使用的一个平台是 Bolt.New，我自行部署了一套，并定制了许多功能，使用体验非常震撼。目前，一些小型网站甚至复杂模块已经能够通过对话式生成实现。前段时间，我们尝试复现一个名为“小猫补光灯”的项目，仅通过几句话就成功用自然语言实现了该功能，展现了强大的 AI 能力。

此外，我们产品本身是一个低代码平台，团队中的教练团队负责产品交付。我们的产品具备多项 AI 能力，包括自然语言编程、代码补全推荐等，这些功能通过微调业内代码生成模型和多模态模型实现，例如利用多模态模型进行设计稿识别。

最后，我个人也有一些使用 AI 的习惯。由于经常出差，我需要在路上处理一些材料，因此我在本地使用 LM Studio 部署了一些模型，用于文章总结、文档编写、代码补全、SQL 生成和代码转换等任务。我认为，本地的小参数模型已经能够很好地满足这些需求。

段潇涵： 我们团队由于专注于 AI 与编程结合的项目，接触相关技术较早。大约一两年前，大家开始尝试使用 Copilot，包括后来的 Copilot Chat，当时普遍的感受是对这些工具缺乏信任。经过这一两年的发展，我们自己也开发了相关产品，并使用这些工具进行代码开发，团队的信任度有了显著提升。

从行业产品来看，Cursor 已经存在多年，大家对 AI 在编程中的应用看法也发生了巨大转变。尤其是去年年底，Windsurf 的推出带来了极佳的体验，社区对此讨论热烈。由于我们从事相关产品的开发，使用频率较高，正如天意提到的，这些产品逐渐从小规模代码补全扩展到更大项目的应用。例如，Bolt.new 在新项目生成方面体验较好，而 Windsurf 和 Cursor 则能够处理历史项目的分析和拆解，效果逐渐提升。

我认为有两点值得关注：首先，AI 在工程中的落地方式逐渐成熟，工程实践得到了提升；其次，随着模型的进步，去年 Cloud 的推出和今年 DeepSeek 的火爆，极大地推动了 AI 与编程结合的应用，大家普遍认为 AI 生成的代码能够服务于实际生产。

我个人也有类似的感受。AI 不仅提升了代码生成的生产力，还改变了我们的研发流程。过去，我们通常需要分析需求、设计架构，然后进行编码。而现在，AI 在各个阶段都提供了辅助，包括需求分析、文档生成和架构设计，显著提高了效率。在代码编写方面，我倾向于让 AI 完成大部分工作，然后进行 review。目前，AI 生成的代码占比大约在六七成到七八成之间，极大地提升了开发效率。

马翀：DeepSeek 的编程能力大家是怎么看的？有评测显示 DeepSeek 最新的模型在代码生成领域表现相当不错，尤其在价格和正确率方面很突出。它还支持多语言、64K tokens 的长上下文，以及项目级的编程辅助，整体看来很有竞争力。此外，这类大模型在编程能力场景下最核心的竞争力应该体现在哪些点？

段潇涵： 我正好可以分享一下我们最近接入 DeepSeek 的体验。从我的编程场景来看，DeepSeek 的表现非常接近国外的主流模型，比如大家常提到的 GPT 和 Claude 3.5。不过，DeepSeek 在实际使用中有一个与其他模型不同的特点，即它对 prompt 的敏感度较高，或者说对噪音的容忍度较低。因此，我们在使用 DeepSeek 时，会更加关注提示词的精准性，这一点在其他模型上可能没有那么重要。

DeepSeek 的优势也非常明显。首先，它的响应速度非常快。这可能有两个原因：一是我们位于中国区，DeepSeek 作为开源模型，可以利用更好的资源和硬件，同时借助就近的网络优势，提供更快的速度。其次，从一些评测来看，DeepSeek 的生成速度确实更快，资源占用也更少。特别是在代码生成方面，它的逻辑性表现非常出色。我们在使用中没有发现它比 Claude 或 GPT 逊色很多，甚至在某些方面表现更好。因此，DeepSeek 迅速走红，甚至出圈了。

我身边很多朋友，即使不是编程领域的从业者，甚至不是程序员，也在关注 DeepSeek。朋友圈里经常看到相关转发，确实非常火热。接下来，我们会进一步研究 DeepSeek 在编程领域的深度应用，比如在 Agent 规划和复杂任务拆解方面的表现。

姜天意： 网易算是较早接触 DeepSeek 的团队之一。早年我们在做代码大模型微调时，选择了 DeepSeek 的 Deep Coder 33B 作为基座模型，当时它是我们使用过的最好的开源代码生成模型之一。而且，这家公司最初是做投资和量化的，这让我们感到非常惊讶。

目前，我们主要在做两件事：一是借助 DeepSeek R1 进行模型数据合成和效果评测，二是探索其在代码生成中的应用。举个例子，我们在微调模型时需要生成大量训练数据，尤其是针对数据查询生成 DSL（领域特定语言）。我们发现，DeepSeek 生成的效果已经接近 4O Mini，而且 R1 在多轮对话中表现出色，能够通过深度思考检查和修正结果。因此，我们认为通过优化提示词和增加调用次数，它的潜力会更大。不过，我们也遇到了一些问题。例如，在进行任务拆解和代码生成时，推理结果非常准确，但实际生成的代码与推理结果存在偏差。我们猜测可能是思考过程占据了较多上下文，导致输出时未能充分激活模型参数，或者 DeepSeek 对提示词的敏感性不足。

此外 GPT-4 在 Agent 任务中的表现略优于 DeepSeek，但我相信 DeepSeek 后续会针对这些问题进行优化。目前，我的建议是将 DeepSeek 用于逻辑推理和任务拆解，比如用户意图识别和逻辑推理，而将代码生成交给更成熟的下游模型，例如 Claude 3.5 Sonnet 或 Channel Coder。单纯依赖 R1 进行深度思考和代码生成可能不是最佳选择，采用多 Agent 协同的方式会更有效。

马翀： 大约一年多以前，我们在杭州多次讨论了 AI 编程的未来发展方向。当时的一个深刻印象是，国内模型的起步时间与国外相比存在一定的滞后性。当时我们感到困扰的是，许多设想的 AI-first 时代的交互和产品功能形态，由于当时国内模型能力的限制，还难以实现。当时，我很期待大模型能在以下四个方面实现突破：

首先，是多模态能力的提升。多模态能力，意味着输入和输出的颠覆性变化，不同的交互方式会带来全新的交互变革，从而对产品功能产生实质性的影响。

其次，是端到端延迟的极大提升。我记得一年多前，我们的第一版产品当时的端到端延迟最初高达十秒，后来逐渐优化缩短到几秒，再到几百毫秒。当时我们就在讨论，如果延迟能降到 300 毫秒甚至百毫秒以内，AI 将给人感觉是从被动变为了主动，能够实时响应用户输入，甚至对用户后面的动作产生预判，这将极大提升用户体验。

第三，是从单轮到多轮对话的演进，多轮下保持输出的稳定性。最初，AI 交互主要是单轮对话，像代码补全，是静态的文本交互。如果能实现多轮对话，并处理好上下文的稳定性和生成的一致性，不是每次都重新生成，而是基于之前的对话进行增量式生成，这将为交互式 Agent 提供坚实的基础。

第四，是成本的极大降低，几个指数级的降低。如对比最初的大模型调用成本，模型侧及工程侧共同作用提升，成本起码需要降低 1000 倍，否则高昂的成本将限制其广泛应用。

如果当时能够在这四个方面取得质的突破，那么 AI 编程时代的颠覆性产品应该会很快到来。我们看到，国外的大模型，每隔几个月就更新一次，交替领先。最先是 ChatGPT，接着是 Claude，之后是 Gemini，再如马斯克的 Grok，彼此之间的竞争在加剧。当时我有种感觉，国内和国外的差距似乎在逐渐拉大。然而，令人欣喜的是，2024 年下半年越发明显，无论是字节的豆包，还是阿里的通义，以及最近行业瞩目的 DeepSeek，都让人感到国内大模型的能力，和国外头部产品的差距在明显缩拉近，拉近的速度越来越快，甚至局部有超越。这个变化意味着我们在国内也能够很快做出与国际水平全面接近的大模型，以前受限于模型能力无法实现的服务会获得坚实基础，这给我们这些从业者带来了更多的信心。

AI 如何融入日常工作？

马翀：怎么让 AI 真正融入到日常编程工作流程中？比如，在团队协作、Code Review、版本控制、DevOps 流水线当中，AI 是如何融入进来；做 Prompt 工程、代码审计、测试环节时，是否会额外制定规范？

姜天意： 在正常的业务开发中使用 Copilot 不用过多赘述，大家都在用。除此之外，我还有一些实践经验。首先，在进行测试时，我们尝试将 AI 接入，效果还不错。还有 AI 审查和 AI 扫描，早期的过程中，我们使用像 SonarQube 这样的工具进行扫描，这个过程相对繁琐，因为这些扫描工具会检测出很多 code style 问题，但意义不大。后来，我们接入了 AI 审查的能力，它将 M2DIFF 内容和原始文件交给大模型，然后生成一些非常有价值的建议，比如函数命名规范、哪些函数可以封装，或者某些组件在初始化时没有销毁，可能会导致内存泄漏等问题。

AI 审查比一般的静态扫描工具更强大，因此我们现在也在推动团队使用 AI 审查，并根据团队的实际情况添加一些规则。此外，由于我们是做 ToB 的，难免会涉及到 oncall 问题。因此，我们也在用 AI 进行台账和日志解读，它能够帮助我们解析用户运行时的报错，并给出 AI 解读。比如，一些配置问题或代码翻译问题，AI 可以清晰地告诉用户问题所在，用户也能知道如何处理。

此外，我们还发现 AI 在扫描慢 SQL 时效果非常显著。我们已经将这一功能集成到产品中，帮助用户快速识别和定位慢 SQL 问题。现在，我们还在尝试 ChatOps，与监控团队合作。以前，分析或预警监控数据是个比较麻烦的事情。接入 AI 后，我们发现它在异常分析和变动分析上具有优势，尤其是某些情况下机器的毛刺、水位异常等问题，AI 无需我们编写规则就能有效处理。

最后，我想提一个我自己觉得非常好用的工具，我们正在使用 AI 工具进行代码优化和重构。早在 2020 年，我在阿里时，我们团队开发了一个表格组件，这个组件在 GitHub 上有相当多的用户。去年，我请求 Windsurf 帮我优化该组件的多维表格计算性能，结果它给出了几千字的优化建议，令我非常惊讶。我测试了一些建议，确实有效地提高了效率。

段潇涵： 首先，在公司内部，我们可以看到 AI 逐渐渗透到 DevOps 的各个环节。例如，在 Git 管理平台上，最初是出现了 AI 对 commit message 的总结，或者是有机器人帮你进行代码审查。随着时间的推移，基于大规模代码库和索引，Git 平台会逐步分析代码中是否存在变量命名问题、是否存在碎片化的函数等问题，这些功能也逐渐得到实现。我认为 Git 相关的演进还是非常迅速的，因为编码与 AI 的结合，确实是大家探索的一个重点方向。

第二个方面是，在文档整理和架构设计时，我和团队成员会使用一些 AI 工具。过去我们可能更倾向于使用 C4 模型和 Plant UML 来画图，但这些图其实可以通过文本表达出来。很多时候，只需要清楚地表达需求，AI 就能快速生成相应的图形。如果手动绘制，这个过程非常耗时，且需要考虑布局和连线的问题。而通过代码转化为图像，再结合 AI，可以大幅提升效率。还有，我们内部使用的飞书工具也包含了非常实用的 AI 功能，尤其是在多维表格和文档处理方面。过去我会自己整理对比表格，处理表格的宽度、高度和单元格合并等细节。而现在，我只需使用无序列表，完成后可以一键整理成表格，效率非常高。AI 还能帮助设置表格的宽度与最长的对齐，自动合并同类项，这对云端文档非常有帮助。

回到我自己负责的 AI 与编码相关的工作，我们在 IDE 中更多地考虑如何将 AI 能力集成到开发者的日常工作中。大家常见的就是聊天侧边栏功能，比如 Windsurf 和 Cursor 等工具，它们通过对话生成内容。除此之外，IDE 的基础功能也可以与 AI 结合，比如在编辑器中，当出现 lint 类错误时，AI 可以快速联动到聊天窗口，或者直接在原地更新代码。比如，使用 VSCode 或 JetBrains 等 IDE 时，AI 可以帮助分析语法错误，处理自定义的 lint 报错，甚至检测出代码中的潜在问题，在终端中调试和查看报错时，AI 可以帮助我们快速判断问题是出在代码还是环境配置上，这些都能通过 AI 提高开发效率。搜索功能方面，AI 可以更好地理解自然语言，帮助开发者快速找到需要的内容。可以预见，在传统 IDE 功能的基础上，AI 将会为各个环节提供更深层次的支持。

观众：AI 代码生成与低代码平台的结合能力能为开发者模式带来哪些新的机遇？

姜天意： 我暂时把这个问题拆成两个维度来讨论。首先是生态位的维度，高代码开发者通常使用 Cursor、Windsurf、Trae 这样的工具，而普通的产品经理现在可以使用 Bolt.new 或 Replit Agent 这类工具。其实，这中间缺少一个生态位，专门用于方便二次修改和编辑的位置。目前业内通过对话式工具或其他方式去做，难以达到精细控制的效果。我认为低代码正好填补了这个空白，它可以帮助非专业开发者，提升他们在二次修改和精细控制方面的能力。

另一个问题是，什么样的语言能够与大模型真正有效地交互？从输入的角度来看，使用自然语言与大模型进行交互不一定高效。很多公司尝试用自然语言输入，但常常需要输入大量内容。例如，要生成一个采购表单，如果这个表单有 200 个字段，如何逐个输入？这就非常困难。所以，很多公司开始尝试使用类似“PRD to code”这样的功能，说明自然语言本身存在局限性，比较模糊，效率并不高。

因此，我们正在探索一个方向，即建立一个新的语言体系，将多个技术栈融合起来，作为传统编程语言与大模型之间的桥梁。我们开发了一个叫做 NASL 的低代码 DSL（领域特定语言），它将页面流程、逻辑、数据查询等进行了高级抽象。当我们与 AI 交互时，它首先生成一个与技术栈无关的部分，然后根据用户的技术栈，像是 Spring Boot 2、React、Vue 等，再将其翻译成对应的代码。

低代码为什么适合这一方向呢？因为它天然具有抽象能力。无论是我们开发的 NASL，还是百度的 AMS、阿里的 Local Engine、字节的星图，它们其实都有 DSL 的概念。DSL 概念天然对 AI 友好，因为它不像传统的编程语言那样包含大量的技术栈，也不像自然语言那样模糊，它是一种较为精确的中间语言。因此，我认为低代码是一个很好的机会，可以创造一种与 AI 交互的中间语言，从而实现高效生成。

马翀：处于 AI 时代，我们面对的生产力提升和新的生产关系，会给我们自己带来什么机遇？潇涵你们团队本身也在进行前沿的实践探索，在这方面有没有一些经验或建议可以分享？

段潇涵： 我认为在我们团队内部，AI 给同学们带来的机遇主要是拓宽了大家的能力边界。过去，各个职能的分工非常明确，但是随着 AI 的出现，很多工作，尤其是一些不需要非常深入的任务，跨职能的界限变得模糊了。很多时候，一个服务端开发人员负责的模块，正常情况下需要前端开发人员配合，但有了 AI，很多时候他们可以独立完成一些小需求。这种职能边界的模糊以及能力的拓展，实际上也对业务节奏产生了正向的推动作用。

不过，这也带来了一些挑战，因为 AI 虽然能拓展能力，但它本身仍然具有不确定性，这就要求同学们学会审视 AI 生成的代码。当 AI 生成代码时，大家需要结合搜索引擎、其他文档以及官方文档来判断这些代码是否可用，只有确认可用后才能采纳，让大家从单一职能逐步向交叉职能过渡。在过去，跨职能的学习其实是非常困难的。但有了 AI，借助 AI 提供的一些思路和方案，作为切入点，大家可以更容易地深入到新的领域，而不再觉得学习的过程那么痛苦。

马翀： 我们这两年都有听到一些声音，讨论某些职能是否逐渐失去重要性。例如，我最近还和主编开玩笑，提到今年 QCon 的大前端主题叫做“越挫越勇的大前端”。好不容易这些年大家已经差不多忘记了“前端已死”这个梗，快没人提了，结果又来了这么一个专题。虽然这是个玩笑，但确实最近可以看到一些职能的同学，比如前端工程师或者 QA（Quality Assurance，质量保证），开始讨论这些职能是否会逐渐变得不那么重要。尤其是当业务进入平台期之后，0 到 1 的创新机会在变少，工程化进入稳定阶段，复杂度和业务支撑体系呈现一定的固化趋势。工程化的稳定，职能如前端的很多技术复杂度会被成熟的工程化方案封装起来，那么机会是不是变少了？

我觉得不是，工程化是技术建模，而 AI 的发展能为技术职能如前端等带来更多赋能业务建模的机会。比如，在之前的业务，从事 B 端的前端开发者在晋升方面可能相对处于劣势。与 C 端相比，B 端的业务量级通常较小，不如 C 端业务规模大更能够提供放大效应。和基础工程的比，B 端的技术复杂度又往往比不上做基础架构的。B 端开发者在职业发展上可能会面临更多挑战。

但如前面所言，在 AI 时代，很多嗅觉敏锐、动手能力强的工程师，尤其是前端工程师，会看到很多新的机会。最近我观察到，一些 B 端前端开发者由于具备直接的平台开发能力，能够直接对接 AI 模型并调用大模型的 API 接口，在不需要服务端强配合的情况下，也可以直接与模型进行交互，包括调参、训练以及 Prompt Engineering 等工作。只要他们能够结合业务需求提出创新想法，就有机会推动一些具有实际价值的能力落地。

举例来说，B 端都是平台化产品，各种表单、流程系统等，产品文案常常被用户批评为“不说人话”，尤其是在表单字段的设计上。许多字段需要额外添加说明（如小问号图标），因为用户难以理解其含义。无论是入驻流程还是消费场景，不同用户群体都可能遇到理解障碍。最近我注意到一个案例：有开发者利用 AI 技术检查文案的有效性，识别潜在的歧义或合规风险，甚至实现了巡检功能（包括前置和后置检查）。这些能力可以基于 AI 模型快速搭建，且无需跨职能团队的广泛参与，前端开发者可以独立完成闭环。这为 B 端开发者带来了新的机遇。

对于 B 端开发者而言，AI 的结合为业务带来了新的可能性。这种机遇甚至可能比以往从 0 到 1 的新业务更具潜力。但关键在于，开发者是否能够洞察当前业务阶段及其未来演进方向，识别业务痛点，并围绕这些痛点提出技术驱动的解决方案。如果开发者对业务有足够的敏感度，那么在 AI 时代，他们将迎来更多的发展机会。

马翀： 刚刚聊了不少关于 AI 如何驱动编程能力的内容，接着咱们聊聊“方法论的升级”，比如 团队协作上，如何把个人使用 AI 工具的零散行为或经验，上升到团队协同的标准化流程？再比如，针对不同框架、老旧系统或新兴技术，团队是否需要定制化的 AI 策略？

姜天意： 我认为在 AI 时代，“AI 友好”（AI Friendly）是一个非常重要的概念。首先，我们需要善于发现 AI 擅长的事情，而不是为了使用 AI 而强行应用。以我的经验为例，2022 年我们在腾讯云落地 AI 项目时发现，AI 在生成 Swagger 代码或 HTTP 接口时表现较为吃力，但在生成 GraphQL 代码时效果却非常好。这让我们意识到，大模型对 GraphQL 这类结构化数据的理解可能比业务代码更清晰。此外，我们还发现，AI 在生成 Next.js 或 Tailwind CSS 等技术栈的代码时表现优异，但在生成 Element 或 Ant Design 的代码时效果则大打折扣。因此，选择 AI 擅长的领域进行代码生成或训练，远比强行套用 AI 更为重要。

第二点是我对团队内部的要求：将 AI 视为团队的一员，确保代码具备“AI 友好”特性。大家都知道 RAG 的概念，代码 Colipot 工具在理解或搜索代码时，需要通过 RAG 的方式寻找合适的代码片段。如果 API 设计清晰、注释完整、类型明确，AI 很容易引用这些代码。但如果代码结构复杂、接口命名混乱，AI 补全或生成的难度就会大大增加。因此，让 AI 理解代码就像让人理解代码一样，必须确保代码易于阅读和分析，这样才能更好地支持 AI 的补全和分析功能，这也是 AI 时代带来的一个重要变化。

段潇涵： 过去，开发者更多关注如何编写代码、如何使代码更优雅、架构更合理。而在 AI 时代，开发者需要更多地思考如何将问题想清楚、描述清楚，因为 AI 的效力在很大程度上取决于我们是否能够清晰地定义问题。只有当我们对问题有清晰的理解时，AI 才能更好地执行任务，从而发挥其最大价值。正如前面提到的，有些任务适合 AI 处理，而有些则不适合。AI 并不会完全取代开发者，而是作为开发者的补充或辅助工具，最终的效果仍然取决于开发者自身的技能水平以及对问题的分析能力。因此，开发者的关注点正在从单纯的编码转向如何梳理问题、设计架构。当我们能够清晰地定义任务并将其交给 AI 时，AI 的执行效果会非常好。这也解释了为什么开发者对 AI 的态度存在分歧：一部分人认为 AI 能显著提升效率，而另一部分人则认为 AI 生成的代码需要大量优化和调整，反而不如自己编写，这种差异实际上反映了开发者与 AI 交互时的表达能力。未来，如何更精准地编写 Prompt 将成为一项重要技能。

另一个挑战在于代码审查。AI 生成的代码是否可信？目前还没有一种特别有效的手段能够自动化地判断 AI 生成的代码是否可以直接采纳。传统的代码审查更多依赖于对同事的信任，因为长期合作让我们了解某些同事在特定领域的专业性。然而，AI 并不具备这种背景。目前，我和团队内的成员更多采取一种“默认不信任”的态度，以挑剔的眼光审视 AI 生成的代码。但随着 AI 技术的进一步发展，大规模生成代码将成为常态。为了提升效率，我们必须找到一种自动化评估代码可信度的方法。这不仅对开发者是一个挑战，对后续的 QA 团队也是如此。现在，QA 团队的工作已经不再局限于功能测试，一些新型团队（如效果评测团队）正在兴起，专门针对大模型生成的内容进行评估。

马翀：假设一个团队想尝试做 AI 相关的事情，但团队成员更多偏向支撑和执行，那是否有能力胜任？你们的团队在建设过程中，是否经历过类似的转型阵痛？还是说团队原有的成员可以直接上手，不需要额外的培养，甚至不需要进行招聘或人员替换？

段潇涵： 我们团队原本是一个常规的工程研发团队，在转向 AI 领域时确实经历了一段调整期。对于从 NLP（Natural Language Processing，自然语言处理）领域转型过来的同学来说，他们在模型训练，尤其是大模型训练方面有一定的积累，这为他们理解和使用 AI 技术奠定了良好的基础。此外，AI 领域的一些关键技术概念也是普通研发团队在转型过程中必须掌握的内容，这些都需要逐步补充。不过，我们并不是纯粹的算法团队，因此对技术深度的要求相对适中，不需要深入掌握各种神经网络的知识，但至少需要了解大语言模型的基本构建方式，以便更好地辅助团队使用 AI 技术。从团队成员的视角来看，大家对 AI 的兴奋感远大于转型的阵痛。AI 技术确实带来了非常积极的影响，大家对它充满期待，也觉得它非常有趣。因此，我们是在不断摸索中逐步转型，并逐渐掌握了如何在 AI 领域进行工程实践。

姜天意： 我有一个很强烈的感受：跨界并不一定是坏事。特别是在早期，很多前端工程师开始尝试调大模型时，算法团队通常更关注算法的准确性，即生成的内容是否精准。然而，前端工程师则更倾向于通过工程手段解决问题。例如，内容的过滤、重组和计算，算法团队可能希望一步到位，通过一个 prompt 就能生成 100% 准确的内容。 但前端或工程团队的同学会采用一些工程化的思路，比如通过 fixer、checker 或多轮对比、打分等方式来优化结果，这种工程化的解决思路与算法并不冲突。尤其是在去年，当 AI 能力还不够强大时，我们面对多模态模型时，就采用了规则加多模态识别的方式。

因此，我认为纯工程师的跨界转型反而可能成为一种优势。过去，算法工作被视为门槛极高，算法工程师的薪资和学历要求通常也是最高的。但随着技术的发展，算法的门槛逐渐降低，普通研发工程师也能够通过结合自身的工程能力，低成本地调用算法能力。比如，擅长前后端开发的工程师，如果能够辅以一定的 AI 算法能力（如动态识别、代码生成、文本生成等），将会显著提升工作效率，加速任务的完成。

AI 撼动行业未来？

马翀：DeepSeek 的出现，让行业关注到 AI 模型的训练成本降低这一趋势。相比 OpenAI、Anthropic 这些厂商，DeepSeek 以较低成本提供了不错的能力，这是否意味着 AI 应用的门槛正在快速下降？从行业角度来看，这会带来哪些新的变化？

段潇涵： 我的看法可能更积极一些：AI 目前更多是辅助工程师的角色。在开发过程中，我们常常感受到时间紧迫和排期压力，这通常源于从技术分析到实现、测试再到上线的整个流程中有大量工作需要完成。在这个过程中，如果开发者能将一些辅助性、重复性的工作交给 AI 来完成，自己更专注于核心链路的设计，效率提升会非常明显。我不确定未来几年，模型能否做到仅通过一句自然语言指令就能完美分析并完成任务。如果真的到了那个时代，讨论 AI 是否替代人类可能会更合适。

我们现在做的很多事情都是在为模型的输出“擦屁股”，因为模型的输出具有很大的不确定性，尤其是在结构化任务方面。尽管最近一年随着 Claude 3.5、GPT-4o 等技术的出现，情况有所改善，但仍然无法完全避免问题。因此，我们的大部分工程工作都集中在这些方面。如果 AI 模型的能力逐步提升，趋近于百分百的准确性，那么开发者的精力将得到释放，开发 AI 型应用的成本也会进一步降低。有编码经验的人可以借助 AI 开发出更好用、更炫酷的软件。同时，基于 AI 的生产工具（如 IDE）和低代码平台，非研发人员也能参与到代码生成中。

举个例子，我的一位保险代理人最近在使用在线的 AI 平台来帮助他规划客户关系网状图，分析客户在特定周期内需要更新的税务规划。这非常有趣，因为他完全不属于编码行业。我认为 AI 的积极作用在于帮助人们拓展编码能力：不会编码的人可以用它来编码，而会编码的人则可以更高效地开发出更有意义的工具。除非未来某天模型具备了“自主意识”或超高的“智商”，否则 AI 更多是辅助工具，而非完全替代人类。

马翀： 最后我们来聊一下产品表达，交互范式，这也是我最近想的比较多的方向。虽然低代码平台在垂直领域的一些环节做了优化和标准化，但它并没有完全打破传统工程时期的交互流程。在生产力工具范畴，无论是 MarsCode、Trae IDE，还是 Cursor、Windsurf、Copilot 等工具，它们也多是在目前工具产品的基础上在做加法及辅助性改进，而并未颠覆过去十几年工程时代形成的以人编码为核心的交互方式。如果我们展望未来 10 年，AI 驱动的时代，在 AI-first 视角，是否会出现以 AI 为核心的新的交互范式和产品表达？

姜天意： 我们认为，早期做需求时采用的是枚举式策略，也就是分支式策略。产品需要为不同用户预留不同的 Landing Page 来承接流程。例如，如果你有一个 SOP（标准操作流程），就需要一个专门的 SOP 页面来承载整个流程，这导致系统变得非常臃肿。 而在 AI 领域，第一个可能带来的变化是从枚举式系统转向动态式系统。未来的入口可能是一个超级 Agent，整个界面会根据用户的需求动态生成。例如，当你提出“我要下一个采购单”时，系统不会使用预置的采购界面，而是根据你的 prompt 和需求动态生成一个交互界面。这种变化可能会彻底改变 ToB 系统的交互方式。比如，CRM 领域的 Agent Force 就在做类似的事情。他们已经掌握了各种场景、数据、业务流程和接口，只需要构建一个 Headless 系统，能够分析用户意图并动态生成界面即可。因此，我认为这可能会对传统交互方式带来变革。

此外，AI 在计算机操作能力方面也有显著优势。去年我们在做自然语言生成 SQL 时，我认为这个方向并不理想，因为自然语言过于冗余，生成的界面效率未必比 GUI 高。我认为，能够通过自然语言输入的系统早已存在，比如 Siri，我们没有必要为了某个功能再专门开发一个 LUI（语言用户界面）。然而，一旦计算机操作能力出现，情况就会改变。大模型对外界的交互能力将从传统的 Function Call，提升到对界面、世界甚至接口的理解。

例如，Claude 团队提出了 MCP（Model Ccontext Protocol）的概念。未来，所有的服务接口、数据库或操作指令都可以变成一个 FM（Function Module），并通过 MCP 协议被大模型调用。这将彻底改变产品的交互形态。所有的入口和处理路由都集中在大模型侧，开发者只需提供各种服务并暴露 MCP 接口，大模型就可以调用它们。这将形成一个网状、离散的“用完即走”的生态系统，超级 APP 的概念也将不复存在。

段潇涵： 关于 MCP，虽然 Claude 提出了这种交互理念，但历史上类似的事情并不少见。回想移动互联网时代，最初大家各自为战，后来出现了 APP link 等协议，实现了 APP 之间的互跳，甚至逐渐完善了权限控制。我认为，在 AI 时代类似的情况可能会重新上演。AI 的交互方式将迎来变革，甚至未来可能不再需要 GUI。虽然短期内可能还无法实现，但从长远来看，GUI 可能不再是一个强需求。目前，除了 MCP 这类协议，还有一些更前沿的尝试，比如为 AI 时代开发的操作系统，这些变革可能会深入到技术底层。作为开发者，我们需要持续关注这些变化，思考如何在这样的时代背景下提升自己的工程能力和编码能力，以适应未来的技术演进。