"其实是这样的，助手只要能给出正确的代码，粘贴一下，不是主要工作量"
这种思路还是把大模型当成一个信息获取工具来用，那么注定难以变革生产力，他和搜索引擎没有任何区别，那么把搜索引擎换成大模型，会有大的变化么？我认为是没有的。未来的发展一定是我之前说的： 我边输入文字，大模型边修改代码，那边边预览效果。
如果要达到这种状态，那么必然要绕过去自动合并代码这个障碍。
可能一个月都不搞清楚这个产品怎么用
这个问题最主要其实来源两点：
目前 auto-coder 文档不够全，案例不够多，导致用户入门有障碍。
auto-coder 完全变革了开发流程，需要用户卸载掉自己的一些包袱，把它作为一个专业工具来学习。
大模型不会消灭复杂性，如果要完成很多专业的工作，依然需要专业的学习和使用。
现在我们在官网提供了更加清晰明确的开发流程介绍，包括我最近也写了一些实际的工作流程。
我们现在也已经开始聚焦文档，案例以及宣传。相信会好转。
devv就很简单，选择一个github项目，问一些业务逻辑，确实可以将不同的文件整合到一起给出回答
当你把 auto-coder 开启human_as_model模式，并且关闭 auto_merge,此时就可以把他当做一个代码解读助手，只要写你问的问题，他会给你生成一个文件，丢给袋模型，就能解读。此外你可能还需要善用 auto-coder的知识库。可能对于devv,他的产品就是帮你找信息，所以你不需要额外的学习。但 auto-coder 可能需要你在对他的功能熟悉的前提下，才能帮助你完成类似的事情，毕竟他主打的还是编程。但是你越熟悉，你就越发现他的强大。
这不是产品设计问题，我们核心还是编程，编程需要极大的灵活性和强大的功能才能support,所以给人一个感觉就是，老手因为包袱太重，导致难以接受auto-coder 一些新思维，新手又觉得门槛偏高。
我相信随着时间发展，包括我们封装一些IDE插件，入手门槛会降低。但是如果要严肃的项目迭代，对人还是会有专业度要求的。
用户永远都是对的。转变一下这个角度，就能改进产品易用性。易用性高，自然用户就用了。
易用性一定是要改变的，但不是迎合用户，而是要给用户带来无法拒绝的价值。
然而，时间事情总是很难两全，有真正变革生产力的工具，往往都有较大的学习成本。
就像我一直举的例子，从马车夫变成汽车司机，对用户的阻力就是很大的，核心在于，你认不认为汽车是趋势。很多用户还是完全在自己以前的路径以来里，你看看马车转到汽车的历程，只是历史潮流逼的大家不得不转变。变革的工具需要持续的学习和丢掉老的包袱，并且重构整个开发模式，
你可以看到，无论使用auto-dev还是github copilot类型的产品，开发模式和以前没有任何本质区别，只是通过大模型把每个小点的工具做的更易用而已。
但是，马车再改进，再改进驾驶体验，能提升多少速度呢？能节约多少成本呢？
所以才有我说类github copilot 的产品有30%的天花板存在。
)
)
)