大模型的第一个杀手级应用场景出来了

大家终于都意识到大模型首先改变的是软件行业自己，而软件的根基是代码生成。代码生成第一波就是AI辅助开发，这个会是大模型第一个杀手级应用。大家苦苦逼问自己的大模型杀手级应用，为什么会是辅助编程，这里说下什么：

1.  必须吃狗粮，颠覆性技术连自己的领域都颠覆不了，那还叫啥颠覆性技术。
   

2. 允许出错。AI辅助开发具有良好的容错率，允许出错，这个相当重要，也是当前大模型在其他领域目前难以落地的根本原因。

3. 市场规模大，整个软件市场是千亿到万亿规模的。
   

4. 初始客群接受度高。AI辅助编程的第一波客群程序员，技术人员群体规模大，对新技术敏感，接受度高，github copilot 这种处于非常初级的产品就获得百万付费用户（月流水至少两亿）。 

这也是为什么我一直致力于代码生成的工作，并且愿景比 Cursor这类大的多，不只是个IDE，这个我们后面再说。

AI辅助编程流派

先说下当前AI辅助编程的流派：

1. 命令行交互式，代表为 auto-coder.chat,aider,mentat,plandex 等。

2. IDE 集成式，代表为 cursor,codium 等，此外还有插件子派，比如 auto-coder.chat, claude-dev 等。

3. Web IDE 为主，代表为 devin, phind(这个比较简陋)，以及在 git 内置的一些编程辅助工具。

这里没有提及github copilot 等类似产品，是因为我认为他们不属于AI编程...hmmm... 我只能说是更智能的代码补全工具。

目前真正能落地是两个，一个是命令行交互，一个是IDE 集成。 今天会分别以 auto-coder.chat 和 cursor 来作为两派的代表来对比。

IDE派的优点：

1. 对于程序员而言，大家熟悉度更高，门槛更低。

2. 可以在 IDE 交互上做到极致的交互体验，所见即所得。

3. 开箱即用，下载IDE，打开即可使用。

4. IDE 提供了一些交互button,比如运行项目，debug项目，这个是其他工具很难替代的。
   

IDE派的缺点：

1. Cursor为了追求极致的体验，没有用插件的方式，而是直接二次开发，导致IDE绑定。

2. 适合人机交互，但难以自动化。

3. 交互界面在复杂场景下，容易繁琐，想设计好不容易，用户也有一定的学习成本。大家用compser 这种就会发现这个问题。

另外，必须提的一点：大家觉得IDE 交互简单其实是因为大家已经前置学习了 IDE（从你接触编程开始的第一件事就是学习IDE）。IDE 就是图片界的Photoshop 是一款专业软件，实际门槛并不低（但因为前面的原因感觉门槛低）。

命令行流派的优点：

1.  兼容所有IDE（所有IDE都有内置terminal），甚至不需要IDE

2.  对于纯萌新而言，实际入门门槛比IDE低（参考前面我特别提醒的点）

3.  交互一旦学习了以后，效率是远高于IDE的（这点和历史一样）

比如，当你看到一个github 项目，三步即可添加新功能特性：

1.  clone 项目到本地

2. 进入目录运行 auto-coder.chat

3. /coding <描述你的需求>

会比 IDE 更轻松。

命令行流派的缺点：

1. 需要用户适当记住一些指令，比如 /coding /chat 等。但是随着大模型越来越强，用户可能只需要一两个指令即可。

2. 很多人对命令行略显恐惧。但实际上现在的命令行非常强大，不输编辑器（唯一的缺点是对鼠标支持不好）

3. 对于有代码阅读需求的，或者需要手工做修改，或者要做代码debug,那么还是需要 IDE 配合。

流派融合

看完了上面的比对，你肯定在纠结，那到底应该用哪个呢？亦或者你心里早就有谱了，我就是用IDE，或者我就是用 Terminal。Naive! 成年人需要做选择题么？成年人应该是：我都要！

所以我今天特意发了这么一个文案：

免费版 cursor + auto-coder.chat = cursor pro
付费版 cursor + auto-coder.chat = cursor pro NEXT

其他你喜欢的IDE工具：

Vscode + github copilot/comate/灵码  + auto-coder.chat = cursor pro
Idea + github copilot/comate/灵码 auto-coder.chat = cursor pro
Vim + auto-coder.chat = cursor pro

然后我发现也有不少用户已经这么组合来用了，果然，"你再快能快的过用户"？

为什么要这么组合使用呢？因为 1+1 大于2么，各自弥补对方的缺点，提升自己优点。我推荐 cursor + auto-coder.chat。

cursor 可以作为 GitHub copilot 的更好的替代品。 而auto-coder.chat 则有更好的多文件编辑能力，算是更好的 composer。 

Cursor 深度剖析，为什么是极致版的 github copilot

重度使用了 cursor 两天。他的迭代路径也很清晰，从早期的copilot (tab tab) 到支持可以参考多个文件针对 “单文件自动修改和合并”（apply）。其中第二个能力是当前 github copilot 没有的，github copilot chat框里的代码没有办法直接合并到文件里，你只能拷贝黏贴。cursor 的单文件修改交互体验做到很极致，那个酷炫的apply 效果很容易勾动程序员的小心脏，但做的再好，也只是一个编辑器辅助功能，程序员很爽，但天花板也很明显，效率提升有限，毕竟还是程序员在手写代码(tab tab) 或者只能针对一个文件做修改（apply）。尽管如此，体验还是吊打 GitHub copilot的。

加上sonnet 3.5 理解能力很强，而且context相对来说比较简单，基本生成的效果相当好。

很多同学看到这，就觉得，很好了呀，为啥不够？代码都能自动写，自动合并了，还有啥可以提升的呀？

注意，实际场景是，当你想添加一个功能需求的时候，你可能需要修改一组相关联的文件，修改多个文件后，你还需要确保他们可以正常的协同工作。这才是最有难度和消耗时间的地方。

程序员会经常说： 

1. 哦，我漏了某个地方忘了改了，导致系统错误，

2. 亦或者说，哦 我改了一个地方，结果影响到另外一个地方了。

这是最常见的情况，也是最难，效率最低，也是bug的温床

所以未来cursor的希望，就是他们新推出的composer，composer默认是关闭的，需要你去单独开启(新版本据说已经开启了)，估计很多人就没体验到。这个功能让cursor迈向了支持多文件新建，修改和合并。这个是从功能迈向“需求”的关键，可以针对现有代码实现一个完整的功能需求。整体效果也不错。

cusor 里composer 的界面是这样的：

和原有的功能是相当割裂的，新启动了一套窗口。我实测下来，他还是比较适合新增一些文件，对于比较复杂的文件修改，还是不太行，合并不进去。我估计是因为他们采用的是 wholefile + diff 算法来做的合并，但目前看效果并不理想。这个我会在后面的案例里详细说明。

这个发展历程和我之前想的差不多，之前我说 cursor走了很多“弯路”。auto-coder.chat 从项目之初，就是要走需求驱动，根据需求自动实现多文件新增修改，相当于第一版我们就做了个composer。我们在 Opus 时代就已经发现可以很好的支撑了多文件修改能力了。

总之 cursor 发展是好事，极大的降低了 auto-coder.chat 的布道门槛，增大了行业的蛋糕。

auto-coder.chat 深度剖析，为什么可以作为极致版的 cursor composer

auto-coder.chat 从一开始就是支持“多文件修改”，面向需求的的代码辅助工具。

对于代码补全和简单的代码续写生成亦或者手动编写代码，debug调试等，用户可以搭配 GitHub copilot ,通义灵码，comate或者cursor来完成。

auto-coder.chat 在 cursor 等IDE中的使用也极度简单，比把大象装进冰箱还少一步：

1. 打开IDE terminal， 输入 auto-coder.chat 命令

2. 输入 /coding <描述你的需求>

两步相当于给你带来了真正生产级别的 composer 功能。

来个真实的小案例

昨天我正好想给auto-coder.chat 加上国际化功能。修改之前我们可以看到，所有交互信息都是直接写死在代码里的（英文）：

现在我们希望把系统初始化过程中，交互和输出给用户的信息都要支持中英文。基本思路就是，

1. 新建一个python文件，里面放中英文文本，并且提供 get_message 函数方便外部使用。

2. 修改所有 chat_auto_coder.py 文件中所以打印信息的部分，采用get_message。

相信很多程序员对这个事都记忆犹新，大量的苦力活，而且还容易错漏，要反复测。

cursor composer 的艰难尝试

我一开始采用 cursor 的 composer 功能来完成。下面是我尝试和他的沟通：

这是新增的文件内容：

这是他修改的文件内容：

很遗憾:

1. 新增内容的路径没有放对，放到了项目根目录，说明对目录理解还是不够。

2. 修改的内容，无法合并到原有代码（原有代码大概有两千多行）。

我尝试了三次，你看到是最后一版，依然没有成功。

auto-coder.chat 的手到擒来

就一句话，没有更多：

然后在准确的位置新增了一个文件：

修改了一个已经拥有2000多行代码的文件：

大概修改了十几个地方，从diff 可以看出，没有一处遗漏。

最后实现的效果：

依葫芦画瓢改了其他地方：

顺利实现了我的需求，我昨天也顺利发版了 auto-coder==0.1.165 版本。

一个小总结

1. 和人比，如果是人去做这件事，虽然没啥难度，但必然是漏了这里，漏了哪里，基本上 auto-coder.chat 几分钟可以搞好的事情，人需要花半天到一天。

2. 和 cursor composer 比，它没有运行成功，并且它还有繁琐的交互的。而auto-coder.chat 的思想是，快速合并，快速/reivew, 快速 /revert 或者 go on。
   

auto-coder.chat 不仅仅是 auto-coder.chat

如果你觉得 auto-coder.chat 仅仅是一个命令行工具就Naive了，给大家看一张图：

auto-coder.chat 只是水上的冰山，我们在下面做了大量工作，从而支持各种形态的辅助编程产品，提供的API接口也支持企业将自动化编程接近自己的 CICD 开发流程中。

此外，我们还提供了最好的编程知识库集成，以及类似 cursor directory 的 auto-coder.chat lib 功能。

想了解更多，欢迎点击 "原文阅读"。