互联网大厂AI平台负责人表示市面大模型AI应用未达预期

文章原始信息来源为阿里巴巴代码平台负责人—向邦宇

A.大模型AI当前在研发领域应用的现状如何？

AI并未给研发工程师带来危机感

智能化研发领域现在发展得特别快，也特别有挑战。在阿里巴巴，他们不仅做了代码补全和代码对话这些基本功能，还特别关注Prompt市场和Extensions这些场景，以支持业务的自定义需求。在外部，除了灵码和快码等产品有进展外，还出现了很多创业公司，比如Cursor和Windsurf。同时，很多创业公司围绕Github生态开发了局部智能化的Agent，比如Gru.ai能生成单测。

现在，研发智能化主要有以下几种形式：

1. 智能研发插件如Github Copilot、通义灵码、Comate，通过JetBrains、VSCode插件提供代码补全服务。

2. AI Native的IDE如Cursor、Windsurf、MarsCode，以独立IDE方式服务开发者，PearAI等公司基于VSCode二次开发。

3. CodeReview智能化领域起步早但效果一般，阿里巴巴项目存在模型能力和工程化不足问题。

4. RAG解决搜索和Summary问题，面临用户问题上下文不足、知识不保鲜、信息不完整、难以评测等挑战。

5. 智能解决代码冲突、自动解决编译问题等已在阿里巴巴内部平台上线，智能诊断、智能监控等也在调研中。

6. 局部智能化的Agent如Gru.ai、readme-ai、RepoAgent，帮助用户生成单元测试、Readme、补充注释，成功率较高。

7. 广泛自动化的Agent如Devin、OpenDevin，利用大模型生成任务plan，并在独立容器内执行，实现简单issue或需求。

目前对大模型能力有清晰界定，常见模型缺陷有应对策略，使用RAG增强模型上下文，降低模型幻觉。尽管模型发展迅速，但除了SWE-Bench榜单分数提高外，并未出现让程序员有危机感的产品，对大模型解决复杂问题的信心减弱。问题究竟出在哪里呢？

这到底是遇到了哪些阻碍问题呢

大模型基于Next-Token原理的局限性会影响其在智能领域的表现，但半年来的发展表明，问题不仅在于模型推理能力，还包括工程能力和数据的不足。即便推理能力强大的gpt o1模型发布已久，复杂系统研发问题上仍未见突破。大模型解决简单问题也面临挑战，并未能达到预期效果。

问题1：即使非常垂直的场景，需求也很难以自动化完成

Aone Copilot 在上半年推出了 Extensions 功能，旨在让专业人士创建插件，实现如 RAG 搜索、业务版本更新和业务代码生成等功能。尽管如此，我们发现特定场景的自动化还是难以实现，用户难以直接使用 Extensions 生成的代码，需要在反复本地调整。
使用者反馈指出，遇到了不同程度的问题，如：
1.定制组件时代码可能返回空值，缺乏定制方法的展示。
2.对字段作用和展示方式不清晰。
3.需要统一的语言输入和背景知识。
4.扩展点选择困难。
5.技术与领域上下文不匹配。
此外，业务上下文不足和需求理解与描述不足也是大模型落地的障碍。尽管积累了丰富的经验，但难以记录和传承，导致模型缺乏知识参考。我们发现，需求理解不足是大模型落地的主要问题，而无需详细描述需求的场景落地则状况较好。

问题2：用户期望过高而场景实际无法落地，给使用者们带来了负面影响

自GPT3.5发布以来，人们期待GPT4和GPT5能解决众多问题。随着简单问题的解决，探索更复杂、富有想象力的领域成为趋势。众多厂商和团队在SWE-Bench上竞争，但一年后，对这些榜单的兴趣减退，公测产品仍在测试中。行业对大模型的前景充满期待，但同时也感到焦虑，导致基础设施和数据建设的基础工作未得到足够关注。此外，许多管理者和企业领导者对人工智能抱有过高期望，但当他们发现辅助工具未显著提高效率时，开始怀疑技术的未来，对智能化研发的进程产生负面影响。

问题3：既没解决工程上下文问题，也没解决业务上下文问题

开发者通常负责维护旧系统、修复问题、开发新功能。如果大模型要开发新需求，它需要学习工程结构，理解项目目录、代码和配置，掌握本地开发、调试、发布、测试和验收流程，以及项目的历史演进，避免常见问题。此外，理解业务上下文也很重要，包括项目目的、业务背景、需求细节和验收标准。没有这些经验，即便是聪明的程序员也难以应对复杂系统。

许多初创企业的产品由于形态限制，难以整合不同平台的数据。同时，人们往往未充分认识到数据在处理复杂任务中的重要性。例如，Aone Copilot通过结合代码库和用户历史修改记录，提高了代码辅助修改的准确性。在代码审查中，引入需求文档和问题报告有助于发现更多潜在的业务逻辑错误。

基础设施的不足也是问题所在，如内部研发生态系统中需求与代码、文档与代码之间的联系微弱，且Commit Message编写不规范，导致数据处理成本高而有价值信息少。尽管阿里内部代码平台强制生成自然语言描述以改善这一状况，但研发基础设施工作仍需继续推进。

问题4：不能忽视“人”才是这其中的决定性要素

现在，很多产品觉得开发者不重要，以为只要写好需求，就能自动生成完整的自动化解决方案。但问题在于，人类才是理解需求和确定验收标准的关键，为什么要把他们排除在生产流程之外呢？不管是Copilot这样的辅助工具还是其他智能代理，人工智能和人类合作才是最好的。模型不确定的时候要找开发者帮忙，完成任务后也要开发者确认。有些知识只有开发者自己知道，改好的代码也需要人工审核。

一些IDE产品，比如Windsurf，已经开始实现这个理念，让模型在对话框里寻求人类确认。这种理念强调人类和AI合作，而不是取代人类。开发者可以通过自然语言和产品互动，随时确认并应用更改。在这种协作模式下，人和IDE的角色变得不那么重要。我们现在看到的是一种新产品形态，就是以IDE为平台，人和AI一起合作，用自然语言为主要交流方式的产品。

问题5：各系统平台间信息孤岛割裂，无法整合用户的操作行为和意图

因为不同平台的信息不统一，所以有时候我们搞不清用户到底想要什么。就像你用阿里Aone平台时，如果能看到和构建问题有关的信息，那AI帮你解决问题的速度就能快多了。还有啊，监控系统的报警如果能告诉我们最近都有什么活动，比如改了什么、发了什么，还有哪些高风险操作，那我们就能更快地找到问题所在。但现在这些重要信息都是孤立的，没有有效地整合在一起。所以啊，把不同平台的数据打通，让它们共享起来，是技术发展的一个重要方向，这样既能提高用户体验，也能更好地提供技术支持。

B. 大模型时代，我们又需要怎样的基础设施?

面向大模型的数据基础设施远远不够， 数据质量的重视仅停留在口号上

大语言模型的能力主要靠模型、数据和推理机制。虽然推理能力和模型性能有所提升，但数据处理还停留在基础阶段，数据迭代和管理的重要性常被忽视。在微调过程中，少量数据也能显著提高模型表现，强调了数据质量的重要性。提升数据质量需要迭代和演进，依赖于有效的版本管理和基础设施。这些基础设施应包括模型版本管理、数据存储、处理工具、审查系统和数据分析功能。当前数据存储基础设施存在不足，尤其是处理非结构化数据方面。在大模型领域，数据处理和使用人员不同，数据质量责任不明确。Aone Copilot 项目通过一年多的努力，开始解决这些问题，构建了可优化、审查和管理的数据基础设施，确保了数据处理的可追踪性和透明度，促进了团队间的高效合作。

人机的AI交互是关键，因此IDE成了最重要的战场

现在这个大模型时代，今年下半年，Cursor 突然火了起来，显示了 IDE 的重要性，它已经不只是个工具了，而是变成了很关键的基础设施。IDE 能把大模型的能力和用户需求结合起来，让协同工作更高效。Cursor 成功了，说明 Copilot 模式还能继续进步。它的亮点包括能一次填好多个地方，还能实时调整光标位置。

它能自动纠正代码中的错误，比如发现错别字并提供修复建议。还能迅速将对话框内容应用到编辑器中。

第一次用这些功能，我特别惊讶它们的性能。它们既不像传统的代码补全那样，又显得特别简洁，用起来也很顺滑。我们带着好奇试了很多，发现它们真的很厉害。Cursor 的关键是“重写”，就是重新写一遍文件或者文本段落，这和传统的方法完全不一样。通过这种方式，可以做到多点的补全和修正错误。比如，我把命名空间里的变量名改了。

Cursor能自动识别代码并重新写，记录模型对代码的改动，然后和本地代码对比，标出不一样的地方。它还能自动修复代码里的错误，更新变量名，保证代码的一致性。Apply功能简化了插入代码的步骤，省去了手动找位置和解决冲突的麻烦，让操作代码对话框更有效率。

用 Apply 功能，Cursor 能把你要改的代码和原来的代码放一起，让语言模型把左边的代码改写一下。IDE 会帮你对比改写后的代码和原来的代码，让你自己选要不要改。不过，还是有点麻烦：得知道改写到哪儿为止，还得赶紧生成好多文本，还得保证不卡。团队已经解决了服务器上的技术难题，让模型推理更快了，但在 VSCode 上，因为 API 的限制，还是有点难。是不是应该开发一个单独的 IDE，给用户提供更好的体验？这是个值得讨论的问题。单独的 IDE 有好多好处，比如可以搞个“影子仓库”机制，还能用 LSP 支持文件操作啥的。

研发平台作为基础设施底座，具有不可估量的潜在知识经验转移场景可应用

咱们聊了聊数据基础设施和集成开发环境（IDE）的重要性，但Aone Copilot的潜力实际上还看研发数据。这些数据展示了研发过程中的复杂信息，帮助AI更高效地完成任务。研发数据包含了必要的知识和经验。比如说，通过分析需求、代码变更和架构设计、代码实现之间的关系，我们能了解项目进展并提出解决方案。像Aone、Code或GitHub这样的研发平台在数据和工具方面有优势，有助于应对大型语言模型的挑战。在大型模型时代，研发基础设施需要提供数据支持和工具能力，但很多团队的研发流程管理不严格，导致有价值的数据积累不足。不过，通过引导和推动规范化，我们可以改进研发的标准化，认识到数据对效率提升的重要性。

C. 每个企业都应重视内部智能化产品的机会

本篇文章谈到了开发智能体遇到的难题，即使智能体智商很高、推理能力也很强，也难以满足所有复杂需求。没有高质量数据支持的智能体是不现实的。同时强调了数据工程和集成开发环境在大规模模型时代的重要性，并解释了人机交互的重要性和工作原理，最后还分析了研发平台的基础建设作用，打通所有数据孤岛的重要意义。

尽管企业内部智能研发工具没有广泛的外部用户基础，但它们能利用内部资源为使用者们提供了更为深层价值，推动标准化文档和研发习惯，促进工程发展。因此，在AI革新研发模式的前夕，我们应该更积极地考虑AI取代人类工作的担忧是否合理，同时更应思考在变革彻底到来之前，我们作为研发领域的资深从业者们，又该如何做好应对准备。