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

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

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

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

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

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

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

1. 首先我们需要了解和参考Byzer-LLM 之前是怎么对接各种模型的代码
2. 其次我要找到 Qwen-VL的API 文档了解 Qwen-VL 的API
3. 我可能还需要搜索下参考下别人是怎么对接的，以及如果我使用了第三方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 的时候，也发现，就是根据用户的需求创建一个基本的项目模板，要稳定的重现，对很多大模型来说都是有挑战的。

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

1. 他演示整个过程最大的败笔就是不让程序员去修改和调整代码。
2. 此外，现存需要维护的代码远比新建的代码多，如何帮助用户实现现有代码的迭代，远比重新创建一个新项目更有价值和挑战。

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

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

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

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

1. 契合现有模型的能力，专注模型当前能够做好的环节，避免好高骛远。
2. 产品要满足和人一起小步快跑，保证和需求迭代同步。
3. 要留有足够扩展性，需要保留很多有想象空间的的的功能，这些功能随着模型的提升，一个一个都会有质的变化。

根据这么几个理念：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