我在我的开源项目上正式使用了一下Cursor Composer，这是一个相对来说中型的客户端项目，用这个项目来做测试有两个目的：一是我不想测试从零开始搞个网站或者开发个小工具的场景，那在我的日常场景中占比太小了，没有参考价值；二是我的项目刚好还有很多需要做的新需求，这些需求足够清晰且难度大于单独写一个网页。

使用的需求场景是这个Issue：https://github.com/xieisabug/tea/issues/2
输入到Composer的Prompt就是Issue的描述：

当前的bang操作有：  
!s、!selected_text 获取打开快速聊天窗口之前选中的文字（暂时不太好用，需要优化）  
!sub_start([text],[length]) 从开始截取[text]文字[length]长度  
!ct、!current_time 获取当前的时间  
!cd、!current_date 获取当前的日期

计划增加：  
!sc、!screen 获取打开快速聊天窗口之前的屏幕截图  
!w([url])、!web([url]) 获取对应[url]的网页  
!wm([url])、!web_to_markdown([url]) 获取对应[url]的网页并且转换为markdown

在 快速聊天窗口 或者 完整聊天窗口的新对话界面 中展示部分bang的预览内容  
在输入框中敲击!时出现bang列表用于选择

评价

工程能力部分

能够在我仅给出需求的情况下，准确的找到了之前编写bang的rust代码文件，属于加分项。但它并没有对我的前端文件进行更改（rust和前端都在这一个项目里），因为我的描述其实明确提到了需要修改界面。
并且它没有帮我创建对应的测试用例来检测该bang的实现，我是有专门针对bang的测试文件的，如果能力强一点肯定是能发现需要编写测试用例的，不过在我要求创建测试用例的时候，它还是能准确的找到之前编写测试用例的文件并且完成测试用例编写。

代码完成部分

此次测试使用Sonnet3.5加持。
正确按照我之前的编写模式创建了我需要增加的6个bang命令，且实现了获取网页内容和获取网页内容并且转markdown这两个功能的内容。
但是，实现的部分功能不可用甚至报错，当然这不是Composer的问题，这是大模型的问题。但它没有将大模型出现的非前端问题解决掉，而是留在了那里。

UI UX部分

都说Composer交互是最好的，个人觉得还不是最完美的方案，对话界面和功能较为割裂，我觉得可能会有更好的展示方式来对每次对话产生的影响进行展示，比如每次修改产生的影响都和对话做一个能够对印上的交互。
并且不知道是不是我使用的bug，我过去使用的Composer记录找不到，个人觉得查看过去的Composer然后继续改还挺重要的。
不过能够直接在编辑器里选择每一项更改是否生效，这个交互还是比较爽，不过我想这个操作是否有必要，在不久的将来，肯定是无需人去干预这个交互的，而且如果有git之类的版本控制，基本的IDE都能看到修改对比的。不想修改这个不分直接撤回就行了。

总结

和我之前Cursor的评测结论差不多，干简单的事情太麻烦，干麻烦的事情干不成，未来可期。