DevLog:2026年1月26日

1、截至目前,四款应用问题如下,加粗内容暂未修复:

1.DoitWith

-在添加Todo和编辑Todo的界面中增加“优先级”选项,包括“高”和“低”两个选项,放在“下一步”和“分组”之间

-在“待办”和“已完成”中间加一个“四象限”,共有四个大卡片,在卡片中罗列符合条件的Todo条目

-当天到期且优先级为高的在右上,当天到期且优先级为低的在右下,非当天到期且优先级为高的在左上,非当天到期且优先级为低的在左下,四个卡片的颜色略有区别,右上为浅红色,右下和左上为浅黄色,左下为浅绿色

-在这四个大卡片中,有“下一步”的Todo位置靠上,没有“下一步”的Todo位置靠下

-卡片上,每条Todo只显示标题和下一步,没有下一步的Todo就只显示标题

-四象限界面的Todo条目显示效果还有待优化,现在有些简单

-当天到期的Todo,早上九点推送通知

-添加小组件,小组件上显示当天到期的Todo,信息包括所在分组、标题、下一步

2.DoitWith for Mac

-简化优先级设置,只留“低”和“高”两个选项

-在全部Todo和已完成Todo之间增加“四象限”Tab,和手机端的四象限划分逻辑、Todo显示逻辑保持一致,但这个Tab可能不需要像另外两个Tab那样分为三栏,样式上要有区别

-调整新建分组、添加和编辑Todo窗口的视觉效果,部分图标和文字太小

-设置-关于页面下方增加“近期更新”区域,由Cursor总结近期更新了哪些功能

3.ChatWith

-首次启动时启动速度超级慢,大概要20秒左右

-清除后台后,再打开应用秒闪退,无法使用

-发送消息后立刻显示在对话界面内,现在好像是在AI有响应后才会显示

4.ChatWith for Mac

-在AI对话中是否可以调用笔记内容作为参考

-火山引擎的Bot无法显示思考过程,即使其使用的是支持深度思考的DeepSeek

-OpenRouter提供的Claude API无法正常使用,测试返回403错误

-界面上有些文字需要改小一点,比如设置列表中的文字、对话列表和对话详情页上的“对话”、笔记列表和笔记详情页上的“笔记”、搜索页面顶部的“搜索”

-笔记详情页,未打开笔记时会显示“还没有笔记 从AI对话中保存内容到这里”,改成“请选择一个笔记或创建新笔记”,跟对话详情页的空状态提示字体大小一致

-在笔记界面,笔记列表中标题下的小字仅显示纯文本,不要显示富文本符号或Markdown语法标记

-笔记编辑视图的工具栏现在是居中对齐,需要改成靠左对齐

-关于页面的“初始版本发布”放到最上边

-优化上传附件和图片后的显示效果,比如取消附件和图标的红叉需要改小一些

2、这两天先修改DoitWith和DoitWith for Mac,增加四象限功能板块,先是DoitWith移动版,需求包括:

1.在添加Todo和编辑Todo的界面中增加“优先级”选项,包括“高”和“低”两个选项,放在“下一步”和“分组”之间

2.在“待办”Tab和“已完成”Tab中间加一个“四象限”Tab,该Tab内共有四个大卡片,在卡片中罗列符合条件的Todo条目

3.当天到期且优先级为高的在右上,当天到期且优先级为低的在右下,非当天到期且优先级为高的在左上,非当天到期且优先级为低的在左下,四个卡片的颜色略有区别,右上为浅红色,右下和左上为浅黄色,左下为浅绿色

4.在这四个大卡片中,有“下一步”的Todo位置靠上,没有“下一步”的Todo位置靠下

5.卡片上,每条Todo只显示标题和下一步,没有下一步的Todo就只显示标题

3、针对这5条需求,修改点包括在结构体中添加优先级字段、添加优先级选择器、添加四象限Tab、创建QuadrantView视图以实现四象限布局和逻辑等等,首次构建即成功,但四象限页面的显示效果还需要优化,比如四个卡片可以都用长方形,让四个卡片占满整个界面,现在底部有大片空白,“重要不紧急”、“重要紧急”、“不重要不紧急”、“不重要紧急”放到四个卡片顶部居中,另外,已过期且优先级为高的Todo也显示在“重要紧急”卡片里,已过期且优先级为低的Todo显示在“不重要紧急”卡片里,最后把“重要紧急”改成“重要且紧急”

4、修改后再次构建测试,发现这次四象限占满了整个屏幕,Cursor使用的GeometryReader可能不合适,反馈后,添加了边框和内边距,并且移除了全屏布局,让内容在安全区域内显示,再次测试,效果基本符合预期,但首次遇到了紫色的警告信息,原因在于当可用空间不足时,计算可能为负,需要改用更安全的方式来计算卡片尺寸,包括移除手动尺寸计算、使用自适应布局、添加ScrollView等,调整后四个卡片又变成了正方形,在将卡片的最小高度调整至320之后,基本达成需求

5、DoitWith移动版修改告一段落,接下来继续优化ChatWith for Mac,目前界面上比较明显的问题在于略显粗糙,而且有大量的依赖版本比较旧,也需要更新,昨天在用ChatWith for Mac的源文件开发iOS版之后,今天构建测试Mac版,又需要运行一次pod install,然后成功构建,继续检查并修复问题

6、首先是设置-关于页面,把初始版本发布挪到近期更新的最前边,然后修复该页面的底部溢出问题(内容太多时底部会出现BOTTOM OVERFLOWED BY XX PIXELS的提示),解决方法是用SingleChildScrollView包裹整个内容,窗口较小时可滚动查看,构建测试,问题已修复

7、上传附件和图片后,附件图标/缩略图右上方的红叉现在太大了,需要改小一点,另外附件图标/缩略图的圆角边框也显示不全,针对这一需求,Cursor将红叉图标从16缩小至12,并调整了位置,同时优化了圆角边框显示,上传附件预览区域和消息中的附件显示做了同步调整,构建测试,需求已达成

8、在设置-AI模型管理中添加了火山引擎的Bot,提供商选自定义,高级设置中填写完整URL(包含/chat/completions),测试通过,但对话时收到了“错误:未收到任何响应内容”的提示,Cursor添加了更详细的诊断信息,经过多次修改,并修复构建问题(又出现了反复创建脚本修改、反复运行脚本失败的循环),之后打断,要求直接检查有没有语法错误,修复之后成功构建,已经可以和火山引擎的Bot对话,但看不到思考过程,后面还需要再让Cursor检查并增加

9、然后是在与支持文档/图片的claude 3.7对话时,出现了“错误:访问被拒绝,请检查API Key权限”的提示,在测试模型时出现了403错误(为啥之前好好的,现在又不行了?),Cursor添加了OpenRouter推荐请求头,改进了错误处理,并统一了请求头格式,再次构建测试,依然403,并且提示“this model is not available in your region”,这种像是被墙了的提示,可是这个API我在Chatbox中使用时是完全正常的,多次修改后依然未能解决,而且好像越改越复杂了,之前没有这么复杂时也可以正常使用

10、发现在笔记界面,笔记列表中标题下的小字显示了富文本符号或Markdown语法标记,而不是纯文本,观感上有些不好,Cursor同时在笔记列表视图、搜索视图、回收站视图、回收站设置视图中添加了_stripMarkdownAndRichText函数,用于清理富文本符号和Markdown标记,测试发现已经去掉了Markdown标记,但富文本符号依然存在,再次修改(添加dart:convert导入,用于解析JSON格式的Quill Delta数据,并增强上述函数)之后,需求达成

11、然后改一下笔记编辑视图的工具栏,现在是居中对齐,需要改成靠左对齐,Cursor用Row包装了QuillSimpleToolbar的工具栏,并设置了左对齐,但如果缩小编辑窗口,导致一行无法显示所有的工具按钮时,会出现“RIGHT OVERFLOWED BY XX PIXELS”的提示(溢出了),再次反馈修改,这次又给工具栏包装了一层SingleChildScrollView,并且启动了水平滚动,在保持左对齐、避免溢出的同时,当窗口宽度不足时,工具栏可水平滚动查看所有按钮,需求达成

12、界面上有些文字需要改小一点,现在有些突兀,比如设置列表中的文字、对话列表和对话详情页上的“对话”、笔记列表和笔记详情页上的“笔记”、搜索页面顶部的“搜索”等等, 反馈给Cursor后,发现它将多处20号字改成了16号字,于是再次要求它直接将其它20号字也改成16号字,再把设置详情等界面里超过16号的文字都统一成16号字(除了关于ChatWith界面的ChatWith标题保持在32号不变),这下整体看起来协调多了

13、然后优化笔记详情页的空状态提示,现在未打开笔记时会显示“还没有笔记 从AI对话中保存内容到这里”,改成“请选择一个笔记或创建新笔记”,跟对话详情页的空状态提示字体大小一致

14、经过这一下午对ChatWith for Mac的修改,发现它的细节问题还是挺多的,还是需要在后续使用中陆续发现、修改

15、DevLog已记录100天,明天起仅记录当天修复、调整、新增的功能和重要心得,不记录完整的修改过程

DevLog:2026年1月11日

1、继续修复发送图片给Claude API时的问题,包括图片缩略图无法正常显示、发送图片给Claude API后返回HTTP 400错误,针对缩略图问题,添加了文件存在性检查、优化错误处理、添加调试日志,针对HTTP 400错误,调整了系统消息处理、历史消息格式和消息构建顺序,但测试发现问题依然存在,缩略图依然不能正常显示

2、结合调试信息,Cursor认为问题在于应用无法访问用户选择的图片文件(如桌面上的文件),因为macOS沙盒限制,解决方案是在用户选择图片后,将文件复制到应用沙盒目录(文档目录),并保存复制后的路径,但依然没有解决问题

3、针对这一问题进行了多次修改,中途Cursor还认为可能是因为OpenRouter提供的Claude API和Anthropic官方的Claude API在图片代码格式上的区别导致的,在与Chatbox对话,确认OpenRouter提供的Claude Sonnet 4 API支持读取图片之后,再次让Cursor检查并修复问题

4、后来发现在一个对话中,如果默认模型不是Claude Sonnet 4,即使在对话中切换模型为Claude Sonnet 4,发送图片后也会回答“我目前无法直接查看和分析您上传的图片”之类的话,但在设置中将Claude Sonnet 4设为默认模型后,就可以读取图片了,但是返回的回答内容显示不完整,并且在调试信息中会有大量的“解析JSON错误”

5、Cursor认为这是流式响应解析问题,SSE流式响应中的JSON数据可能是分块的,导致JSON不完整,需要在解析前检查JSON是否完整,修复过程包括添加缓冲区、检查JSON完整性,同时移除了错误日志,再次测试后读取和输出正常

6、发现一个新问题,在对话界面右上角切换模型后,显示为新的模型,但仍然在跟切换前的模型对话,原因在于切换模型时,代码只更新了数据库和父组件的session,但ViewModel的_currentSession没有被更新,sendMessage方法中使用的是_currentSession,所以即使切换了模型,实际使用的仍是旧的session配置

7、Cursor修改之后,再次测试发现模型仍然不能正确切换,从支持深度思考的模型A切换至不支持深度思考的模型B后再提问,仍然是模型A在回答我,只是不显示思考过程,并不是由模型B来回答我,这是不对的,这次修改包括添加updateCurrentSession方法、修改sendMessage方法,这样在切换模型后,ViewModel的_currentSession会被正确更新,再次测试后模型切换正常,并且会结合上文内容回答我

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日