DevLog:2025年9月12日

1、继续修改备忘录模块,目前已经应用了MarkdownUI,但仍然没有实现我希望的所见即所得的效果,仍然需要点击编辑按钮才能修改内容,修改之后变成了点击备忘录内容区域就能进入编辑模式,在编辑模式下使用TextEditor进行纯文本编辑,在预览模式下显示MarkdownUI渲染的效果,并且支持文本选择
2、接下来尝试用MarkdownUI优化AI回答内容的渲染效果,先用MarkdownUI优化除代码块和表格之外的内容的渲染效果,因为代码块和表格已经有单独的文件在渲染,Cursor通过在UnifiedMarkdownView中添加import MarkdownUI,并将.text组件的渲染从简单的Text替换为Markdown(text),实现了这一需求
3、然后用MarkdownUI渲染了AI回答中的表格,让普通文本和表格渲染效果一致,再将MarkdownUI用到代码块的渲染中,我发现在这个过程中Cursor修改的文件是UnifiedMarkdownView,并不是专门用于渲染代码块的CodeBlockView和MarkdownWithCodeBlocksView,以及专门用于渲染表格的TableView和MarkdownWithTablesView,询问后Cursor表示这些文件目前没有被使用,于是删除并修改了项目文件,移除对这些文件的引用,之后测试了一个新的问题,删除这四个文件的确对AI回答的渲染没有任何影响,现在AI问答中所有的Markdown内容都通过MarkdownUI进行统一渲染
4、真真切切感受到了使用成熟的三方库给应用开发带来的效率提升,之前为了实现对代码块和表格的渲染不知道修改了多少次代码才让这两个模块的显示效果基本可用
5、但现在还有CodeBlockParser、TableParser、MarkdownTableCell 三个文件,不知道是否还在使用,询问Cursor后得到的答复是只有TableParser还在使用,它定义了TableRow结构体,是UnifiedMarkdownView中表格解析的核心数据结构,所以仍然保留了这个文件,另外两个文件已经不再使用,直接删除并修改了项目文件,实测对目前的AI回答内容渲染效果无影响
6、发现在AI对话列表里,有部分对话只显示了标题,没有显示摘要,这和我之前的规划不符,再次明确标题默认是我在这个对话中提出的最后一个问题,下面小字默认是最后一个回答内容的前50字
7、由于近期对应用的修改较为频繁,猜测可能还有部分文件也没有被使用,但依然存在于文件目录中,于是直接让Cursor检查目前还有哪个文件未被使用,并明确“先检查下,不要直接删除”防止像上面第3步那样直接删除多个文件,虽然没有什么实际影响
8、检查发现MarkdownTextView、MarkdownRenderer都已被MarkdownUI取代,还有多余的DataManger,以及前边经过分析认为有用的TableParser,都可以删除,决定让Cursor逐个删除并测试构建,确认没有依赖关系,在将这些文件删除,并且将原本在TableParser中定义的TableRow结构体移到了UnifiedMarkdownView中之后,构建成功,并且AI问答和备忘录的渲染依然正常,今天一共删除了大概9个文件,这下项目更干净了,且功能没受影响
9、AI问答的内容,与消息气泡的边缘的距离有些太近了,需要适当增加一点边距,询问Cursor了解当前的边距设定之后,将用户消息和AI消息的下边距统一由4增加到8,现在看来稍微好些了
10、发现不知道从啥时候开始,在AI对话、备忘录和待办事项三个界面,第二栏和第三栏之间无法通过拖动分割线调整比例了,我记得之前已经将这三个界面的第二栏和第三栏统一用HSplitView,并且设置了最大宽度、最小宽度和理想宽度,检查后发现AIChatSessionView、NotesListView和TodoListView都设置了固定的宽度300,会阻止用户通过拖动分割线调整比例,并且待办事项列表页也设置了最小宽度,也会影响待办事项列表(分组)的宽度
11、在修改过程中,我提出希望Cursor能够保存用户通过拖动调节的宽度值,Cursor创建了新的InterfaceSettings数据模型和ResizableHSplitView组件,前者用于持久化保存宽度设置,后者用于监听用户拖动分割线时的宽度变化,多次修改后默认宽度依然是400,虽然可以通过拖动分割线调整宽度,但调整后的宽度不会被保存,切换到其它界面再切回来,宽度依然是400,后续再修改
12、突然想看看最近Trae多次更新之后水平有没有什么提升,于是复制了一份ChatWith,改名为ChatWith for Mac,让Trae把这个iOS应用改成Mac应用,经历了修改项目文件、Info.plist、ContentView、ConversationListView、ChatWith、MessageViews等等文件,以移除iOS特有、在macOS上不适用的代码,接下来就是漫长的构建失败-查找原因-修改-继续构建失败-清理缓存-继续构建失败的过程,在这一过程中遇到了6次“模型思考次数已达上限”的提示,即使经历了如此漫长的修改,仍然构建失败,没想到Trae的Auto模式还是这么难用,第七次提示模型思考次数已达上限之后终于还是没耐心了
13、由Cursor接手继续修改,指令“这是一个由iOS应用改成的macOS应用,但在修改过程中反复出现构建错误,看一下原因”,Cursor在构建一次之后直接定位了问题所在,于是创建了任务列表来修复错误,只用了几分钟就构建成功,为什么Trae连快速定位问题都做不到呢?
14、而且Trae在修改过程中,还在项目文件夹里创建了很多个扩展名为.o的文件,Cursor表示这是编译过程中的中间产物,包含机器码,但通常应该在DerivedData目录下,而不是在源代码目录,于是让Cursor直接删掉了这些文件
15、然后让Cursor评估是否还需要原本iOS应用的启动画面文件SplashView,macOS应用通常直接显示主界面,不需要启动画面,删除此文件后Cursor同步从项目文件中移除了SplashView的引用
16、测试发现应用可以打开,但在Dock栏没有图标,且打开的应用没有直接出现在所有窗口最前,让Cursor修改之后解决了应用未显示在所有窗口最前的问题,但应用的图标不是macOS应用默认的图标,接下来让Cursor排查目前未被使用的文件,包括了由Trae创建的测试文件TestFile.swift,以及Package.swift(Swift Package Manager文件,但项目使用的Xcode项目,又是一个Trae的迷之操作),果断删掉了这两个文件,然后在Xcode中重新打开项目所在文件夹,图标问题解决了
17、接下来可以测试和完善功能了,首先就是设置界面和AI对话界面弹窗太小的问题,完全看不到其中的内容(可能macOS上不太适合这种弹窗sheet的交互方式吧),Cursor同步修改了对话列表界面的弹窗、AI对话界面的模型选择器、设置界面的模型编辑弹窗、收藏界面的弹窗,但修改效果不佳
18、发现Cursor在最近更新后,修改过程中会标出哪个操作使用了用户的习惯或规则
19、接下来,优先把应用的数据存储方式由UserDefaults改成User Defaults和Core Data混用

DevLog:2025年8月4日

1、今天开始优化ChatWith,比如流式输出、Markdown渲染、深色模式等功能同样也可以加到ChatWith里,另外尝试一下增加多模型设置和切换功能
2、测试下看Cursor能否看懂这种指令“参考NoteWith,完善一下ChatWith在与AI对话时的流式输出和Markdown渲染效果”毕竟上次使用时刚刚用它完善了NoteWith的流式输出和Markdown渲染效果,但看样子Cursor无法在修改一个项目时参考另一个项目的代码
3、在修正“新的实例没有加载已保存的大模型相关配置”这一问题之后,测试流式输出和Markdown渲染的效果,发现还有一些可优化的地方,比如:1.我添加了支持深度思考的模型,但没有看到思考过程,需要同样以流式输出显示思考的过程,并且在样式上要和回答的内容有所区别,且可以将思考过程折叠和展开 2.回答的内容在流式输出时好像会居中显示,也不符合日常的使用习惯 3.正在流式输出时,回答内容的上方有一个灰色的圆形,那是啥?
4、继续修正测试时发现的小问题,比如:1.为什么思考的过程和回答内容都显示不全?2.Markdown渲染效果也有问题,比如同时使用多个Markdown语法时会混合显示部分渲染效果和语法标记,可否把几种比较常见的Markdown语法混用情况写到MarkdownRenderer里?3.应该优先显示思考过程,再显示回答内容,现在会先显示一部分回答内容,然后又弹出了思考内容
5、继续修正测试时发现的小问题,比如:1.在回答过程中会出现上下两部分同时显示的问题,到底哪个是思考过程?2.回答完毕后只剩一个回答结果,但回答过程中内容显示错乱,而且回答过程中无法上下滑动查看回答内容,3.“收藏”页面需要改成列表,以列表形式,显示每条收藏的内容的前两行,并且点击打开后可查看经Markdown渲染的内容
6、继续修正测试时发现的小问题,比如:1.我需要按照这个顺序:先流式输出思考过程,思考完成后,思考内容自动折叠,之后流式输出回答内容。2.目前这版的思考过程和回答内容无法区分,且在对话界面会同时显示两块内容,不知道哪个是思考过程哪个是回答内容,且应用会卡死
7、多次调整之后发现仍然无法搞定思考过程流式输出的需求,好在回答内容可以正常流式输出了,然后让Cursor去掉对话界面顶部的“已加载全部消息”提示,并且收藏列表页顶部添加一条和对话页顶部一样的搜索栏,并且收藏列表的样式、间距等和对话列表保持一致,让界面更统一一些
8、边添加功能边测试真的太重要了,之前用Trae编写ChatWith并且让Cursor做了些优化之后,一直没有实际测试,今天才发现有这么多的细节问题需要调整
9、接下来在设置中增加深色模式切换功能,让用户可以在浅色、深色、跟随系统三个选项间切换,然后增加多模型设置和切换功能,比如可以在设置中添加新模型,可以给不同的模型添加备注,在对话界面可以自行切换模型(显示模型的备注)
10、Cursor在修改过程中出现了单个对话内容太长的提示,可能是因为我在上次修改的基础上继续进行对话,导致触及了单个对话的内容长度限制,于是开启了一个新的对话,好在出现这一提示之前已经构建成功了
11、接下来优化设置界面添加模型、编辑模型的逻辑,在设置界面中点击“添加新模型”时,直接打开添加新模型页面,内容和编辑模型界面一致,然后设置界面的模型名字和备注名字换一下顺序,突出备注名,弱化模型名,之后再根据测试情况继续优化编辑模型的操作方式,以及外观选项的显示效果和位置,模型管理放在上面,外观设置往下挪
12、反复测试并让Cursor优化设置、模型添加/编辑、切换的功能,出现了切换外观不立即全局生效,首次打开编辑模型界面时内容为空的问题,于是让Cursor添加多处调试信息以帮助定位错误,结合调试信息,Cursor解决了首次打开编辑模型界面内容为空的问题,但外观切换不能立即全局生效的问题还存在
13、Cursor解释说SettingsView在sheet内部,可能时因为外观的变动未能正确传递到sheet内部的视图,于是让Cursor将SettingsView拆分成独立的文件,但还是没能解决外观变动不立即全局生效的问题,再次让Cursor检查后快速修正,看来可能将SettingsView拆分成独立文件后的确提升了应用的可维护性,检查和修正问题变得简单些了
14、到今天为止,尝试使用AI(按使用频率排序Cursor>Trae>Lingma)开发应用已经有一个月了,简单总结下:
1.初期构思应用时,需求尽量简单一些,提升首次编写的成功率
2.找到一个心目中的样本,参考它的功能构思自己应用的功能,或者结合它的不足,让Cursor在自己的应用中有针对性的解决
3.后续增加功能时,每增加一个功能就在Cursor中构建,并且在模拟器中测试一下,看是否有明显问题,修正问题之后再增加新功能,不要妄图一次增加太多功能
4.遇到问题,可以让Cursor在代码中添加调试信息,结合调试信息和实测表现,Cursor可以更快地解决问题
5.关于数据持久化方案,零基础开发不要轻易尝试Core Data,UserDefaults对于一个刚刚开发的应用也已经足够了,不可能一步到位,等对Swift足够熟悉之后,再尝试Core Data
6.开发过程中不要频繁切换工具,也不要频繁切换模型,其实Cursor的Auto模式就已经够用了,切换模型可能会导致在修改某个功能的同时,其它功能也被修改
7.可以在开发过程中让Cursor记住你的某些使用习惯,比如默认用哪个型号的模拟器,在修改后先行构建测试,检查有没有语法和编译问题等等
8.如果卡在某个功能上太长时间无法解决,可以开启一个新会话,再让Cursor重新检查问题出在哪儿,或者先妥协一下,缩减一些功能
15、仍然不确定目前ChatWith,以及NoteWith是否能正常展现支持深度思考的模型的思考过程,留给明天吧,今天就到这儿了

DevLog:2025年7月28日

1、上周经历了Trae、Lingma和Cursor的多轮修改之后,DoitWith原本已经具备的删除Todo和回收站功能暂时消失了,但RecycleBinView文件还在,决定让Cursor试一下恢复这个功能
2、但在模拟器中测试目前的DoitWith时,发现无法创建Todo,创建时Debug信息会提示:
UIKeyboardLayoutStar implements focusItemsInRect: – caching for linear focus movement is limited as long as this view is on screen.
Error: this application, or a library it uses, has passed an invalid numeric value (NaN, or not-a-number) to CoreGraphics API and this value is being ignored. Please fix this problem.
If you want to see the backtrace, please set CG_NUMERICS_SHOW_BACKTRACE environmental variable.
且应用会卡死,直接把这些错误信息给到Cursor,Cursor在修改TodoData.swfit、TodayView.swift、AddTodoView.swift之后,虽然可以构建成功,但又卡在了启动界面,不进入TodayView界面
3、在排查问题的过程中,Cursor在多个文件里添加了调试信息,以便于定位问题,后续可以把这些DEBUG信息给到Cursor,更有针对性的解决问题
4、多次修改之后仍然会卡在启动界面,决定暂时让Cursor简化当前的应用:“不需要Today界面了,进入应用后直接显示Todo界面,底部也不需要在Today和Todo之间切换,先看下都有哪些文件和代码可以简化”,Cursor征求我的同意后删除了TodayView.swift、MainTabView.swift,并对多个文件进行简化,在我的要求下保留了SplashView启动界面和RecycleBinView回收站,Cursor还顺便在设置中添加了回收站功能,简化之后的应用经Xcode模拟器测试,可以正常启动,且可以正常创建Todo
5、但是相比之前我的需求,缺少了长按菜单(删除Todo、修改截止日期、修改分组等)、Todo页面视图也过于简单,甚至看不到Todo条目的截止时间,但是相比之前多了左上角的“Edit”按钮,点击后可以对Todo条目进行拖动排序,后续调整和增加功能时,还是要遵循“小步快跑”的原则,不要一次调整或增加太多功能,这样出现问题后也比较容易排查
6、询问Cursor当前的文件中是否有长按Todo弹出的菜单相关代码、给Todo条目分组的代码,前者已经没有了,后者还存在,但功能未启用,决定先让Cursor完善一下Todo条目的显示:目前Todo列表中仅显示Todo标题,还需要显示描述(Description)、截止日期(Due Date)、重复频率(Repeat)信息,并且适当拉高Todo条目的显示高度,以容纳这些信息,Cursor很快修改完成,并且优化了显示效果
7、重复频率目前有Daily、Weekly、Monthly,分别对应日、周、月,需要增加一个Yearly,即每年重复提醒一次,继续让Cursor添加此功能,很快添加完成
8、感觉现在每一条Todo显示的高度有些太高了,需要稍微减小一些条目高度,可以适当缩短每个Todo的三行内容之间、每两条Todo之间的垂直间距,Cursor给出了修改前后的对比:
调整前:条目间垂直间距:8pt、内容间垂直间距:6pt、图标顶部间距:2pt
调整后:条目间垂直间距:5pt、内容间垂直间距:3pt、图标顶部间距:1pt
9、接下来修正一个问题:点击右上角“+”时,每条Todo的右侧会出现删除按钮,需要调整成点击左上角的”Edit”时,每条Todo的右侧会出现拖动调整顺序按钮(已有,且功能正常)和删除按钮,点击删除按钮可删除本条Todo,点击右上角“+”时,每条Todo的右侧不要再出现删除按钮
10、在修正这些问题之后,继续让Cursor修正删除Todo时卡死、删除的Todo不显示在回收站里,回收站里的Todo点“恢复”之后,不会显示在 Todo界面等问题,顺便解决数据结构冗余的问题(同时存在Todo和TodoItem两个结构体),Cursor在代码中添加了很多调试信息,方便定位问题,结合调试信息和Xcode代码窗口的错误提示,Cursor修正了这一问题,今天就到这儿了

DevLog:2025年7月25日

1、Trae今天早上竟然修正了昨天的无限循环的错误问题,可以构建,并在Trae的模拟器中打开应用了,但经测试发现,Today页面的头部缺失,只显示了截止日期为当天的Todo,而且也缺失右上方的添加和设置按钮,继续让Trae修正
2、不知道为啥用Trae修改应用时,既会修改我要求的地方,又会自己改一些我没有要求的地方,比如DoitWith中条目的样式、底部Tab的底色、底部两个Tab的名字(之前是英文Today和Todo,现在被改成了今天、待办),难道是我中途切换了模型导致的?
3、这两天Trae还出现了一个问题,就是会判定某个文件存在重复(但实际上并没有重复文件),然后删掉这个文件,再创建一个新的文件,但命名变成了全小写,比如maintabview.swift,之后再表示之前判断错了,并没有重复文件,这是在折腾啥?
3、AI IDE貌似存在一个通用的问题:初期能够很快实现简单的需求,随着后续功能增加,出问题的概率就会越来越大,近期从UserDefaults切换至Core Data时必出问题
4、下载了一个新的AI IDE,阿里的通义灵码,反正DoitWith也已经被Trae中的多个模型(Doubao-Seed-1.6、Kimi-K2、Claude Sonnet 4、Qwen-3-Coder)修改的面目全非了,准备试试,内置了Qwen-3-Coder、Qwen-3-Thinking、Qwen-2.5-max,可以使用Auto模式,也可以手动切换
5、先询问了Lingma对当前DoitWith的体验和优化和功能增强的建议,决定先让Lingma为当前应用增加Trae没能完成的重复任务功能:
我需要增加这个功能:支持为每个Todo设置“重复”,在创建Todo/修改Todo截止时间时,可以设置/修改重复频率,可选“每天、每周、每月、每三个月、每年”五种重复频率
6、Lingma添加了这个功能,涉及TodoData、TodoView、TodayView三个文件,并且要求它检查了,不存在语法错误,但是Lingma表示它无法直接构建项目,建议我在X中进行构建,甚至智能问答模式下不会主动修改文件,只会给出“应该改成什么样”的建议,要求它修改文件之后才直接对这三个文件做了修改
7、在处理一些警告时,再次出现了只给建议和示例,不直接修改文件的问题,再次要求后,在Xcode中构建仍然提示同样的问题,试试看将“智能问答”模式切换为“文件编辑”模式,但是使用过程中Lingma变得非常卡,点击“停止”后甚至卡住不动了,不完全退出后重新打开项目,历史记录显示已完成修改,Lingma IDE技术人员建议我用智能体模式,可以给出建议并修改文件,但是智能体模式同样无法直接构建项目
8、再次切换回Cursor,希望能够解决Trae和Lingma一直没能解决的频繁出现的编译错误,但提示免费额度已经用完了,充了一个月的Pro,支付宝付款144.11,之后Cursor开始修复问题并进行构建测试,很快就修复完成,构建成功,过程中提示解决了MainTabView的问题、数据结构不一致的问题、缺失的属性和方法问题、枚举类型问题、类型不匹配问题、组件引用问题、语法错误,问题着实有点多,可能都是之前频繁切换IDE和模型的后遗症,现在已经可以构建成功,然后又遇到了之前一直没能解决的卡在启动界面的问题
9、在“移除Today界面长按Todo弹出菜单,只可以点击Todo条目前的圆形按钮以完成Todo”之后,终于解决了应用卡在启动界面的问题,看来可能是Today界面的功能太过复杂导致启动时被卡住
10、今天的最后一步操作是:把界面右下角的设置按钮移动到Todo界面右上角,并且在设置中增加Todo条目统计功能,分为“待完成Todo”和“已完成Todo”两条显示,每次换用不用的IDE或模型,都会导致需求之外的改动,以后尽量只用一个Cursor,少用Trae和Lingma

DevLog:2025年7月24日

1、暂时没能找到Trae的官方交流群,官网引导到了稀土掘金的Trae用户交流圈,已注册稀土掘金并加入了交流圈,并且发帖询问Xcode模拟器测试时卡在启动页的问题
2、继续让Trae提供功能增强和优化的建议,基于Kimi-K2模型的分析,Trae给出了划分优先级的功能增强和用户优化建议,我只选了这两项:
1.重复任务:支持设置每周、每月、每三个月、每年重复任务,可以在创建Todo/修改Todo截止时间时进行设置/修改
2.Todo界面右上角添加多选按钮(图形按钮),点击可以多选Todo,并进行批量完成/删除操作
3.截止日期中的月份现在显示为英文,需要改成数字+中文,如“July”需改成“7月”
3、发现在切换模型为Kimi-K2之后,Trae不会自动检查语法错误了,也不会自动进行构建测试了,将模型切换为自动后,思考和修改过程又开始出现英文,明确要求了下以后不要用英文输出,但之后还是有出现用英文回答的时候,特别是复制Xcode的报错信息给Trae之后
4、不知道是不是Trae将我上面的第二条需求理解错了,修改了AppIcon,导致后续频繁出现编译错误,而且Trae在运行一段时间之后会提示“模型思考次数已达上线,请输入继续后获得更多结果”,这时如果使用的是带有深度思考能力的模型(比如Doubao-Seed-1.6),可能操作就会被打断,忘记了前面已经检查/修改到了哪个文件的哪一部分,手动选择其它不带有深度思考能力的模型就不会有这种“因中断而忘记进度”的问题出现
5、在使用AI编程的过程中还是尽量不切换模型比较好,切换模型之后Trae需要一些时间来熟悉整个项目,对之前出现的错误的理解可能也会有问题,而且使用Kimi-K2模型时,无法自动进行构建测试,切换到Qwen-3-Coder模型之后就可以自动进行构建测试了
6、貌似在今天的修改过程中,卡在了“重复任务”这条需求上,然后尝试让Trae去掉这个功能及相关代码,还在不断修复编译错误等问题

DevLog:2025年7月23日

1、今天没有让Cursor或者Trae优化应用,询问AI了解了Cursor和Trae的区别,这样看来可能Trae更适合我,免费,模型随意切换,开发流程自动化,对新手更友好
Trae与Cursor作为AI编程工具的代表,在定位、功能及用户体验等方面各有优劣,以下从多维度对比分析二者的优势与不足:
一、Trae的优势
本土化体验突出:专为中文开发者设计,提供全中文界面、中文代码注释及语义优化,支持直接通过中文自然语言描述需求(如“实现带登录功能的网页”)生成完整代码框架,更符合国内开发习惯。
免费策略与企业支持:完全免费使用,集成Claude 3.5、GPT-4o等模型(国际版)或Doubao-1.5-pro、DeepSeek系列模型(国内版),且支持私有化部署及企业级数据隔离,降低个人及企业使用成本。
开发流程自动化:通过Builder模式实现“对话式开发”,简化项目设置、文件创建及初始代码编写,支持实时预览开发成果;同时自动修复环境错误(如缺失依赖),对新手更友好,降低编程门槛。
二、Trae的不足
模型能力与多样性受限:国内版主要依赖Doubao-1.5-pro、DeepSeek系列模型,在复杂业务逻辑推理、代码生成质量及准确性上弱于Cursor的Claude、GPT系列模型;模型数量较少(国际版受政策限制不可用)。
复杂任务处理能力较弱:在复杂代码生成(如数字时钟、俄罗斯方块)、需求理解及优化上表现不足,生成代码可能存在功能缺失或运行稳定性问题(如闪退、报错)。
三、Cursor的优势
模型能力与多样性领先:支持Claude 3.5/3.7、GPT-4/4.5等国际顶尖模型,代码生成质量、逻辑推理及复杂任务(如跨文件开发、复杂项目上下文感知)处理能力更优。
生态与兼容性强:基于VS Code重构,保留其插件生态及跨平台能力,支持多语言(Python、Go等)和复杂项目开发,适合成熟开发者。
功能全面性与准确性:在代码完成质量(如环形进度条、数字时钟)、逻辑完整性及纠错优化(如修复猜拳游戏代码并优化)上表现更优,agent模式下对项目整体把控更精准。
四、Cursor的不足
使用门槛高:国内访问需技术手段(如网络工具),Pro版需付费(40美元/月),增加个人及企业使用成本。
中文支持不足:界面以英文为主,中文理解偶发歧义,本土化体验弱于TRAE。
新手友好度低:错误提示需手动排查,依赖插件组合完成开发流程,对零基础用户不够友好。
总结:Trae以本土化、免费及自动化开发为核心优势,适合快速迭代的中文项目及新手开发者;Cursor凭借顶尖模型与生态能力在复杂工程中更具优势,但存在访问及成本门槛。两者可根据开发者需求(如语言偏好、项目复杂度、成本限制)选择使用。
2、了解到阿里和腾讯也有类似产品,阿里通义灵码,腾讯CodeBuddy

DevLog:2025年7月22日

1、继续修改DoitWith,尝试让Trae完成编辑截止日期的功能:
完善添加和编辑截止日期的功能,在创建Todo时默认以当天为截止日期,也可自行选择截止日期,精确到天,长按每一条Todo可编辑截止日期,同样精确到天
2、Trae在修改过程中会反复验证语法是否正确,这一步应该可以提升在Xcode中构建成功的概率,减少因语法错误导致构建失败,Trae已经按上述要求添加了设置和编辑截止日期的功能,Xcode模拟器测试也已成功
3、接下来完善分组相关功能,比如点Todo界面右上角加号可以添加分组(目前已支持),在添加Todo时可以选择分组,默认放到用户创建的第一个分组里,长按每条Todo可编辑所属分组
4、Trae完成了上述需求,但应用存在一个问题,目前在创建Todo时,如果没有分组,应用中会提示请先创建分组,但点击无法创建分组,需要修改成这样:应用内预置“工作”和“生活”两个分组,在创建Todo时默认位于“工作”分组,且可以点击切换到其它分组(包含用户自行创建的分组)
5、同时给Trae提了另一个要求:以后除非我另做要求,都统一用iPhone 16模拟器来构建,但不在模拟器中进行测试,我自己会去Xcode中测试,但Trae貌似没有理会这个要求,也可能理解成了这是仅对上一条需求提的要求
6、发现Trae在构建成功后不会进行下一步,好像会卡在构建这步,即使底部的“终端”中已提示BUILD SUCCEEDED,当然可以选择“跳过”,没有任何影响
7、接下来完善TodayView,需在该界面显示截止日期为当天的Todo,可勾选完成,不需要其它长按菜单,如果没有符合要求的Todo,则该界面显示“今天没有待办事项 享受轻松的一天吧!”多次修改后未能完成,后来回想起之前Cursor在修改Today界面时,在 MainTabView.swift中,Today标签页显示的不是TodayView.swift组件,而是一个静态的“Today”文本,让Trae修改之后已经基本满足需求
8、下一步,让Trae添加Todo的删除和恢复机制,删除后进入回收站,可在设置界面进入回收站并恢复已删除的Todo,结合应用当前的功能写一个README文件
9、在Xcode中测试应用时再次出现了卡在启动界面,不进入Today界面的情况,但在Trae中进行测试时就正常,按指导清理了Xcode和模拟器缓存,但无效,之后暂时先在Trae的模拟器中进行测试
10、用Trae修正了在Today界面和Todo界面创建Todo和分组时,两个界面的数据同步问题,在其中任何一个界面创建Todo和分组时,都会同步显示在另一个界面
11、到现在已经把我在OpenRouter平台充的钱用完了,基本都是这两天在Trae中使用Claude Sonnet 4消耗的,这消耗的也太快了,当然Claude Sonnet 4的API价格比较贵也是原因之一,OpenRouter上的Claude Sonnet 4的价格是百万输入3美元,百万输出15美元,作为对比,DeepSeek-R1 0528的价格是百万输入和输出均为0.272美元
12、切换Trae的模型为Kimi-K2,先让它给应用增加回收站功能,可以集中查看已经删除的Todo条目,并且在右侧设置恢复按钮,可以恢复到这条Todo被删除时所在的分组中,Kimi-K2的表现好像还可以
13、决定让Kimi-K2来检查一下当前应用是否会在启动时卡在启动页,不进入Today界面,在对代码进行多次优化,比如优化数据加载逻辑,改进数据更新机制等等之后,在Xcode模拟器里测试应用仍然会卡在启动界面,但在Trae中测试时就可以正常使用,很奇怪
14、让Trae结合应用现有的功能,创建了一个README.md文件,放在应用文件的根目录里,今天到此结束

DevLog:2025年7月21日

1、继续让Cursor修正DoitWith卡在启动页的问题,结合昨天和今天修改的内容,猜测可能是因为Today页面存在问题导致卡在启动页,决定先让Cursor进一步简化应用功能试下,先去掉Today界面及相关代码
2、果然在去掉Today界面及相关代码后可以正常进入应用,并直接显示Todo页内容,之后让Cursor逐步将Today界面及功能加回来,比如先恢复Today界面,但不需要什么功能,只为测试应用能否正常打开,经测试应用确实可以正常打开,看来问题出在TodayView的具体实现上
3、逐步恢复Today界面和功能,先给这页添加标题“Today”和右上角的“设置”按钮,位置与Todo页的标题和设置按钮位置一致,顺便把启动页的副标题改成“Manage all you need to do.”
4、使用Xcode模拟器测试发现上述需求已达成,接下来继续恢复功能:
在Todo列表中点击右上角“+”,添加新Todo时,无法选择截止日期,只能添加标题,需要有可选择日期的窗口,默认选择今天,也可以手动选择之后的日期
5、Curso在实现上述需求的过程中又重复出现Ambiguous use of ‘toolbar(content:)’的问题,感觉又陷入了新的循环,决定让Cursor先去掉所有的选择日期、修改日期相关功能
6、发现Cursor在Pro试用到期之后,更多的是给到修改建议,而非之前的主动修改,在修改一个文件时,也会一部分一部分的修改,不会一次修改完整个文件,可能的确是在使用上有些限制了
7、让Trae对当前的项目进行了检查,Trae修正了目前存在的编译错误,目前已经可以正常打开,Trae还给出了如下建议,第一条是因为Cursor还没能完全去掉编辑截止日期相关的功能吗?
1.功能完善 :完成编辑截止日期功能的具体实现
2.UI优化 :考虑使用更现代的SwiftUI设计模式
3.数据模型 :考虑迁移到Core Data以获得更好的数据管理

DevLog:2025年7月19日

1、Cursor的Pro试用到期,但之前DoitWith卡在启动页的问题仍未解决,转战Trae,先让Trae熟悉一下这个由Cursor创建的项目,然后让Trae检查卡在启动页面的原因,在检查并修正它发现的一些问题之后,结论仍然是存在重复的文件,它需要删除这些手动生成的Core Data文件,先拒绝了,耗时半小时,并未解决问题,且出现了两次“模型思考次数已达上限,输入“继续”后获得更多结果”
2、对Trae有些失望,Trae更新了2.0版本,继续让它操作之后仍然在不断尝试和重复之前进行过的的一些修改,不仅没有解决问题,甚至还导致使用Xcode查看项目文件时,Xcode频繁崩溃,参照Cursor给到的方法多次修正后仍然会闪退
3、决定让Cursor简化整个项目,将备忘录相关功能移除,数据存储方案也不再使用较为复杂的Core Data,这样也就不再需要富文本编辑器等功能,应用功能和文件结构都大幅简化,变成一个纯Todo类应用,可能一开始给的需求就太复杂了,简单一些会更少出错,之后再随着使用和对代码的熟悉程度的提升,丰富应用的功能
4、Cursor移除了NoteView及相关文件,删除了所有Core Data相关的实体、属性、初始化、模型文件,删除了Persistence.swift等持久化相关文件,MainTabView只保留Today和Todo两个Tab,之后对TodoView及其相关子视图进行修改,并提供UserDefaults(适合简单数据)和文件存储(适合结构化数据)两种本地存储方式,此处选择用UserDefaults
5、修改完成之后手动删除了一些重复文件,Xcode提示构建成功,且启动了模拟器,但不会自动打开App,也没有任何的错误提示,之后手动重建了项目,解决之前文件结构上的问题,但之后又多次让Cursor修正因之前使用Core Data,后来改用UserDefaults遗留的问题
6、偶然发现同一个问题在Cursor多次修改后仍然重复出错,不能正常构建,但在Xcode中参考Xcode的建议(建议代码、Fix)可以快速修正且完成构建,Cursor好像有时会陷入到一个循环里,反复修改,每次都保证说这次100%能够成功构建,100%可以解决问题,但就是解决不了

DevLog:2025年7月15日

1、结合Cursor昨天给的建议,对NoteWith做一些功能和性能方面的优化,给Cursor的指令如下:
结合你上面的建议和我的需求,对当前版本做如下优化:
1.备忘录本身的功能优化:增加更多格式设置(选中文字后底部弹出格式设置按钮,点击即可应用格式)、备忘录详情页底部增加常驻的字数统计功能,可通过iOS系统分享面板分享备忘录至其它应用
2.备忘录和AI会话列表页采用分页加载或懒加载,以优化性能
3.采用本地缓存机制Core Data,并将数据存储操作放到后台线程
4.完善网络、存储等异常场景的错误处理,并给予用户友好提示
5.设置界面填写大模型API地址时,无需填写/chat/completions,防止造成重复路径
2、这次耗费的时间比较长,可能是由于需求数量较多,且中途Cursor为应用添加了旧数据迁移机制,但我反馈不需要改机制,因为应用还未上线,之后Cursor有一处频繁出现的错误时Xcode工程结构问题,无法通过代码自动修复,需要在Xcode中手动操作
3、但我这时并未按Cursor的提示手动操作,一直让Cursor帮我处理,多次让Cursor处理并夹杂一些不知道是否正确的手动操作之后,错误越积越多,已达20条,在Xcode中导出错误提示后复制给Cursor,分析原因可能是:
1.自动生成的 NSManagedObject 子类文件重复
你很可能有两份同名的 Core Data 实体类文件,比如:
一份在 Xcode 自动生成的(通常在 .xcdatamodeld 旁边的 “Generated” 文件夹或你指定的目录)
另一份是你之前手写的,或者你把自动生成的文件又拖进了项目,导致重复引用
2.文件被多次添加到 Target
有时候同一个文件被多次添加到 Target(比如拖进项目时勾选了 Copy if needed),也会导致重复编译。
4、Cursor给出的解决办法是,删除所有手写的NSmanagedObject子类,在Finder和Xcode中都检查并删除,只保留自动生成的文件,检查Xcode工程文件引用,删掉多余的文件,完成这两步之后,错误减少至11条。
5、实际操作中我好像把手写的和自动生成的文件搞混了,于是都删掉,再重新生成NSmanagedObject子类
6、之后还是反复出现“Invalid redeclaration”错误,Cursor提示我可能是有重复的文件,或者把同样的文件在Compile Sources列表中添加了两次,但我多次检查并没有重复文件,也没有重复添加,不停的让我检查.xcdatamodeld的Codegen设置,要求每个实体的Codegen设为Manual/None,删除DerivedData,重新打开Xcode,Clean Build Folder,检查Compile Sources,确认每个实体相关的Swift文件只出现一次
7、觉得造成今天这种错误反复出现的原因,可能是我要求切换存储模式为Core Data
8、将目前的项目文件给到Trae,使用新的Doubao-Seed-1.6模型,但直接让Trae检查项目时没有检查出当前的问题,提供错误截图之后,才对重复声明进行修正,这次貌似有点作用,错误消失了一部分,继续让Trae来修正试试,这时思考过程突然变成了英文(可能是公司网络状况不好?但现在大家都下班了,应该不至于啊)
9、Trae修改之后,又跳出来更多错误,没能帮我解决问题
10、怀疑可能是Cursor在处理我今天早上的第三条需求时,添加了数据迁移机制导致的这些问题,于是问Cursor:有没有可能是数据迁移机制导致的今天这些问题?去掉旧数据迁移机制,直接让应用以Core Data来存储数据,是否能解决?Cursor给出了相当于是肯定的答复:去掉旧的数据迁移机制,只用 Core Data 存储数据,确实能解决你遇到的大部分“重复声明”“编译冲突”等问题。只要保证项目里只有一套 Core Data 实体类和数据访问逻辑,相关配置正确,问题基本都能解决。
11、让Cursor去掉了旧的数据迁移机制,只用Core Data存储数据,经过多次且涉及多个文件的修正之后提示构建成功,看来今天这些问题就是由于Cursor在修改存储模式时添加了数据迁移机制导致的
12、接下来优化细节并处理警告,AI对话列表中没有对话时,将“没有找到匹配的AI对话”修改为“还没有AI对话”,将备忘录列表页的“创建第一个备忘录”改成“创建备忘录”,并且处理一下六处警告:/Users/jinlei.wu/Documents/GitHub/NoteWith/NoteWith/Services/CoreDataManager.swift:56:49 Conditional cast from ‘NSManagedObjectID’ to ‘NSManagedObjectID’ always succeeds
13、Cursor提示:所有objectID as? NSManagedObjectID的无意义强转已去除,直接使用note.objectID或session.objectID,这样可以彻底消除你提到的“Conditional cast from ‘NSManagedObjectID’ to ‘NSManagedObjectID’ always succeeds”警告。
14、基本全部搞定了今天一开始的需求,后续在模拟器中测试一下实际使用的体验,进一步优化