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月4日

补充一条,时间线有点乱了,但还是要记录一下。

1、继续试用ChatWith,发现目前的应用在使用支持深度思考的模型时,思考内容好像限制了显示高度,一旦达到高度限制,就不会随着思考的内容继续自动滚动,Cursor表示思考内容的显示高度的确固定在了400点,且超出之后会出现滚动条,但超过400点后就不会再自动滚动,在修改过程中发现了另一个问题,好像在对话中切换了另一个模型,再提出新问题时应用就会卡死

2、Cursor分析了可能导致应用卡死的几个问题:Core Data并发冲突、通知监听器生命周期、状态读取时序、缺少状态同步,特别是Core Data并发冲突,由于直接在主线程修改Core Data managedobject,如果此时用户立即发送消息,可能造成并发访问冲突,updateAISession可能触发Core Data save操作,与其他操作冲突,明天继续修改这个问题

3、添加其他模型来测试Base URL的填写方法,之前已经要求Cursor将其改为用户手动填写AI服务的跟地址,应用会自动补全路径,比如api.openai.com、openrouter.ai/api,然后针对火山引擎的“应用”(bots)做了特别优化,需要填写完整地址https://ark.cn-beijing.volces.com/api/v3/bots/,测试发现百度云千帆的Base URL填写仍然有问题,比如我填写官网提供的https://qianfan.baidubce.com/v2/chat/completions就会连接失败,删掉v2往后的内容也不行,只填写https://qianfan.baidubce.com也不行,与其设定各种复杂的自动补全规则,倒不如直接要求用户填写完整的Base URL,或者应用内置一些常用的Base URL来的简单

附上常用的几个AI的Base URL:

OpenAI

https://api.openai.com/v1/chat/completions

DeepSeek

https://api.deepseek.com/v1/chat/completions

OpenRouter

https://openrouter.ai/api/v1/chat/completions

硅基流动

https://api.siliconflow.cn/v1/chat/completions

火山方舟

https://ark.cn-beijing.volces.com/api/v3/chat/completions

https://ark.cn-beijing.volces.com/api/v3/bots/chat/completions

百度云千帆

https://qianfan.baidubce.com/v2/chat/completions

阿里云百炼

https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions

4、询问Cursor目前应用在Base URL补全方面的规则是怎样的,根据回答内容,规则包括:

1.如果没有http://或https://,就自动添加https://

2.如果URL末尾有斜杠,就自动移除

3.如果已经包含完整路径,就不做任何修改

4.如果包含部分路径,就自动补全,比如补全v1,补全/chat/completions

5.如果只有基础URL,就自动补全/v1/chat/completions

按照这套规则,我填写了完整的百度云千帆的Base URL,应该能正常使用才对,但填写完整地址之后测试仍然提示404

5、问题可能出现在自动补全v1上,也就是在“包含/chat/completions但不包含v1时,会自动添加v1前缀,包含/api/、/bots/、/v3/、/v2/,且不含/chat/时,则添加chat/completions”这里,根据Cursor给出的示例,可能会出现/v1出现在/chat/completions之后的情况

6、目前的规则的确有些复杂,可能用户在填写过程中也会不知道该填写完整的地址还是部分地址,倒不如直接在应用里内置几个常用的、完整的Base URL,由用户自行选择,要求:目前的规则有些复杂,我希望能在添加和编辑AI模型界面,预置几个常用的API平台的完整Base URL,用户只需要填写备注、模型名称、选择模型提供商、填写API Key、填写Tavily API Key即可使用模型

7、Cursor在修改过程中创建了APIProvider枚举,包含10个常用平台(OpenAI、DeepSeek、Anthropic Claude、OpenRouter、Google Gemini、智谱GLM、月之暗面Kimi、百度文心一言、阿里通义千问、腾讯混元、自定义),这样就不再需要配置路径补全规则,用起来也更方便了,先添加几个模型试试,再决定要不要增加或删减APIProvider

8、在修正因为使用中文引号导致构建失败的错误之后,百度云千帆和火山方舟的API都可成功连接,当API提供商选择自定义时,需在“高级设置”的Base URL中填写完整地址,即带有/chat/completions的地址

9、APIProvider需要增加硅基流动、火山方舟、百度云千帆、阿里云百炼,这四个都放在“自定义”前面,另外我发现在选择某个APIProvider之后,模型名称部分也会出现预置的模型名称,但我不需要,改成由用户手动填写模型名称,修改之后测试了几个不同的模型,都可以成功连接了

DevLog:2025年12月19日

1、测试当前版本的ChatWith for Mac,目前已经支持在打开应用后自动开启新对话,并且新对话位于置顶对话下方,之前已经要求应用在开启新对话时默认使用模型列表里的第一个模型,并且在对话过程中也可以点击右上角切换模型,但由于多次遇到切换模型后对话界面卡死的情况(也有可能是在加载历史对话时出现卡死?),决定调整模型切换的逻辑试试

2、首先,在AI模型管理界面,增加“默认模型”设置,按钮放在每个模型的“测试”按钮前面,可以将任何一个模型设置为默认模型,并且在创建新对话时直接使用默认模型,若用户需要使用其他模型,就在AI模型管理界面手动切换默认模型,再去开启新对话,这样也能防止某个对话中积累太多内容

3、另外我还发现现在每次在应用的不同界面间切换时都可能触发“创建新对话”的操作,比如首次启动应用时会创建新对话,看看收藏界面,再回到对话界面,也会创建一个新对话,这样就导致会出现多个空白的新对话,我只需要在首次启动应用时创建新对话,并且如果已经有空的新对话,就不要再自动创建新对话了

4、或者去掉自动创建新对话的机制,但在对话界面增加一个提示,比如请点击开启新对话,与默认模型对话,需要看下这种方式是否和目前的空状态提示有冲突

5、综上,本次修改内容包括:

1.在AI模型管理界面,增加“默认模型”设置,按钮放在每个模型的“测试”按钮前面,可以将任何一个模型设置为默认模型,并且在创建新对话时直接使用默认模型

2.去掉每次打开应用自动创建新对话的机制,在对话界面最右侧栏增加一个提示“请点击右上角开启新对话,若需切换模型,请前往设置中修改默认模型”

6、Cursor的修改内容包括:在DataManager中添加默认模型ID的保存和读取方法(使用UserDefaults);在AIModelManagementView中添加“默认模型”按钮(放在“测试”按钮前面);修改AIViewModel的createNewSession方法,使用模型模型而不是第一个模型;修改AIChatView的sendMessage方法,使用默认模型;去掉AIChatSessionListView中的自动创建新对话逻辑;在AIChatView的emptyChatView中添加提示信息,除此之外还增加了一条“更新removeAIConfig方法:删除的模型时默认模型时,清除默认模型设置”

7、测试发现默认模型设置功能已经具备,创建新对话时会直接使用新模型,但对话界面右侧的提示目前有两行,并且内容有重复,于是让Cursor去掉了第一行,只留新添加的一行,并且稍微加大了提示内容的字号

8、本次的修改需求基本达成,发现AI模型管理界面的“数据统计”功能好像没啥用,于是也让Cursor去掉了,至于在使用应用的过程中频繁出现的FSFindFolder failed with error=-43错误提示,Cursor认为这种提示通常出现在CoreData初始化时,系统内部可能使用旧的Carbon API(FSFindFolder)查找Application Support目录,导致出现了-43即“文件未找到”错误,Cursor改成了显式指定Core Data存储位置,使用FileManager的现代API,避免系统使用旧的FSFindFolder API,初步测试暂时未遇到这一错误

9、今天的修改就到这里,接下来测试两天,如果没有什么明显的问题就修改设置-关于页面、刷新README文档,并打包,版本号用v0.3

DevLog:2025年11月17日

1、继续修正之前的问题,并且增加一些细节,首先是数据统计功能,对Cursor说:我需要在设置中增加针对每个模型的数据统计功能,显示自从该模型被添加以来的对话数据量,包含输出Tokens和输入Tokens,这一修改涉及Core Data模型、AIService、DataManager和AIModelManagementView

2、修改后测试发现AIModelManagementView里显示的内容有些多,比如Base URL这一行其实没有必要在这里显示,数据统计功能现在像是一个表格,改成单行就可以了,继续让Cursor修改

3、测试过程中发现对话时偶尔会遇到点击发送按钮后应用卡死的情况,继续让Cursor排查问题,Cursor进行了添加防止重复发送机制、优化Core Data操作、改进错误处理、减少不必要的操作等改进,但仍然没有解决问题,我在打开应用后,打开一个有历史对话记录的对话,输入问题并提交后应用就会卡死,可能是加载历史对话记录导致的卡顿?Cursor优化了处理大量历史消息时的性能问题,并且优化消息的payload构建,包括预取数据、减少faulting、优化排序等等操作

4、再次测试,首次打开一个有对话记录的对话并且提交问题后不会卡死了,但切换到另一个对话并且提交问题时又卡死了,Cursor继续优化流式响应处理,但依然存在应用卡死的问题,甚至打开应用后,打开一个已有历史消息的对话,应用就会被卡死

5、再次修改时,Cursor采用了分批处理消息(每批处理50条消息,避免一次性处理过多)、异步执行、预取优化等操作,并指出卡死时因为打开有大量历史消息的对话时,应用会一次性处理所有消息,长时间占用主线程,Core Data faulting导致同步IO操作,且排序操作在处理大量数据时耗时,现在我看见Cursor这种煞有介事的解读都已经麻木了,AI对自己的思考和操作都非常自信,但实际结果可能并没有多么好,实测果然还是会卡死

6、决定先绕开这个问题,将应用的对话界面修改成每次打开应用时,默认用模型列表里的第一个模型开启新对话,这样应该能避免一打开应用就加载历史对话导致的卡死问题,修改后的工作流程变成了:应用启动时,AIChatSessionListView出现——检查是否有模型配置——如果有模型,使用第一个模型创建新对话——自动选中新对话,用户可以直接开始聊天

7、修改之后实现了我的需求,但我发现目前应用的流式输出好像又出现了问题,像是每次跳出来一两句甚至一两段,Cursor分析后表示这是因为之前使用定时器延迟更新(0.12秒),导致内容在buffer中累积,每0.12秒才更新一次UI,于是将content和thinking内容改成了立即更新,不再使用定时器延迟,tavilyResults也改成了立即更新,这样可以实现接近逐字显示的平滑输出效果,明天再测试下看看

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,的确都支持在对话过程中切换模型

DevLog:2025年11月6日

1、让Cursor将当前版本(v0.2)打包,Cursor这次还同步创建了发布说明文档,其中包括版本信息、安装说明、更新内容、系统要求、支持的AI平台、反馈与支持、注意事项等内容,看起来还是挺规范的

2、已经用上了v0.2版本,以后对话时多多使用,修正问题并进一步优化,同时我还询问了Cursor下一个版本的建议,以细节补充和优化为主,Cursor给出了高、中、低三个不同优先级的建议,但我个人还是觉得有些并不着急

3、高优先级建议包括停止生成按钮(发送消息后按钮变成停止生成按钮,可以随时点击停止)、会话重命名/自动命名(其实现在可以重命名,也会自动获取用户的最后一个问题作为会话的名字)、消息复制按钮(已有)、快捷键支持(比如给创建新对话、切换模型、搜索等功能指定快捷键,这个可以有)、错误处理优化(更友好的错误提示、API限流处理、离线模式、崩溃日志等,我暂时不需要)

4、中优先级建议包括重新生成功能、代码块复制(这个可以有)、消息时间显示(我忽略了这一点,现在还真没有)、空状态设计(无对话、无收藏时的引导界面,这个好像也已经有了)、数据导出功能(收藏内容导出成.md还是比较实用的)

5、低优先级建议包括主题色自定义(花里胡哨,不需要)、使用统计(显示使用次数、Token消耗等,后面可以加上)、标签分类(暂不需要)、字体调节(暂不需要)、帮助文档(暂不需要)

6、总结一下,v0.3要增加的功能包括:停止生成按钮、快捷键支持、代码块复制、消息时间显示、数据导出功能、使用统计,也都是一些细节上的补全

7、目前在进行中的开发项目,移动端有ChatWith、NoteWith和DoitWith,Mac端有ChatWith for Mac和NoteWith for Mac,NoteWith for Mac是由移动端NoteWith修改而来,功能上相当于在ChatWith基础上增加了备忘录和待办事项功能,整合的功能比较多,后续可能会考虑删掉待办事项功能,留给DoitWith,且AI对话功能需要重复开发,暂时先搁置,接下来继续开发移动端NoteWith

8、将近三个月没有修改过NoteWith了,甚至都忘了它的功能都有啥,先让Cursor梳理一下目前的项目,都有哪些功能,有哪些优化建议,在梳理过程中,先整理了应用功能与优化建议文档,然后检查发现了重复文件,Cursor建议先清理重复文件(我还发现目前应用文件夹里有多个Trae创建的项目文件备份和.sh文件,也都不需要了,一并清理掉)、清理调试打印和未使用的代码,后面可以考虑更换数据持久化方案为Core Data,然后优化性能、扩展功能等等

9、Cursor直接删掉了15个无用文件(应用能否正常运行还有待验证),然后我删掉了多余的空文件夹,和之前不知道啥时候、由哪个AI工具编写的重构指南文件,以及一个项目初始化脚本setup.sh

10、时隔三个月再次启动了iOS模拟器,iOS 26已经发布,模拟器也换成了iPhone 17 Pro、iOS 26.0,并且部分界面也自动变成了iOS 26的效果,比如底部的AI对话、备忘录、我的三个按钮及其切换效果,决定趁现在应用功能还很简单,结合近期修改ChatWith for Mac的经历,先开启一个新对话,把NoteWith的AI对话和备忘录的数据永久化方式改为Core Data,AI模型、设置等仍然采用UserDefaults

11、Cursor的建议是使用Core Data存储Note、AIChatSession、AIMessage、SearchLink、deletedNotes,仍然使用UserDefaults来保存AIConfig和应用设置,因为Core Data适合结构化数据,支持关系、查询和迁移,UserDefaults适合小量配置,访问频繁但更新不频繁

12、接下来创建Core Data模型文件和相关组件,创建了备忘录、AI对话、AI消息、搜索链接四个实体及对应的扩展类,重构了DataManager,并更新了项目文件,和以往修改数据永久化方式一样,这次Cursor也增加了迁移机制,首次运行时会自动将现有的UserDefaults数据迁移到Core Data,但因为当前应用还没有发布,不需要迁移机制,让Cursor去掉了迁移机制,并且修复了构建错误,具体使用体验怎么样,哪些功能受到了影响,明天再测试,然后引入三方库MarkdownUI和RichTextKit,完善AI问答和备忘录的渲染效果和编辑体验

DevLog:2025年11月5日

1、今天先来修复在对话过程中切换模型会导致应用卡死的问题,以及思考内容高度超出400点后无法自动滚动到最新内容的问题

2、昨天Cursor分析了切换模型可能导致应用卡死的问题,认为首要问题在于Core Data并发冲突,主要修复策略是1.将通知监听器从sheet移到主视图 2.使用安全的方式更新Core Data 3.添加状态管理避免并发冲突,测试发现仍然会卡死,于是要求Cursor添加调试信息来定位问题,在排查过程中还出现了在不同对话间切换会卡死的问题,甚至只是打开一个对话就会导致应用卡死

3、Cursor在对话流程涉及的多个文件中都添加了大量调试信息,在可以正常切换对话、可以看到对话内容后,又出现了与支持深度思考的模型对话时看不到流式输出,但调试信息里可以看到正在输出的问题,原因在于负责思考内容的ThinkingProcessView的ScrollView频繁重建导致卡死(思考内容每秒更新10-20次——每次更新都重建ScrollView——ScrollView重建会触发布局计算——主线程被大量布局计算阻塞,导致卡死),修改过程中Cursor移除了ScrollView,改用简单Text,并且移除了展开/折叠动画,但我觉得展开/折叠动画还是可以保留的,又让Cursor加了回来

4、在修改过程中顺便给浅色模式下的AI对话增加了不同的底色,在最近更新系统到macOS 26之后,浅色模式下对话内容底色太浅,几乎是透明的,深色模式还是正常的,切换深色和浅色外观有时不会立即生效,也一并修改了

5、还是感觉AI回答内容的输出有些慢,怀疑可能是先接收到所有回答内容后再批量输出,Cursor认为当前“应该是”实时流式输出,但也添加了调试信息来帮我确认,如果是实时流式输出,就会在每次收到新内容后,MessageView立刻重新渲染,如果是批量延迟输出,就会在内容累积完成后再渲染,结合调试信息,的确是实时流式输出,在回应Cursor之后,Cursor便自动开始清理所有调试日志,让代码更简洁,涉及文件包括AIChatView、AIViewModel、AIService、MessageView、DataManager、CoreDataManager、TavilySearchService、AIChatSessionListView,二百来行调试信息

6、再次测试,发现现在又出现了在对话中切换模型、发送问题后应用会卡死的问题,打开一个新对话并且使用新模型就不会卡死,要求Cursor把跟这个过程相关的调试信息加回来,好定位一下问题出现在哪里,但添加调试信息后重新测试,发现无论是在新创建的对话里切换模型,还是在已有的对话里切换模型并对话,应用都不会再卡死,难道还是概率性出现?先留着调试信息,后面如果再出现就直接提交给Cursor

7、我需要在设置-关于页面下面增加一个文本区域,显示近期更新内容,并且让Cursor先拟一下近期更新点,微调内容和顺序之后,把版本号也改成了v0.2,以后每个版本都在这个位置显示一下更新日志,目前的更新日志包括:

“🎯 新增OpenAI、DeepSeek、Anthropic Claude及硅基流动、火山方舟等14个平台预设”,

“✨ 优化 AI 模型配置流程,自动填充常用平台的完整 API 地址”,

“🚀 大幅优化流式输出性能,AI 回答更加流畅”,

“🎨 改进消息气泡样式,浅色模式下有明显的背景色区分”,

“🎨 优化思考过程显示,支持完整内容展示”,

“⚡ 优化 Core Data 保存策略,减少数据库操作频率”,

“🔧 修复应用在切换对话时卡死的问题”,

“🔧 修复应用在切换模型后发送消息时卡死的问题”,

“🔧 修复深度思考模型卡死的问题”,

“🔧 修复外观模式切换无法生效的问题”,

“🐛 修复空消息导致的渲染循环问题”,

“🐛 修复死锁问题,提升应用稳定性”

8、然后优化收藏界面,发现在点击右上角的复制按钮时虽然的确可以复制整条收藏内容,但没有任何提示,于是让Cursor增加了Toast提示,并且在2秒后自动隐藏

9、收藏界面最右侧详情栏会显示两行一模一样的标题,Cursor检查后在收藏列表(NoteListView)和收藏内容(NoteEditView)中各有一个标题,只保留了后者,正好和复制收藏的按钮位于同一行,但复制按钮的高度好像有点高,导致收藏列表顶部的分割线和收藏内容顶部的分割线不对齐,可能是plus和doc.on.doc两个图标本身高度就不一样,于是让Cursor改成了文字按钮“创建新对话”和“复制收藏内容”,这下高度都一致了

10、再在更新日志中增加一条“🎨 优化创建新对话、复制收藏内容按钮的样式,删除重复的收藏标题”,明天继续测试、优化应用

DevLog:2025年11月4日

1、继续试用ChatWith,发现目前的应用在使用支持深度思考的模型时,思考内容好像限制了显示高度,一旦达到高度限制,就不会随着思考的内容继续自动滚动,Cursor表示思考内容的显示高度的确固定在了400点,且超出之后会出现滚动条,但超过400点后就不会再自动滚动,在修改过程中发现了另一个问题,好像在对话中切换了另一个模型,再提出新问题时应用就会卡死

2、Cursor分析了可能导致应用卡死的几个问题:Core Data并发冲突、通知监听器生命周期、状态读取时序、缺少状态同步,特别是Core Data并发冲突,由于直接在主线程修改Core Data managedobject,如果此时用户立即发送消息,可能造成并发访问冲突,updateAISession可能触发Core Data save操作,与其他操作冲突,明天继续修改这个问题

3、添加其他模型来测试Base URL的填写方法,之前已经要求Cursor将其改为用户手动填写AI服务的跟地址,应用会自动补全路径,比如api.openai.com、openrouter.ai/api,然后针对火山引擎的“应用”(bots)做了特别优化,需要填写完整地址https://ark.cn-beijing.volces.com/api/v3/bots/,测试发现百度云千帆的Base URL填写仍然有问题,比如我填写官网提供的https://qianfan.baidubce.com/v2/chat/completions就会连接失败,删掉v2往后的内容也不行,只填写https://qianfan.baidubce.com也不行,与其设定各种复杂的自动补全规则,倒不如直接要求用户填写完整的Base URL,或者应用内置一些常用的Base URL来的简单

附上常用的几个AI的Base URL:

OpenAI

https://api.openai.com/v1/chat/completions

DeepSeek

https://api.deepseek.com/v1/chat/completions

OpenRouter

https://openrouter.ai/api/v1/chat/completions

硅基流动

https://api.siliconflow.cn/v1/chat/completions

火山方舟

https://ark.cn-beijing.volces.com/api/v3/chat/completions

https://ark.cn-beijing.volces.com/api/v3/bots/chat/completions

百度云千帆

https://qianfan.baidubce.com/v2/chat/completions

阿里云百炼

https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions

4、询问Cursor目前应用在Base URL补全方面的规则是怎样的,根据回答内容,规则包括:

1.如果没有http://或https://,就自动添加https://

2.如果URL末尾有斜杠,就自动移除

3.如果已经包含完整路径,就不做任何修改

4.如果包含部分路径,就自动补全,比如补全v1,补全/chat/completions

5.如果只有基础URL,就自动补全/v1/chat/completions

按照这套规则,我填写了完整的百度云千帆的Base URL,应该能正常使用才对,但填写完整地址之后测试仍然提示404

5、问题可能出现在自动补全v1上,也就是在“包含/chat/completions但不包含v1时,会自动添加v1前缀,包含/api/、/bots/、/v3/、/v2/,且不含/chat/时,则添加chat/completions”这里,根据Cursor给出的示例,可能会出现/v1出现在/chat/completions之后的情况

6、目前的规则的确有些复杂,可能用户在填写过程中也会不知道该填写完整的地址还是部分地址,倒不如直接在应用里内置几个常用的、完整的Base URL,由用户自行选择,要求:目前的规则有些复杂,我希望能在添加和编辑AI模型界面,预置几个常用的API平台的完整Base URL,用户只需要填写备注、模型名称、选择模型提供商、填写API Key、填写Tavily API Key即可使用模型

7、Cursor在修改过程中创建了APIProvider枚举,包含10个常用平台(OpenAI、DeepSeek、Anthropic Claude、OpenRouter、Google Gemini、智谱GLM、月之暗面Kimi、百度文心一言、阿里通义千问、腾讯混元、自定义),这样就不再需要配置路径补全规则,用起来也更方便了,先添加几个模型试试,再决定要不要增加或删减APIProvider

8、在修正因为使用中文引号导致构建失败的错误之后,百度云千帆和火山方舟的API都可成功连接,当API提供商选择自定义时,需在“高级设置”的Base URL中填写完整地址,即带有/chat/completions的地址

9、APIProvider需要增加硅基流动、火山方舟、百度云千帆、阿里云百炼,这四个都放在“自定义”前面,另外我发现在选择某个APIProvider之后,模型名称部分也会出现预置的模型名称,但我不需要,改成由用户手动填写模型名称,修改之后测试了几个不同的模型,都可以成功连接了

DevLog:2025年10月15日

1、上次修改搜索功能之后,增加了点击搜索结果立刻跳转到应用的对应内容的功能,实测可以跳转到对话的对应位置,但不能跳转到收藏的对应位置,在搜索结果页面,对话和收藏条目下的更新时间显示也有问题,对话内容创建于几天几小时前,收藏内容更新于几天几小时前,统一成创建于年月日,小时分钟,与对话列表和收藏列表条目的时间显示形式一致,让Cursor检查并修正一下

2、修改过程中发现,前者是因为CoreData对象不能直接跨不同的实例传递,需要通过ID来传递和查找Note对象,后者是将相对的时间格式改成绝对的时间格式,修改后测试,时间显示正常了,但点击对话和收藏的搜索结果都无法直接跳转到对应位置

3、通过反复的添加调试信息、反馈调试信息定位并解决了问题,并且适当缩短了等待时间,目前点击搜索结果中的对话内容可以直接跳转到对话所在位置,点击收藏内容可以直接打开对应的收藏条目,已经基本实现了优化搜索页面的需求

4、上次修改应用时,我想到可能需要按照macOS 26的最新设计规范来调整一下ChatWith for Mac的界面,于是询问Cursor“你熟悉最新的macOS Tahoe应用设计规范吗?如果要对当前的应用的UI做一些针对macOS Tahoe的优化,你有什么建议?在进行这些修改后,还能否兼容macOS Tahoe之前的系统?”Cursor的回答很诚实:我需要先确认一下您提到的 macOS 版本。根据我的知识(截止到2024年4月),Apple 的最新版本是 macOS Sonoma (14.x) 和 macOS Sequoia (15.x)。我没有关于”macOS Tahoe”的具体信息。

5、不过Cursor也给了一些既适用于macOS 14.0 Sonoma,也能保持向后兼容的UI优化建议,包括材质和视觉层次、增大圆角和边距、使用Typography排版、增加hover效果等交互反馈、使用多色SF Symbols等等,这些都是锦上添花的东西,不急,还是继续优化功能更要紧

6、下一步计划增加上传图片和文档的功能,在对话界面的联网搜索和发送按钮之间增加附件按钮,点击可以上传本地的图片或文件(主要是文档格式),上传之后不直接发送给 AI,可以在输入框补充一些文字需求,一并提交

DevLog:2025年9月23日

1、突然发现Cursor的DashBoard统计竟然正常了,又能看到近期修改、建议、接受的代码量了

2、先让Cursor结合当前应用的功能更新了一下README文档,主要的变化除了将备忘录改成收藏之外,还有数据持久化方案由UserDefaults变成了Core Data,Markdown渲染由自定义解析器改为MarkdownUI等等

3、接下来优化上周遗留的设置列表显示局促的问题,直接将SettingsListView添加到对话,并要求Cursor优化一下这个设置列表文件,目前显示有点局促,看它能否理解,Cursor调整了间距、布局,增加了卡片式设计和选中指示器,但总觉的跟另外两个界面的风格不是很搭,设置列表左右两侧和上方有明显的空白

4、统一调整了设置列表SettingsListView、收藏列表NotesListView、对话列表AIChatSessionListView三个文件的选中状态,不再使用圆角,因为圆角会导致出现一些小的空白,反而不够美观,然后调整了设置列表的点击区域和底色,点击区域扩大到整行而非文字部分,至于底色,多次修改并让Cursor对比文件后,发现是因为设置列表使用的是List容器,而收藏列表使用的是ScrollView+LazyVStack容器,List容器有自己的默认背景色和样式,于是也将设置列表改成了收藏列表一致的容器,问题解决

5、然后调整了数据统计、回收站的细节,还是之前调整备忘录和AI对话顺序后的后遗症

6、下一步清理当前应用中的调试信息,AI对话部分调试信息很多,可能也会影响应用的性能,Cursor一次清理了8个文件中的67行调试信息,并且处理了一个警告信息,明天再测试当前应用的功能,规划下一步修改,并尽快打包当前应用,实机安装、测试