Cline

Cline 正在落伍：

• 模型能力才是 AI Coding 产品的根本，而不论是 Claude Code 还是 Codex 都有根据自家产品形态定制模型的能力（比如 Claude Code 会使用 file edit 但是 Codex 有时候会用 PY Code 来读写代码），但是 Cline 只能不断的根据新的模型去适配提示词（也就是所谓的 LLMOps）

• 开源 + BYOK 的模式没有商业化潜力，无法维持长期高频的更新，隔壁 Kilo Code 已经开始卖自己的 plan 了

但是感谢 Cline，能够让我从源码一窥早期的 Coding Agent 的提示词编写、工具设计、Context 管理、代码库索引等等，为我开发 Agent 提供了很多灵感

得益于claude 3.5，第一代产品叫做‘claude dev’，后来才改名叫cline。

我的评价是，cline的迭代速度非常快，三天两头一更新；

实际体验上，用过cursor之后就没有再用回去了。如果你只有api，那么用cline是最好的选择。

当ClaudeCode/GeminiCLI把CLI工具作为新的开发范式推广后，从周围研发同事的实际使用频率来看，CLI很可能取代IDE。
实际的生产环境中，IDE还是比较重，而且可能要打断开发思路，切换交互焦点。尤其是Cline本身还是IDE的插件能力，使用时的焦点切换更多。
也许将来的趋势是产品经理/独立开发者投入codebuddy/cursor/trae等集成AI的IDE工具，工程开发更多的是CLI工具。

太好用了，尤其是任务导向，可以取代cursor了

Cline是一款非常棒的插件，用户可以在VS Code、windsurf、cursor等AI编程软件的应用商店中添加使用，只需要设置API就能调用AI模型帮助你进行与代码相关的操作。

我是从OpenRouter里接入claude的API使用的，使用场景是对项目的代码文件各个部分进行详细的分析和讲解并输出文档，这对于准确性的要求非常高。最开始我是使用智能体manus来做这件事的，后面由于manus幻觉过于严重，就转而使用了cline和roo这两个插件。

我个人感受：

cline的优点是：对代码文件读取和分析会比较准确深入，对用户意图识别比较准确，可以自己设定规则提示词（和roo相比），因此能更快的完成任务。

cline的缺点是：如果是接入OpenRouter，某个代码文件夹如果太大，就会报错无法继续进行下去；项目文件的目录不能有中文，否则cline会报错；还有一个不太算缺点的缺点：如果是接入claude，非常烧钱！！！

在2025年初，我偶然浏览到一篇关于Vibe Coding的文章，它宣称这种方法能让非技术背景人士——如我这样的零代码基础的设计师，通过与AI的对话，轻松构建应用程序，而无需深入代码细节。这听起来颇具吸引力，作为一名设计师，我决定探索Cline这一工具。然而，经过实际体验，我认识到Vibe Coding的宣传虽富有远见，但泡沫成分显著：开发门槛并未真正降低，尤其是对代码小白而言，仍需基本的编程素养来把控输出质量。否则，AI生成的代码可能引入无谓的复杂性，损害产品整体设计与功能。Cline作为入门工具，具有赋能潜力，但它并非万能解决方案；用户须以理性态度审视其局限，以确保创意不被技术债拖累。

作为设计师，我以往的工作常常陷入一种困境：脑海中涌现诸多创新idea，如交互式工具或视觉化应用，却因缺乏编程技能而难以实现。每次尝试打开代码编辑器，我便感到迷失——语法规则晦涩难懂，调试过程耗时费力，教程虽多却难以转化为实际行动。更何况，我的核心专长在于设计思维而非工程实践，日常事务已占据大量时间，无暇系统学习Python或JavaScript等语言。早期的AI辅助工具虽有所帮助，但往往局限于简单任务，稍涉复杂即显无力。Cline以“vibe coding”理念吸引我，承诺通过描述氛围即可从规划到部署一气呵成。我尝试构建一个简单的工具应用，初始阶段的确高效，AI借助Claude迅速生成界面与逻辑框架。然而，问题随之显现：作为代码小白，我发现Vibe Coding需尽量精简步骤，在对话轮次较少时清晰表达需求，方能获得理想输出。一旦对话延长，AI便开始对代码进行不当修改，这些变动不仅让我难以理解，甚至明显违背我提供的官方文档要求——例如，忽略了指定的数据处理规范，导致功能偏差。那些宣称“零门槛”的论调虽降低了某些障碍，但对完全缺乏基础的用户而言，仍需理性对待coding

尽管存在挑战，使用Cline后，我确实感受到显著的转变。它将生产力推向新高度：以往以我个人的代码水平很难构建的原型，如今只需简短描述idea，便可在短时间内成型，我只需专注于设计决策而非技术细节。例如，我利用它快速生成一个游戏变体，完全依赖Vibe Coding的交互模式，几分钟内便有了可操作框架。作为设计师，这让我首次体会到“构建”的满足感，不再被技术门槛束缚，而是能从零起步验证创意。它确实降低了入门壁垒，让我将精力转向用户交互与审美表达。此类工具在效率层面表现出色——它将编码转化为一种对话式设计过程，让我更像一位统筹全局的架构师，而非技术门外汉。

通过对Cline的深入使用，我得出几点个人观点：

Vibe Coding生态的泡沫显而易见，那些文章与博客往往过度夸张的说简化到零门槛，我认为使用者仍需掌握基础代码知识，方能有效驾驭工具；否则，AI生成的垃圾代码将积累技术债，破坏产品设计的一致性和质量稳定性。

此类工具虽创新，却可能侵蚀软件工程的最佳实践，我们不应让它取代学习与思考的过程。其次，成本与可靠性还有待提升——高端模型虽然费用高，但也会bug频发，更适合原型迭代而非生产级应用。

总之，Cline对设计师与小白而言是宝贵资源，但当前生态尚不成熟，需以理性、睿智的态度运用。欲涉足者，不妨先夯实代码基础，方能避免创意沦为“一锅粥”。

在最初阶段，都是以插件形式AI编程的那段时间，cline的更新速度非常快，各种新功能框框整，比如mcp，比如规则，曾经有一段github上出了一个指挥官模式，设定100+角色，先由指挥官决定选择哪个角色去完成任务，非常酷，但是随着AI IDE出现，cline使用的少了，功能和IDE有重合，IDE已经具备了这些功能，另外就是cline需要自己配置api，跑任务token消耗比较大，不像IDE可以提供多个免费模型使用。现在用的比较少了，只是在ide插件里沉睡，不定时弹出更新的消息。