又到了一年年末，按照惯例对2025这一年进行总结。

在写这篇文章前，看了一眼去年在此时写的总结。

去年的感受是“彷徨”：学术横向两头堵，论文投了无回音，前路漫漫，不知路在何方。

今年的感受完全不一样：论文发了，工作定了，烟雨任平生，吟啸且徐行。

心态上的转变，很大程度上是得益于AI工具的进化。

回看去年年末，DeepSeek尚未出圈，Cursor正在积累原始用户，豆包还在牙牙学语，国内还在讨论文心一言和通义千问谁才是更好的ChatGPT平替。

而在今年年末，AI已然发生了天翻地覆的变化，我的日常AI工具，也换了好几番。

因此，我把这篇文章的主题定为：和AI一起进化的一年。

Github上的活跃图很好地浓缩了我这一年的发展，下面我将结合这一年做的各种项目，来回顾一下具体是如何和AI一同进化的。

古法松动的伊始

年初，论文已经投了两个月，仍没有回应。

彼时，组里刚接了一个企业横向项目，需要做一个AI相关的处理软件。

项目周期很短，在不到一个月的时间内，就要交付一个版本。

如此短的研发周期，即便去外面找软件开发公司都来不及，他们往往会为一个项目配备一个团队：项目经理管进度、产品经理管需求、美术人员管设计、工程人员管研发。

并且，工程人员又可以继续细分成前端、后端、运维、测试等各工种。一套流程下来，不仅成本高，而且工期长。

人多了之后，效率并不会提升，因为沟通和拉齐的成本变高了。

项目开发是个线性过程：先有设计，再写代码，最后测试。

如果某一环节的理解有出入，那么其它环节都无法并行执行，项目逾期的风险也更高。

于是，经过开会讨论，最终决定：这个软件由我来主导完成，其他人配合实施，主要有以下理由：

• 我之前有相关框架的开发和使用经验，部分逻辑可以复用
• 软件所需的其它功能，基本都能找到开源实现，研发路径是清晰的，只需要花时间去把各模块进行有机整合

为了加快开发进度，顺带去调研了一下AI编程的相关产品，发现 Cursor 的能力远高于当时只能做代码补全的 Copilot，于是让组里报销了一个月的 Cursor 会员。

那时是我第一次在用 Cursor 去做项目开发，在此之前，我一直在使用 ChatGPT 去写代码，它写完代码，手动把代码片复制到 IDE 里面。

它经常喜欢偷懒，只输出一些代码片段，导致我做插入时，还得找到正确位置，再调格式。

我输入最多的提示词应该是：给我完整的代码！

Cursor 则方便很多，它能够自己把修改的内容应用的代码的编辑区，然后我能逐行审阅修改内容，并选择是否接受修改。

Cursor 里面接了不少第三方的模型，当时各家模型的编程水平都相差不大，成功率都不是很高，一旦遇到一个模型解决不了的问题，就只能切换成另一个模型再“碰碰运气”。

相较而言，Claude 3.5这个模型是体验下来效果最好的，但用的人也很多，即便是会员，也需要排队用。

当时，我的主要工作流是日常用其它模型辅助开发，遇到解决不了的难题，留到晚上睡前用 Claude 3.5 慢慢排队解决，期待早上醒来能看到一个“奇迹”。

那会还没有Agent的概念，AI很“笨”，它不会去自己找相关的上下文。

最终效果的好坏，非常依赖输入的上下文。

所谓上下文，就是在和AI交互时，告诉它的一些“先验背景知识”。

比如，你想让它开发一个新的模块，那就需要告诉它：老模块的编码规范是什么，新模块如何在项目里进行注册。

如果上下文提供得不足，它就会写出相对“孤立”的内容，没法整合进项目。

如果上下文提供得太多，比如把整个项目代码都喂给它，又会触发内容截断，每个模型的上下文窗口有限，它只能看到前面的一些内容，重点内容没看到，回答出来更加糟。

所以，要利用好AI，就得像一个药剂师，“小心翼翼”地调节上下文内容和输入指令的配比，如果发现它开始“胡说八道”了，大概率是上下文超载了，那就得新开一个聊天窗口，清干净它的历史记忆。

总之，虽然在AI的帮助下，开发效率得到了成倍提升，但有些复杂的任务，AI反复做也做不好，还是得靠“古法手搓”的方式去精调。

经过两周的高强度开发，整个软件基础功能开发完了。

下一步就是做测试，这一点AI没法替代，因为测试往往依赖于输入的样本，样本输入之后，异常情况如何应对，UI元素是否会错位，多线程是否会崩溃，这些得测了才知道。

于是找团队其它成员各自找样本测了一下，遇到异常情况(Bad Case)，就放到共享文档里去汇总，根据问题严重程度和处理难度，配置不同的优先级。

再经过一周的时间解决完所有的异常情况，再没有新的异常增加，基本就顺利交付了。

Ragflow-Plus：第一个出圈项目

上一个项目结束后，回去过了个春节。

回来刚开学，就收到了论文的一审通知，结果是拒稿重投，两个审稿人，提了十多条意见。

好在意见不是很尖锐，花了些时间补了点实验，意见就回复掉了。

DeepSeek带来的新需求

DeepSeek 在那会火得“一塌糊涂”，官网都被庞大的用户量冲到直接宕机，腾讯、阿里更是第一时间在自家平台接入DeepSeek。

现在很难再见到那种“荒谬”的场景：大模型的厂商们不宣传自家的产品，反而靠“接入DeepSeek”的噱头来吸引用户。

DeepSeek不是一个模型，而是一系列模型，特别是R1有多个参数量的版本，小参数量的版本引发了一种新的可能性：那就是模型的本地部署。

为什么要本地部署模型？因为高校、企业内部，有很多材料并不适合放到公网上去。

例如，想让AI按照以往的材料风格去写新的内容，势必要把以往的材料给它看。那如果直接用官网的DeepSeek，那材料就放到人家的服务器上去了。要是材料的质量不错，还会被它们的研究人员拾掇拾掇，当做下一代模型的语料。

于是组里开会决定，我们也要做内部的本地模型，并且要让它更适合学术场景，用我们已有的学术材料让模型变得更专业化。

导师在组里看了一圈，同门师兄弟都各有各的研究内容和正在进行的项目，就我刚刚结束上一阶段，赋闲在位。

于是这项任务自然落到我的头上。

对我而言，还是挺高兴的，因为以往我有一段时间处在“人格分裂”的状态：项目上需要研究算法或开发功能，学术上需要研究内容、组会汇报，生活中看到一些新奇的东西，也想研究一下。

但现在大模型这个方向非常新颖，有足够多的内容去研究探索。

当兴趣和工作内容相重合，就催生出了强大的工作热情。

确定路线

接到需求后，拆解任务点，核心就是两点：

• 本地部署大模型，具体部署哪一款模型，需要什么资源？
• 如何利用好内部材料，让模型回答得更好？

对于第一点内容，我那会写了好几篇播客，涵盖了模型的量化精度、显存占用计算、KV-Cache原理等内容，这里不做赘述，感兴趣的读者可自行考古。

对于第二点内容，说白了就是两条技术路线：微调或RAG，两者的特点如下表所示：

听说，当时有不少初创团队选择微调这条道路，投了很多资源，费时费力弄完，结果发现基础模型更新到下一版本之后，微调完的模型还不如通用型的新模型效果好。

我后面也尝试过微调的方案，发现微调往往是一种模型分布上的改变，比如，拿学术材料微调模型之后，它的回答会更有“学术味”。但要它精确地去回答“xx文章的方法精度是多少”，它往往是答不上来的。

因此，微调远不如RAG灵活，RAG对于模型的增益，可解释性更强，并且，它不会动基础模型，别人模型开源出新款后，它能无缝衔接。

虽然当时还没有现如今“事后诸葛亮”似的思考，但还是选了RAG这条路线，只因RAG做起来更快，现有的生态相对成熟。

与 Ragflow 结缘

当时，有不少开源的 RAG 相关的框架，但不是所有的框架都适合拿来使用。某些框架成熟度高，但在许可证(License)上做了严格限制，这让方案部署后，如果要作为成功经验推广，存在侵权风险。

综合影响力、成熟度、开放性三个维度综合考虑，选择了 Ragflow 这个框架，此时它还处于 v0.17.0 版本。

虽然部署跑通了 Ragflow 这套框架，但从实际应用的角度出发，还是会发现不少问题，比如：

• 它默认允许用户能直接无限制地进行账户注册，在内部使用时，更希望能有管理员去分配用户账号。
• 不同用户在同一团队能共享知识库，但用户想要加入到同一团队，必须通过互相邀请，而没有一个管理员的角色来进行分配。
• 用户想要和AI聊天，需要自己去配置嵌入模型和聊天模型，配置完之后才能聊。

某种程度来说，它是一个功能齐全的框架，但不是为实用场景设计的框架，因为普通用户的基本诉求就是：别搞复杂的配置，一打开就能用。

于是一个自然而然的解决思路就产生了：需要有一个管理员来提前帮用户把配置都搞定，最简单的方式就是直接去数据库里，修改相关的配置信息。

为了找到改的位置，我对 Ragflow 进行了拆解。

当时还没有 DeepWiki、Zread 这种拆框架的AI产品，要了解代码结构，只能一个个文件去查看梳理。

于是对 Mysql 中用户注册、密码加密、信息验证等链路进行深入研究，写了个脚本能够批量注册用户并统一配置，具体内容可参考Ragflow技术栈分析及二次开发指南这篇文章。

这篇文章发布后，阅读量是个史无前例的数字：公众号平台4k多阅读量，CSDN播客上万阅读量。

今天刚看到CSDN推送的年度总结，这篇文章仍然是2025年度阅读量最高的文章。

ragflow-plus 的诞生与发展

在这篇文章稍微有点影响之后，有个读者找到我说，他不懂代码，希望我能帮忙部署一下我的脚本。

欣然同意，在他邀请下，我远程连接了他的电脑，他的电脑很干净，什么开发环境都没有，从下载安装Python环境，配置各种依赖，解决依赖冲突问题，到最后成功部署完，前后花了接近一小时。

在这之后，一个新的思考产生了：有这种需求的用户不止他一个，每一个都去配置脚本运行环境，太费时间了，能否搞一个可视化界面，打成 Docker 镜像，这样用户直接拉下来就能用。

和 Ragflow 相似，有个知名的 RAG 框架叫 Dify，它本身也没做用户后台管理，有人就补充了一个后台管理系统，叫 dify-plus。

于是，我找了一套开源的 Vue 系统模板，把用户注册的功能接进去，作为 Ragflow 的补充，仿照 dify-plus 的命名方式，起名为 ragflow-plus，并在Github上开源。

开源之后，它很快吸引了一波关注，主要原因来自于Github的关键词搜索，项目名称中，包含 ragflow 的不多，当有人搜索这个关键词时，这个项目天然就会出现在它的搜索列表中。

顺着这个项目和相关的开发日志文章，有不少人过来加我，有反馈问题的，有提新需求的，还有单纯讨论技术的。

其中，不乏很多重复性的内容，和人交流就占据了我大部分的时间，以至于研究技术的时间被极度压缩。

于是采用了一个非常有效的方案，那就是建群。问题直接在群里沟通，有解决过类似问题的群友就直接帮忙解决了。

并且，群友天然是响应极快的测试资源，当我有一些新的改动，发布新版本时，第一时间在群里发通知，就有人帮忙测试。如果出现了一些问题，可以快速解决，有效防止bug传导到线上版本。

经历了一两个版本迭代之后，在实际应用中，又发现了新的问题：ragflow自带的文档解析对扫描件的解析效果不佳(如下图所示)。

有群友推荐用 MinerU 这个解析框架去解析PDF文件，效果不错。顺着该思路，去做了最小可行性验证，的确解析效果有明显改善(如下图所示)。

因此，决定把 MinerU 集成进 ragflow-plus，并对用户侧的解析权限进行收缩，防止用户误操作。

从此，ragflow-plus 就走上了一条和 ragflow 相独立的路线，并因 MinerU 的许可证的“传染性”，修改许可证为 AGPL-3.0。

后面经常有人问：这个项目能和 ragflow 最新版同步吗？

起初，想着可以通过 cherry pick 的方式去把原版本的一些核心pr pick过来，但后面发现根本做不到，一旦选择了独立这条道，就回不了头了。

在开发这个项目的过程中，能够发现，本地RAG应用的这个需求相当旺盛。

社群中不乏有一些初创团队在做类似的事情，有一个群友经常问我什么时候更新项目内容。

我有时高估了AI的能力，信口开河：“明天一定更”。结果发现AI不仅没有解决问题，还制造了新的问题，更新计划被迫跳票。

有一天，他连问我三次(早中晚各一次)：“(新版本)承诺发布的为什么不发布？”

我本来想解释，把我问疲之后，我也懒得解释，剽悍的开发者不需要解释。

结果过了几天，他突然没动静，看了他的朋友圈，才知道原来他一直在用我的更新内容写日报，后面一段时间没推进，他们团队现金烧完，解散了。

随着这个项目的影响力日渐增加，有一个Pycon组委会的成员看到了这个项目，邀请我去 Pycon 2025 进行一次演讲分享。

分享时间是在9月20日，在上海的对外经贸大学。

我本身对于演讲没有恐惧，还有点兴奋。

但是，主办方不报差旅，前一天晚上到上海，为了省钱，住了一家廉价酒店。

空调内机像发动机一样响彻整晚，搞得我整宿失眠。

第二天是硬着头皮把PPT的内容讲完了，如果对此项目的内容想进一步了解，可参考这个演讲切片。

当然，这个项目到中后期，我也在找了个正读大四的学弟做帮手。

本想让他继续维护，结果他未能保研成功，准备考研去了，这个项目逐渐停止维护。

后面再找人接手时，AI工具已经有些成熟了。重新理解这个复杂的项目，还不如让AI去写一个新的，小而美，且易于维护。

至此，该项目告一段落。

ragflow-plus 因起名获得了早期的流量，但后期也因起名问题所困扰。

对于不了解发展脉络的新用户，看到这个项目，天然就会想到和ragflow的同步问题。

并且，有的用户会提一些issue，结果发现是ragflow本身部分固有的问题，为了解决它，还需要给它去做“善后”。

下一次，我绝对不起这种项目名了。

FreeTex：无心插柳的产品

在研发 ragflow-plus 时，对 MinerU 这套解析算法进行了深入研究。

MinerU 在 2.0版本之前，是一套集成式的文件解析方案。

在查看它的解析结果时，意外发现它对数学公式的解析效果奇好。

所谓数学公式解析，就是根据数学图片，将其转换成Latex的格式，这样就能二次编辑。

对于做学术的人来说，这个使用场景很普遍。

市面上不乏有类似产品，国外有个MathPix，每月好像能免费用10次，国内有个SimpleTex，起初它主打免费无限用，后面因成本扛不住，决定开始采用收费制。

SimpleTex收费的主要原因是，它的公式识别是在云端进行的，天然就有推理计算/流量成本，用免费模式，企图用捐赠来维持，没有可持续性。

MinerU 给我的启发是：如果公式识别这件事能够在端侧解决，那就完全能做到免费了。

于是，顺藤摸瓜，找到了 MinerU 的公式识别算法 UniMERNet。

我想要做一个免费的数学公式识别软件，产品名自然而然地命名为FreeTex。

在做这款软件时，我是先把 UniMERNet 的本地推理跑通，然后搭建一个基本的PyQT框架，再开始借助AI进行完善。

这个产品从5月1日劳动节开始做，花了一个五天的小长假就做完了。

除了第一天是我手动搭建的产品原型，后面一直是和AI交互完成，大部分时间是在等AI出结果。

5月6日，发了篇播客，正式推出这个产品。

结果没想到，文章刚写出来，阅读量就爆了，当天就有1w的阅读量。

比阅读量猛增更“爆炸”的是，产品存在“缺陷”：很多用户反馈装了之后，启动闪退。

我的电脑采用 Win10 操作系统，没有问题，问题普遍出现在 Win11 操作系统中。

于是赶紧在社群里找了一台无法成功运行的群友，趁中午时间人家暂时不用电脑，远程连过去调试。

结果发现，是 Torch 版本的问题，在 Win11 系统中，会提示某个dll文件缺失。

于是赶紧打了个补丁包，发布了修复通知。

有些不知情的读者可能会怀疑，是不是故意搞个缺陷，“引诱”读者评论，来给文章增加热度。

客观来讲，确实存在某种程度上的因祸得福。

除了这个问题外，这个软件初版还有一个“经验问题”，那就是过份追求推理速度。

当时存在一个刻板印象：GPU一定比CPU推理快，所以我在软件中内置了Torch-gpu的依赖，这个windows版本的依赖巨大无比，整整2个多GB。

加上模型本身的体积和其它杂项依赖，整个安装包压缩完，还有3个多GB。

这么大的软件，还放了百度网盘，直接被一些用户喷的“体无完肤”。

用户对安装包体积的感知是很敏感的。有许多手机游戏，在下载页面的安装包特意设定成300MB左右，结果一打开，又开始联网继续下载资源。

这给用户的一个错觉是“软件本身不大”。它们这么设计是有消费者心理学层面的考虑的，如果让用户看到安装包就几十个GB，即便软件本身就需要这么多空间，他们也会选择放弃下载。

在第二个版本中，试了一下纯用CPU推理，发现对于小规模参数的模型来说，CPU和GPU的速度差异几乎感觉不到，甚至CPU可以更快一些，因为模型只需要搬到内存，搬到显存上，还需要花额外时间。

并且，模型默认是FP32的精度，实际上给它做适当量化，变成FP16，体积减少一半，精度减少微乎其微。

经过这套优化的“组合拳”之后，软件的安装包体积骤减至600MB，这对于大部分用户来说，算是可接受范围了。

凑巧的是，在我紧锣密鼓地开发这个产品时，在6月2日，收到了论文中稿的通知。

在三天后(6月5日，也是我发小的生日)，正式刊发，具体细节可参阅我之前的文章，这里不作赘述。

做FreeTex，为科研者造福，同时也收获科研成果，算是一场福报。

FreePDF：第一次Vibe Coding

某天，当我按往常习惯，用 Zotero 看论文时，遇到一些看不懂的英文名次，配上插件，进行划词翻译。

突然，我意识到，这种划词翻译的方式效率好像有点低。

即便一个人的英文水平再出色，也不会有它的母语中文出色。

既然如此，那为什么不直接把整篇PDF文章按原本的排版，翻译好之后，直接看中文呢？

于是，调研了一下，发现了 PDFMathTranslate 这个项目支持按照PDF格式进行翻译。

但是，它本身的应用交互做得不够方便：它需要让用户自己用Docker部署项目，然后在Web上面打开运行。

并且，它只是做翻译，并不能把原文和翻译后的文章对照来看。

于是，我催生出做 FreePDF 这个产品的想法，它是一个双栏型的文献阅读软件，左边是原文，右边是译文。

文件拖进去就能自动翻译，平时看翻译就好了，如果遇到某些专业术语翻译的不准确，需要精看段落，再回去看原文。

开发这个产品时是6月末，此时到了AI的变革期。

从3月份 Manus发布后，一个新的概念开始涌现，那就是Agent(智能体)。

和AI的交互不仅仅局限于对话，Agent能够调用各种工具，去自动看你的代码结构，自动联网搜索，自动完成编辑测试。

当代码编辑工具开始逐渐上线Agent，一个新的名词产生了，那就是Vibe Coding(氛围编程)。

为什么叫它氛围编程？因为它营造了一种“氛围”：你不再需要看具体的代码，而是通过自然语言就能让AI写代码。

即便是一个完全不懂代码的文科生，也能通过Vibe Coding来做自己的产品。

这种感觉实在是“太嗨了”，前几天刚看到王自如的播客，谈他第一次用Vibe Coding的感觉：天灵盖都飞起来了。

对于经历过传统手搓代码，刀耕火种时代的人来说，这种感觉更是冲击，以至于当时流传了这样一张表情包。

我有个研究3D渲染的同门，花了一周的时间搓出来一条基于OpenGL的渲染管线，试用了Vibe Coding之后，一分钟搞定了，甚至效果更好。

他的感觉有点五味杂陈，用一个最贴切词形容就是 jealousy（妒忌）。

当还在研究怎么挑马，怎么换轮子才能让马车跑得更快时，突然出现了一辆汽车，一口气把人拉到目的地。

此时会开始怀疑：辛辛苦苦学的养马知识，辛辛苦苦攒的木工经验，在一瞬间，都丧失了意义。

我之前写代码写疲了，就会打会游戏放松一下。

但游戏本质上是在一个别人限定的框架中做约束性的事，Vibe Coding则像是打开了一个上帝模式，这可比游戏有意思多了。

FreePDF 就是我第一个纯粹用 Vibe Coding 写的产品，我一行代码都没有自己敲，所有内容全是靠AI来完成。

AI的工具也是在那时高频切换，因为用得太猛，半个月就把Cursor的额度烧完了。

此时，很多同类型的产品开始涌现，字节的trae、亚马逊的kiro、腾讯的codebuddy、谷歌的gemini、Anthropic的claude code、OpenAI的codex等等。

这些产品我基本全用过，因为每家刚推出来的时候，为了抢占市场，会让新用户免费用，也相当于帮它们的产品进行测试。

除了 FreePDF 外，我当时还顺带在做其它的小玩意（后面会具体说），一台电脑上开多个窗口，最多时候让3个AI各自写三个项目。

我就像是一个“包工头”，时不时看看哪个实习生AI把阶段性任务做完了，然后检验一下它的质量，给它下达新的任务。

三个项目不是AI的上限，而是我脑力的上限。因为思维需要在不同的项目之前来回跳跃，稍不注意，可能就会把A项目的指令不小心输入到B项目里，这样就把AI的上下文污染了。

虽说 Vibe Coding 上手很容易，但用起来还是有一些门道。

在一开始开发 FreePDF 时，我想让它做一个PDF文件加载的功能，要支持ctrl+鼠标滚轮进行缩放。

AI理解了我的意思，但效果始终不好，PDF渲染很模糊，没法看，搞了很多轮，它还是来回打转。

转念一想，这种功能应该不需要自己从头开始实现，应该早有开源的方案。

于是修改了指令，让它先去Github上面看看，有没有当前最佳的实践方案，果然，它就搜到了pdf.js这个比较成熟的PDF加载器。

解决完核心问题后，后面的开发就比较顺了。

AI本质上就是工具，不同人的用法不同，出来的结果也不同。

因此，对于AI模型的评测，结论往往是很主观的。别人说好，那在自己的使用场景中，它未必好。到底好不好，试过才知道。

当然，在开发 FreePDF 的过程中，还是能学到一些新东西的。比如，这个项目开始用 onnxruntime 去进行模型推理，它更偏向于做纯推理的任务，比 torch 要轻量不少。

FreeTex 和 FreePDF 的应用链路都是采用 PyQT + Pyinstaller。

虽然AI很强，但在用这套方案去做Win/Mac双平台适配时，遇到的问题也是不少，后面迭代了多个版本，才逐渐解决把问题一一解决。

从流传度来说，FreePDF这个产品不如FreeTex，因为它的名称没法体现出它的功能，以至于有人曾经留言：如果给它起个接地气的中文名，传播度肯定会更好。

但现在看已经无所谓了，FreePDF不是终点，它只是Free全家桶的一个组成部分。

FreeEditor：第一个网站产品

FreeEditor 诞生于国庆节假期期间。

当时我正在经历找工作的阶段，本以为会面试很多，没时间去研究新东西。

结果发现面试邀约寥寥无几，市场冻得令人发指。

对于我而言，反倒是一段非常充实的时间，因为基本不用忙组里的活，每天都有时间去自由探索。

于是开启了文章日更的节奏。

我写文章习惯用 Markdown 去写，并且习惯用双栏型的编辑器，写作区和渲染区相分离。

之前一种用的是墨滴编辑器(mdnice)，甚至还买了它的包年会员。

但是它的多级列表在公众号里面的样式有bug，格式会乱。

遇到问题后，直接给开发者发邮件：希望能解释或者修复一下。

但直到现在，依然没有回应。

既然墨滴欺我老无力，那我愤而重写编辑器。

这就是 FreeEditor 这款产品诞生的初衷。

直到现在，FreeEditor仍然是我最高频使用的产品，它具体的功能不过多介绍了，感兴趣的读者可以看我之前的文章。

在10月份，AI编程的战局基本上已经成型，Cursor因为丧失了Claude的模型接口，市场份额不断下滑。而Claude Code经历了时间的检验，目前是最好的AI编程工具。

Claude Code除了能接自家的产品模型外，还能接别家的。

当时国内第一家能接的是kimi-k2，但kimi的定价策略很糟糕，免费用户每分钟只能交互3次，对于高频交互的编程任务来说，完全没法用，只能充￥50才能有使用的机会。

kimi的问题是过早的商业化，而且模型本身的能力也不是很好。

之前kimi-k2-thinking刚出来的时候，国内媒体普遍都在吹，我可能是第一批用过之后提负面意见的，具体见这篇文章。

当时还有人不服气，说你是不是拿了kimi竞争对手的好处，搁这写黑稿。

现在回过头来看，市场依然证明我的判断是准确的，在openrouter上，调用量前二十都看不见kimi，它已经不知道甩到哪去了。

从国内模型平替看，用的比较多的就是 MiniMax M2 和 GLM 4.7。

不过，这俩我都还没时间去具体测试过，后面会再补一下我的使用体验。

FreeEditor的产品形态是在线网站。

在线网站的天然好处是用户不用下载，而且可以热更新。

这比做前两个产品顺利得多，因为浏览器的标准是基本统一的(少部分情况会有差异)，用户直接通过网址就能访问，不再会有因操作系统而出现的差异性问题。

FreeGIF：解决自己的痛点

FreeGIF 这个产品完全是解决我个人的小众痛点，那就是GIF动图制作繁琐。

我的文章中，有时候想插入一些动图，往往需要先开始录屏，再把录屏转成gif格式，转完之后发现文件过大，发不出来，还得再压缩。

为什么不能把gif的录制、剪辑、压缩三个步骤在一个软件中一站式搞定呢？

于是就用AI做了 FreeGIF 这个产品，除了做产品演示的动图之外，做表情包也极为方便。

这个产品实际上迭代了两次，第一次尝试用 Rust + Tauri 的技术栈去做，但发现AI对于小众的编程语言来说，效果不好。

后面改用前端 + Electron 的技术方案，效果好了不少。

Electron 的跨平台做得很好，用它来进行 Win 和 Mac 双端适配时，非常顺畅，基本没遇到什么问题。

FreeTool：用集成解决问题

FreeTool的思路来源于一次网站收藏夹的整理。

很多网站都仅局限于做好它这一项功能，比如，我要编辑数学公式，要跳到latexlive，编辑表格要跳到tablesgenerator，翻译内容又要跳到highlightcode。

为什么不能在一个网站上，把一些高频使用的功能都进行集成呢？

FreeTool就做了常见工具的集成，它是一个用纯前端写的网站，用户输入的内容，基本都在本地执行。

并且，所有工具的交互逻辑都是一致的，在菜单选择->输入文本/图片/视频->得到结果，没有弯弯绕绕，清爽简洁。

为了统计这个网站有多少人访问，我在里面增加了 GA 埋点，结果意外发现还有很多人下载了开源代码，改名换皮进行部署，里面的 GA 埋点都没删，直接被我在后台看见了。

事实上，该产品开源协议采用的是GPL-3.0，里面有一个条款是要保留原作者的版权声明和许可证文本。

有些网站直接把我的版权声明给删掉了，客观上说就是侵权行为。

但国内的版权意识显然没有很好地普及，我也懒得去追究。

换个角度说，它们也是用另一种方式，来表达对网站的认可。

FreeHub：产品陈列柜

Free全家桶有了一些成员后，一个天然的想法是给它们做一个导航。

于是做了 FreeHub 这个站点。

当然，它的设定之初并不局限于我自己的产品，一些别的产品也可以入驻，只要满足两个条件：免费且开源。

为什么我能坚持做免费产品呢？因为有了 Vibe Coding 之后，开发开始变得不值钱。

用的AI模型可以是免费的，网站部署在Github上，或者用CloudFlare去部署，早期成本几乎为零。

既然成本为零，为什么要收费？

有些产品需要付费，核心原因是人力成本很高。

但AI的出现，就产生技术平权：普通人也能做小而美的产品出来。

FreeHub 发展到后期，内容已不局限于导航免费产品，它更是一个AI信息获取的入口。

我借助 Github 免费的 Action 资源，让它每日定时(早上十点)去互联网上搜集有关AI、科技相关的行新闻。

现在我已经养成习惯：早上先访问 FreeHub，看看有哪些新鲜事。

拼字幕：第一个微信小程序

今年以来，我的下饭工具发生了很大的变化。

起初，吃饭的时候，刷刷短视频，有一天突然意识到：为什么放着大投资、专业导演拍的电影不看，而看小作坊、自媒体随手拍的东西。

于是用吃饭的时间，一连串看了不少电影，平均一天就能看完一部。

看了半个月，突然觉得电影和游戏差不多，都是用视听来愉悦观众，能留下思考的东西，不多。

意识到之后，转头开始去看书。

书也分很多种，我比较偏爱看名人自传，因为自传的内容基本都是真实的，而且往往包含一些从媒体上看不到的内容。

花了几个月的时间，一连看了成龙的自传《我是成龙》、李连杰的自传《超越生死：李连杰寻找李连杰》、曹德旺的自传《心若菩提》、孙宇晨的自传《这世界既残酷也温柔》、郎朗的自传《千里之行，我的故事》……

看完之后，又发现一个问题，这些自传的写作时间有些比较早，只能反映作者写书时的思考，怎么看到他们当下的思考呢？

最简单的方式就是看采访，听播客。

今年可以说是播客繁荣的一年，于谦、陈鲁豫、罗永浩都开始开播客节目，还有一些职业媒体人的播客节目，如张小珺商业访谈录。

看视频播客比看书能获取到更多信息，因为说话的语调、访谈的微表情这些都是仅通过文字所无法捕获的信息。

之前我尝试过用AI去做播客的内容压缩，虽然这样做很高效，但是会丧失人味。

看播客的一大乐趣是，看到一段内容，如果嘉宾说得很出彩，我想把它摘录下来回味。

比如，前天看insta360CEO刘靖康的那期播客，这段“需求背后的需求”理论说的很棒，把它变成下图这样的形式，就很易于收藏和分享。

这种方式有个词，叫做拼字幕。

手机上，能够做到此功能的应用不多，于是我做了一个拼字幕的微信小程序，全称叫拼字幕-长图拼接助手。

它的界面极为简洁，上传图片，调节裁切边界就可以了。

这个产品逻辑简单，是我开发周期最快的产品，在AI的帮助下，一小时就完成了。

其它产品

除了这些主线产品外，开发之余，还做了一些支线。

羲和

羲和是一个摆件类App，能够让手机变成一个优雅的诗词时钟，现已在App Store中上架。

AI象棋大战

尝试用纯语言驱动的方式，让中外语言大模型进行象棋对战。

这个实验证明，大模型的泛化能力是不行的，纯语言去下象棋，效果很差，远不如专为象棋训练的AI。

AI炒股大赛

尝试用语言模型驱动的 AI Agent 去进行炒股，试了一周，结果还没有大盘收益高。

3D六子棋

一个3D版的六子棋游戏，支持人机对战和联网对决。

这个项目做完还是有点刷新我认知的，我之前认为，做联机游戏得在服务器上去大量验证信息，很耗资源。

实际上，不考虑作弊检测的话，可以通过P2P的模式进行，服务器只需要做地址转换，所需资源量很小。

离线翻译器

一个不联网也能用的离线翻译器。

一个PPT小插件

FreeCut，一个PPT插件，可以将当前页面裁剪出来，直接导出成PDF。

游戏模组

给《逃离鸭科夫》游戏做了一个CF反馈和音效模组。

做了两个角色音效：飞虎队(男角色)和灵狐者(女角色)。

男角色先做，女角色后做，结果女角色的订阅量是男角色的两倍还多，大抵是明白了为什么游戏行业普遍要出更多的女角色了。

---

这些产品的设定之初，基于出发点都是我个人的痛点或者兴趣所致。

实用性是产品好坏的基本判断标准，如果一个产品开发出来，自己都不用，那就不是好产品。

目前经常能看到一些所谓“科技先锋”，做AI应用产品出海，整天在谷歌上搜新词，挂外链，做SEO优化。

甚至还有人通过抢注域名的方式来截大厂的流量，一个典型的例子是sora2.com，假装是sora2的官方站，结果是套壳站。

对我而言，做产品不是职业驱动，而是兴趣驱动。这就意味着我不用向钱看，而能切实解决本土用户所面临的需求。

AI发展预测

除了智能体方面，今年的AI在基础模型方面也有很大的提升，印象比较深刻的是这几个节点：

• 4月，GPT-Image上线，吉卜力画图形成风潮
• 7月，Veo3上线，视频生成首次出现音画同步
• 9月，Nano Banana上线，设计行业迎来洗牌
• 10月，Sora2上线，AI视频开始能以假乱真
• 11月，Nano Banana Pro上线，优化了中文短板，衍生出做PPT的新玩法

当然，音频领域的发展应该更大，目前刷到过很多台词替换的视频，已经栩栩如生了，但我目前还没关注，后面也打算去看一下。

总之，当前在基模领域，国外还是由OpenAI和Gemini两家在引领模型性能，国内仍处于追赶状态。

字节的豆包在应用侧持续发力，阿里的千问开始奋起直追，腾讯蓄势待发。

AI六小虎之中，百川、零一转向下桌，阶跃还在默默支撑，智谱、MiniMax开始上市续血，月之暗面还在做上市准备。

万众瞩目的DeepSeek还在做降模型成本的研究，按照去年惯性，也许憋了大招等过年再放。

目前来看，有个明显的趋势是模型即产品。

现在很多人试图在应用层，搭建所谓的Agent去优化功能，但模型本身已经朝着是Agent的方向去优化。

有些工程优化，只是临时的解决方案，比如，有人尝试用多次调用模型去分离一张图片的各个元素，而阿里最近开源的 Qwen-Image-Layered 已经能够在模型侧实现多元素分离。

但短期看，模型的迭代速度没那么快，做相关应用还有一定的窗口期。

正如llya所说，scaling law已经见顶，明年要开始转向研究时代，至少有这几个方向：

• 模型的体积会进一步缩小，成本会降低
• 手机端可能会出现端侧大模型，豆包手机的功能将成标配
• 创作方面可编辑的程度会更高，抽卡成本会下降
• AI的主动性会更强，不再是人去问AI，而是AI随时准备好，提供方案让人选择

明年的计划

对我个人而言，明年会有一些新的计划：

• 正在计划做一个完全toC的AI产品，不再需要用户自己去配API Key，而是开箱即用。
• 移动端AI的潜力很大，也许会考虑试试用移动端的算力去做AI应用。
• 当我有一个相对独立的空间后，会尝试去做一些硬件，以及3D打印。

对于有探索欲望和热情的人来说，现在的时代无疑是最好的时代。

信息获取变得简单，产品开发变得容易，唯一需要提升的就是自己的认知水平，只有认知跟上时代，才能驾驭最前沿的AI。

写这篇文章时，窗外正迎来西安今年以来的第一场鹅毛大雪。

瑞雪兆丰年，也许明年会是一个丰收之年。