2024年让人眼前一亮的产品、模型和技术博客确实不少，但要从中挑出几个最具代表性的来聊，基于过去一年的实际使用体验，下面这几个核心判断，值得拿出来说道说道。

最喜欢的产品

Cursor

如果要评选今年的年度产品，Cursor绝对要算一个，甚至可以说没有之一。这不仅仅是一个工具，它定义了一种全新的开发范式。

对于技能栈在机器学习与数据科学方向的人来说，编程是绕不开的核心能力。在实践中，它不仅关乎算法和模型的实现，更是解决问题、优化性能、提升效率的关键手段。日常使用Python做数据分析时，大量的DataFrame处理和可视化任务也需要通过编程来获得更高的自由度。而Cursor的出现，让编程效率至少提升了五倍以上。

刚开始接触Cursor时，不少人的习惯还停留在GitHub Copilot上——在Jupyter Notebook或其他脚本中进行局部的代码自动补全与编辑。这种习惯的根源在于早期的模型实验和数据分析工作高度依赖Notebook。但Cursor的Chat与Composer模式，如果只是被当作自带AI对话功能的IDE来用，那确实有点暴殄天物。

这里需要区分一下Chat和Composer的定位：Chat模式更像是一个快速问答助手，开发者可以通过快捷键直接与代码对话，获取解释或建议；而Composer模式则更侧重于复杂的代码生成和修改任务，它适合需要跨文件操作或全局修改的场景。两者各有侧重，关键看具体需求。

随着使用次数增多，很多人会开始尝试减少Notebook的使用，转向更多的py脚本。Notebook在处理简单实验和数据分析时依然好用，代码Cell的直观输入输出方便查看中间结果，也适合数据可视化。但在构建更复杂、更自动化的项目时，py脚本的灵活性和高效性就显现出来了。而Composer模式，恰恰是打开这扇门的关键钥匙——它带来了编程的乐趣，也伴随着debug的挑战，让独立开发这件事变得越来越触手可及。

案例一

以一个文本分类的模型训练与评估实验为例，将整个过程按照数据处理、LLM标注、模型训练、模型评估与应用划分成不同模块。只要做好初步规划，清晰地向Composer描述想法，选择Claude 3.5-Sonnet作为底座模型，根据任务需要添加不同脚本作为上下文，或者直接@codebase让模型读取整个项目代码，那么Composer就会开始跨文件理解，修改局部代码或生成全新的py脚本来实现需求。

实际使用中，描述数据处理需求的一个典型提示是这样的：“写一个脚本，读取‘nlp/data/article1’里面的所有csv文件，合并成一个df1，再读取‘nlp/data/article2’中的所有csv文件，合并成df2，最后把df1和df2通过列_id合并到一起。”整个流程的要点在于：做好规划、清晰描述需求、然后根据IDE中的diff进行人工review与理解，有选择性地Accept或Reject。一次下来，快速打出草稿，再持续迭代，就能让整个实验快速实施并实现一定程度的自动化，省去了在Notebook中手动运行代码块的各种麻烦。

案例二

此前用Gradio这个库做了几个研究实验的网页端可交互demo。相比直接给同事看Notebook，这种方式更直观、更动态，也让对方省去看代码的麻烦。但Gradio做的前端页面相对简单，当想做一个更像个人产品的工具，涉及较多前后端交互与逻辑处理时，它就不太够用了。

写前端？说实话，仅有的前端知识基本只限于在Obsidian里修改CSS，以及搭建个人博客时简单用到的Tailwind。后端方面，除了Python外，Ja va和Go都不熟悉。不过既然要做的是基于LLM的demo小工具，Python已经足够处理后端的数据与逻辑。前端部分，索性的交给Cursor——它用什么，就用什么。描述完需求后，同样选择Claude 3.5-Sonnet作为底座模型，Cursor用Python的Flask库搭建后端框架，前端则用Ja vaScript，一步步把整个前后端搭建起来。所有HTML和CSS文件都由它完成，开发者只需要集中精力处理后端的模型交互与数据处理，同时在这个过程中了解前端知识。关键在于，从来没有亲手写过一行前端代码——对于前端代码和页面设计来说，AI确实太合适了。

一个典型的描述前端需求的例子是：“搜索页面参考输入图片：1. 输入框改大一点，允许输入多行；2. 在没有输入任何搜索前，将输入框放在页面正中间；3. 图片的其他元素就不要了。”就是这样一句简单的描述，就能驱动AI完成复杂的前端调整。

Cursor团队在产品迭代中持续添加新功能。比如在Composer中支持的Agent模式——普通模式下模型基本是照本宣科地完成提示的需求，而Agent模式下，模型会进行反思与工具使用，将提示的需求按思维链方式拆解，一步步完成子任务，并在需要时检索访问项目中的相关脚本或联网查询最新文档。Agent模式下，模型解决问题的能力有明显提升，不过token的消耗也更大。

另一个让人惊叹的更新是：可以直接在Composer的对话框中运行终端命令。这样一来，Composer可以直接获取终端的报错信息，再结合读取相关脚本的代码，在一次对话中持续地修改错误。以往解决一个报错需要多次复制粘贴、反复debug，现在Composer可以同时修改脚本代码并给出终端命令（需要手动确认执行），运行后根据返回的错误信息继续排查。

更适合什么人？

Cursor更适合有一定编程经验的开发者来提升效率。这个产品的设计者显然非常了解开发者——Cursor的工程师本身就是用Cursor来开发Cursor的。产品的功能设计融入了大量开发者自身的思考，最终打造出了在功能和体验上远超GitHub Copilot的产品。这不仅仅是调用LLM API那么简单。

Cursor刚开始火的时候，经常能看到“纯小白用Cursor在XX小时内做出了一个网页或App”这样的标题。确实，用Cursor可以实现一些简单项目，但一旦项目变得复杂一点，没有编程经验甚至没有编程概念的普通用户就很难继续推进了。所以，Cursor并不是专门为编程小白设计的，它的目标用户群体始终是开发者。

目前Cursor并没有帮助小白用户彻底解决编程的“第一大拦路虎”——环境配置。在这方面做得比较好的产品是StackBlitz的Bolt.new和Vercel的v0。Bolt.new通过Web Container这种容器技术帮助用户配置好独立的开发环境；v0则支持网页基于Vercel直接快速部署。当然，未来Cursor是否会在环境与部署方面有所动作，是否还会继续基于IDE的产品形态迭代，都还不好说。但可以确定的是，软件开发领域很可能会像Photoshop与Figma一样，分化出不同的产品形态。

ChatGPT 与 Perplexity

这两个产品虽然都不是今年才推出的，但经过一年的迭代，在日常使用中的价值进一步提升，尤其是ChatGPT。

ChatGPT在数据分析方面的表现堪称惊艳。它支持上传Excel或CSV文件，后台调用Python代码进行文件读取、分析并生成可视化结果，界面还支持对Excel文件的交互操作。对于数据分析来说，这几乎是革命性的，甚至可能让“取数分析”这一类型的数据分析师大幅降低竞争力——当然，熟悉业务的资深分析师仍然无法被替代。

日常工作流程通常是：用SQL获取原始数据，脱敏之后直接扔进ChatGPT，完成一系列数据转换、统计与可视化操作后，将整理好的数据下载回本地，有时也直接保存ChatGPT生成的可视化图片。一进一出，快的话半小时就能搞定，更多的时间其实花在思考如何让ChatGPT处理数据才能避免误差、得出令人信服的结论。

此外，ChatGPT的高级语音功能在日常练习英语口语方面也相当实用。至于Perplexity，它仍然是目前AI搜索领域做得最好的产品。虽然ChatGPT开放了搜索功能进行联网搜索，但在搜索到的信息质量和回答的准确度上，依然无法与Perplexity相提并论——这可能是因为ChatGPT底层使用的仍是Bing作为搜索引擎。

最喜欢的模型

Claude3.5-Sonnet

今年的年度模型毫无疑问属于Anthropic的Claude 3.5 Sonnet。它在编码能力上的突出表现，恰恰是2024年模型能力进化最有力的证明。

Claude 3.5 Sonnet是一个让不少产品真正实现PMF（产品-市场匹配）的模型。比如前面提到的最喜欢的产品Cursor，它的底座模型就是Claude 3.5 Sonnet。Cursor真正爆发也是在接入这个模型之后。

从实际体验来看，Claude 3.5 Sonnet对代码的理解和编辑能力明显优于OpenAI的GPT-4o。至于和o1的对比，由于在Cursor中开启o1需要额外付费，所以没有实际测试过。但从目前接触最多的Python代码来看，Claude 3.5 Sonnet在完成需求时，会在有需要的地方主动考虑异常捕获、可视化美观和异步处理等细节——规范的代码加上清晰的注释，某种程度上也成了提升自身编程能力的高质量学习材料。

其他模型

其他闭源模型各有特点：Gemini拥有超长的上下文窗口，o1则在推理能力上表现突出。但这两个在个人实际使用中频率较低。开源模型方面，用得比较多的是阿里的Qwen2.5和智源的Embedding模型bge。Qwen2.5-7B在内部数据标注任务中的表现，无论是生成质量还是速度，都比同等大小的微调版Llama 3.1要好，尤其是在中文场景下。

bge这个模型几乎成了Embedding领域的业界标杆——相关论文经常拿它做Benchmark进行比较，Jina的Embedding模型也经常以它为参照。bge在文本向量化方面表现稳定，今年用它做过聚类和RAG中的向量搜索，效果都相当不错。感觉它确实是社区中使用最广泛的Embedding模型（至少在中文领域是这样）。Jina的相关模型也很值得尝试，不过目前更多是关注他们的博客和论文，实际使用还比较少。

最喜欢的 Blog

Jina.ai

Jina AI的核心产品是搜索底座平台，包含向量模型、重排器和小语言模型，支持处理文本、图像、音频和视频等非结构化数据。用户可以利用这些工具构建高性能的生成式AI和智能搜索应用。

Jina.ai的技术博客是今年阅读量最大的。他们非常乐于分享实践中的经验和教训，比如如何训练Embedding模型、如何设计零样本/少样本分类器、以及如何提升RAG的效果。其中印象比较深刻的是他们提出的Late Chunking技术，以及端到端实现HTML-to-Markdown的模型：

Jina Reader刚发布的那几周，团队收到了大量用户反馈，主要集中在内容质量上。有人觉得内容太详细，有人又嫌不够详细，还有人说Readability过滤器删错了东西，或者Turndown转换HTML时出了问题。很多问题通过正则表达式和一些小技巧解决了。但团队一直在思考：与其不停地修修补补——维护起来麻烦，还不支持多语言——能不能直接用语言模型端到端地解决这个问题？

端到端不一定能解决所有问题，但这个思路值得认真思考。毕竟，从用户体验的角度看，端到端是最优解决方案（大概率情况如此）。Jina博客中关于他们如何尝试端到端解决问题的过程，让人深受启发。虽然没有机会接触大模型的训练，但端到端训练某项具体功能的小模型的需求，未来大概率会遇到。正如Jina CEO所说：“1B参数量以下的小模型是未来的趋势，垂直领域、为解决特定任务而设计的小模型才是真正让人兴奋的方向。”

Anthropic 和 Hugging Face

• Anthropic Research
• Hugging Face Blog

除了Jina，这两家公司的技术博客也是阅读频率最高的。HuggingFace的技术博客内容非常丰富，既有模型基础知识的科普，也有前沿技术的落地实践，以及如何将它们集成到Transformer库中。对于很多机器学习工程师来说，Transformer库就是日常工作的核心工具，博客中提供了大量关于该库使用的示例。此外，博客还会介绍HuggingFace开发的其他工具库及其用法，比如用于微调的trl库，对开发者来说非常实用。

相比之下，Anthropic的技术博客阅读难度要大一些。有些文章篇幅更长，涉及的知识也更难理解，尤其是那些关于模型可解释性的文章。官方research主要分为三大方向：Interpretability（可解释性）、Alignment（对齐科学）和Societal Impacts（社会影响）。可解释性团队致力于更好地规划一个安全的AI未来，理解大模型；对齐科学团队则专注于理解未来的挑战，创建安全地训练、评估和监控高能力模型的协议；社会影响团队则利用各个领域的工具，促进AI与人类之间的积极关系。

最后不得不提的是，Anthropic官网的UI与配色非常舒服，这种注重设计感的博客网站，再加上图文并茂的技术文章，读起来确实是一种享受。