DevLog:2026年1月5日

1、年前对目前的项目进行了盘点,暂定先主要推进ChatWith移动端(已使用Flutter重写)和ChatWith for Mac的开发工作

2、针对ChatWith for Mac,节前要求Cursor进行了微调,以实现“所有网络请求必须在后台线程执行,所有UI更新操作必须在主线程执行”的需求,今天起对应用进行测试,主要看是否还会在切换对话时遇到卡死问题,已经去掉了在对话中切换模型的功能,如果测试没有什么明显的问题就修改设置-关于页面、刷新README文档,并打包,版本号用v0.3

3、对比Chatbox,有几个功能后面还是要加上,比如上传图片、上传文件并由AI进行解读,这两个功能留到后面v0.5时再添加

4、接下来调整一下UI,特别是输入框,目前应用的输入框看不到边框线,且右侧的联网搜索和发送/停止按钮大小不一样,要求Cursor给对话界面的输入框增加灰色边框线,并修改联网搜索按钮,去掉已关闭、已开启的文字,只留图标

5、输入框和按钮的修改基本完成,但总感觉发送/停止按钮和联网搜索按钮大小不一样,且在测试时再次遇到了应用卡死问题,从调试信息来看,对话的输入和输出是正常的,但没有看到UI更新,继续反馈问题给Cursor,修改一次之后卡死问题更加严重,只要打开应用-打开历史对话就会卡死,再次反馈、修改

6、目前打开应用-打开历史对话暂时不会卡死了,但在翻看更早的历史对话消息时又会卡死,要求Cursor添加调试信息来定位问题,同时还询问了豆包,豆包认为所有的耗时操作都不应该放在主线程执行,比如网络请求(之前已经挪到了后台线程)和本地数据读写(涉及DataManager和MessageView等文件),修改之后Cursor指出,虽然Core Data的保存操作必须在主线程执行,但由于使用了异步执行,不会阻塞调用线程

7、再次测试,仍然会出现卡死问题,逐渐失去耐心了,询问豆包,换用 Flutter 完全可以从根源上解决这类卡死问题,且Flutter对「消息列表加载/渲染」的适配性远优于原生Swift,99%的原生卡死场景在Flutter中都能彻底规避;更关键的是,Flutter无需像原生那样做大量「线程切换、异步处理」的繁琐适配,基础写法就自带防卡死能力,开发效率更高

8、开启了一个新对话,决定在新对话中先梳理目前应用的功能,并且用Flutter来重写当前应用,步骤包括创建Flutter项目结构和基础配置、创建数据模型、实现数据层、实现AI服务层、实现视图模型、创建主界面、实现AI对话视图、实现收藏视图、实现设置视图、实现搜索视图、检查并完善所有模型类等等,耗时大概50分钟,中间还中断了一次,点击继续之后Cursor首先查可能了已有文件,了解进度,并逐步完成剩余部分

9、使用Flutter的项目结构包含models-数据模型、services-服务层、viewmodels-视图模型、views-UI视图,之后让Cursor生成了该应用的的macOS平台代码,并且在生成ephemeral文件,并修复编译错误、图标问题后,项目成功构建

10、使用Flutter构建的应用界面稍显简陋,主要的功能板块已经有了,包括对话、收藏、设置三个页面,设置中包含了AI模型管理、外观设置和数据统计,但每个界面右上角都带了一个DEBUG的标志,不知道是干啥用的,先让Cursor去掉它(debugShowCheckedModBanner),同时也问问能否把之前已有的图标文件复制过来一份,继续使用(将Swift版本的图标复制到Flutter版本,并重命名为Flutter所需的文件名格式)

11、修改过程中再次出现了频繁创建.md说明文件的情况,其实我用不到,要求Cusor清理掉

12、目前ChatWith for Mac已经实现了基于Flutter的改写,并且可以成功构建,接下来需要对各个功能进行详细测试和修改,目前已发现的问题包括:

1.在添加和修改模型时,我需要让添加和修改窗口在最前,只有点了取消或确定后才能回到主界面,现在只要一点主界面,添加和修改窗口就会被关闭

2.对话时,点击发送按钮后问题发不出去,没有任何反应

3.设置-外观设置-主题模式中,我需要跟随系统、浅色模式、深色模式三个选项,并且点击选项后可实现对应的主题模式

4.需要增加回收站功能(删除和恢复对话和收藏)和搜索功能(搜索对话和收藏)

5.设置-AI模型管理界面,需要增加删除模型按钮

13、初步修改了一轮之后,发现上面的五个问题里,

1.已解决

2.未解决,发送按钮有时可用有时不可用

3.已解决

4.需要把回收站挪到设置页的数据统计下边,即设置界面共有AI模型管理、外观设置、数据统计、回收站四个功能

5.未解决,AI模型管理界面还是没有删除模型按钮

14、继续修正问题2和问题4,问题2通过添加输入框监听器和_cansend状态变量,已完成修改,问题4主要是在entitlements文件中添加了com.apple.security.network.client权限,允许应用进行网络请求,已完成修改,并且在测试过程中发现之前使用Swift实现的深度思考、流式输出等功能均可正常使用

15、继续修正问题5,通过移除if(config.isCustom)条件判断,改为每个模型后边都会显示删除按钮,解决了问题

16、明天继续修改其他问题,包括:

1.把右上角的搜索按钮挪到最左侧,放在“对话”上面

2.明确对话列表的显示规则,标题直接用用户提出的最后一个问题,下面小字显示最后一次回答的内容,只显示一行

3.对话列表和收藏列表的宽度都固定为300,且不需要拖动调整

4.其他问题视测试情况而定

DevLog:2025年11月7日

1、今天再次遇到了用ChatWith for Mac对话时应用卡住的问题,但强制退出、重新对话时又能正常对话了,猜测可能是因为单个对话中内容比较多时,应用还未加载完成就提问,就会导致应用卡死?而且我还发现在不同对话间切换时,有时不会直接跳到最新的对话底部,有时还需要滚动一下才能看到对话内容,体验上也不够统一,继续优化,并且需要把停止生成按钮、快捷键支持、代码块复制、消息时间显示、数据导出功能、使用统计这些功能加进来,测试基本完善后,更新版本号为v0.3,移动端NoteWith的开发暂停

2、向Cursor反馈了这些问题,询问是否是因为内容加载机制导致的,Cursor分析后表示的确和对话内容加载机制有关,主要包括“流式更新时频繁遍历Core Data关系”和“每次保存都整表刷新会话列表”,建议拆分保存和刷新逻辑,减少loadAISessions()调用频率,或换成增量更新,同时在切换会话和流式结束后再合适地触发滚动,避免“滚动到底部”信号在数据还没稳定时被打断

3、具体操作上,需要先重构流式消息的更新方式,再优化Core Data刷新的节奏,修改一次之后依然存在打开对话窗口时不自动滚动到最新对话底部的情况,再次让Cursor修改之后可以自动滚到到最新对话底部了

4、接下来开始增加一些小功能,包括停止生成按钮、快捷键支持、代码块复制、消息时间显示、数据导出功能、使用统计,先增加停止生成按钮(发送消息后、正在回答时发送按钮变成停止生成按钮,点击可以停止生成)、消息时间显示(显示绝对时间),这两个功能都在AI对话界面里,其他功能稍等

5、修改过程中发现,今天Cursor的对话的语言风格突然变了,可能是Auto模式换成了另一个模型?而且也不会根据我之前的要求自动进行构建测试了,甚至在我要求进行构建测试时,也会出现因为权限问题导致的构建失败,挺奇怪的

6、修改之后测试发现已经有了停止生成按钮(但未测试)和消息时间显示功能,连续询问了三个问题,前两个问题都可以正常回答,但第三个问题在点击发送后应用就卡死了,我提交了调试信息,Cursor再次进行了节流流式更新、结束时一次性收尾、降低Core Data压力等优化,这次依然没有自动进行构建测试,那我只有自己继续测试了,连续多轮对话看是不是还会被卡死

7、连续问到第三个问题时应用依然会卡死,再次让Cursor修改,流式输出过程中只往缓冲区追加字符串,不直接操作Core Data,用定时器把写库和UI刷新节流到120ms等操作,这样每条回复只会做少量大块复制,避免了第三次对话时的主线程卡顿(当然这都是Cursor说的,具体体验如何还得看测试结果),再次测试,打开上次因卡死未收到回复的对话时也被卡死了,这次Cursor进行了清理空白AI消息、修改滚动逻辑、思考内容默认折叠(我还是更希望默认展开)等操作,再次测试,切换对话、切换模型后提问时依然有问题

8、这两天对ChatWith应用卡死问题的修改不是很顺畅,开始反思到底有没有必要在同一个对话里切换模型,对这种操作的支持,可能增加了应用的复杂性,如果增加一个默认模型机制(其实一开始是有的,但我给去掉了),每次创建新对话时就直接用默认模型,或者在新建对话时即要求用户选择模型,在一个对话中只允许使用一个模型,可能会更简单一些,但我最初借鉴的Chatbox和Cherry Studio,的确都支持在对话过程中切换模型

打工人接入DeepSeek-R1 API不完全指南

这段时间DeepSeek爆火,工作中使用DeepSeek-R1的频率也越来越高,但DeepSeek官方的服务经常会出现服务器繁忙问题,基本无法正常使用,相信大家也经常遇到。解决办法有两个,一是使用已经接入了DeepSeek-R1的其它AI App,比如腾讯元宝、百度App、纳米AI搜索、Monica、Poe等等,二是使用云服务厂商或者硅基流动这种MaaS提供商都提供的DeepSeek-R1的API。这篇笔记结合这段时间的使用经历,给大家盘点一下哪家的客户端和API更好用。

说明一下,申请API,和在客户端中接入API都需要一点点动手能力,如果懒得搞,可以用去用上文提到的那些App。但对于工作场景来说,我还是更推荐去申请、接入API,更利于专注工作,不被各家厂商各种形式的广告或引流手段干扰。而且这不仅仅是DeepSeek官方服务不稳定时的一个过渡手段,更能给后续使用其它API积累一些经验。

1、怎样申请API

去DeepSeek开放平台、硅基流动或火山引擎官网注册账号、实名认证、选择模型、获取并复制API Key,不同平台在操作上略有区别。

2、用哪个客户端接入API

这里我主要推荐两款App,Chatbox和Cherry Studio,需要注意的是这段时间两款App更新非常频繁,如下内容仅说明了我在写这篇笔记时使用的版本功能。

Chatbox(Mac端版本号1.10.4,安卓端版本号1.9.8)

优势:

电脑端和手机端都有App;

接入API非常简单,预置了一些常用的AI服务,只需填写API Key就能使用;

预置了一些“搭档”可以添加使用,可以分别调用不同的模型;

支持联网搜索,会给出所有的参考链接,并且免费,点亮工具栏的地球就可以了。

不足:

不同模型的切换略显复杂;

思考过程的展现和对话内容的输出会卡顿,一段一段的蹦出来,不够流畅;

界面设计较为粗糙,或者说复古;

对话记录和模型设置无法做到多端同步(没有账号系统,希望后续能够上线)。

Cherry Studio(Mac端版本号1.0.4,安卓端无)

优势:

接入API非常简单,预置了比Chatbox更多的常用的AI服务,特别是大量国内的大模型,只需填写API Key就能使用;

支持自行设置助手,分别调用不同的模型;

预置了一些“智能体”可以添加使用,可以分别调用不同的模型;

不同模型的切换非常简单;

思考过程的展现和对话内容的输出都非常流畅;

以小程序(或者说网页)的形式提供了40余个大模型,点击并登录就能使用;

界面美观,设计比较现代;

支持翻译、生成图片等等办公中常用的功能;

最新版本可通过申请tavily的API实现全部模型联网搜索,会给出所有的参考链接,每月可以免费使用1000次,解决了下文会说到的部分API无法联网获取最新信息的问题,默认会提供5个搜索结果,可调整至最多20个,并且可以设置搜索结果黑名单,屏蔽来自部分网站的搜索结果。

不足:

暂无手机端App,仅有电脑端App;

对话记录和模型设置无法做到多端同步(没有账号系统,希望后续能够上线);

支持知识库功能的模型非常有限,我接入了DeepSeek官方、硅基流动、火山方舟三家的多个模型,其中仅有硅基流动提供的BAAI/bge-m3向量模型支持知识库。

3、哪家的API好用?

DeepSeek官方提供的API:

服务不稳定,经常遇到因繁忙不响应的情况,且API本身不支持联网搜索最新信息,时不时的就用英文回答我,像极了GPT-4刚上线那段时间。

硅基流动提供的API:

服务稳定性居中,偶尔会不响应,或者响应速度比较慢,且API本身不支持联网搜索最新信息,也会时不时的就用英文回答我。

不知道大家有没有遇到这个问题,硅基流动的API貌似需要先充值(充几块钱就行)才能使用,如果不充值会提示连接失败,充值之后立刻就能正常使用。

火山引擎提供的API:

服务稳定,响应速度快,在我使用的这段时间基本没有遇到不响应的情况,且API本身就已支持联网搜索最新信息(唯一的不足是看不到具体参考了哪些链接)。

综上,目前看来最稳定、功能最完整的API,是火山方舟提供的deepseek-r1 。

3、哪家的API更便宜?

DeepSeek官方API价格(deepseek-reasoner):

百万tokens输入(缓存命中)1元,百万tokens输入(缓存未命中)4元,百万tokens输出16元。

硅基流动API价格(Pro/deepseek-ai/DeepSeek-R1):

百万tokens输入4元,百万tokens输出16元,目前赠送14元。

火山引擎API价格(deepseek-r1):

百万tokens输入4元,百万tokens输出16元,目前赠送50万tokens免费额度。

综上,个人比较推荐的两个组合是:

电脑端:Cherry Studio+火山引擎/硅基流动的DeepSeek API

手机端:腾讯元宝/Chatbox+火山引擎的DeepSeek API

大家还有哪些用起来很顺手的组合?欢迎讨论。

最初发布于2025年3月5日