可以使用不同的模型，让他们之间进行真正的有见解的讨论，要求能给出结论，这个结论是模型之间某种层面能达成共识，而不是为了开会而开会。 如果只是聊天开会，这样就感觉像是然后扮演不同的角色，把回答的上下文发给他，让他回复，看上去像是在在开会而已。
可以完善一下相关的提示词包括意图理解相关的处理，更完善，比如每个角色，思维逻辑不一样，有一定的互补关系，角度又刁钻，让他们一起尝试思考，每个角色加入一些不同的思维链的逻辑，让他们围绕着主题，慢慢寻找一些共识，这样可能会更好玩一些。

@wsbqdyhm 如果你是指试用扩展的话，发你个播客激活码：O96Z-V56O-5LX2-1KJO

可以试试这个用 cursor 开发的扩展 https://rssflow.oinchain.com/

今天还没打开过，可以检查下对话是否太长了，这个对话上下文一多也会卡顿的，可以新开个对话窗口试试。
这个版本应该出来应该不是一两天了，没遇到这个问题。

每次执行新的任务，都 @codebase 一下，起码让他熟悉一下当前项目，即使啥都没有，它也得知道目录是怎样的。如果没有执行创建也是很正常的，直接自己创建就好。

也可以每次都让他先给出方案，你确认方案没问题后再让 cursor 执行代码建议。它就会比较乖，每次都会先说方案，要改哪些东西，怎么改，也会问你是否要执行代码建议，你检查一下，没问题就让他创建就可以了，方案有问题就让他改方案，没有必要每次都让它给出代码建议，有时候会乱来的，你有个方案确认的步骤，起码有个上下文影响，出错机率会小一点。

@suke119 嗯，我也挺早就听说了，不过一直没用。只是看到老是在吹 cursor ，其实也挺烦的，但是又看不到这些人使用纯 cursor 搞个完整的有前后端的项目出来给大家看看，给大家打个样，老是说做了很多小工具，小脚本之类的这些简单，没啥参考价值，其实也证明不了 cursor 有多神。同时让一些没有代码基础，但是又想用实践下搞点小工具的大概有个概念，使用 cursor ，可以完成复杂度能到到什么程度的项目，如果你的复杂度在我这个之下，完全是可以满足的，可以大胆的付出行动，赶紧实践做出来，大概是这么个意思。

@Zzzz77 这东西限于篇幅也说不了太细。你告诉 cursor 我需要验证功能是否符合需求，他就会给出一些解决方案了，按照他的建议执行就行了，他会在关键节点加上日志，看看日志数据，再结合界面上点击点击，就差不多了验证完了。其实如果你还想更细验证也可以的，你让他输出某个功能完整的调用链路，要求说明清楚每个方法的作用和调用顺序，包括数据流程。 他立马就能输出出来了。

@zhady009 扩展有简单有复杂的，我这个相对复杂些，也是想验证下实现一些相对复杂的功能，对于没有代码基础的人来说，cursor 能不能胜任，算是一个验证测试吧。

@aikilan 哈哈，的确有点这个意思。好就好在 cursor 写的代码，提示词里都要求写注释，看看注释就知道大概的逻辑了（其实他的逻辑本来就是根据我的需求来实现的，看符不符合需求就行了）。比如想更进一步提高可控性，就让 cursor 每次建议完，自己审视自己的代码，告诉他要求就行了，比如：保证逻辑清晰、高效，不能跟其它方法冲突、不能有冗余的代码。

@suke119 真不懂代码，这东西用多了就差不多，多试错就能总结出来了。每段代码 cursor 写的代码都会有注释，看注释就行，执行完，让 cursor 检查自己写的代码是否完整和健壮，不能重复和冲突，并检查是否有冗余的代码和逻辑。

@27149 windsurf 我也使用过，不过我是用来写一些 tradingview 的指标，也写了挺多个了，也觉得挺好的。我感觉没有很大的区别，可能一个是手动挡一个是自动挡吧。我个人觉得 cursor 用来实现复杂的逻辑回避 windsurf 好一些，windsurf 更不可控一些。
针对很简单问题，cursor 直接用 chat 模式就可以了，不需要使用到 composer 。就比如这个扩展中有个 TTS 功能，接的是 azure 的服务，还有一个后端的激活码验证功能，这些都是用 chat 模式来迭代的。一个很简单的问题，其实如果五六轮都没有解决，就不用再问下去了，直接新开个窗口，重新把问题说清楚，先让他熟悉代码，然后然让他分析问题，不断问它细节问题，问的差不多了，再让他开始进行代码建议，完成修复。

@zzsqwq 也是用 cursor 来实现啊，让 cursor 更新一下项目的 readme ，不满意的话，你可以在这个基础上修改一下描述。 再找一个类似的网站，让 cursor 照着结构实现一遍，文案从 readme 中抽取，然后你让设计个你喜欢的风格或主题色，最后优化下文案差不多就行了。

@layxy 提示词上增加些描述，让他加入思维链的方式思考。其实最好的方式是自己略微看得懂代码，如果逻辑很清晰的话，复杂逻辑也是可以执行的。也可以引导它一步步来实现，比如先让他输出数据流程，不要进行代码建议。
想办法让他一步步严谨的思考。
## Methodology
1.**System 2 Thinking**: 用分析严谨性来解决问题。将需求分解成更小、更易于管理的部分，并在实施之前彻底考虑每个步骤。
2.**Tree of Thoughts**: 评估多个可能的解决方案及其后果。使用结构化方法来探索不同的路径并选择最佳路径。
3.**Iterative Refinement**: 在最终确定代码之前，考虑改进、边缘情况和优化。通过潜在的增强功能进行迭代，以确保最终解决方案是健壮的。
**Process**:
1)**Deep Dive Analysis**: 从对当前任务进行彻底分析开始，考虑技术要求和限制;
2)**Planning**: 制定一个明确的计划，概述解决方案的架构结构和流程，必要时使用 <PLANNING> 标签;
3)**Implementation**: 逐步实施解决方案，确保每个部分都符合指定的最佳实践;
4)**Review and Optimize**: 对代码进行审查，寻找潜在的优化和改进领域;
5)**Finalization**: 通过确保代码满足所有要求、安全且性能良好来最终确定代码;