DevLog:2025年9月17日

1、昨天已经基本实现了模型添加、AI对话的基础功能,今天继续完善,首先是添加多个模型并在对话时切换模型,首先在添加两个模型之后,发现设置-可用模型的模型列表里,两个模型之间有两条分割线,而且创建新模型时,无法保存我填写的新API密钥和基础URL,而是沿用了我添加的第一个模型的API密钥和基础URL

2、首先更新了AIModel结构体,添加了apiKey和baseURL字段,移除了isDefault字段,修复了ModelEditView的保存逻辑,更新了模型测试逻辑和对话配置逻辑,使用模型自己的API配置进行对话,而不是使用全局的API配置(早就应该这样了),然后移除了modelRow函数中的Divider():,去掉了多余的分割线,再次测试,两个问题成功解决

3、但AI对话窗口里又出现了回答在上、问题在下的情况,另外切换模型的弹窗显示也有问题,先修复切换模型的弹窗的显示效果,同时修复一下AI对话列表的选中状态,目前根本看不出来选中了哪个对话,修改后仍然不能在对话列表中标示出当前选中的对话,还需要再修改

4、先用硅基流动的DeepSeek R1 API测试了一个需要联网获取最新信息的问题,发现目前思考过程没有展示、AI回答内容没有经Markdown渲染、看不到Tavily提供的资料链接,决定让Cursor同时修复这些问题,并明确要求使用MarkdownUI来进行Markdown渲染,其实之前已经有了一部分支持这些功能的代码,但功能不完整,Cursor列出了Todo,一步步修改,稍后一并给Cursor反馈问题

5、Cursor一次修改了思考过程展示/折叠和展开、Markdown渲染、Tavily资料链接显示等功能,其中在Markdown渲染上,先创建了一个新的文件MarkdownView,但没有添加到项目里,提示构建失败,于是又重新启用现有的MarkdownRenderer,并且引入了MarkdownUI,同时还保留了自定义AttributedString实现作为备选方案,原因貌似是MarkdownUI只支持14.0以上的macOS,我觉得没有必要保留备选方案,之前修改NoteWith时已经验证了MarkdownUI的渲染效果,于是要求Cursor去掉了自定义实现相关代码,使用MarkdownUI作为唯一的渲染方案,MarkdownRenderer代码更加简洁了

6、接下来测试一下思考过程、Markdown渲染、Tavily链接的显示效果,先把AI对话内容的显示顺序搞定,然后处理了一下点击AI对话右上角无法切换模型的问题(原因是ChatView的模型选择回调中代码被注释掉了,没有实际实现模型切换功能,而且每个对话都显示第一个可用模型,而不是用户选择的模型,模型切换没有保存到对话中,我需要为每个对话独立保存选择的模型),Cursor自称目前已经实现如下目标:新对话默认使用第一个可用模型、点击右上角的模型名称选择其它模型、选择的模型立即保存到该对话中、每个对话都有自己独立的模型选择、重启应用后每个对话仍然使用之前选择的模型

7、模型可以正常切换了,但试了几个问题,发现无法触发应用通过Tavily获取最新信息,Cursor分析发现虽然Tavily密钥已经存储在模型中,但实际的消息发送逻辑中没有使用Tavily服务,需要实现Tavily集成,创建了一个新的Tavily服务类TavilyService,并修改了OpenAIService,表示当提问时应用会自动通过Tavily获取最新信息

8、测试发现即使是不支持深度思考的模型,回答内容里也会出现思考过程区域,而且回答内容没有经过Markdown渲染,也看不到Tavily的资料链接,在用MarkdownUI来实现Markdown渲染效果的过程中,Cursor多次创建和删除Package文件(因为一直没有真正引入MarkdownUI),多次用命令行修改MarkdownRenderer,多次尝试不使用MarkdownUI,而是换用SwiftUI的原生功能来实现基本的Markdown渲染,不知道为啥今天反复出现这种“退步”的操作,我多次打断,反复强调要用MarkdownUI来渲染

9、已经有部分文字可以呈现渲染后的效果,但表格还是无法正常显示,参考NoteWith,可能要对表格和代码块的显示进行单独的优化,猜测上面重复同样的操作可能是因为这个对话的上下文太长了导致的,后面在Cursor里开一个新对话再修改这些内容

10、又遇到了刚刚进行的问答没有被保存到对话里的问题,在修改ChatWith,将用户消息和AI消息更新后都调用onUpdate将其保存到Core Data后,问题解决

11、在修改MarkdownRenderer以支持对表格和代码块的渲染优化时,Cursor反复检查MarkdownUI的版本、添加MarkdownUI默认的表格和代码块渲染样式、添加自定义的表格和代码块渲染样式,然后删除这些内容,多次操作后相当于没有做任何的修改

12、决定试试让Cursor创建单独的文件来处理表格和代码块的渲染,并且使用MarkdownUI,Cursor创建了TableRenderer和CodeBlockRenderer,并将新文件添加到项目,但多次尝试后,即使已经将这两个新文件集成到AssistantMessageView之后,仍然未能实现对表格的正常渲染

13、由于目前的ChatWith是由iOS应用修改而来,且在修改过程中对代码和架构进行了大量的调整,怀疑目前有部分文件功能是重复的,让Cursor列举结构和分工后发现ChatWrapper是多余的、ChatView过于庞大、且组件职责不清晰,比如ChatMessageListSection和ChatMessageListView功能重复、ChatInputSection和ChatInputView功能重复,Cursor建议简化架构、删除冗余文件、重新组织文件结构,决定让Cursor实施这些优化

14、修改完成后架构更清晰(每个文件职责单一,易于维护,减少了不必要的中间层),代码更简洁(ChatView从436行减少到约280行,移除了重复的组件子定义),维护性更好(组件独立,便于单独测试和修改,文件结构更符合SwiftUI最佳实践),当然每次Cursor在修改完后都会这么说,还是要实际测试一下修改成果

15、继续测试具体的功能,首先发现在与支持深度思考的DeepSeek R1模型对话时,思考内容和回答内容混在了一起,未能像之前规划的那样分成两块,并且思考内容要可以折叠,可以展开,Cursor在分析后修改了OpenAIService中的seperateThinkAndAnswer函数,以正确解析思考内容,但仍然没有解决问题

16、我现在觉得可能将iOS版的ChatWith修改成Mac版,再逐个测试、恢复功能,可能是做了大量的重复工作,既然之前NoteWith for Mac已经基本可用了,那其实可以对它进行简化,实现我对ChatWith for Mac的一系列需求,于是复制了一份NoteWith for Mac的源文件,并要求Cursor将应用的名字改成ChatWith,这一过程包括将应用名称由NoteWith改为ChatWith、更新XCode项目文件中的名称引用、更新Swift文件中的名称引用、更新Info.plist文件、重命名相关文件夹和文件等

17、Cursor很快完成了修改,并且按照我的反馈替换掉了一些漏网之鱼,接下来就是去掉待办事项模块、测试功能了,后面可能还要把备忘录替换为收藏,去掉待办事项模块及相关功能包括了分析待办事项模块的组件和依赖、移除待办事项相关的数据模型、移除待办事项相关的视图、移除待办事项相关的视图模型、从DataManager中移除待办事项相关代码、从导航中移除待办事项相关项目、从项目文件中移除待办事项相关文件等步骤,并且根据我的反馈删掉了两处遗留的待办事项相关功能

18、构建成功后,整理了文件结构,特别是Views文件夹下既有AIChat和Notes两个文件夹来存放AI对话和备忘录相关的视图文件,又有大量视图文件散落在Views文件夹下,ViewModels文件夹也有类似问题,移动文件并更新project.pbxproj中的路径后,问题解决,结构清晰了一些

DevLog:2025年9月16日

1、今天首先解决昨天的遗留问题,统一一下应用的布局,改成三栏布局,最左边是应用的名字,以及对话、收藏、设置 三个按钮,中间栏是对话列表、收藏列表和设置大项,第三栏是对应的详情,Cursor延续了昨天的NavigationSplitView,并且创建了AppSidebar和MiddleSideBar组件(都在ContentView里,后面可能也要拆分这个文件了),然后修改了多个文件来匹配三栏布局

2、最左侧导航栏的颜色、图标、文字大小等样式都还可以,但目前对话界面缺少了创建对话按钮,设置界面的详情显示也都比较局促,需要继续调整布局和功能,比如:

1.模型设置界面需要有多模型管理功能,可以添加、删除、测试模型,并且增加Tavily联网搜索能力的支持,Base URL需要具备自动补全能力

2.增加回收站功能,可以管理已删除的对话和收藏,并且按钮放在数据统计和外观设置之间

3.外观设置的样式也需要改一下,现在这种横向三个按钮切换显得很局促

3、接下来一步步修改,先从模型的添加、修改、删除、测试功能开始,第一次修改后效果不佳,我发现DetailView好像包含了对话、收藏、设置三个模块的最右侧区域,于是让Cursor将其拆分为单独的文件,ConversationDetailView、FavoriteDetailView、SettingsDetailView,拆分后DetailView由596行代码缩减成了42行,并且新创建的三个文件每个文件都专注于特定功能,代码结构清晰了一些

4、现在添加模型的弹窗显示不正常,可填写信息的窗口只有很小一块,存在大片空白,无法正常使用,让Cursor修复,同时删除可用模型列表顶部的API配置按钮,我不需要在列表里配置API Key和BASE URL

5、然后调整弹窗的功能,包括给弹窗增加Tavily密钥字段,放在API配置的最后,弹窗底部增加取消和保存两个按钮,去掉“默认模型”相关的设置等等,现在弹窗信息可以完整显示,并且效果还可以,然后删除了部分按钮的边框线,去掉了“默认”标识,但Cursor标识在删除当前使用的模型时会自动切换到第一个可用的模型,看样子还是有类似默认模型、当前模型的设置,还是要清理掉

6、开始添加模型,测试后决定,删掉应用预置的默认模型配置,所有的模型都由用户来自行设置,另外在点击测试时,无需通过弹窗提示测试结果,直接在列表里模型名称的下方显示测试结果,比如错误信息、响应时间等,然后修正部分问题,比如在添加模型后重启应用模型信息会消失,创建新模型时可以看到之前填写的API KEY和Base URL

7、发现SettingsView里目前还有一些AI模型相关设置,但刚刚这些修改都不涉及SettingsView,怀疑可能有部分代码未被使用,询问后发现整个文件都未被使用,并且SidebarView里也有部分过时代码,一并进行了清理

7、看起来暂时没有引发新的问题,目前已经添加了第一个模型,继续测试AI对话功能,首先就是对话界面缺少了创建新对话按钮,把这个按钮加在对话界面右上角,测试发现即使是经过测试提示连接成功的模型,也无法正常对话,Cursor表示目前没有实现真正的模型测试功能,没有真正调用API,怪不得每次测试连接时间都是1.2s,并且ChatView使用的是全局的AppStorage值,而不是用户选择的模型配置,在修改过程中Cursor添加了一些调试信息,发现可能是因为currentModelID为空字符串,导致无法找到匹配的模型,系统回退到默认配置gpt-3.5-turbo,而不是我自己配置的模型

8、这就是上面说的“当前模型”的设置,要求Cursor去掉这个增加了应用复杂性的功能,在开启对话时,直接用可用模型列表里的第一个模型

9、测试了几次对话,但发送消息后会报错400,结合Cursor添加的调试信息,多次反馈后定位了问题,然后修正了AI对话内容无法保存的问题,可能是未能将新对话和更新的对话保存到Core Data,至此已经基本实现了添加模型、AI对话的基础操作

10、修改了AI对话消息的显示顺序,改成问题在上、回答在下,明天再继续完善功能,比如添加多个模型、测试模型的切换效果,完善AI对话列表的选中状态提示、更新时间、置顶/取消置顶等右键菜单操作

DevLog:2025年9月8日

1、上周在修改NoteWith时,通过调试信息发现目前AI对话并不是真正的流式输出,而是在完整回答后模拟流式输出,Cursor建议使用真正的流式API,实现增量渲染(只渲染新增部分),并且缓存已渲染的组件,避免重复解析,今天先修改这个问题
2、在修改过程中,遇到了AI回答内容不完整显示(但调试信息里是完整的)、问题只有一行时下方有一行空白、流式输出内容的汉字显示为乱码等问题,最终实现了真正的流式API调用,通过修改AIService,新增streamAIModel方法,实现了流式响应和实时解析数据,AI一开始生成内容就立即显示,用户能更快看到回答开始,使用起来更流畅了,并且测试发现思考过程也可流式输出
3、至于汉字显示为乱码,是因为之前的逐字节处理流式数据,但UTF-8编码的中文字符,一个字符能占用2-4个字节,这就会导致中文字符被截断,从而显示为乱码
4、有意思的是Cursor竟然从我发送的全是乱码的AI回答内容中看出了我真实的问题,并在修改代码后问我“关于您提到的OpenRouter vs Anthropic官方API的对比,这是一个很好的技术选择问题。如果您需要进一步的建议或想要实现特定的API集成,请告诉我!”
5、用百度云千帆的DeepSeek-R1-250528写了一个斜体字Markdown语法正则表达式,试试看能否解决备忘录预览界面斜体字无法正常渲染的问题,测试发现没能解决,斜体字依然无法显示为斜体
6、AI回答内容中的表格一直无法正常渲染,特别像是仅仅把表格中的文字复制出来,根本不像个表格,于是询问Cursor能否用类似CodeBlocksView的形式,创建一个单独的文件来渲染AI回答内容中的表格?Cursor创建表格渲染组件,包含表格解析器TableParser、表格视图TableView、表格渲染视图MarkdownWithTablesView
7、创建新文件之后,经历了多次测试和修改,仍然无法正常渲染,包括看不见我提出的问题,看不见AI回答中的文本内容(基本上除了表格之外,其它的对话内容都看不到,但深度思考内容和参考链接区域没有受影响)等等,多次添加调试信息、反馈调试信息后仍然无果,决定发起一个新的Cursor对话再试试
8、看了一眼Cursor网站的DashBoard,出现了“Analytics are currently degraded and showing incomplete data. We’re working on resolving this issue. You can subscribe to updates here.”这样的提示,看来Cursor终于发现了数据统计功能的问题
9、询问Cursor发现当前AI问答内容全都是在使用新创建的MarkdownWithTablesView来渲染,和我理解的不一样,我希望的是在AI回答中有表格时使用MarkdownWithTablesView来渲染表格,在AI回答中有代码块时,使用MarkdownWithCodeBlocksView来渲染代码块,于是让Cursor创建了一个新的组件UnifiedMarkdownView来统一处理文本内容,并修改MessageView来使用分离的渲染逻辑,这样避免了功能冲突,可以看到AI问答中表格以外的其它内容了
10、但UnifiedMarkdownView对普通文本的渲染使用了简单的Text组件,丢失了Markdown渲染效果,后续还是要换成NSTextView,以实现良好的Markdown渲染效果、文字选择、右键菜单等功能,明天再完善UnifiedMarkdownView

DevLog:2025年9月5日

1、继续测试和优化体验,前两天盘了下各个API平台的余额,发现百度云千帆和硅基流动上还各有五六十块钱,先用硅基流动的API来测试NoteWith的AI对话功能了
2、首先就是在添加模型时,硅基流动官方文档里提到base url是https://api.siliconflow.cn/v1,但我直接填写这个url之后,在测试时仍然提示404错误,去掉后面的v1就好了,可能是因为之前我让Cursor添加了base url自动补全功能,所以现在只需要填写AI服务的根地址就行了
3、然后是在AI对话中切换模型时,选择AI模型的界面,每个模型都显示了模型的名称和“自定义模型”两行文字,我不需要“自定义模型”,我需要在这个页面看到每个模型的备注和模型名称两个字段的信息,Cursor删除了AIModelSelectorView中“硬编码”的“自定义模型”文字,并且完成了修改
4、接下来优化一下流式输出,发现AI回答内容像是在一段一段地输出,并且在AI回答内容输出之前就会有一条白色的区域,然后“AI正在思考中”前面的加载图标也比较大
5、Cursor表示目前的流式输出回答内容的分块是160字符,减少到了50字符,同时将思考过程的分块从80字符减少到了40字符,输出间隔时间也有缩减,至于在AI回答内容输出之前的白色区域,通过修改MessageView,只有当消息内容不为空时才显示消息内容区域,只有消息有内容时才会显示操作按钮(收藏、复制、删除),避免了空消息占位符显示白色背景区域的问题,然后缩小了“AI正在思考中”前面的加载图标
6、流式输出回答内容的分块还是有点大,还可以再缩小一些,另外由于目前AI回答中的文本内容渲染采用了NSTextView,虽然可以看到渲染后的结果,但语法标记所占的位置都显示成了空格,效果不是很好,这样做的原因是之前想要复制部分回答内容
7、尝试继续完善文本的渲染效果,将语法标记完全移除而不是设置为透明,这次竟然真的搞定了!真是万万没想到
8、然后调整下AI对话的标题,之前已经修改了AIChatView,目前它只负责AI对话详情页,也就是AI对话模块的第三栏,这页左上角的标题目前固定显示为“AI对话”,决定将其改为显示当前AI对话的标题,如果我没有打开任何对话,则显示为“AI对话”,如果我打开了某个对话,就显示当前对话的标题
9、发现AI对话内容(无论是提问还是回答)的底部都有一小条空白,Cursor表示这是因为消息容器的边距和内容区域的边距叠加导致的,稍微缩减了一下,目前显示效果还行
10、在测试时我发现调试信息里很早就已经出现了API返回的回答内容,但迟迟不见AI对话界面显示回答内容,猜测可能是API返回回答内容之后,先用MarkdownWithCodeBlocksView完成渲染,再流式输出到AI对话界面,实际上是API返回完整回答(AIService),然后分块流式输出(AIViewModel),再实时渲染(MessageView+MarkdownWithCodeBlocksView)
11、这不是真正的流式API,而是完整回答后模拟流式输出,由于这种方式每次内容更新都会重新渲染整个Markdown内容,可能会在长回答时造成性能开销,导致渲染闪烁(特别是复杂格式),Cursor建议使用真正的流式API,实现增量渲染(只渲染新增部分),并且缓存已渲染的组件,避免重复解析

DevLog:2025年8月11日

1、今天先试一下上周五新增的Tavily联网搜索功能是否可用,但在Xcode模拟器中打开应用发现,添加Tavily API字段之后原本保存的模型都被删掉了,先添加一个deepseek v3试试,果然可以在AI回答内容中融合最新信息,并且会标注信息的来源(以“来源1、来源2、来源3”的文字形式),我需要增加参考的搜索结果数量至5条,并且在回答内容中带上链接,点击可以直接跳转到来源链接,然后结合Cursor的建议添加更多的搜索触发词,毕竟现在已经很少会完全让AI基于训练数据回答了
2、Cursor大幅扩展了搜索触发词列表,可以通过更多自然语言触发搜索,并且支持调用Tavily API获取5条搜索结果,在AI回答下方显示参考链接区域,点击链接可以直接跳转到浏览器,甚至还设计了卡片和蓝色主题?同时还有一些性能优化,比如链接信息轻量化存储、异步处理避免阻塞主线程等等,实测并没有出现“参考链接”区域,链接也无法点击、跳转,只能看到网址,而且Xcode中还有一些警告信息,截图反馈给Cursor调整
3、在修改过程中,同步让Cursor修改了对话页面的收藏逻辑,去掉消息右侧的收藏按钮,改为长按消息弹出菜单,菜单中包含收藏、复制、删除,目前已经可以看到AI回答内容底部的“参考链接”区域,且链接可以点击跳转至浏览器打开
4、测试发现复制和收藏功能已经实现,但“删除”功能好像不管用,让Cursor修复,然后优化了“选择模型”界面(ModelSelectorView)的视觉效果,采用和“AI模型管理”界面(AIModelManagementView)一致的视觉效果
5、发现在AI模型管理界面,AI模型列表上方有大片的空白,Cursor认为是因为AIModelManagementView使用了NavigationView包装整个界面,这回自动添加导航栏的空白区域,修复之后选择模型界面和AI模型管理界面样式已经一致

DevLog:2025年7月14日

1、今天对NoteWith做一些优化,包括:
1.去掉启动页面的图标,只留应用名和下面的文字就行
2.在模拟器中打开应用时,进入启动页前会有一两秒的白屏,需要去掉,打开应用直接进入启动页
3.在模拟器中运行应用时会有警告,需要修正一下:
/Users/jinlei.wu/Documents/GitHub/NoteWith/NoteWith/ViewModels/AIViewModel.swift:86:21 Capture of ‘self’ with non-sendable type ‘AIViewModel’ in a ‘@Sendable’ closure
2、修正后经Cursor构建和模拟器测试,上述优化均已完成,但还是感觉启动速度有些慢,继续让Cursor优化:感觉应用启动有点慢,虽然现在启动时没有白屏了,但还需要在蓝屏状态下等一两秒才会出现应用明和副标题
3、Cursor检测了当前的启动流程,发现SplashView会显示2秒钟,Cursor对这个问题进行了修正,并通过异步加载数据来减少启动时间,告诉我启动页显示时间由2秒缩短为0.5-1.2秒,并加入了淡入淡出动画,在启动时异步加载数据,主界面准备好后立刻切换,最大程度减少等待,Xcode模拟器测试发现冷启动时仍然会先蓝屏再显示标题和副标题,继续让Cursor优化
4、Cursor指出这是由于当前的启动页SplashView并没有在应用一启动时就立刻渲染,而是先显示了LaunchScreen,然后才切换到SwiftUI的SplashView,Cursor在修改中表示更好的方法是完全移除LaunchScreen配置,让应用直接进入SwiftUI,修改后构建测试成功,Cursor告诉我现在应用冷启动时会立即显示标题和副标题,无蓝屏过渡,直接显示内容,并且会快速进入主界面,数据加载完后立即切换,Xcode测试发现现在启动页面一闪而过,虽然给人一种快速进入应用的感觉,但不利于让用户记住这款应用的名字,决定将启动页面显示时长固定为1秒钟
5、Cursor快速修改,包括:简化启动逻辑,固定显示时间,清理不再使用的代码,但实际测试发现在冷启动时依然会先白屏,然后再显示启动页,不像ChatWith那样可以直接进入启动页,直接问Cursor:现在冷启动时还是会先白屏一下再进入启动页,为啥不能像ChatWith那样启动应用就直接显示启动页呢?
6、Cursor好像理解了我的问题(涉及两个项目之间的对比),并表示需要创建并配置Laucn Screen Storyboard文件,并对PBXFileReference等进行修改
7、Cursor一通操作之后又删除了刚刚创建的LauchScreen.storyboard文件,构建测试成功,再次用Xcode模拟器测试,好像没有任何的变化,应用启动时的表现又回到了今天最初的状态,可能是因为应用在启动时的数据加载要比ChatWith多吗?
8、直接问Cursor这个问题,Cursor表示NoteWith的确需要在启动时加载更多内容,并给出建议,比如将部分数据加载延迟到用户首次访问时,或者进行异步初始化,将数据加载移到后台线程,或者分页加载等等
9、参考Cursor的建议:延迟加载AI会话历史页面,当用户访问该页面时再行加载,以缩短启动时间,Cursor对多个文件进行了修改,将AI对话数据加载从初始化中分离,实现了备忘录数据和AI配置的立即加载,且仅在用户访问AI对话页面时加载AI会话历史,再次进行构建测试,提示成功
10、Xcode测试,好像启动速度的确比之前快了一点点,白屏时间缩短了一些,继续优化:把AI配置也改成延迟加载吧,和AI会话历史一样,仅在用户访问AI对话页面时再行加载。但我忽略了一点,用户在访问AI配置时当然也需要加载配置,但Cursor发现了这个问题,并且进行了同步修改,还是很智能的
11、Cursor总结,现在在启动应用时只加载备忘录数据,访问A对话页面时会加载AI会话历史和AI配置,访问设置页面时加载AI配置,实现了启动性能的提升和按需加载,减少启动时的内存占用,Xcode模拟器测试发现相比上一次修改没有特别明显的变化,后面等真机测试,积累一些数据之后再看看启动性能如何吧
12、用Cursor分别打开NoteWith和ChatWith,并询问同一个问题:你对目前这版应用有什么完善功能、优化性能的建议吗?
13、Cursor对当前版本的NoteWith的功能和性能方面的建议:
基于你目前对NoteWith的启动性能和数据延迟加载优化,整体架构已经非常合理,用户体验也有明显提升。以下是一些进一步完善功能和优化性能的建议,供你参考:
一、功能完善建议
多端同步与云备份
支持 iCloud 或第三方云服务(如 Dropbox、OneDrive)同步备忘录和AI会话,防止数据丢失,方便多设备协作。
搜索与筛选功能
在备忘录和AI会话列表中增加全文搜索、标签筛选、时间排序等功能,提升内容管理效率。
多主题/深色模式自定义
支持更多主题色彩和自定义深浅模式,提升个性化体验。
AI助手能力扩展
增加AI助手的多轮对话记忆、上下文理解、语音输入/输出等功能,提升智能化水平。
数据导入导出
支持导入/导出备忘录和AI会话为常见格式(如txt、markdown、csv),方便迁移和备份。
快捷操作与小组件
支持iOS主屏幕小组件、Siri快捷指令,提升便捷性。
二、性能优化建议
数据分页与懒加载
对于备忘录、AI会话等大数据量列表,采用分页加载或无限滚动,避免一次性加载全部数据。
本地缓存与异步存储
采用本地缓存机制(如 NSCache、Core Data),并将数据存储操作放到后台线程,避免主线程阻塞。
图片与多媒体资源优化
若后续支持图片、音频等多媒体内容,需考虑资源压缩、懒加载和缓存,减少内存占用。
启动流程进一步精简
检查启动流程中是否还有可以异步处理的逻辑,确保主线程尽快渲染首屏。
内存泄漏与资源释放
定期使用 Xcode Instruments 检查内存泄漏,确保大对象及时释放,避免长时间运行后内存膨胀。
三、代码结构与可维护性建议
模块解耦与协议抽象
通过协议(Protocol)和依赖注入解耦各模块,便于单元测试和后续扩展。
单元测试与UI自动化测试
增加关键功能的单元测试和UI自动化测试,提升代码质量和发布稳定性。
错误处理与用户提示
完善网络、存储等异常场景的错误处理,并给予用户友好提示。
如果你有具体想扩展的方向(如AI能力、协作功能、数据安全等),可以进一步细化需求,我可以帮你详细设计实现方案!
14、Cursor对当前版本的ChatWith的功能和性能方面的建议:
非常感谢你的信任!基于你目前的ChatWith应用(多会话AI对话、收藏、会话置顶、API配置、数据本地化、原生SwiftUI等),我有以下功能完善和性能优化建议,供你参考:
一、功能完善建议
消息搜索功能
支持在所有会话或当前会话内全文搜索历史消息,提升信息检索效率。
多模型/多API切换
支持在不同会话中选择不同的模型或API(如GPT-3.5、GPT-4、Claude等),满足多样化需求。
消息多选与批量操作
支持批量收藏、删除、导出消息,提升管理效率。
导出与分享
支持将会话导出为文本、Markdown或PDF,便于归档和分享。
自定义主题/暗色模式
增加主题切换,适配不同用户的视觉偏好。
消息撤回与编辑
支持用户撤回或编辑已发送的消息(本地层面)。
快捷指令/预设Prompt
提供常用Prompt模板,用户可一键插入,提升效率。
多端同步(iCloud/云端)
支持iCloud同步,实现多设备无缝切换。
更丰富的消息类型
支持图片、代码块、表格等富文本消息,提升交互体验。
消息上下文管理
支持设置会话上下文长度、历史消息截断策略,优化大模型调用成本。
二、性能优化建议
异步加载与懒加载
对长会话消息列表采用懒加载,避免一次性渲染全部消息导致卡顿。
本地缓存与数据归档
对历史会话、收藏等数据做分批加载和归档,减少内存占用。
UI渲染优化
使用LazyVStack、@ViewBuilder等SwiftUI高效渲染方式,避免不必要的重绘。
API请求超时与重试机制
增加网络请求的超时、重试和错误恢复机制,提升稳定性。
内存泄漏检测
定期用Instruments等工具检查内存泄漏,优化数据结构和引用关系。
启动速度优化
精简启动流程,异步加载非核心数据,提升冷启动体验。
三、用户体验提升
新手引导与帮助中心
增加首次启动引导页、FAQ或内置帮助,降低上手门槛。
交互动画与反馈
适当增加发送、收藏等操作的动画和提示,提升操作愉悦感。
无障碍适配
适配VoiceOver、动态字体等,提高可访问性。
如需对某一条建议详细展开(如实现思路、代码示例、UI设计等),请随时告诉我!
15、结合Cursor的建议,先对ChatWith进行优化:
结合你的建议,我需要为ChatWith增加如下功能:
1.增加消息搜索功能,搜索栏放在对话列表顶部,可以在所有会话的历史消息中进行搜索,无需保存搜索历史
2.对长会话消息列表采用懒加载,避免一次性渲染全部消息导致卡顿
3.使用SwiftUI高效渲染方式,避免不必要的重绘
4.在收藏消息时增加动画提示,提醒用户“收藏成功,可前往收藏页查看”
5.可长按收藏内容进行取消收藏、复制内容到剪贴板等操作,长按弹出的菜单提示“取消收藏”、“复制收藏”
Cursor对这些需求制定了实现方案,我要求“按你计划的步骤来开发吧,并且每步完成后都使用iPhone 16模拟器构建一下,先不用在模拟器中运行”,Curso开始逐条处理,中间需要多次确认,Cursor很快处理完成并提示构建成功
16、在Xcode模拟器中添加模型测试对话,提示服务器错误:HTTP 404,并且还有两处可以优化:新建对话的顶部不需要“已加载全部消息”的提示,优化一下会话列表的样式,可以改成无边框的卡片式风格,继续让Cursor修改,修改的效果也不是很理想,全部对话列表页的样式太丑了,目前每个卡片的长度是只比标题长一点儿吗?我需要即使标题特别短,卡片边缘也能到达屏幕左右两侧,另外,设置页面的API路径,有没有自动添加/chat/completions?继续让Cursor修改
17、404问题已解决了一部分,目前使用模型时需要在设置中填写不带/chat/completions的API路径,如https://api.deepseek.com/v1/,Cursor解释说实际请求的API路径时“你设置的baseURL+/chat/completions”,设置页面只需填写基础URL,不要带/chat/completions
18、经测试DeepSeek官方的API(API地址是https://api.deepseek.com/v1/)和火山引擎的API(增加了联网搜索能力之后的“应用”,API地址是https://ark.cn-beijing.volces.com/api/v3/bots/)均可正常使用,但OpenRouter的模型仍然会报错404,即使API路径只填写了https://openrouter.ai/api/v1/
19、今天用Cursor修改代码时,在构建测试环节多次出现“看起来没有iPhone 15模拟器,让我使用可用的iPhone 16模拟器来构建”的提示,需要等待iPhone 15模拟器无法进行测试,并多确认一次用iPhone 16模拟器测试(甚至后来还出现了一次用iPhone 14模拟器进行测试),可能是我的Xcode里没有安装iPhone 15的模拟器,但我没有找到从哪里设置Cursor默认的模拟器,且测试过程中还出现了Cursor自动启动模拟器、安装并启动应用的情况
20、这段时间用Cursor一直用的是默认模式,没有手动切换过模型,感觉也基本够用了,可能我的应用功能比较简单吧

稳定使用Claude 3.7 Sonnet的方法(不免费)

Claude官方网站是出了名的难注册+易封号,我之前好不容易注册的账号第二天就被封了,即使写了申诉邮件也没有任何回应,导致我从Claude 3发布到现在一直没能用上。

但办法总比困难多,最近我综合网上的一些教程,找到了可以稳定使用Claude 3.7 Sonnet等大模型API的方法。

首先去OpenRouter网站注册账号,申请API并充值,可以用国内的信用卡充值(但是需要架梯子才能打开OpenRouter网站)。注册、登录、充值、申请API Key之后,再去AI对话客户端中添加大模型。

关于AI对话客户端,个人比较推荐在电脑端用Cherry Studio,在手机端用Chatbox,但Chatbox其实不是很好用,特别是最近还偶尔会出现不明详情的网络错误,即使更新了几个版本这种问题仍然存在。期待Cherry Studio能尽快推出手机版。

接下来说说设置方法:

Cherry Studio
设置-模型服务-OpenRouter
启动OpenRouter服务
填上API Key
API地址(默认的,不用改):https://openrouter.ai/api/v1/
模型:拉到最底下,管理,找到“Anthropic: Claude 3.7 Sonnet”并添加

Chatbox
API模式:OpenAI API兼容
名称:随便填
API域名:https://openrouter.ai/api/v1
API路径:默认的,不用改
填上API Key
模型:anthropic/claude-3.7-sonnet

建议大家在使用时打开Cherry Studio或Chatbox的联网搜索功能,Claude 3.7 Sonnet的训练数据截止到2023年年底,不知道啥时候能更新一下,如果不打开联网搜索功能,给到的结果会比较陈旧。

价格方面,OpenRouter网站上有标示,Claude 3.7 Sonnet的API价格为:
$3/M input tokens、$15/M output tokens
的确比国内常见AI的API要贵很多。

关于Claude 3.7 Sonnet、Claude 3.7 Sonnet (thinking)、Claude 3.7 Sonnet (self-moderated)三个模型的区别,我也问了下Claude 3.7 Sonnet,答曰:需要直接答案选标准版,需要了解思维过程选thinking版,需要更保守、更安全的回答选self-moderated版。

OpenRouter提供了大量的国外大模型API,比如Gemma/Gemini、Grok、Llama、Phi、GPT、Cohere、Mistral、Perplexity等等,也有来自国内的Qwen和DeepSeek,实测Gemma、Gemini、Perplexity的API都可以直接使用,但Grok、GPT无法直接使用,如果不架梯子,会报错This service is not available in your region或unsupported_country_region_territory,其它的我还没试过,有兴趣的朋友们可以试试。

最初发布于2025年3月26日

打工人接入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日