大模型的第一个杀手级应用场景出来了
大家终于都意识到大模型首先改变的是软件行业自己，而软件的根基是代码生成。代码生成第一波就是AI辅助开发，这个会是大模型第一个杀手级应用。大家苦苦逼问自己的大模型杀手级应用，为什么会是辅助编程，这里说下什么：
必须吃狗粮，颠覆性技术连自己的领域都颠覆不了，那还叫啥颠覆性技术。
允许出错。AI辅助开发具有良好的容错率，允许出错，这个相当重要，也是当前大模型在其他领域目前难以落地的根本原因。
市场规模大，整个软件市场是千亿到万亿规模的。
初始客群接受度高。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派的优点：
对于程序员而言，大家熟悉度更高，门槛更低。
可以在 IDE 交互上做到极致的交互体验，所见即所得。
开箱即用，下载IDE，打开即可使用。
IDE 提供了一些交互button,比如运行项目，debug项目，这个是其他工具很难替代的。
IDE派的缺点：
Cursor为了追求极致的体验，没有用插件的方式，而是直接二次开发，导致IDE绑定。
适合人机交互，但难以自动化。
交互界面在复杂场景下，容易繁琐，想设计好不容易，用户也有一定的学习成本。大家用compser 这种就会发现这个问题。
另外，必须提的一点：大家觉得IDE 交互简单其实是因为大家已经前置学习了 IDE（从你接触编程开始的第一件事就是学习IDE）。IDE 就是图片界的Photoshop 是一款专业软件，实际门槛并不低（但因为前面的原因感觉门槛低）。
命令行流派的优点：
兼容所有IDE（所有IDE都有内置terminal），甚至不需要IDE
对于纯萌新而言，实际入门门槛比IDE低（参考前面我特别提醒的点）
交互一旦学习了以后，效率是远高于IDE的（这点和历史一样）
比如，当你看到一个github 项目，三步即可添加新功能特性：
clone 项目到本地
进入目录运行 auto-coder.chat
/coding <描述你的需求>
会比 IDE 更轻松。
命令行流派的缺点：
需要用户适当记住一些指令，比如 /coding /chat 等。但是随着大模型越来越强，用户可能只需要一两个指令即可。
很多人对命令行略显恐惧。但实际上现在的命令行非常强大，不输编辑器（唯一的缺点是对鼠标支持不好）
对于有代码阅读需求的，或者需要手工做修改，或者要做代码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 加上国际化功能。修改之前我们可以看到，所有交互信息都是直接写死在代码里的（英文）：
现在我们希望把系统初始化过程中，交互和输出给用户的信息都要支持中英文。基本思路就是，
新建一个python文件，里面放中英文文本，并且提供 get_message 函数方便外部使用。
修改所有 chat_auto_coder.py 文件中所以打印信息的部分，采用get_message。
相信很多程序员对这个事都记忆犹新，大量的苦力活，而且还容易错漏，要反复测。
cursor composer 的艰难尝试
我一开始采用 cursor 的 composer 功能来完成。下面是我尝试和他的沟通：
这是新增的文件内容：
这是他修改的文件内容：
很遗憾:
新增内容的路径没有放对，放到了项目根目录，说明对目录理解还是不够。
修改的内容，无法合并到原有代码（原有代码大概有两千多行）。
我尝试了三次，你看到是最后一版，依然没有成功。
auto-coder.chat 的手到擒来
就一句话，没有更多：
然后在准确的位置新增了一个文件：
修改了一个已经拥有2000多行代码的文件：
大概修改了十几个地方，从diff 可以看出，没有一处遗漏。
最后实现的效果：
依葫芦画瓢改了其他地方：
顺利实现了我的需求，我昨天也顺利发版了 auto-coder==0.1.165 版本。
一个小总结
和人比，如果是人去做这件事，虽然没啥难度，但必然是漏了这里，漏了哪里，基本上 auto-coder.chat 几分钟可以搞好的事情，人需要花半天到一天。
和 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 功能。
想了解更多，欢迎点击 "原文阅读"。