当前位置:AIGC资讯 > AIGC > 正文

为什么不是Github Copilot,不是 Devin 而是 AutoCoder

我之前常说,不要逆AGI潮流去做一些事情,但也要对当前的大模型的边界有清晰的了解。

Github Copilot 本质还是IDE工具的衍生,是一个更加“智能”的代码提示,而其提供的Copilot Chat 则更加只是把一个聊天框做到IDE而已,和集成一个搜索框到IDE工具没有任何区别,然还是一个古典产品的思维在做的一个产品。

更细节的,我可以从三个维度做给大家做分析:

第一个维度是 Github Copilot 的定位,我一直是 Github Copilot 的铁杆用户,但因为它的定位是只能代码提示,这决定了他需要追求响应延时而不是效果,所以他最大的问题是,它无法基于整个项目的源码去做新的代码实现(这样会导致延时增加到不可接受,并且成本太高)。

第二个维度是 Github Copilot 无法模拟人类的开发行为,我们实际做开发的时候,一般都是基于已有功能,并且根据某种“文档”,“第三方代码”和“搜索引擎”来进行开发。

比如 Byzer-LLM 要对接 Qwen-vl 多模态大模型,那么作为一个开发,我至少需要准备三个事情:

首先我们需要了解和参考Byzer-LLM 之前是怎么对接各种模型的代码

其次我要找到 Qwen-VL的API 文档了解 Qwen-VL 的API

我可能还需要搜索下参考下别人是怎么对接的,以及如果我使用了第三方SDK,我还需要第三方SDK的文档或者代码。

只有获取了这些信息之后,我们才能写出一个靠谱的代码。但 Github copilot 能做到这些么?显然做不到。

第三个维度是,我没有办法替换模型,也就是只能用 Github Copilot 背后的模型,哪怕我有 GPT-4/Claude3-Opus的 web订阅版,如果是公司在用,如何保证模型的私有化部署呢?

所以 Github Copilot 的产品本质决定了他只是一个更加smart的提示工具,而不是模拟人去编程。这个虽然说不上逆AGI潮流,但确实不够 AI Native, 没有把AI 充分利用起来。

而 Devin 则走了另外一个极端,他是一个AI辅助编程工具,但是他的目标是让AI通过一个简单的需求收集,自动完成为了实现这个需求的所有流程,需求分析,拆解,环境安装,构建项目,编写代码,自动debug,甚至自动运行,这个目标太过于宏大,而且不符合基本的规律,在当前大模型的能力边界上,基本只能作为Demo和科研探索。

为啥不符合基本的规律呢?因为但凡做过研发的人就知道,需求是一个动态变化的过程,是迭代出来的,也是迭代的过程中慢慢想明白的,中间有太多甲方,乙方,商业,技术,人性等等的因素在里面。所以我说 Devin 不仅仅目标过于宏达难以实现,而且也不符合基本的规律,就算AGI实现,也难以完全可行。

正好这两天看到一个star数很高的项目,也是做AI辅助编程的。作者用该工具来辅助自己用JS创建一个聊天程序,基本思路就是通过terminal shell交互来完成沟通,结果演示的时候,在最后关头,AI写的代码出现死循环,因为已经花了大量时间了,他又不想剪辑,就说,反正整体演示出来了。。。很尴尬。。。。

说白了,就算为了完成一个简单的应用,当前最聪明的大模型失败率都太高了。我之前在做 AutoCoder 的时候,也发现,就是根据用户的需求创建一个基本的项目模板,要稳定的重现,对很多大模型来说都是有挑战的。

所以我总结他演示其实有两个大的问题:

他演示整个过程最大的败笔就是不让程序员去修改和调整代码。

此外,现存需要维护的代码远比新建的代码多,如何帮助用户实现现有代码的迭代,远比重新创建一个新项目更有价值和挑战。

虽然该项目的同学还是很理性的认识到:

我不认为A能够(至少在不久的将来)创建应用程序而不涉及开发人员。因此,GPT Pilot会逐步编写应用程序,就像开发人员在现实生活中一样。

但就像很多人说自己坚信Scaling Law,但在具体实践的时候又容易背离Scaling Law。

所以,我在做AI辅助类编程产品的时候,核心有如下几个理念:

契合现有模型的能力,专注模型当前能够做好的环节,避免好高骛远。

产品要满足和人一起小步快跑,保证和需求迭代同步。

要留有足够扩展性,需要保留很多有想象空间的的的功能,这些功能随着模型的提升,一个一个都会有质的变化。

根据这么几个理念:AutoCoder 一些特点就出来了。

专注在编码环节

AutoCoder专注在编码环节,相比需求分析,拆解,环境安装,构建项目,编写代码,自动debug,甚至自动运行测试,我们只专注在编程这个环节,让这个环节真正做到提效,稳定,可靠。

模拟程序员编码环节,和程序员一起小步快跑

我们模拟了程序员在实现代码的一些过程,使得AutoCoder能够阅读已有项目源码,阅读第三方库,参考文档,自动搜索寻找问题参考,在才能让AutoCoder对当前程序员的需求有足够清晰的理解,从而实现更加准确而好用更好的代码。

此外,我们鼓励程序员使用进行小步快跑的方式使用AutoCoder,每次只做tiny 迭代,类似于人类一个大PR 需要拆解成几个小PR才能被提交。

此外,我们还提供了仅生成Prompt,自动执行Prompt,到自动merge代码 三种可选自动化程度,在每一步小迭代中都可以由用户来选择自动化什么程度。由于每一个小迭代,我们都采用了yml配置来描述需求,意味着用户可以回顾自己迭代的整个过程。

保留足够的扩展性

我们也提供诸如目标分析,需求拆解,规划,自动生成流程步骤,并且自动执行等等能力,但是这个只是为了保证AutoCoder 在模型能力达到一定程度后,相应的功能能够自动可用,保证AutoCoder 随时能享受模型进步带来的红利。

总结

所以,AutoCoder 相比Github Copilot,对研发人员的效率提升会更加上一个台阶,而相比Devin,我们是可以真正落地,给到广大开发人员提升效率,帮助企业降低研发成本的,而非一个Demo或者科研产品,但我们也提供了有竞争力的功能,保证我们在模型进步后,能够快速的对用户提供更多的价值。

如果你对 AutoCoder 感到好奇,那么不妨关注下我们文档: https://github.com/allwefantasy/auto-coder

更新时间 2024-03-29