DevLog:2025年12月3日

1、参考ChatWith for Mac添加模型的逻辑,预置一些常用的模型服务提供商,供用户在添加模型时选择,包括OpenAI、DeepSeek、Anthropic Claude、OpenRouter、Google Gemini、智谱GLM、月之暗面Kimi、百度文心一言、百度云千帆、阿里通义千问、阿里云百炼、腾讯混元、硅基流动、火山方舟、自定义,用户在添加模型时只需选择模型服务提供商,就能自动匹配对应的BASE URL,并且都是完整的地址,选择“自定义”时,可以自行填写BASE URL,并且有提示文字“需填写完整地址”,备注、模型名称、API Key仍然需要用户自定填写

2、在修改过程中,Cursor创建了模型服务提供商定义AIModelProvider.swift,并且将新文件添加到了项目文件里,测试发现功能基本正常,然后修改了AIModelManagementView里的几处细节:

1.有两个“服务提供商”,需要删除位置靠下的“服务提供商”,虽然完成了,但目前这里的界面略丑,后面再优化一下

2.模型名称下面的说明文字需要固定为“如openai/gpt-3.5-turbo,可根据需要修改”

3.在模型列表页,左滑菜单中已有“测试”按钮,就不需要再在模型右侧设置“地球”标志了,已经让Cursor去掉了

3、明天再让Cursor引入RichTextKit,替换目前的备忘录模块吧,今天就到这儿了

DevLog:2025年12月2日

1、昨天在引入MarkdownUI替换之前自定义的MarkdownRenderer之后,Cursor未能进行构建测试,虽然也自称检查后未发现语法错误,但今天在Xcode中构建测试发现AI对话核心的文件AIChatView存在多个错误,导致构建失败,先复制给Cursor让它修复下这些错误

2、Cursor在简化了AIChatView的部分代码后构建成功,接下来测试并逐个修改各个模块的问题,先是这两个:

1.添加模型之后,发送消息后收到错误提示:发送消息失败:API错误(404),导致无法正常对话

2.AI模型管理界面缺少对模型的测试机制,需要增加测试机制,点击可测试,确认能正常连接

3、Cursor认为第一个问题是因为缺少URL补全机制导致的,于是修复了URL拼接问题,在用户填写的Base URL后面增加/chat/completions,然后在模型管理界面(包括列表视图、表单视图)添加了测试UI

4、在Xcode中打开发现测试UI工作正常,但我与测试可用的模型对话时,出现AI正在思考中的提示之后,没有收到任何回复,继续让Cursor检查原因并修复

5、Cursor修复了流式解析问题,包括改进流式响应解析逻辑、改进错误处理、增强兼容性等,虽然可以正常构建了,但我测试了两个问题,回答内容都未能完整显示,输出了一部分就停了,并且停止按钮一直未能变成发送按钮(正常的话应该收到所有回答之后停止按钮就会变成发送按钮)

6、Cursor认为问题原因在于流式输出解析顺序和ViewModel中的更新逻辑,前者主要是先检查finish_reason再处理delta,导致最后一块内容可能被跳过,当finish_reason存在时直接break,未处理该条数据中的delta,后者主要是更新频率限制在100ms,可能导致最后的内容未及时更新,同时,为了确保流式输出正确完成,Cursor也做了一些修改,无论finish_reason是否存在,都会在结束时调用onUpdate,即使delta为空,也会更新一次,确保状态正确,isLoading会被正确设置为false,停止按钮会变回发送按钮

7、继续在Xcode中测试了两个问题,这次可以完整显示所有回答内容了,并且停止按钮也会随着输出结束变回发送按钮

8、接下来准备参考ChatWith for Mac添加模型的逻辑,预置一些常用的模型服务提供商供用户选择,包括OpenAI、DeepSeek、Anthropic Claude、OpenRouter、Google Gemini、智谱GLM、月之暗面Kimi、百度文心一言、百度云千帆、阿里通义千问、阿里云百炼、腾讯混元、硅基流动、火山方舟、自定义,然后让Cursor引入RichTextKit,替换目前的备忘录模块

DevLog:2025年12月1日

1、目前ChatWith for Mac的主要问题在于偶发应用卡死问题,之前已经多次修复但一直未能解决,先暂停

2、先把手机端的NoteWith搞一个版本到手机上进行实测,目前的NoteWith还有很多地方需要完善下才能通过TestFlight发布测试版,比如还没有应用图标(需要让ChatGPT给做一套),上次将对话和备忘录改用Core Data存储之后未做实际测试,且还需要引入三方库MarkdownUI和RichTextKit,完善AI问答和备忘录的渲染效果和编辑体验

3、先让ChatGPT给设计图标,这次以蓝色为底色,并且“也需要一些设计感,像上面那套图标那样简洁就可以”,但这次ChatGPT也把“NoteWith”给套到了对话消息的图标里,要求“不要把NoteWith放在对话消息图标里,没有体现出Note的含义”,然后要求ChatGPT基于这张图生成一套用于iOS App的图标文件,可以直接放到项目文件里使用,很快就生成了,图标搞定

3、时隔半个月再打开Cursor,发现它推出了自己的模型Composer 1,据称生成速度相比同类模型快四倍,且目前可以免费使用,决定使用它来为应用引入三方库MarkdownUI和RichTextKit

4、先引入MarkdownUI,指令“我需要为当前的应用引入三方库MarkdownUI,用于AI问答内容的显示效果渲染”,Cursor指出需要先添加Swift Package Manager依赖,再更新代码以使用MarkdownUI渲染AI回答内容,在引入MarkdownUI之后更新了AIChatView,以使用MarkdownUI来渲染AI回答内容,并且相比之前自定义的MarkdownRenderer增加了代码块、行内代码等样式,接下来需要在Xcode中打开项目,MarkdownUI会自动下载并集成,AI问答内容将使用MarkdownUI进行渲染

5、Composer在执行这次修改时速度的确很快,但在修改结束后未能进行构建测试,要求构建之后仍然不行,说是“命令行构建因模拟器配置问题无法完成,但依赖已成功解析,代码语法检查通过,项目配置正确,建议在Xcode中直接构建和运行,Xcode会自动处理模拟器配置”

6、然后打开Xcode,发现模拟器又要更新版本至iOS 26.1,需要下载8.32GB,看来我的确是有阵子没有用Xcode运行iOS应用了,而且貌似在新的系统版本下载完之前无法进行构建测试,只能等了,看今晚能不能把模拟器下载完,明天再构建测试

7、想尝试添加一个自定义的模型,在Cursor的设置中,目前预置的模型包括Composer 1、Grok Code、Kimi K2,并且可以通过填写API Key等信息快速添加OpenAI、Anthropic、Google、Azure、AWS Bedrock的模型,有一点之前没有注意,就是如果要使用其他兼容OpenAI的模型的话,可以开启“OpenAI API Key”,填写Key,并打开Override OpenAI  Base URL修改API地址,然后在上方找到Add Custom Model填写模型名称,我试一下OpenRouter的Claude Sonnet 4,不知道为啥加不上,感觉添加模型不是很方便

8、上周看Trae.ai官方公众号推送了文章说TRAE SOLO已经登陆中国版,并且可以免费使用,今天更新了下Trae,据介绍,SOLO 模式集成包括 IDE 在内的多种工具。你只需表达需求,它就会基于目标主动推进完整开发流程。

-SOLO=The Responsive Coding Agent,可以让你直观了解智能体正在处理的内容——从文件、工具到完整的工作上下文,它会随你的操作和变化即时响应,始终与你的工作流保持同步。

-从清晰的规划开始,与子智能体协作,将复杂问题拆解为更为聚焦的任务。借助完整代码上下文进行迭代、重构与优化,实现高精度的工程化执行。

-自动将长对话整理为结构化的任务流,清晰呈现执行路径。所有改动统一汇总在代码变更视图,配合上下文状态统一展示,方便回溯与协作。

介绍了这么多,也没有看出来它到底和之前、和Cursor有什么不同,后面再实际测试看看吧

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